Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity - Why?

[maximillianus]

Describe the issue

Referring to this error in assuming role using OIDC (issues 1137).

I wonder what's the actual issue? This issue came up when I use environment in my workflow.

I resolve this by making my sub to be more generic and it works.
Was:

"StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
        }

Now:

"StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
        }

But I dont' understand how adding environment changes the repo's URL syntax. Can anybody show me how so I can make more specific & least privileged URL syntax. I am expecting something like this

"StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:environment:*ref:refs/heads/GithubBranch*"
        }

[jsandov]

@maximillianus I recently implemented this. When you add an environment to a GitHub Actions job, it indeed changes the format of the sub claim in the OIDC token. This change is not immediately obvious and can cause confusion when setting up IAM roles for OIDC authentication.

When an environment is specified in a job, the sub claim in the OIDC token changes from:

repo:<GitHubOrg>/<GitHubRepo>:ref:refs/heads/<GitHubBranch>
to

repo:<GitHubOrg>/<GitHubRepo>:environment:<EnvironmentName>
This change occurs because GitHub treats environment-based workflows differently from branch-based workflows for security reasons. Read over the docs.

[jsandov]

@maximillianus Using both formats If you need more precise control, you can include conditions for both formats:

"StringLike": { "token.actions.githubusercontent.com:sub": [ "repo:<GitHubOrg>/<GitHubRepo>:ref:refs/heads/*", "repo:<GitHubOrg>/<GitHubRepo>:environment:*" ] }

Adjusting your IAM role configurations accordingly

[jsandov]

These are the Terraform modules I used for AWS:

• OIDC provider for AWS
• IAM Policy
• IAM Role Policy

[maximillianus]

Thanks @jsandov . Those exactly what I did too after further research, but discovering this is not exactly straightforward. I wish there is some documentation from the aws-action Github team here. Again, while * wildcard works fine (and convenient), I prefer least privileged style with more control.

Thanks for the answer.

[jsandov]

@maximillianus I linked the TF modules above. You will need to handle this at the infrastructure as code level. More precisely at the at the trust policy level which goes into the IAM role. This is how I am handling the different repos and environments that can be plugged in. Hopefully this helps!

Here is a trust policy I created for least privileged access to repo and environment.

  trust_policy = {
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = local.provider_arn
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
          }
          StringLike = {
            "token.actions.githubusercontent.com:sub" = flatten([
              for repo, envs in var.repository_environments : [
                for env in envs :
                "repo:${repo}:environment:${env}"
              ]
            ])
          }
        }
      }
    ]
  }