Working example of Github OIDC and using Session Tags in IAM policies?

[roskelleycj]

I'm trying to figure out how one would achieve using Github's OIDC w/ AWS AssumeRoleWithWebIdentity.
I can get Github OIDC and aws-actions/configure-aws-credentials to work really well straight out of the box and as advertised. 🎉 (And thank you for making it easy.)

However, when I try to do more complex conditions in IAM policies it seems to fall apart.

By more complex I mean to use Session Tags. E.g., aws:PrincipalTag:Repository which seems to be documented to work. However, this rather cryptic message is also present:

Note that for WebIdentity role assumption, the session tags have to be included in the encoded WebIdentity token. This means that Tags can only be supplied by the OIDC provider and not set during the AssumeRoleWithWebIdentity API call within the Action. 

And in fact when you inspect the code those 'documented session tags' are deleted when using a WebIdentity or webIdentityTokenFile.

And the document seems to indicate that if you need 'Session Tags' you need to look to the Github OIDC for providing those. So how does one do that? How do you provide the expected AWS Session Tag contract in the JWT? When all that you can use to configure Github OIDC is this:

    permissions:
        id-token: write

There does appear to be one other poor soul that has bumped into the same problem.

Is anyone willing and able to educate the uneducated? Thank you for your kindness, in advance. 😊

[roskelleycj]

Correct me if I'm wrong, but most of the examples I found do a double assume role. E.g., the first Assumed Role can only be assumed by the Github OIDC prepared case, and that assumed role only has one permission and that is to allow a second role to be assumed AND at that point aws-actions/configure-aws-credentails can be used again. And it does NOT skip tagging when assuming the second role. And of course this does work!

However, there is nothing preventing anyone inside a github org / repo / branch from cloning the aws-actions/configure-aws-credentials code into their own code base (or similar code), and then using it as a local 'action' and then subverting that code to use a different github org/repo/branch and in essence redirect the security constraints on the second assume role. The rogue code can determine what values to give the session tags at the time the second role is assumed. I know, it is a lot of 'what ifs'. However, in a security conscience environment you don't want any of those what ifs to come to pass, so you ensure that they can not.

That is why Github OIDC w/ the Cloud provider is so great. It establishes w/o question the trusted entity. The issue is that it is weakly defined, thus leading to work arounds that could subvert the security that was intended.

Again, the AWS Session Tags needs to be accomplished w/ the Github OIDC is executed.

For example this invokes the Github OIDC to generate a JWT:

curl -s -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com"

The returned JWT might look like this: (in fact this is exactly what I got back from the above curl, w/ most values changed for security purposes in this thread)

{
  "jti": "<jti>",
  "sub": "repo:<github repo>/<repo name>:ref:refs/heads/<branch name>",
  "aud": "sts.amazonaws.com",
  "ref": "refs/heads/<branch name>,
  "sha": "<sha>",
  "repository": "<github org>/<repo name>",
  "repository_owner": "<github org>",
  "repository_owner_id": "<repository owner id>",
  "run_id": "###",
  "run_number": "##",
  "run_attempt": "#",
  "repository_id": "<repository id>",
  "actor_id": "<actor id>",
  "actor": "<actor name>",
  "workflow": "<workflow name>
  "head_ref": "",
  "base_ref": "",
  "event_name": "push",
  "ref_type": "branch",
  "job_workflow_ref": "<github org>/<repo name>/.github/workflows/<workflow file name>.yml@refs/heads/<branch name>",
  "iss": "https://token.actions.githubusercontent.com/",
  "nbf": ###,
  "exp": ###,
  "iat": ###
}

and ideally, since I specified audience=sts.amazonaws.com when I invoked the Github OIDC it should additionally include the following in the JWT: (look at the very bottom of the JWT example)

