Question

A company uses a central identity account. Developers assume a role named DevAccess in a workload account via 'sts:AssumeRole'. The DevAccess role's identity-based policy grants access to Secrets Manager secrets only when the request includes a principal tag matching the secret's 'team' tag, using a condition on 'aws:PrincipalTag/team'. Developers report AccessDenied when retrieving secrets even though their IAM users in the identity account have a 'team' tag set. What is the MOST likely cause and correct fix?

Accepted Answer

Principal tags on the source IAM user are not automatically carried into the assumed-role session; the AssumeRole call must pass the tag as a session tag (sts:TagSession) so 'aws:PrincipalTag/team' is populated.

Answer

Resource-based policies on secrets always override identity-based conditions; attach a secret policy that denies untagged principals instead.

Answer

The DevAccess role's trust policy must include the 'team' tag as a Condition key; adding it there will populate 'aws:PrincipalTag/team' during retrieval.

Answer

Secrets Manager does not support 'aws:PrincipalTag' conditions; the policy must use 'aws:RequestTag/team' instead.