guides/compliance/how-to-achieve-cis-benchmark-compliance/

[utterances-bot]

How to achieve compliance with the CIS AWS Foundations Benchmark

Learn how to achieve and maintain compliance with each of the CIS AWS Foundations Benchmark recommendations.

https://gruntwork.io/guides/compliance/how-to-achieve-cis-benchmark-compliance/

[kylelundstedt]

Hi Team Gruntwork

I think there's a mistake in the "wrapper code" subsection. You have the user build their own infrastructure-modules repo that uses the iam-password-policy compliance module from the Gruntwork cis-compliance-aws repository. However, at the end of that subsection, you have the user "create terragrunt.hcl with the following contents":

terraform {
  # Make sure to replace <VERSION> in this URL with the latest cis-compliance-aws release
  source = "git::ssh://git@github.com/gruntwork-io/cis-compliance-aws.git//modules/iam-password-policy?ref=<VERSION>"
}

Shouldn't the terragrunt.hcl point at the user's infrastructure-modules repo, rather than directly pointing at the cis-compliance-aws repository?

terraform {
  source = "git@github.com/<YOUR_ORG>/infrastructure-modules.git//security/iam-password-policy?ref=v0.3.0"
}

[bwhaley]

Hi Kyle. Actually, it is written correctly, though perhaps a bit unclear. The idea is that Terragrunt can call the password policy terraform module in the cis-compliance-aws repo directly, with no need for the local wrapper. It's an OR operation: create either the Terraform module OR the Terragrunt configuration calling the canonical Terraform module in our repo. I've clarified the wording in gruntwork-io/gruntwork-io.github.io#270. Do you think that proposed wording makes more sense?

[kylelundstedt]

