IAM Identity Center SSO: Multi-Account Permission Sets

Why — The Problem This Solves

Week 6 built an Account Vending Machine — a ServiceNow ticket now produces a real AWS account inside the right Organizational Unit in minutes, with SCP guardrails attached automatically. That answers where the account lives. It says nothing about who can log into it.

Filled in by hand, that gap looks the same way it always does: someone creates an IAM user per person, per account, hands out an access key, and quietly loses track of which user has which permissions where. Multiply that across every account this lab has vended (and will keep vending), and the access model becomes the actual security problem — not the accounts themselves.

The Business Value

IAM Identity Center fixes this by inverting the model: define access centrally, once, and let AWS provision it everywhere it's needed.

What You Need to Know — Skills & Tools

This week is lighter on moving parts than Week 6 — no Lambda, no Step Functions — but it leans hard on Identity Center concepts that don't show up earlier in this series.

Required AWS Knowledge

Required Engineering Skills

Concepts to Understand Before Starting

Architecture — How It Fits Together

Why Groups Instead of Per-User Assignments?

The Terraform assigns permission sets to groups, never directly to individual users. Adding someone to Engineers grants them every account that group is already assigned to, automatically — no new Terraform apply needed per person. Same idea as IAM groups, just at Organization scope instead of single-account scope.

Why a Cross-Product for Assignments?

Every group needs the matching permission set in every target account, so the module builds the assignment set as setproduct(keys(groups), target_account_ids) — add one more account to the target OU, and the same Terraform apply assigns every existing group to it with no additional code.

How We Built It — Step by Step

Step 1: The identity-center Terraform Module

One module, six resource types, looped over a single groups map:

locals {
  assignments = {
    for pair in setproduct(keys(var.groups), var.target_account_ids) :
    "${pair[0]}-${pair[1]}" => {
      group_name = pair[0]
      account_id = pair[1]
    }
  }
}

resource "aws_ssoadmin_account_assignment" "this" {
  for_each = local.assignments

  instance_arn       = var.instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.this[each.value.group_name].arn
  principal_id        = aws_identitystore_group.this[each.value.group_name].group_id
  principal_type      = "GROUP"
  target_id           = each.value.account_id
  target_type         = "AWS_ACCOUNT"
}

The target accounts themselves aren't hardcoded — they're looked up from Week 6's vended OUs, so adding a new account to Sandbox or Production automatically becomes a new assignment target on the next apply:

data "aws_organizations_organizational_unit_child_accounts" "target" {
  for_each  = toset(local.target_ou_ids)
  parent_id = each.value
}

locals {
  target_account_ids = distinct(flatten([
    for ou_id, result in data.aws_organizations_organizational_unit_child_accounts.target :
    [for acct in result.accounts : acct.id]
  ]))
}

Step 2: Enable IAM Identity Center (Manual, One-Time)

Step 3: Standing Up the HCP Workspace via API

Rather than click through the HCP UI, week-07-dev was created the same way week-06-dev was — via the HCP Terraform API, using the token already saved locally in credentials.tfrc.json. POST a workspace, PATCH/POST its variables, done:

curl --header "Authorization: Bearer $TOKEN" \
     --header "Content-Type: application/vnd.api+json" \
     --request POST \
     --data '{
       "data": { "type": "workspaces", "attributes": {
         "name": "week-07-dev",
         "working-directory": "week-07-identity-center-sso/terraform/environments/dev",
         "vcs-repo": { "identifier": "katta698/AWS-Platform-Engineering-Lab",
                       "branch": "main",
                       "github-app-installation-id": "ghain-H7CUcPhefZdVqW8S" }
       }}
     }' \
     "https://app.terraform.io/api/v2/organizations/Katta/workspaces"

The OIDC trust policy on hcp-terraform-role already wildcards workspace:* from Week 6, so the new workspace inherited working AWS auth with zero IAM changes.

Confirmed directly in the console — the three groups exist:

And the permission sets, each backed by its managed policy:

Step 4: Adding a Test User and Assigning to a Real Account

With the permission sets live, a second apply added a test user (jane.engineer, in the Engineers group) and the account assignments — five new resources: the user, the group membership, and three account assignments (one per group):

The assignment is visible from the account side too — all three groups now show up against the target account:

Step 5: Confirming AWS Auto-Provisioned the Roles

This is the part that makes Identity Center worth using: nothing was ever declared inside the target account's own IAM. Switching into it directly shows three roles that simply appeared the moment the assignment was made:

Step 6: Signing In as the Test User

Identity Center users created via Terraform have no password and no MFA device by default — there's no Terraform equivalent of "send invite email." An admin-initiated password reset (not the self-service "Forgot password?" flow, which got stuck on a stale MFA-required error during testing) got a usable credential. Signed in, the portal showed exactly one account and exactly one role:

That's the scoping working exactly as intended: the portal only ever shows what this user's own group membership grants, not everything assigned to the account. Picking the role federates straight into a live console session:

Challenges — What Actually Went Wrong

Security — Controls at Every Layer

Cost

IAM Identity Center, permission sets, groups, users, and account assignments are all free — so are the IAM roles Identity Center provisions into target accounts.

Cleanup — Tearing It Down

week-07-dev is VCS-connected, same restriction as Weeks 5–6 — destroy is confirmed from the HCP UI, not local CLI.

References

• What is IAM Identity Center — permission sets, identity store, account assignments explained.
• aws_ssoadmin_permission_set / aws_ssoadmin_account_assignment — the two resources doing most of the work this week.
• aws_identitystore_user / aws_identitystore_group — full user/group management via Terraform, no console clicking required.
• aws_organizations_organizational_unit_child_accounts — how the target accounts are discovered dynamically from Week 6's OUs.
• HCP Terraform API — used to create the workspace and set its variables programmatically, same pattern as Week 6.
• Full source code — week-07-identity-center-sso

Takeaways — What I'd Do Differently