{
  "jti": "<jti>",
  "sub": "repo:<github repo>/<repo name>:ref:refs/heads/<branch name>",
  "aud": "sts.amazonaws.com",
  "ref": "refs/heads/<branch name>,
  "sha": "<sha>",
  "repository": "<github org>/<repo name>",
  "repository_owner": "<github org>",
  "repository_owner_id": "<repository owner id>",
  "run_id": "###",
  "run_number": "##",
  "run_attempt": "#",
  "repository_id": "<repository id>",
  "actor_id": "<actor id>",
  "actor": "<actor name>",
  "workflow": "<workflow name>
  "head_ref": "",
  "base_ref": "",
  "event_name": "push",
  "ref_type": "branch",
  "job_workflow_ref": "<github org>/<repo name>/.github/workflows/<workflow file name>.yml@refs/heads/<branch name>",
  "iss": "https://token.actions.githubusercontent.com/",
  "nbf": ###,
  "exp": ###,
  "iat": ###,

  "https://aws.amazon.com/tags": {
        "principal_tags": {
            "Repository": ["<GITHUB_REPOSITORY>"],
            "Actor": ["<GITHUB_ACTOR>"],
            "Branch": ["<GITHUB_REF>"],
            "Commit": ["<GITHUB_SHA>"],
            "Workflow": ["<GITHUB_WORKFLOW>"]
        }
    }
}

or something similar, that meets the contract for AWS IAM roles to establish BOTH the trust for the role, as well as to utilize the session tags in IAM policies associated w/ the role. This would prevent having two roles AND would allow one to create an AWS IAM role that is both assumable by Github actions AND contains exact information in the session tags to allow complex policies to be created and governed by the values of the aws:PrincipalTag. E.g., I can have policies that are specific to a github org, or repo or branch or workflow. This really provides very powerful constructs to allow the ease of workflows in Github and utilizing AWS Resources for CI/CD.

🤷 Again, I'm probably uneducated and need more education to understand what the expected approach is.

[manics]

I'm not sure if this helps you, but the example in the README works fine if you add a Policies section to the role with the permissions. Are you needing the second assume-role to achieve something else?

[roskelleycj]

@manics, yes I've accomplished that part. But if you notice there are no 'policies'. They are missing. That is the part that I want to add. And more importantly I want to add them to the role that can be assumed by aws-actions/configure-aws-credentials. Not a two role combination.

However, because the Github OIDC is not implemented correctly (as to my understanding ) then you can not make policies in that role w/o making them very, very specific to either the github org or the repo/etc. E.g., I have 1600+ repos spread over a number of github organizations. Meaning I would have a large number of roles.

The ideal is what AWS describes in that if the following (or something like it) is provided by Github OIDC:

"https://aws.amazon.com/tags": {
        "principal_tags": {
            "Repository": ["<GITHUB_REPOSITORY>"],
            "Actor": ["<GITHUB_ACTOR>"],
            "Branch": ["<GITHUB_REF>"],
            "Commit": ["<GITHUB_SHA>"],
            "Workflow": ["<GITHUB_WORKFLOW>"]
        }
    }

then a very few roles can be defined AND have very specific policies that include the Github provided information. Information that can not be spoofed.

For example. Suppose I have an S3 bucket that we use for 'dynamic configuration'. And further suppose that Github OIDC provided the AWS Session Tags as described. Then I could add the following policy statement to the Role:

{
  "Action": [
    "s3:GetObject",
    "s3:DeleteObject",
    "s3:PutObject"
  ],
  "Effect": "Allow",
  "Resource": [
    "<some bucket arn>/env/prod/repo/${aws:PrincipalTag/Repository}/private/*",
    "<some bucket arn>/env/prod/repo/${aws:PrincipalTag/Repository}/shared/*",
  ]
}

If you'll notice, I'm able to use the <GITHUB_REPOSITORY> from the AWS Session Tag in the policy. This means that when I create a github workflow that uses Github OIDC along w/ aws-actions/configure-aws-credentials I have a single role for all 1600+ repos in all the github organizations that I trust w/ this role to copy files from the content in the repo into the S3 bucket. E.g., I don't have to have lots of roles per repo / github org combination.

This is the power of Github OIDC and AWS, when implemented correctly.

[roskelleycj]

