Permission sets and account assignments

Skill and boundary

When an operations team enters several AWS accounts, a reassuring role name such as Administrator or Auditor is not an access design. Start with a matrix of people, groups, accounts, and required actions. IAM Identity Center defines a permission set; an account assignment connects that set to a user or group in a specific account. Provisioning creates an IAM role in the target account. Seeing a permission set in the center therefore does not mean everyone in the organization has it in every account. Separate the permission definition, assignment, provisioned role, and effective account policy. This lesson diagnoses human access rather than copying an open policy across accounts.

Decision model

Build a four-column decision model: worker identity, membership group, target account, and requested operation. If auditors need to inspect CloudTrail and selected resource metadata in production, define a read-scoped permission set and assign the auditor group to that account alone. A developer needing write access to a test account gets a separate assignment; that need is not a reason to give auditors production write privileges. Check custom managed policies as well: a policy included by name and path in a permission set must already exist with the matching name and path in each assigned account. Selecting its name centrally does not create the managed policy in the member account.

Worked case

The smallest repair assigns `AuditReaders` to `AuditView` in production, verifies provisioning there, and tests one intended read and one write that must be denied. Keep `BuildTest` limited to test; avoid a universal role merely because it seems easier to administer. Record the account identifier in the access matrix so that a portal label cannot disguise the wrong account. If an applicable SCP explicitly denies the read in the member account, expanding a permission set cannot fix the conflict; the guardrail owner must resolve it. If the worker assumes a second role after portal access, trace the actual chain rather than assuming the Identity Center assignment is the final authorization step.

A counterfactual changes the repair: suppose the assignment and role exist, but a custom managed policy referenced by the permission set is missing at the exact name and path in production. Do not add a second assignment. Prepare the policy in that account, reprovision, and then retest the read. Another counterfactual is an application making service calls as a workload: a human portal assignment is not a substitute for a workload role with its own trust and permissions. The diagnostic value of the model is that the failed stage names the corrective owner and prevents an identity defect from becoming an overly broad data grant. Before closing the access request, ask for decision evidence rather than a portal screenshot: group ID, account ID, permission-set revision, provisioning state, and one API outcome with its allow or deny reason. Keep a negative write test. After a worker moves groups, inspect old assignments so unnecessary access does not persist. Record exception ownership and expiry; a temporary grant without expiry becomes an unreviewed permanent route.

Exercise and product

Solution review