search

aws / aws-sam-cli

CLI tool to build, test, debug, and deploy Serverless applications using AWS SAM
https://aws.amazon.com/serverless/sam/
Apache License 2.0
6.51k stars 1.17k forks source link

Extending OIDC subject claims #4606

Open aksel opened 1 year ago

aksel commented 1 year ago

(I'm only speaking about the GitHub OIDC provider, as I'm not familiar with the others)

Currently, the OIDC subject claim is dependent on the branch name. https://github.com/aws/aws-sam-cli/blob/5e90c508d50fc57b786d1076bab351c3144ddd77/samcli/commands/pipeline/bootstrap/pipeline_oidc_provider.py#L88-L91

I'm trying to alter the workflow to run on pull_request events. However, the subject that GitHub uses is different for pull_request events: repo:$org/$repo:pull_request. So my workflow is being denied access, because the trust policy of the role does not match.

It is possible to customize the token claims on GitHub's side (link). But I think it makes sense to extend upon the trust policy configuration, to support e.g. pull request events.

For posterity, these are the resulting subject claims used in AssumeRoleWithWebIdentity:

Pull request:
"subjectFromWebIdentityToken": "repo:$org/$repo:pull_request"

On push:
"subjectFromWebIdentityToken": "repo:$org/$repo:ref:refs/heads/$branch-name",
aksel commented 1 year ago

For now, I've circumvented this by updating the SubjectClaim parameter of the pipeline CloudFormation stack to repo:$org/$repo:*, but it'd be nice to be able to specify multiple subject claims there, too.

jfuss commented 1 year ago

@aksel Are you looking to have a CLI parameter for this or something else? I (personally) am not well verse in the sam pipeline command so would be good to understand the flow you are aiming to have.

aksel commented 1 year ago

As I understand it, the SubjectClaim parameter in the CloudFormation template is constructed using parameters found in pipelineconfig.toml. It would be nice to be able to extend that, so you can specify a list of subject claims.

aksel commented 1 year ago

My specific use-case, is that I've refactored the generated workflow file, so there's one for the overall pipeline, and another for the feature branches.

In addition to that, I'm now extending the template, so I can add more repositories: We have two different SAM applications, and I want to manage them with the same resources (bucket, roles, image repo).

aksel commented 1 year ago

I've updated the YAML in a fork, if you're interested in how I'm using it.

It's a breaking change, of course, and I'm hard-coding it to be GitHub Actions because I couldn't figure out how to dynamically construct the aud and sub condition keys. But the template does what I need it to do, which is support any number of repositories/branches/tags/etc

https://github.com/aksel/aws-sam-cli/blob/develop/samcli/lib/pipeline/bootstrap/stage_resources.yaml#L151

eliasbrange commented 2 months ago

Do you happen to have any news on this? Configuring the subject (and allowing more than one) is useful for deploying ephemeral environments from pull requests or using GitHub "environments."

The bootstrapping process only allows you to specify a repository and branch, resulting in a subject like repo:ORG/REPO:ref:refs/head/BRANCH. The other use cases requires the format to be: 

repo:ORG/REPO:environment:ENV
repo:ORG/REPO:pull_request

The generated pipeline from sam pipeline init even refers to using environments to add a manual approval step. That will not work with the bootstrapped role.