Skip to content

Commit

Permalink
Fixes on the guide (#668)
Browse files Browse the repository at this point in the history
  • Loading branch information
marinalimeira authored Mar 14, 2023
1 parent e5b29d6 commit 83bd64f
Show file tree
Hide file tree
Showing 8 changed files with 204 additions and 26 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -32,14 +32,27 @@ Next install the AWS plugin with Steampipe:
steampipe plugin install aws
```

## 1.2 Configure Steampipe with AWS credentials
## 1.2 Configure Steampipe to analyze all regions

The file `~/.steampipe/config/aws.spc`, that is created by Steampipe, needs to be updated to analyze all regions,
by adding `regions = ["*"]`. Otherwise, multi-regions resouces, like AWS Config, IAM Access Analyzer will fail in the check:

```hcl
connection "aws" {
plugin = "aws"
# You may connect to one or more regions. If `regions` is not specified,
# Steampipe will use a single default region using the same resolution
# order as the AWS CLI:
# 1. The `AWS_DEFAULT_REGION` or `AWS_REGION` environment variable
# 2. The region specified in the active profile (`AWS_PROFILE` or default)
regions = ["*"] # <- Update this line
# ... other existing config
}
```

The [Steampipe AWS plugin](https://hub.steampipe.io/plugins/turbot/aws) supports a range of options for granting
Steampipe access to your AWS accounts.

In order for the compliance checks to work correctly, you need to:
- Configure [multi-region connections](https://hub.steampipe.io/plugins/turbot/aws#multi-region-connections) so that Steampipe can access to all the regions you are using
- Configure [multi-account connections](https://hub.steampipe.io/plugins/turbot/aws#multi-account-connections) so that Steampipe can access all the accounts you are using

## 1.3 Clone the Steampipe AWS Compliance Mod

Expand Down Expand Up @@ -74,8 +87,69 @@ aws-vault exec dev -- aws iam generate-credential-report
aws-vault exec dev -- steampipe check aws_compliance.benchmark.cis_v140
```

### In case not all checks pass

:::caution

If you have failing checks, then there are manual steps necessary to your infrastructure achieve CIS compliance.

:::

After deploying a CIS Reference Architecture, there are steps that unfortunately can't be automated. See the [Manual steps](/guides/build-it-yourself/achieve-compliance/deployment-walkthrough/manual-steps) page, with step-by-step instructions
to achieve complience.


:::note

If you Reference Architecture was deployed before February 9th 2023, there are two extra steps that need to be followed:

:::

#### Enable `ap-northeast-3` at your `multi_region_common.hcl`

Add `ap-northeast-3` to the `opt_in_regions` local variable in `multi_region_common.hcl`.

```hcl title=multi_region_common.hcl
# ----------------------------------------------------------------------------------------------------------------
# MULTIREGION CONVENIENCE LOCALS
# The following locals are used for constructing multi region provider configurations for the underlying module.
# ----------------------------------------------------------------------------------------------------------------
locals {
# Creates resources in the specified regions. The best practice is to enable multiregion modules in all enabled
# regions in your AWS account. To get the list of regions enabled in your AWS account, you can use the AWS CLI: aws
# ec2 describe-regions.
opt_in_regions = [
...
"ap-northeast-3"
]
# ... other vars omitted for brevity ...
```

There is a new region `me-central-1`, that you will need to add in the `multi_region_common.hcl` after doing the version updates.

### Enable AWS Organizations metrics filter

If the `4.15` recommendation is also failing, it's because the filter is still not created in the account. So in the
files `_envcommon/landingzone/account-baseline-app/account-baseline-app-base.hcl` and `security/_global/account-baseline/terragrunt.hcl`,
Add this a variable:

```hcl
inputs = {
# ... other variables above
cloudtrail_benchmark_alarm_enable_organizations_filters = true
}
```

Run `terragrunt apply` in each account to create the new metric filter.

If the check is still not working, the release [v0.44.1](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/releases/tag/v0.44.1)
of the CIS Service Catalog contains a fix for the filter match Steampipe's query. In the next steps you will update
the versions of CIS Service Catalog (and some other services) to the latest, so it will be fixed.

## Next steps

If you've confirmed that your live infrastructure is compliant with the CIS AWS Foundations Benchmark v1.4 then you're
ready to move to [step 2](step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md) and update your
references to the Gruntwork Infrastructure as Code Library. Otherwise, if some checks are failing you should check the [Manual steps](/guides/build-it-yourself/achieve-compliance/deployment-walkthrough/manual-steps) section, that contains extra steps to achieve CIS compliance.
references to the Gruntwork Infrastructure as Code Library.
Original file line number Diff line number Diff line change
Expand Up @@ -184,16 +184,16 @@ Access Token with `repo` and `org` scope and set the environment variable `G
export GITHUB_OAUTH_TOKEN="<YOUR_GITHUB_PAT>"
```

Next, in your terminal navigate to the directory with your CIS `infrastructure-live` code and run Patcher’s `upgrade cis` command:
Next, in your terminal navigate to the directory with your CIS `infrastructure-live` code and run Patcher’s `upgrade cis` command once on each environment (dev, prod, stage, security etc):


```bash
cd <PATH/TO/YOUR/INFRASTRUCTURE-LIVE/CODE>
cd dev
patcher upgrade cis
```

Patcher will then scan your current directory and its subdirectories, looking for the files containing Terraform or Terragrunt
dependencies.
Patcher will then scan your current directory and its subdirectories, looking for the files containing Terraform or Terragrunt dependencies.

#### Analysis of module usage

Expand Down Expand Up @@ -234,10 +234,18 @@ You must run the migration scripts. Failing to do so will result in data loss.
:::

When Patcher completes successfully it provides a list migration scripts that need to be run before proceeding.
In order to see the full path of the new scripts, run `git status`, and they will appear as a new file.


![Screenshot of Patcher's summary.](/img/guides/stay-up-to-date/cis-1.5.0/patcher-summary.png)

Example:

```bash
cd us-west-2/dev/data-stores/rds/
aws-vault exec dev -- ./01_state_mv_rds_database.sh
```

### Next Steps

:::caution
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -47,4 +47,5 @@ For Terraform, follow the migration guide in [the migration guide of the release

If you have successfully completed step 3.1 then you should now move to [step 4](step-4-verify-the-code-changes)
in order to verify the changes that have been made. We strongly recommend that you verify the changes that have been
made before executing `terraform/terragrunt apply`.
made _before_ executing `terraform/terragrunt apply`.

Original file line number Diff line number Diff line change
Expand Up @@ -106,5 +106,11 @@ When applying the changes manually, you can run `terragrunt run-all apply` insid
security, shared etc), and waiting them to successful update before applying the changes before the next one, e.g. wait
for `dev` to successfully finish before applying `prod`.

Example of using Terragrunt, after running Patcher in the `dev` folder:
```
aws-vault exec dev -- terragrunt run-all init
aws-vault exec dev -- terragrunt run-all apply
```

After the changes have been applied we recommend you complete [step 5](step-5-check-your-live-infrastructure-is-cis-v1.5-compliant)
and confirm that your infrastructure is now CIS AWS Foundations Benchmark v1.5.0 compliant.
Original file line number Diff line number Diff line change
Expand Up @@ -32,14 +32,27 @@ Next install the AWS plugin with Steampipe:
steampipe plugin install aws
```

## 1.2 Configure Steampipe with AWS credentials
## 1.2 Configure Steampipe to analyze all regions

The file `~/.steampipe/config/aws.spc`, that is created by Steampipe, needs to be updated to analyze all regions,
by adding `regions = ["*"]`. Otherwise, multi-regions resouces, like AWS Config, IAM Access Analyzer will fail in the check:

```hcl
connection "aws" {
plugin = "aws"
# You may connect to one or more regions. If `regions` is not specified,
# Steampipe will use a single default region using the same resolution
# order as the AWS CLI:
# 1. The `AWS_DEFAULT_REGION` or `AWS_REGION` environment variable
# 2. The region specified in the active profile (`AWS_PROFILE` or default)
regions = ["*"] # <- Update this line
# ... other existing config
}
```

The [Steampipe AWS plugin](https://hub.steampipe.io/plugins/turbot/aws) supports a range of options for granting
Steampipe access to your AWS accounts.

In order for the compliance checks to work correctly, you need to:
- Configure [multi-region connections](https://hub.steampipe.io/plugins/turbot/aws#multi-region-connections) so that Steampipe can access to all the regions you are using
- Configure [multi-account connections](https://hub.steampipe.io/plugins/turbot/aws#multi-account-connections) so that Steampipe can access all the accounts you are using

## 1.3 Clone the Steampipe AWS Compliance Mod

Expand Down Expand Up @@ -74,16 +87,77 @@ aws-vault exec dev -- aws iam generate-credential-report
aws-vault exec dev -- steampipe check aws_compliance.benchmark.cis_v140
```

### In case not all checks pass

:::caution

If you have failing checks, then there are manual steps necessary to your infrastructure achieve CIS compliance.

:::

After deploying a CIS Reference Architecture, there are steps that unfortunately can't be automated. See the [Manual steps](/guides/build-it-yourself/achieve-compliance/deployment-walkthrough/manual-steps) page, with step-by-step instructions
to achieve complience.


:::note

If you Reference Architecture was deployed before February 9th 2023, there are two extra steps that need to be followed:

:::

#### Enable `ap-northeast-3` at your `multi_region_common.hcl`

Add `ap-northeast-3` to the `opt_in_regions` local variable in `multi_region_common.hcl`.

```hcl title=multi_region_common.hcl
# ----------------------------------------------------------------------------------------------------------------
# MULTIREGION CONVENIENCE LOCALS
# The following locals are used for constructing multi region provider configurations for the underlying module.
# ----------------------------------------------------------------------------------------------------------------
locals {
# Creates resources in the specified regions. The best practice is to enable multiregion modules in all enabled
# regions in your AWS account. To get the list of regions enabled in your AWS account, you can use the AWS CLI: aws
# ec2 describe-regions.
opt_in_regions = [
...
"ap-northeast-3"
]
# ... other vars omitted for brevity ...
```

There is a new region `me-central-1`, that you will need to add in the `multi_region_common.hcl` after doing the version updates.

### Enable AWS Organizations metrics filter

If the `4.15` recommendation is also failing, it's because the filter is still not created in the account. So in the
files `_envcommon/landingzone/account-baseline-app/account-baseline-app-base.hcl` and `security/_global/account-baseline/terragrunt.hcl`,
Add this a variable:

```hcl
inputs = {
# ... other variables above
cloudtrail_benchmark_alarm_enable_organizations_filters = true
}
```

Run `terragrunt apply` in each account to create the new metric filter.

If the check is still not working, the release [v0.44.1](https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/releases/tag/v0.44.1)
of the CIS Service Catalog contains a fix for the filter match Steampipe's query. In the next steps you will update
the versions of CIS Service Catalog (and some other services) to the latest, so it will be fixed.

## Next steps

If you've confirmed that your live infrastructure is compliant with the CIS AWS Foundations Benchmark v1.4 then you're
ready to move to [step 2](step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md) and update your
references to the Gruntwork Infrastructure as Code Library. Otherwise, if some checks are failing you should check the [Manual steps](/guides/build-it-yourself/achieve-compliance/deployment-walkthrough/manual-steps) section, that contains extra steps to achieve CIS compliance.
references to the Gruntwork Infrastructure as Code Library.


<!-- ##DOCS-SOURCER-START
{
"sourcePlugin": "local-copier",
"hash": "62d099236900a6e8c664ee28cc061faf"
"hash": "296848a030a0676c4e7051e606f41a7e"
}
##DOCS-SOURCER-END -->
Original file line number Diff line number Diff line change
Expand Up @@ -184,16 +184,16 @@ Access Token with `repo` and `org` scope and set the environment variable `G
export GITHUB_OAUTH_TOKEN="<YOUR_GITHUB_PAT>"
```

Next, in your terminal navigate to the directory with your CIS `infrastructure-live` code and run Patcher’s `upgrade cis` command:
Next, in your terminal navigate to the directory with your CIS `infrastructure-live` code and run Patcher’s `upgrade cis` command once on each environment (dev, prod, stage, security etc):


```bash
cd <PATH/TO/YOUR/INFRASTRUCTURE-LIVE/CODE>
cd dev
patcher upgrade cis
```

Patcher will then scan your current directory and its subdirectories, looking for the files containing Terraform or Terragrunt
dependencies.
Patcher will then scan your current directory and its subdirectories, looking for the files containing Terraform or Terragrunt dependencies.

#### Analysis of module usage

Expand Down Expand Up @@ -234,10 +234,18 @@ You must run the migration scripts. Failing to do so will result in data loss.
:::

When Patcher completes successfully it provides a list migration scripts that need to be run before proceeding.
In order to see the full path of the new scripts, run `git status`, and they will appear as a new file.


![Screenshot of Patcher's summary.](/img/guides/stay-up-to-date/cis-1.5.0/patcher-summary.png)

Example:

```bash
cd us-west-2/dev/data-stores/rds/
aws-vault exec dev -- ./01_state_mv_rds_database.sh
```

### Next Steps

:::caution
Expand Down Expand Up @@ -306,6 +314,6 @@ If you have successfully completed manually updating the modules to the minimum
<!-- ##DOCS-SOURCER-START
{
"sourcePlugin": "local-copier",
"hash": "edec39c8ee33888c076155f010db3e38"
"hash": "46739fa913b27a01c8a920d59c43c5e3"
}
##DOCS-SOURCER-END -->
Original file line number Diff line number Diff line change
Expand Up @@ -47,12 +47,13 @@ For Terraform, follow the migration guide in [the migration guide of the release

If you have successfully completed step 3.1 then you should now move to [step 4](step-4-verify-the-code-changes)
in order to verify the changes that have been made. We strongly recommend that you verify the changes that have been
made before executing `terraform/terragrunt apply`.
made _before_ executing `terraform/terragrunt apply`.



<!-- ##DOCS-SOURCER-START
{
"sourcePlugin": "local-copier",
"hash": "3b2fcb8ea363ccb6299eb53b83284ce3"
"hash": "1df1b78e9d68f5ff116c2faab5b27126"
}
##DOCS-SOURCER-END -->
Original file line number Diff line number Diff line change
Expand Up @@ -106,13 +106,19 @@ When applying the changes manually, you can run `terragrunt run-all apply` insid
security, shared etc), and waiting them to successful update before applying the changes before the next one, e.g. wait
for `dev` to successfully finish before applying `prod`.

Example of using Terragrunt, after running Patcher in the `dev` folder:
```
aws-vault exec dev -- terragrunt run-all init
aws-vault exec dev -- terragrunt run-all apply
```

After the changes have been applied we recommend you complete [step 5](step-5-check-your-live-infrastructure-is-cis-v1.5-compliant)
and confirm that your infrastructure is now CIS AWS Foundations Benchmark v1.5.0 compliant.


<!-- ##DOCS-SOURCER-START
{
"sourcePlugin": "local-copier",
"hash": "d6bb869058ce4fda05e3b5e2e985657b"
"hash": "9e04dae37862a686590bcfe5c62940d2"
}
##DOCS-SOURCER-END -->

0 comments on commit 83bd64f

Please sign in to comment.