So typically what we do is we have the AWS SSO permission sets that are trusted by the Terraform state component. Meaning the above snippet configures your back end for various stacks. So when Atmos tries to authenticate to the back end, it'll assume that role. The way it goes is you run Atmos Terraform plan. The next step is Atmos authenticates, it'll authenticate with whatever your auth identity is and go all the way down from provider to your identity following that chain. Next thing that happens is we try to assume the role for the Terraform State backend. That's defined in that snippet above, and whatever your auth you assumed into or signed into, you need to be able to access that Terraform State role via that signed-in role via the Atmos auth. Then in the Atmos Auth identity the actual Atmos Terraform plan occurs - that's done through the Terraform provider. For the Terraform providers, we have a new mix-in out that helps integrate with Atmos Auth. It's a more basic one. policy-TerraformAccess.tf in the

aws-identity-center

component handles creating 3 types of access for tfstate. Plan, Apply, and state access (for

!terraform.state

operations). then in tfstate backend component we typically allow the permissionset to access the role via

access_roles:
          default:
            allowed_permission_sets:
              core-root: 
                - Terraform*Access

the asterisk is because we're very close to the ACL Limit of 4096. Finally the typical provider we use is https://github.com/cloudposse-terraform-components/mixins/blob/main/src/mixins/provider-without-account-map.tf (this is vendored in with a component.yaml snippet:

mixins:
    - uri: <https://raw.githubusercontent.com/cloudposse-terraform-components/mixins/{{> .Version }}/src/mixins/provider-without-account-map.tf
      version: v0.3.0
      filename: <http://providers.tf|providers.tf>
    - uri: <https://raw.githubusercontent.com/cloudposse-terraform-components/mixins/{{> .Version }}/src/mixins/account-verification.mixin.tf
      version: v0.3.0
      filename: <http://account-verification.mixin.tf|account-verification.mixin.tf>

these help because were in the process of removing the account-map. and help map a static var account-map rather than the older component lookup. so then people planning terraform are using a custom built permissionset to plan (and or apply) their terraform code. You're deploying it with whatever you have access to via the permissionsets. Which are configured via identities and profiles

yeah that explains it, thanks!