Permission & Configuration Structure

[seanlongnyc]

Context / Environment Status:
we have the AWS Account structure

Root/
- corp1
- core/
   - core-auto
   - core-root
   - core-identity
   - etc...
- plat/
   - sandbox
   - etc...

The AWS Identity Center has been configured with Okta SSO in the corp1 account. Last week during office hours we learned to override account_name in components/accounts/modules/iam_roles to get passed the required naming convention of having an - in the root account name when running aws-sso

corp1 also contains our s3 state.

The account map is as follows:

        root_account_aws_name: root
        root_account_account_name: corp1
        identity_account_account_name: core-identity
        artifacts_account_account_name: core-artifacts
        dns_account_account_name: core-dns
        audit_account_account_name: core-audit

We have found that aws-sso is deployed to corp1 where Identity Center is configured. aws-teams-roles is deployed to all accounts. Then aws-teams & aws-saml were deployed to core-identity

It seems to me that: Since we use aws sso login to authenticate we are assigned permission_sets & need to have trusted_permission_set on the aws-teams & aws-team-roles so that we can manage resources in our plat OU

Questions:
Is this configuration/understanding correct? Is core-identity still the identity account ?

Additionally we see some costs in across all of our accounts that come up as ec2 - other, is there a way to easily see which components/resources have actually be deployed across accounts ?

[milldr]

Is this configuration/understanding correct? Is core-identity still the identity account ?

Yes this sounds correct. We use the root account (or in your case corp1) to manage (1) the AWS organization, (2) Terraform state backend, and (3) AWS Identity Center (sso). We use the core-identity account as the identity "hub" for aws-teams. Developers assume the IAM roles in this core-identity account to apply Terraform across the organization.

It's important to create the account-level boundary between core-identity and your root account, because the root account is highly critical and has control over the entire organization including all accounts. You should grant access to the root account very sparingly, whereas every single developer that will need to apply Terraform will need access to the core-identity account.

However AWS Identity Center creates an additional path to access accounts of the organization. With Identity Center Permission Sets, developers can assume access in a specific account directly. You might want to use a Permission Set to quickly access an account in the AWS web console or to assume a specific account locally. But you need to assume an AWS Team in core-identity to apply Terraform.

Please see this page for more on this design: https://docs.cloudposse.com/layers/identity/centralized-terraform-access/

[milldr]

Additionally we see some costs in across all of our accounts that come up as ec2 - other, is there a way to easily see which components/resources have actually be deployed across accounts ?

Budgets are centralized in the root (corp1 in your case) account too. I'd recommend taking a look at the Cost Explorer

[seanlongnyc]

/stacks/catalog/accounts.yaml needed terraform.account.vars.organization_config.root_account.name to be core-root when in reality we use corp1.

To resolve this discrepancy we needed to change: /stacks/catalog/account-map.yaml to have

• terraform.account-map.vars.root_account_aws_name: corp1
• terraform.account-map.vars.root_account_name: core-root

However since we have an actual core-root account in the core OU this becomes a conflict. To resolve this issue:

• Remove the existing core-root account from the aws org
  • simply closing the account puts it in the post-closure period which assigns it the SUSPENDED state & becomes ignored by the TF plan resolving the issue.
  • to be safe, we first entered into the actual core-root account in the core OU & changed the account name via ClickOps. Since it is not the managed account this is allowed. This also resolves the tf issue

Now with our aws-team identity for the core-identity account we appear to be able to run terraform plans without any configuration for role chaining