Hi Ben Thanks for the quick reply. I think I understand your intent, but your revised wording makes things more clear to me. Let me pose the issue differently - I think I’m struggling with the “CIS compliance” guide because the code examples follow a pattern that doesn’t seem consistent with the other guides (i.e., https://gruntwork.io/guides/foundations/how-to-configure-production-grade-aws-account-structure/#iam-roles-for-services <https://gruntwork.io/guides/foundations/how-to-configure-production-grade-aws-account-structure/#iam-roles-for-services>). If I follow the other guides correctly, for each concept that is being illustrated, the code examples follow a pattern of first showing a code example which builds code in a user “infrastructure-modules” repo using IaC resources and/or modules, then showing a terragrunt.hcl code example which builds a user “infrastructure-live” repo that calls the user's “infrastructure modules” repo directly. For example, in the "production grade accounts” guide, the user is supposed to "First, create a wrapper (ed - not the compliance wrapper) module called iam in your infrastructure-modules repo.” In that user’s infrastructure-modules repo, IaC resources and/or modules are referenced as sources. Then, the user is instructed to "create a terragrunt.hcl file in infrastructure-live. It should go under the file path root/_global/iam”. That terragrunt.hcl uses the user’s infrsastructure-modules repo as its source. So, if I understand correctly, the code examples alternate between code from the user’s infrastructure-modules repo and code from the user’s infrastructure-live repo. On the other hand, if I’m following your “CIS compliance” guide, I think you show code examples from a user’s infrastructure-modules repo, followed by code examples from a user’s infrastructure-live repo that do NOT use the associated user’s infrastructure-modules repo. Doesn’t that violate the pattern establish in previous guides? If your intent is to show the ability to EITHER call the underlying IaC modules in the user’s infrastructure-modules repo, OR to call the “compliance wrapper” modules directly without need for the user’s infrastructure-modules repo, I think it makes more sense to do the following for each “set” of code examples illustrating a given concept: 1. Show code example using IaC resources and/or modules included in the user’s infrastructure-modules repo, which helps make clear what’s going on and what IaC resources are being used. 2. Show the corresponding code example from the user’s infrastructure-live repo that uses the user’s infrastructure-modules repo as its source in the terragrunt.hcl file. 3. Then, show an alternate version of the user’s infrastructure-live repo that uses the “compliance wrapper” repo as its source. Make clear that use of the “compliance wrapper” repo obviates the need to build the user’s infrastructure-modules repo from step 1. Or, show both an alternate version of the user’s infrastructure-modules repo that uses the “compliance wrapper” directly AND show an alternate version of the user’s infrastructure-live repo that uses the “compliance wrapper” repo as its source I hope this rambling on makes some kind of sense, and that you can understand what’s been throwing me off. Best Kyle

…

On Mar 2, 2020, at 8:47 AM, Ben Whaley ***@***.***> wrote: Hi Kyle. Actually, it is written correctly, though perhaps a bit unclear. The idea is that Terragrunt can call the password policy terraform module in the cis-compliance-aws repo directly, with no need for the local wrapper. It's an OR operation: create either the Terraform module OR the Terragrunt configuration calling the canonical Terraform module in our repo. I've clarified the wording in gruntwork-io/gruntwork-io.github.io#270 <gruntwork-io/gruntwork-io.github.io#270>. Do you think that proposed wording makes more sense? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AAXBJ7FD7SPKHTPP2LFALTDRFPPKFA5CNFSM4K7HXXQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQBJSI#issuecomment-593499337>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXBJ7HFZKUQKDETZCQJH3LRFPPKFANCNFSM4K7HXXQQ>.

[bwhaley]

You're not rambling at all. Quite the opposite really. In fact you've made an astute observation! The guide does indeed conflict somewhat with the other guides and previously established Gruntwork practices. This is actually representative of a larger series of changes that we are making about how we approach IaC.

To briefly summarize, in the past, we have had an Infrastructure as Code Library, the repository of Terraform modules that you could wrap in your own infrastructure-modules which are in turn called from your infrastructure-live. This is the pattern you've described above.

What we're working on now is a higher level abstraction that we're calling a Service Catalog. The CIS repository is one of the first services in the catalog. The idea is that you can call our Terraform modules directly from terragrunt.hcl in your infrastructure-live repo. This is better because it's more DRY. You don't have to maintain a wrapper Terraform module that has a lot of duplicated code. You can rely directly on our upstream source. It will reduce our reference architecture from 10ks lines of code to less than 5k or so. Obviously our guides and other docs will need a lot of reworking as a result of this. And course nothing is stopping you from still having a wrapper module if you need/want one.

I'll take your suggested reorganization in to consideration. I knew that it wasn't explained perfectly, so I'll mull over just how to reorganize and make it clear.

[kylelundstedt]

Thanks for the feedback, Ben!
As an aside, I saw the recent Gruntwork Newsletter with the news about Building blocks for a Terraform-backed AWS Landing Zone. I think the "production-based accounts" guide could really benefit from standardizing along the "AWS Landing Zone"-recommended OUs and accounts. Perhaps y'all could make upgrade that guide into a Service Catalog-level abstraction for creating an Organization, OUs, and production grade accounts, using your new building blocks. It certainly would fit with the compliance focus of your CIS service catalog.

Cheers!
Kyle

[brikis98]

I think the "production-based accounts" guide could really benefit from standardizing along the "AWS Landing Zone"-recommended OUs and accounts.

That work is currently in progress 😄

[EvanGertis]

I don't really understand what this means "When the module is working and sets up AWS Config according to the prescribed configuration, you should invoke it once for each region in the account. One way to do this is to use provider aliases. For example, you could specify one provider for each region, then invoke the module for each provider" do I just need to make a provider alias for each region like the example code shows?

[bwhaley]

Hi @EvanGertis. In short, yes. You need to have a configuration recorder in each region, and the way to do that is to create a module and then call that module once for each region. Unfortunately there isn't a way to do this iteratively in a loop in Terraform because for_each does not work with providers. In our module library, we have a program to code generate a multi-region module that finds all regions and creates all the appropriate module blocks automatically.