[aws-sso] Fix root provider, restore SetSourceIdentity permission (cloudposse/terraform-aws-components#830)

Author: Nuru

src/CHANGELOG.md

@@ -2,7 +2,15 @@
 
 ***NOTE***: This file is manually generated and is a work-in-progress.
 
-### PR 740
+### PR 830
+
+- Fix `providers.tf` to properly assign roles for `root` account when deploying to `identity` account.
+- Restore the `sts:SetSourceIdentity` permission for Identity-role-TeamAccess
+permission sets added in PR 738 and inadvertently removed in PR 740.
+- Update comments and documentation to reflect Cloud Posse's current
+  recommendation that SSO ***not*** be delegated to the `identity` account.
+
+### Version 1.240.1, PR 740
 
 This PR restores compatibility with `account-map` prior to version 1.227.0
 and fixes bugs that made versions 1.227.0 up to this release unusable.

src/README.md

@@ -12,17 +12,26 @@ This component assumes that AWS SSO has already been enabled via the AWS Console
 1. Select primary region
 1. Go to AWS SSO
 1. Enable AWS SSO
+
+#### Delegation no longer recommended
+
+Previously, Cloud Posse recommended delegating SSO to the identity account by following the next 2 steps:
 1. Click Settings > Management
-1. Delegate Identity as an administrator
+1. Delegate Identity as an administrator. This can take up to 30 minutes to take effect.
+
+However, this is no longer recommended. Because the delegated SSO administrator cannot make changes in the `root` account
+and this component needs to be able to make changes in the `root` account, any purported security advantage achieved by
+delegating SSO to the `identity` account is lost.
 
-Once identity is delegated, it will take up to 20 to 30 minutes for the identity account to understand its delegation.
+Nevertheless, it is also not worth the effort to remove the delegation. If you have already delegated SSO to the `identity`,
+continue on, leaving the stack configuration in the `gbl-identity` stack rather than the currently recommended `gbl-root` stack.
 
 ### Atmos
 
 **Stack Level**: Global
 **Deployment**: Must be deployed by root-admin using `atmos` CLI
 
-Add catalog to `gbl-identity` root stack.
+Add catalog to `gbl-root` root stack.
 
 #### `account_assignments`
 The `account_assignments` setting configures access to permission sets for users and groups in accounts, in the following structure:

src/policy-Identity-role-TeamAccess.tf

@@ -12,6 +12,7 @@ data "aws_iam_policy_document" "assume_aws_team" {
     effect = "Allow"
     actions = [
       "sts:AssumeRole",
+      "sts:SetSourceIdentity",
       "sts:TagSession",
     ]
 

src/providers.tf

@@ -1,29 +1,29 @@
-# This is a special provider configuration that allows us to use many different
-# versions of the Cloud Posse reference architecture to deploy this component
-# in any account, including the identity and root accounts.
+# This component is unusual in that part of it must be deployed to the `root`
+# account. You have the option of where to deploy the remaining part, and
+# Cloud Posse recommends you deploy it also to the `root` account, however
+# it can be deployed to the `identity` account instead. In the discussion
+# below, when we talk about where this module is being deployed, we are
+# referring to the part of the module that is not deployed to the `root`
+# account and is configured by setting `stage` etc..
 
-# If you have dynamic Terraform roles enabled and an `aws-team` (such as `managers`)
-# empowered to make changes in the identity and root accounts. Then you can
-# use those roles to deploy this component in the identity and root accounts,
-# just like almost any other component. Leave `privileged: false` and leave the
-# backend `role_arn` at its default value.
+# If you have Dynamic Terraform Roles enabled, leave the backend `role_arn` at
+# its default value. If deploying only to the `root` account, leave `privileged: false`
+# and use either SuperAdmin or an appropriate `aws-team` (such as `managers`).
+# If deploying to the `identity` account, set `privileged: true`
+# and use SuperAdmin or any other role in the `root` account with Admin access.
 #
 # For those not using dynamic Terraform roles:
 #
-# If you are deploying this to the "identity" account and are restricted to using
-# the SuperAdmin role to deploy components to "identity", then you will need to
-# set the stack configuration for this component to set `privileged: true`
-# and backend `role_arn` to `null`.
+# Set the stack configuration for this component to set `privileged: true`
+# and backend `role_arn` to `null`, and deploy it using either the SuperAdmin
+# role or any other role in the `root` account with Admin access.
 #
 # If you are deploying this to the "identity" account and have a team empowered
-# to deploy components to "identity", then you will need to set the stack
-# configuration for this component to set `privileged: false` and leave the
-# backend `role_arn` at its default value.
+# to deploy to both the "identity" and "root" accounts, then you have the option to set
+# `privileged: false` and leave the backend `role_arn` at its default value, but
+# then SuperAdmin will not be able to deploy this component,
+# only the team with access to both accounts will be able to deploy it.
 #
-# If you are deploying this to the "root" account, then you will need to
-# set the stack configuration for this component to set `privileged: true`
-# and backend `role_arn` to `null`, and deploy it using either the SuperAdmin
-# role or any other role in the `root` account with Admin access.
 
 provider "aws" {
   region = var.region
@@ -51,10 +51,10 @@ provider "aws" {
   alias  = "root"
   region = var.region
 
-  profile = !var.privileged && module.iam_roles.profiles_enabled ? module.iam_roles.terraform_profile_name : null
+  profile = !var.privileged && module.iam_roles_root.profiles_enabled ? module.iam_roles_root.terraform_profile_name : null
   dynamic "assume_role" {
-    for_each = !var.privileged && module.iam_roles.profiles_enabled ? [] : (
-      var.privileged ? compact([module.iam_roles.org_role_arn]) : compact([module.iam_roles.terraform_role_arn])
+    for_each = !var.privileged && module.iam_roles_root.profiles_enabled ? [] : (
+      var.privileged ? compact([module.iam_roles_root.org_role_arn]) : compact([module.iam_roles_root.terraform_role_arn])
     )
     content {
       role_arn = assume_role.value