Another thought. If when the Github OIDC is generated the '<GITHUB_ACTION>' could be identified and added to the AWS Session Tags, then this would allow another layer of trust. E.g., I'm assuming a lot about actions. In that if actions are sourced from github repos, and all of the security that github org/repos imply, then I have one additional layer of trust that can be established. In that I can make roles that only trust aws-actions/configure-aws-credentials. Or if I really want to go to the work of writing my own action. I can place that action in a github org/repo that only 3 people have access to, thus limiting the possible attack vectors.

Again, this too would be quite powerful in the Github OIDC and AWS combination.

[jasondewitt]

I will chime in with my use case, because I am facing similar issues.

I have a working OIDC connection to a single role in one of my AWS accounts, but I have over 100 accounts to set up for OIDC. This connection works and access can be controlled by allowing each repo in the IAM role trust policy. I was planning to create an OIDC provider and role in each account, but quickly found that this will not easily scale.

I would like to use a single account in our network as the entry point for OIDC connections, and then that session will assume another role in the target account. This is currently documented and working, however, in these secondary assumed roles, in the target aws accounts, I want to be able to have a condition which checks which repo the request is coming from in the IAM trust policy.

It appears this should be possible with Session Tagging, but like @roskelleycj has been demonstrating, no session tags are being set on the OIDC session. The documentation for this action appears to indicate that that Session Tags are supported for OIDC sessions, but it is unclear if that is actually the case:

The action will use session tagging by default during role assumption. Note that for WebIdentity role assumption, the session tags have to be included in the encoded WebIdentity token. This means that Tags can only be supplied by the OIDC provider and not set during the AssumeRoleWithWebIdentity API call within the Action.

Is this a deficency in GitHub's JWT implementation? or something to fix in this action? Its starting to look like this is required on the GitHub side and is not supported...

[roskelleycj]

Looks like @glassechidna ran into a similar issue and made a novel workaround. Although, his approach to the problem is different than mine. In that he wants AWS to change their STS implementation. 🤷 I figured since AWS documented what their approach AND Github OIDC shows that you must provide the audience=sts.amazonaws.com that the two tunnels would align in the middle somehow. 😊

[roddyherries]

Hi @roskelleycj, I am facing the same challenge. If these custom claims were included in the JWT generated by Github OIDC it would be the missing piece to writing powerful and secure IAM policies. I am now faced with the choice between permissive single policies shared by many GH repos or creating specific policies for each repo. Have you had any traction with Github on this?

[RichiCoder1]

Unfortunately the fact that the tags must be in the JWT makes this a GitHub issue more than an AWS issue. AFAIK, the only thing that GitHub lets consumers modify about the JWT is the Audience. Otherwise it's entirely immutable. So either GitHub would need to allow appending extra claims or AWS would need to add session tag mapping to OIDC providers.

[peterwoodworth]

You nailed it @RichiCoder1, this needs to be defined in the JWT because AssumeRoleWithWebIdentity() lacks a tags parameter like AssumeRole() does. Meaning AWS doesn't provide session tag mapping for OIDC directly.

However, I'm unsure how or if there is a way to modify the JWT from GitHub in the necessary fashion. If anyone knows a way to do this, please leave a comment 🙂

[JTarasovic]

Does this announcement remove the service limitation?
https://github.blog/changelog/2022-10-18-github-actionsopenid-connect-support-enhanced-to-enable-secure-cloud-deployments-at-scale/

[RichiCoder1]

Unfortunately no. That just allows customizing the subject claim, while this ticket requires adding additional custom claims.

[ScottGuymer]

I too am running into the same issue.

I want to be able to write an OIDC policy that will allow each repo to write to its own folder in a bucket. We have over 8k repos so not really an option to have a role for each repo.

The claims are there in the JWT, but AWS doesnt let you access them directly
The spec for tags is there from AWS, just GH doesnt implement it..

This could be fixed from either end really.

Being able to use the claims or the tags would be very powerful for a lot of things.

Is anyone aware if GH are working on this?