Define the IAM user permission levels for DevOps and project members #225

Overview

We need to decide what each kind of person working in the incubator AWS account can do, so the IAM groups can be built to match. There are two divisions — DevOps and projects — and this issue decides the levels inside each and what each level is allowed to do.

Action Items

• Decide the levels in each division. A starting point, not a decision: DevOps engineer and DevOps lead; project lead and project developer. Add or merge levels if the work calls for it — for example, whether a new DevOps member starts read-only before becoming an engineer.
• For each level, write down which AWS services it can use, which actions (read, deploy, change config, delete), and on which resources. Use a table like the one in DR-Machine-to-machine-IAM-scoping so the levels can be compared side by side.
• Decide what every person gets regardless of level: MFA enforced, change own password, and whether managing your own access keys is part of the baseline (today only ops-leads has ManageAccessKeys).
• Decide whether the DevOps lead level keeps AdministratorAccess or gets something narrower, and say which actions (if any) are kept for a break-glass path instead.
• Decide how a project member is tied to their project. IAM groups can't carry tags, so there are two real options:
  • per-project groups whose policies name the project directly (aws:ResourceTag/project = "vrms"), generated by Terraform — the approach Epic: Scope machine-to-machine IAM permissions to projects using the project tag incubator#206 took for machine roles; or
  • a project tag on each user, matched in one shared policy with ${aws:PrincipalTag/project}.
    A tag holds only one value, so the second option doesn't work for someone on two projects. Record which option was picked and why.
• List the resource types project members need that the DR does not already require to carry the project tag (for example, the Route 53 zones). Every one of these either needs tagging or has to be granted some other way — write down which.
• Decide who can create and change IAM users, and at what level. (IAMServicesSupervisor was an earlier attempt at this, keyed on an Access Level user tag, and is attached to nothing.)
• Map every current IAM user (see the epic) to a level in the new scheme, except bonnie_hfla and chelseybeck, which this epic leaves as they are.
• Write it up as a decision record on the devops wiki named DR-IAM-user-permissions (a dash, never a colon — a colon makes the wiki un-clonable on Windows). List it under both Decision Records and Decision Records on Solutions Adopted.
• Get sign-off from the CoP leads at the weekly leads meeting, and record the date on the DR.

Resources/Instructions

• Current groups and members: see the parent epic.
• Group and user declarations: terraform/aws-groups.tf, terraform/aws-groups-legacy.tf, terraform/aws-users.tf, terraform/aws-users-legacy.tf.
• DR-Machine-to-machine-IAM-scoping — the project tag standard (decisions 1-4) and the shape a permission table should take.
• Permission Levels for Team Members § AWS access — what the current groups are documented as granting.
• DR-Use-it-or-lose-it-policy-for-IAM-User-Accounts and DR-Password-Requirements-Policy — existing rules for IAM users that the new levels sit alongside, not replace.
• Split the project-leads user group into developer-group, ops-group, and project-leads group devops#59 — the 2022 attempt at splitting groups by role.
• Ship a downloadable terraform.tfvars backed by a read-only Postgres role incubator#209 — related least-privilege work for people running terraform plan locally.
• AWS: ABAC with IAM, and the per-service "actions, resources and condition keys" pages for which actions support aws:ResourceTag.