AWS STS: Validate OIDC provider claims from GitHub, Google, CircleCI, and OCI

AWS annonserte en oppdatering til AWS Security Token Service (STS): du kan nå validere utvalgte identitetsleverandør-spesifikke JWT claims fra Google, GitHub, CircleCI, og Oracle Cloud Infrastructure (OCI) når du bruker AssumeRoleWithWebIdentity. Dette er viktig fordi det gjør det enklere å skrive stramme IAM trust policies for OIDC-basert føderasjon (CI/CD, workload identity) uten å stole på altfor brede mønstre.

Kilde: AWS announcement

Hvorfor dette er nyttig Lenke til overskrift

Hvis du allerede bruker OIDC-føderasjon, har du sannsynligvis gjort minst ett av disse:

Begrenset tilgang med et enkelt sub-mønster og håpet det var spesifikt nok.
Brukt repositorienavn eller branchenavn som er enkle å endre.
Akseptert “enhver arbeidsflyt i denne organisasjonen kan anta rollen” fordi policyen ble for kompleks.

Leverandørspesifikke claim keys lar deg uttrykke intensjon tydeligere: “kun dette repoet (ved uforanderlig ID)”, “kun denne virksomheten”, “kun denne arbeidsflyten”, “kun denne aktøren”.

Eksempel: GitHub Actions trust policy conditions Lenke til overskrift

For GitHub Actions støtter AWS betingelsesnøkler som kartlegger til vanlige GitHub OIDC claims.

AWS STS condition key	IdP JWT claim	Available in session
actor	actor	No
actor_id	actor_id	No
job_workflow_ref	job_workflow_ref	No
repository	repository	No
repository_id	repository_id	No
workflow	workflow	No
ref	ref	No
environment	environment	No
enterprise_id	enterprise_id	No

Merk om “available in session”: disse claim-kontrollene evalueres under rolleantagelsessteget (trust policy). De materialiseres ikke automatisk som attributter du senere kan referere til i rollens tillatelsespolicyer.

Praktiske mønstre Lenke til overskrift

token.actions.githubusercontent.com:actor: identifiser hvem som utløste arbeidsflyten. For eksempel, hvis aktøren er dependabot[bot], kan du kun tillate skrivebeskyttet tilgang.
token.actions.githubusercontent.com:repository_id: foretrekk uforanderlige ID-er fremfor navn for å unngå “endre navn for å omgå policy” -scenarier.
token.actions.githubusercontent.com:enterprise_id: sørg for at kun arbeidsflyter fra din GitHub Enterprise kan anta rollen.

IAM trust policy snippet (GitHub Actions) Lenke til overskrift

Dette er den typen policy jeg liker: hold trust policyen streng, og hold tillatelsene begrenset til de minimum nødvendige handlingene.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:repository_id": "123456789",
          "token.actions.githubusercontent.com:enterprise_id": "987654321"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:ref": "refs/heads/main",
          "token.actions.githubusercontent.com:job_workflow_ref": "my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main"
        }
      }
    }
  ]
}

Kort veiledning Lenke til overskrift

Foretrekk uforanderlige identifikatorer (repository_id, enterprise_id) fremfor navn der det er mulig.
Behandle trust policyen som din “adgangskontroll”: hold den så smal som mulig.
Ikke stol på OIDC-føderasjonssesjonen for å “bære” disse claims; hvis du trenger rikere revisjonskontekst, planlegg for det eksplisitt (CloudTrail, ytterligere logging, eller separate roller per arbeidsflyt).