1. Go to https://gruntwork.io/checkout/?subscription-type=aws
2. Click "Add to Subscription" for the Reference Architecture
3. Click "Checkout"

CIS now appears in the list of requested services:

@bwhaley Could you take a look?

Looks like this currently:

Should look more like this instead:

I'm guessing it broke in this PR when .listingblock > .title was changed to an &.title inside of .listingblock { ... }.

@hngerebara Could you take a look?

NIT: It seems like these issues have a fix now. The first one has a fix shown in another issue: hashicorp/terraform#27934 and here hashicorp/terraform#26211 (comment)

Originally posted by @ina-stoyanova in #426 (comment)

Think through a bit more if we need to detail how you configure Patcher in our landing pages (either a web UI or a patcher.yml config). Might be too much detail at this stage though.

As reported in this Slack message:

We should call the HIPAA Ref Arch, "HIPAA eligible", as HIPAA compliance can only be conferred by an auditor.

As such we should do a scan of the language we're using to make sure we aren't overstating it. Since there's nothing contractual about the waitlist I don't think there's any potential legal ramifications yet, but it would be best to abide by the rules. We can probably talk about user's needs/goals in terms of compliance, just not our infrastructure itself, e.g. "Reach HIPAA compliance faster by building atop our HIPAA eligible reference architecture…"

On the HIPAA page, if you go to "Technical Details" in the nav, there are two problems:

1. The text "Reference Infrastructure" should actually be "Reference Architecture."
2. When you click the "Reference Infrastructure" link, you are taken to the wrong tab of the technical details page. The URL is https://gruntwork.io/hipaa-compliance-on-aws/technical-details#reference-infra, which looks right, but the tab that's visible is "Reference Applications" instead of "Reference Architecture."

The zig zag portion is a bit short. See this comment for ideas on a few more zigs/zags and more info to put below that.

As @ebeneliason reported:
1. The blue border around the tabs isn't showing up for some reason. But, I see the CSS for it…
2. The gray background on the code block that's shorter than the code box should ideally extend to fill the box. Maybe the background color is on the wrong element.

#456 (comment)

• Think through a bit more if we need a patcher CLI to help maintainers test their patches.
• Do we need this by Friday? If no, change the milestone to patcher-v2

NIT: left align the check-boxes, as in the home page footer.

In https://gruntwork.io/guides/foundations/how-to-configure-production-grade-aws-account-structure#configure-the-security-baseline-for-the-root-account

references to

git::[email protected]:gruntwork-io/terraform-aws-service-catalog.git//modules/account-baseline-root?ref=v0.41.4

should be

git::[email protected]:gruntwork-io/terraform-aws-service-catalog.git//modules/landingzone/account-baseline-root?ref=v0.41.4

In Step 2, “Bootstrap your app with our HIPAA-compliant templates,” the text should read “Build on top of application templates for a variety of languages and frameworks (e.g., Node.js/Express, Java/Spring, Ruby/Rails) that show you how to build HIPAA compliant and cloud-native apps, including how to do service discovery, secrets management, schema migrations, encryption, server hardening, and much more (see full list of features here).” and this link is the one that should go to the bootstrap your app page. (/bootstrap-your-app)

The FAQ on the HIPAA pricing page has a question about estimated AWS bill which references "Gruntwork Lite" and "Gruntwork Pro" (twice). These are not subscription options for HIPAA, so this doesn't make sense. Perhaps just remove this question entirely?

Per some feedback from customers, something our HIPAA landing page should mention is how we test for compliance, enforce it on an ongoing basis, and "prove" compliance through self-auditing code. In particular, we may want to call out:

1. Terratest to test basic functionality.
2. Some off-the-shelf compliance-checking solution we use to give you a green check or red "X."
3. OPA policies to enforce compliance on an on-going basis. This seems especially popular these days.

We used to have a preface before going into the table of features available now / later. I think that preface is important. Without it, it’s not clear what we’re looking at. We need to convey in a header + sentence or two that we already have most of the HIPAA stuff there, that you’re starting on a platform that’s already CIS compliant and trusted by thousands of devs, and that we’re actively working on the rest of the HIPAA requirements.

terragrunt aws-provider-patch \
  --terragrunt-override-attr region="eu-west-1" \
  --terragrunt-override-attr assume_role.role_arn=""

needs to be:

terragrunt aws-provider-patch \
  --terragrunt-override-attr 'region="eu-west-1"' \
  --terragrunt-override-attr 'assume_role.role_arn=""'

in 2019-08-12-how-to-configure-production-grade-aws-account-structure.adoc

The pricing seems a little off. See my comments in this PR for more.

From this slack message:

I don’t really want to advertise that we are partnered with someone we’re not. But perhaps we could do a little research on the partners, figure out what we would do to have a first-class integration with them, and add that to our features? For example, for Vanta, I believe you install an agent in AWS somehow that scans all your traffic for compliance. Maybe we pre-install the agent for you.

Right now, the landing page has AWS, K8S, and Terraform logos, which don't make much sense for a Patcher landing page. Replace these with something else. Perhaps the "supported tech" logos, at much smaller size each, should go in this section?

Monthly cost in this table is wrong.

Add a comparison table. The columns should be competitors and then Patcher:

• Do nothing,
• DependaBot,
• RenvoateBot,
• Snyk,
• Patcher.

Rows will be things like:

• works with all version control systems (DependaBot is GitHub only),
• supports version number bumps (yes for all of them),
• can patch breaking changing (yes only for Patcher),
• auto discovers dependencies (yes for all of them),
• can manually identify dependencies (yes only for RenovateBot and Patcher),
• can build dependency graph (yes only for Patcher? @robmorgan has more thoughts on this),
• security patching (yes for all),
• internal dependency management (yes only for Patcher?).

On the HIPAA landing page there is a "Compliance in Progress" section. It's important to make it crystal clear what the offering is, and what is or isn't available, so here's some updated text to consider:

1. Replace "Compliance in Progress" with "Gruntwork Early Access Program."
2. Replace the text below that with: "The Gruntwork Early Access Program (EAP) is the fastest way for you to achieve HIPAA compliance on AWS. Over the last 5 years, Gruntwork has helped hundreds of companies and thousands of developers go to prod on AWS, including achieving CIS Compliance, and we are now actively developing our HIPAA compliance on top of that foundation. If you join the EAP, we'll deploy a CIS Compliant pre-prod environment for you on day 1 and a HIPAA-compliant prod environment for you as soon as it's available, plus a number of other exclusive early-access benefits, including audit assistance and prioritized bug fixes. See the table below for all the HIPAA requirements you'll meet with Gruntwork today, out of the box, as well as those that are currently in progress."

s/hundreds of customers/hundreds of companies and thousands of developers/

Go into a bit more detail of how maintainers create Patches and how Patcher executes those. See show, don't tell here.

One thing to consider for this page is two views: an "end user" view and a "maintainer" view. Each view (tab?) shows the experience for that party. E.g., The End user installs a GitHub app, gets PRs with updates, reviews the code, sees tests run, and merges. The maintainer updates their code, creates a patch, tests the patch with a patcher CLI, and then creates a new release in GitHub.

Update: I flushed this idea out more below.

Redirect /hipaa-cloud-compliance/ to /hipaa-compliance-on-aws.

This page shouldn’t have the same hero section as the home page.

No CSS applied on the page. Reason - app.css is not found.
Request URL: https://gruntwork-io.github.io/assets/css/app.css
Request Method: GET
Status Code: 404

1. Under "Deposit Due Today" we render "$500" over the "Checkout" button, whereas the $500 should be on the same line as "Deposit Due Today":

2. The AWS, GCP, and Enterprise boxes are too wide for the viewport, and it's not obvious that they're selectable.

3. Grunty floats up in such a way that he blocks the content

Issues 1 and 3 are important. For issue 2, perhaps it's enough to just shrink the box width.

Put in screenshots or .gif or more useful images to show what Patcher does.

We want to revamp the walkthrough to describe the new service catalog way to deploy your infrastructure.

• Deploy a production-grade AWS account structure using Gruntwork AWS Landing Zone PR: #439
• Deploy a production-grade VPC on AWS
• Deploy a production-grade Kubernetes cluster on AWS

Check out the DependaBot page in the web archive for inspiration on how they tell their story.

The Grunty cubes to the left of the hero section of the Patcher landing page don't add much value. Perhaps replace with a .gif showing the Patcher workflow (maintainer releases new version with patch, end user gets a PR with updates)? Or tabs with a few screenshots?

The current checkout process asks for minimal identifying information from the customer:

The issue here is that we need to be crystal clear on the corporate entity with whom we have a contract. For that reason, we need to add more identifying information. In particular, this screen should make the following changes:

1. "Company name" should be updated to say "Company legal entity name" (and should be required)
2. We should add "Company legal address" (and should be required)

Note that you can make these changes by logging into our ChargeBee account.

@oredavids Can you prioritize this above all current items on your plate?

Please see PR #232 for more details.

I found a couple of bugs/errors on the "How to configure a production-grade AWS account structure" guide.
The main errors are:

A duplicate variable block added in the iam-groups and cross-account-iam-roles sections.

An error when applying any of the three wrapper modules using terragrunt Inappropriate value for attribute "allowed_account_ids": set of string required

Error traced to 'allowed_account_ids = var.aws_account_id' . This should be allowed_account_ids = [var.aws_account_id]

On mobile the table doesn't fit and create an awkward horizontal scrolling situation. I'm not sure there's a cheap solution here — we could try to add the class so it's at least contained within the page boundary, but that doesn't make it more legible; just less broken…

The supported infrastructure features table on the HIPAA reference architecture page is a confusing once you've seen the similar, but not identical table on the home page. This is my fault, as I think I suggested having a table on the reference architecture page, but seeing it now, I realize that:

1. Showing other Gruntwork subscription types here doesn't make sense, as this landing page offers no other info about those subscriptions at all.
2. The table on the homage page is more complete, and by listing the specific standard requirements, seems more official.

So, as a simple fix, could we just replace the table on the Ref Arch page with the table from the home page?

The FAQ on the pricing page has a "How does the private beta work?" question, but it looks like one copy/pasted from the Heroku page. It should be replaced with a "How does early access work" question that focuses more on:

1. What you get right away: i.e., all the CIS requirements.
2. What we're working on now: see this table for details.
3. What will happen when we're done.

Right below that, we may also want to add a "What are the benefits of early access?" question that talks about:

1. Fastest way to get HIPAA, as you get CIS as your starting point.
2. Discounted pricing.
3. Extra support.
4. Audit assistance.

List that support for other VCS tools (GitLab, etc) is coming in the future.

• Maybe ask customers, or the community support users

In Step 5, “Stay up to date automatically via Terraform pull requests,” the current screenshot is a bit hard to read. Perhaps instead, we show a screenshot of versioned releases from the terraform-aws-eks repo?. Or a screenshot from a RenovateBot PR showing the diff page with an upgrade from version X to Y?

NIT: The URL is currently https://gruntwork.io/hipaa-compliance. I wonder if for SEO purposes, https://gruntwork.io/hipaa-compliance-on-aws wouldn’t be better?

Consider adding to the pricing page a few things to make customers more comfortable, including “need help deciding,” the “no risk,” “no lock-in,” “no gruntwork” badges, and an FAQ. See the bottom of the Heroku pricing page for reference.

NIT: left align the check-boxes, as in the home page footer.

Currently it seems we have identical markup and styling applied to this section as in the home page and pricing page where it's working correctly, but perhaps because of the way we're loading it through a template the final markup is not structured properly to have the content centered while the check mark icons are all left-aligned.

The big white logos aren't particularly nice looking. See "supported languages" on this page for a possible alternative design.

Currently, we've got on the CIS compliance benchmark guide the following snippet:

=== Prepare your `infrastructure-live` repository

We've previously described exactly how to prepare your repository in the
link:https://gruntwork.io/guides/foundations/how-to-configure-production-grade-aws-account-structure/#prepare-your-infrastructure-live-repository[Gruntwork Landing Zone guide].
Follow the steps in that section to get your `infrastructure-live` repository set up for the next steps.

Action: This could/should be moved to our production-aws-grade-design guide

Consider if we should support 1-2 other VCS integrations beyond GitHub out of the gate to better support enterprises. Perhaps GitHub Enterprise is easy to support if you already have a GitHub App? Probably most popular VCS for enterprises is BitBucket. So perhaps GitHub + BitBucket are the launch VCS tools?

• Ask customers if necessary

It isn’t clear which benefits are “exclusive” to the early access customers. We may need a table that shows “early access” in one column and “after launch” in another. Then the early access column can highlight: (a) the lower pricing, (b) perhaps no up-front fee, (c) early access to the code, (d) higher support tier from Gruntwork, (e) audit assistance.