Grant someone read access¶

The problem¶

Someone new joins the rota and needs to decrypt messages sent to the identity.

Understand what you are granting first¶

[!IMPORTANT] Reader access is retroactive. It is not "can read new mail from today" — it is "can decrypt everything ever encrypted to this identity", including messages in an archive from before this person joined.

Unlike a signing key, where a compromise lets an attacker forge things going forward, an encryption key compromise exposes the entire history. That is why the module documents the reader list as "keep it as short as the job allows" and why it is worth actively removing people who leave the rota.

Steps¶

If you use Identity Center¶

Add the person to the group assigned to the reader permission set. That is a directory operation — no Terraform change, no apply, and it takes effect at their next sign-in.

This is the whole reason for putting a permission set in front of the role: onboarding and offboarding stop being infrastructure changes.

If you use ordinary IAM principals¶

Add their role or user ARN to reader_principal_arns and apply:

reader_principal_arns = [
  "arn:aws:iam::111122223333:role/intake-reader",
  "arn:aws:iam::111122223333:role/new-joiner",   # added
]

tofu plan   # expect one change: aws_iam_role.reader assume_role_policy
tofu apply

Only the trust policy changes. The KMS key policies reference the role, not its members, so they are untouched.

Do not add people to the certifier role by default¶

certifier_principal_arns is a different question with a different answer. Signing with the certification primary can rebind the published certificate to a different encryption key — redirecting every future message to a key someone else holds. Being on the reading rota is not a reason to hold that.

Keep the certifier list to a dedicated break-glass principal, and add to it only for the duration of an actual certificate operation.

Confirm it worked¶

Have the new person run:

aws sts assume-role \
  --role-arn "$(tofu output -raw reader_role_arn)" \
  --role-session-name check --query 'AssumedRoleUser.Arn' --output text

If that fails with AccessDenied and they came through Identity Center, check reader_require_mfa — see Use it with IAM Identity Center.