repository_name OIDC claim along with repository_owner

[sorah]

https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token

I wonder if GitHub Actions issue ID tokens with repository_name claim along with the existing repository_owner.

There is already repo claim, but it comes under a format "#{owner}/#{name}". Major providers that accepts ID token allow writing policy with variables taken from OIDC claims, like AWS. However they don't allow string operations, so it would be useful if repository_name claim is given by GitHub Actions.

For instance, workflow jobs which push Docker images to a cloud provider like AWS, we can reuse same IAM role and policy with multiple workflow and repos, because the policy is straightforward and simple. If GitHub Actions provide repository_name claim, we can restrict write access to a Docker registry with the same name.

[ethomson]

Thanks for the feedback @sorah - I've asked the team responsible for OIDC to take a look at this.

[N-Usha]

@sorah , Thanks for the feedback. Quickly checking if you have checked this AWS documentation about its support for String Condition Operators , in specific "StringLike" which supports pattern matching and could potentially help your use-case.

In GitHub "#{owner}/#{name}" is a unique string rather than just the "#{name}" and hence was our rationale to not make it a separate claim. However we will evaluate our decision if we hear this request from more customers. Thanks!

[roskelleycj]

@N-Usha I think that there are two use cases and Github OIDC has attempted to smash those into one use case. Hence the suggestion by @sorah .

The two use cases are:

• Trust a Github OIDC claims
• Identity Policy based on Github OIDC claims

Example of Trust a Github OIDC claims

In an IAM Role there is a trust policy that can be defined. The Github OIDC claim for the 'sub' can be used to define trust associated w/ a trusted github organization.

Effect: Allow
Action: sts:AssumeRoleWithWebIdentity
Principal:
  Federated: !Ref GithubOidc
Condition:
  StringLike:
    token.actions.githubusercontent.com:sub: repo:my-awesome-org/*:ref:refs/heads/main

Assuming that I was the owner of the my-awesome-org than this IAM Role's trust policy AND Github's OIDC would be combined to allow my GHA to assume this role and perform AWS related actions. And only if it was from the 'main' branch for any repo in the organization. This is powerful, and very easy to achieve today.

Example of Identity Policy based on Github OIDC claims

In an IAM Role you an define policy statements that control access to specific resources. The Github OIDC claim for 'repository' can be used to define a resource that is named after the full repository name. For example if there was a GHA that performed a copy of assets from the repository's checkout to an S3 bucket keyspace:

{
  "Action": [
    "s3:GetObject",
    "s3:DeleteObject",
    "s3:PutObject"
  ],
  "Effect": "Allow",
  "Resource": [
    "arn:aws:s3:::my-awesome/env/prod/${aws:PrincipalTag/repository}/private/*",
    "arn:aws:s3:::my-awesome/env/prod/${aws:PrincipalTag/repository}/shared/*"
  ],
  "Sid": "1"
}

This policy would allow ONLY the matching full repo name to GET/PUT/DELETE to that specific S3 keyspace in that specific bucket.
For example if the repo 'my-cool-repo' has assets that are copied by the GHA which has assumed the Role it would could put objects at the following S3 keyspace:

my-awesome/env/prod/my-awesome-org/my-cool-repo/private/<some content>

If another repo 'my-bad-repo' attempted to assume the same role it would only have permissions to GET/PUT/DELETE to its own S3 keyspace. If that repo used a GHA that tried to write to the my-awesome/env/prod/my-awesome-org/my-cool-repo/private/<some content> an Access Denied message would be returned. The repo 'my-bad-repo' can only write to this S3 keyspace:

my-awesome/env/prod/my-awesome-org/my-bad-repo/private/<some content>

And now we get to the use case that requests that Github OIDC include a 'repository_name' claim. If for some reason my organization does not care to place the Github owner name in the S3 bucket keyspace I'm not able to do that easily. In other words I would like to write this IAM policy statement:

{
  "Action": [
    "s3:GetObject",
    "s3:DeleteObject",
    "s3:PutObject"
  ],
  "Effect": "Allow",
  "Resource": [
    "arn:aws:s3:::my-awesome/env/prod/${aws:PrincipalTag/repository_name}/private/*",
    "arn:aws:s3:::my-awesome/env/prod/${aws:PrincipalTag/repository_name}/shared/*"
  ],
  "Sid": "1"
}

This policy no longer allows the Github owner to be placed in the S3 keyspace.

Because this use case was not considered. I am forced to find a work around. That work around involves more infrastructure in AWS or causes what I term double assuming. E.g., assume one role, that can assume another role and the correct Tags can be added to the session for the second role. Neither of these solutions are easily maintained and have the potential for introducing trust issues. The best solution is for Github OIDC to work w/ AWS' requirements for the Tagged session using the OIDC claims that include the repository_name.

BTW, I will note that Github OIDC is broken if you want Github OIDC to work with a GHA to assume the role and a GHA to use the assumed role's session. :-( So, you have to make the work around anyway if you want to trust establish trust. It is just a pain that Github OIDC does not work well w/ AWS.

[ryan-vance-cresta]

The resource name matching is exactly the use case I have as well.

Example from previous comment to make it clear:

{
  "Action": [
    "s3:GetObject",
    "s3:DeleteObject",
    "s3:PutObject"
  ],
  "Effect": "Allow",
  "Resource": [
    "arn:aws:s3:::my-awesome/env/prod/${aws:PrincipalTag/repository_name}/private/*",
    "arn:aws:s3:::my-awesome/env/prod/${aws:PrincipalTag/repository_name}/shared/*"
  ],
  "Sid": "1"
}

Adding a new claim such as repository_name, that does not include the owner, would be very useful. @N-Usha is this something that can still be considered?

[the-real-mathew-moon]

I'd like to 👍 this as well. One use case is for enforcing the Session Name to match the repository's name based on the JWT. Something like this:

{
  "Statement": [
    "Effect": "Allow",
    "Action": ["sts:AssumeRoleWithWebIdentity", "sts:TagSession"],
    "Principal": {
      "Federated": "arn:aws:iam::123456789098:oidc-provider/token.actions.githubusercontent.com"
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:repository_owner": "my-org",
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:iss": "https://token.actions.githubusercontent.com",
          "aws:RequestTag/repository": "${token.actions.githubusercontent.com:repository}",
          "aws:RequestTag/repository_name": "${token.actions.githubusercontent.com:repository_name}",
          "sts:SessionName": "${token.actions.githubusercontent.com:repository_name}"
        },
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::123456789098:role/github-deploy/*"
        }
      }
    }
  ]
}

This ensures we have consistency when looking through cloudwatch as well as gives us the flexibility to allow resources based on the short name of the repository, excluding the org. The issue for session names is that the / is not an allowed character. I think, while well intentioned, trying to shoehorn everything to use the combined org and repo name as an identifier is too prescriptive and overlooks other use cases. IMO we need both.