Applying Aws Best Practices on Account-Baseline-Root

[vramanufidato]

Hi Team,

Its been mentioned "Note that at this time, the Reference Architecture does not configure or manage the root/management account of an AWS Organization set up. That is,
it does not include the account-baseline-root module.
Gruntwork is planning to add this in a future enhancement. "

If we need to achieve this we need to write and maintain a separate terraform code from scratch or is it possible to leverage / reuse the existing modules of gruntworks for the root account level in some cases?

Thanks in Advance

---

Tracked in ticket #109632

[brikis98]

Yes, you can use the account-baseline-root in your root AWS account, but there extra steps you have to take:

1. Configure the code to match existing resources. You likely have created some resources manually in your root account: e.g., perhaps you've already created IAM users, set up CloudTrail, etc. Moreover, to deploy a Reference Architecture, we have you run the gruntwork CLI in your root account, which creates child accounts such as security, logs, dev, stage, prod, etc (these are the accounts into which we deploy your Reference Architecture). You will need to configure the account-baseline-root module to match whatever has been deployed manually. If you're doing it from Terragrunt, the terragrunt.hcl file might look something like this (this is NOT complete/tested code, just an example; see variables.tf for all available inputs):

   # terragrunt.hcl example
   
   terraform {
     source = "git::[email protected]:gruntwork-io/terraform-aws-service-catalog.git//modules/landingzone/account-baseline-root?ref=v0.99.0"
   }
   
   # ---------------------------------------------------------------------------------------------------------------------
   # CONFIGURE A PROVIDER FOR EACH AWS REGION
   # To deploy a multi-region module, we have to configure a provider with a unique alias for each of the regions AWS
   # supports and pass all these providers to the multi-region module in a provider = { ... } block. You MUST create a
   # provider block for EVERY one of these AWS regions, but you should specify the ones to use and authenticate to (the
   # ones actually enabled in your AWS account) using opt_in_regions.
   # ---------------------------------------------------------------------------------------------------------------------
   
   generate "providers" {
     path      = "providers.tf"
     if_exists = "overwrite"
     contents  = <<EOF
   provider "aws" {
     region = "${local.aws_region}"
     alias = "default"
   }
   %{for region in local.all_aws_regions}
   provider "aws" {
     region = "${region}"
     alias  = "${replace(region, "-", "_")}"
     # Skip credential validation and account ID retrieval for disabled or restricted regions
     skip_credentials_validation = ${contains(coalesce(local.opt_in_regions, []), region) ? "false" : "true"}
     skip_requesting_account_id  = ${contains(coalesce(local.opt_in_regions, []), region) ? "false" : "true"}
     skip_get_ec2_platforms      = ${contains(coalesce(local.opt_in_regions, []), region) ? "false" : "true"}
   }
   %{endfor}
   EOF
   }
   
   locals {
     # The following locals are used for constructing multi region provider configurations for the underlying module.
     multi_region_vars = read_terragrunt_config(find_in_parent_folders("multi_region_common.hcl"))
     all_aws_regions   = local.multi_region_vars.locals.all_aws_regions
     opt_in_regions    = local.multi_region_vars.locals.opt_in_regions
   }
   
   inputs = {
     # Fill these in as appropriate for your root account
     name_prefix    = "root"
     aws_region     = "eu-west-1"
     aws_account_id = "111111111111"
   
     # This should match the child accounts you created with the gruntwork CLI for the Ref Arch
     child_accounts = {
       logs = {
         email           = "[email protected]"
         is_logs_account = true
       }
       security = {
         email = "[email protected]"
       }
       shared = {
         email = "[email protected]"
       }
       dev = {
         email = "[email protected]"
       }
       stage = {
         email = "[email protected]"
       }
       prod = {
         email = "[email protected]"
       }
     }
   
     # This should match any IAM users you created manually in your root account
     users = {
       alice = {
         groups = ["admins"]
       }
       bob = {
         groups = ["developers"]
       }
     }
   
     # If you manually enabled CloudTrail in your root account, this should match the settings you used for it
     enable_cloudtrail         = true
     is_multi_region_trail     = true
     cloudtrail_s3_bucket_name = "your-cloudtrail-s3-bucket-name"
   
     # And so on! See variables.tf in account-baseline-root for all the settings exposed. This is just a partial example!
     # https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/modules/landingzone/account-baseline-root/variables.tf
   }

2. Import existing resources. Next, anything you created manually or via the gruntwork CLI will need to be imported into Terraform state so you can manage it as code using account-baseline-root. This requires running the import command. You have to do this on a resource-by-resource basis. It's tedious and will definitely take some time. Note that you'd have to do this no matter what module you used (or even if you used other IaC tools entirely); it's an inherent part of switching from manually managing things to using IaC to manage things. The syntax is import <ADDRESS> <ID> where <ADDRESS> is the address of the resource in Terraform and <ID> is the ID of that resource in AWS. Run the plan command to see all the addresses; check the docs for that resource to see what ID its looking for and then login to the AWS console to get the IDs. For example, to import a child AWS account created by the gruntwork CLI, such as the logs account with account ID 222222222222, you'd run something like terragrunt import 'module.organization.aws_organizations_account.child_accounts["logs"]' 222222222222.

3. Plan. Once you've imported everything, run plan again. If you've done import right, any existing resources should be unmodified (especially any child accounts and IAM users!), and the only things being created are new things in account-baseline-root that you didn't have in your root account before (e.g., perhaps GuardDuty, AWS Config, etc).

4. Apply. If everything looks good, run apply to deploy. Going forward, only use Terraform to manage everything in this account!