This is a proxy that exposes team membership information from Github's OAuth 2.0 interface as an OpenID Connect Authorization Server, with the main aim being to allow AWS IAM Federated Authentication to grant access to IAM roles based on that information.
It is originally a fork of https://github.com/TimothyJones/github-cognito-openid-wrapper, with modifications to support this use-case.
To work around AWS IAM's less-than-comprehensive support for arbitrary OIDC claims, the github team ids a user is a member of are passed as a map of session tags. An IAM assume role policy document to grant access based on one of these values should look something along the lines of:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "${aws_iam_openid_connect_provider.foo.arn}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"${var.connector_host_path}:aud": "${var.github_client_id}",
"aws:RequestTag/t${var.github_team_numeric_id}": "t"
}
}
},
{
"Sid": "AllowPassSessionTagsAndTransitive",
"Effect": "Allow",
"Action": "sts:TagSession",
"Principal": {
"Federated": "${aws_iam_openid_connect_provider.foo.arn}"
}
}
]
}
(the github team ids have indeed been prefixed with a t in the claims to avoid any
possibility of string/integer leading-zero ambiguity)
To deploy a new instance of this app, the easiest approach is to instantiate the deploy pipeline on a concourse instance and keep feeding it with secrets until it stops complaining. Alternatively the terraform module could be directly used, though an external build step would be needed which ran
$ npm install
$ npm run build
to generate the dist-lambda/ directory expected by the terraform module.
A keypair suitable for the deploy pipeline's *-jwks-(public|private)-key
variables can be generated by the create-key script. This will
place files jwtRS256.key and jwtRS256.key.pub in the project root, which is where
the npm run build script would expect to find them too if using the bare-terraform
technique.