Enforce SSO for our GitHub organisation

[kenoir]

We now have a GitHub enterprise supported account, we should take advantage of SSO.

We will need to:

• [x] Set up the Azure half of this with @wellingk
• [x] "Soft" enable SSO and test it works
• [x] Send comms to impacted parties on changed process
• [x] Ensure all existing users have an associated wellcome.org e-mail
• [x] Build an alternative to weco-bot, as it won't work anymore
• [ ] Enforce SSO
• [x] set up reusable workflow for stale PRs and formatting

[kenoir]

Pausing work for a sprint to allow users to adopt, other feature work to proceed.

[pollecuttn]

@kenoir I think this is completed, isn't it? Can this be closed?

[kenoir]

@kenoir I think this is completed, isn't it? Can this be closed?

Not yet, we still have weco-bot. We could schedule some work next sprint to look at this again.

[jamieparkinson]

What is weco-bot?

weco-bot is a machine user on GitHub that we use for a variety of automated actions. I believe this list to be exhaustive:

• Committing and pushing auto-formatting changes (example, equivalent scripts exist on most repos).
• Updating changelogs and pushing release tags (example, equivalents exist for other versioned repos eg terraform modules).
• Deploying our documentation site to GitHub pages (see script and docs)
• Creating automated pull requests for concepts pipeline date bumps and scala-libs version bumps.
• Adding and reading labels on wellcomecollection.org pull requests in service of user control over running e2e tests.
• Updating, pushing, and creating automated pull requests to document Miro suppressions.

How does it interact with GitHub?

weco-bot's current actions are achieved through 3 mechanisms:

1. Use of the git client to commit with the authorship email associated with weco-bot (wellcomedigitalplatform@wellcome.ac.uk) and to push using an SSH key for the weco-bot account.
2. Use of the GitHub API with a personal access token for the weco-bot account, to create and label PRs.
3. Use of the Docusaurus CLI to push to GitHub for GitHub Pages deployment, options documented here.

That is to say that weco-bot's identity is assumed by our CI servers using either:

1. An SSH key - for Buildkite agents, this is stored in an S3 bucket that is automatically accessed by the Elastic CI Stack instances.
2. A personal access token - tokens for various actions are stored in Secret Manager.

How can we use a GitHub app instead?

Authenticating as an app installation is appropriate for all of these use cases.

• Git client authentication - it is not possible to use SSH for GitHub app authentication, but we can use an installation access token for HTTPS-based git access as per the docs with a remote of the form https://x-access-token:TOKEN@github.com/owner/repo.git.
• API authentication - the installation access token can be used just like a personal access token.

While this seems straightforward, the mechanics of getting the access token in the right place are really quite complex. To get an installation access token, a machine first needs access to the app's private key in order to create a signed JWT with which to request the token.

My guess at a minimal implementation would involve something like the following:

• Private key stored in KMS or Secrets Manager
• A custom git credential helper installed on all agents to facilitate access with the git client (something like this)
• Some kind of scripting to get an access token for use with the GitHub APIs - possibly sharing implementation with the above.

This is quite achievable but not trivial - are we sure that the benefits of enforcing SSO outweigh the complexity/risk involved in this solution? There is of course an alternative approach where SSO is enforced and we create a machine user identity in Azure AD - is that a better solution?

[rcantin-w]

@agnesgaroux to have a look whether or not this can be closed/create new tickets if needed.

[agnesgaroux]

• Committing and pushing auto-formatting changes (example, equivalent scripts exist on most repos).
• Updating changelogs and pushing release tags (example, equivalents exist for other versioned repos eg terraform modules).
• Deploying our documentation site to GitHub pages (see script and docs)
• Creating automated pull requests for concepts pipeline date bumps and scala-libs version bumps.
• Adding and reading labels on wellcomecollection.org pull requests in service of user control over running e2e tests.
• Updating, pushing, and creating automated pull requests to document Miro suppressions.

TO DO

• Creating automated pull requests for concepts pipeline date bumps
• autoformat terraform: commit and push changes here. Also here
• other formatting, eg. prettier: commit and push changes
• terraform-aws modules: format and release
• Check no other versioned repo apart from terraform-aws and scala-libs

[kenoir]

The final part of this is migrating from Buildkite to GitHub actions so the weco-bot credentials are not required to allow that build system to check out from GitHub.

See https://github.com/wellcomecollection/platform/issues/5783