Skip to content

Allows AWS IAM to perform federated authentication based on github teams. Originally forked from https://github.com/TimothyJones/github-cognito-openid-wrapper

License

Notifications You must be signed in to change notification settings

alphagov/github-oidc-proxy

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

GitHub OpenID Connect Proxy

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.