A deployment pipeline may prove that it is running a particular workflow and still lack permission to change cloud resources. Authentication maps a request to an identity; authorization grants that identity permission to act. Registering an OpenID Connect (OIDC) identity provider establishes trust in identities it supplies, but does not by itself authorize them. section 8.5.1 section 8.5.1
To authorize a CI/CD identity for cloud deployment:
- Register the pipeline’s OIDC provider with the cloud vendor. For GitHub Actions, the provider URL is https://token.actions.githubusercontent.com. section 8.5.1
- Map the supplied identity to a cloud identity. In AWS, create a role it can assume; in Azure, map it to a service principal. section 8.5.1
- Restrict that relationship. For an AWS role, specify the OIDC provider as a principal and add conditions limiting assumption to the intended repository and workflows. Without those conditions, other users of the provider could assume the role. section 8.5.1
Listing 8.14 Allowing a GitHub Actions workflow to assume a role
jobs:
terraform:
name: Run Terraform against AWS
runs-on: ubuntu-latest
permissions: #1
id-token: write #1
contents: read #1
steps:
- name: Checkout #2
uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4 #3
with:
role-to-assume: arn:aws:iam::999999999999:role/github-actions-${{
github.repository }} #4
region: us-west-2 #5
#1 The AWS action needs the OIDC token to be accessible.
#2 Checkout our repository.
#3 This action is published by AWS and converts the OIDC token into AWS credentials.
#4 When using OIDC you have to tell AWS what role you want to assume.
#5 AWS requires a region when logging in.
The GitHub Actions workflow requests access to an OIDC token, then configures AWS credentials by naming the role to assume. The workflow configuration works alongside the cloud-side role and its restrictions. section 8.5.1
Authorization also governs access to Terraform state. Give backend access only to people and systems that need it: when CI/CD runs production jobs, developers may not need direct state access. Pair that restriction with access logging so problems can be traced. section 6.4.2
