Using a GitHub App instead of PATs

[haydentherapper]

Description

The most significant downside of PATs is their frequent expiration. I'd propose exploring GitHub Apps as an alternative.

This blog post summarizes the steps succinctly, with official instructions here. An org admin will create the app at the org level. You can assign per-repo permissions (which we would do for root-signing-staging and root-signing). You will need an org-level secret private key.

Chainguard just released https://github.com/octo-sts/action (more details) which has the nice property of limiting access to the private key, which lives in KMS, to only the GitHub App. We wouldn't leverage the federation features though, so a simple app might be sufficient.

[jku]

The steps for the workflow user seems to be

• Setup
  • Store the app ID as a GitHub Actions variable
  • Store apps private key as GitHub Actions secret
  • Install app in the org for the specific repository, define permissions
• Usage in workflows
  • generate token with actions/create-github-app-token
  • Provide token to actions that need the tuf-on-ci token

The usage part unfortunately seems to require changing the workflow files which I'd rather avoid -- we can do it but the further the root-signing workflows deviate from the tuf-on-ci template workflows, the more likely it is that they won't be updated correctly when tuf-on-ci changes. I'll think about it... maybe the tuf-on-ci actions can somehow handle this.

Chainguard just released https://github.com/octo-sts/action (more details) which has the nice property of limiting access to the private key, which lives in KMS, to only the GitHub App.

Stuffing a private key in GH secrets really is the weirdest part of the GH App design... it's just so pointless: it seems to me we gain zero security with this exercise, the only benefit is that GH App does not force re-creating the private key regularly -- yay we can make the insecure GH secrets even longer lived 😂

Adding another (unsupported) "KMS" doesn't sound appealing either but the idea is clearly correct and we would be storing less secrets in GH secrets...

[jku]

octo-sts could likely be used by the actions without modifying the workflows at all: if there is a octo-sts trust policy file in the repo, then generate token using octo-sts... This might be a little too magical though

(not saying we should use it, just pointing out it's likely technically easy)

[cpanato]

we can use :) as i help to build that i would say that is good :)

[haydentherapper]

Stuffing a private key in GH secrets really is the weirdest part of the GH App design... it's just so pointless: it seems to me we gain zero security with this exercise, the only benefit is that GH App does not force re-creating the private key regularly

I agree there's no security benefit from this, but the operational benefit of not having to deal with periodic token regenerations and risk breaking workflows is nice.

I'd be up for trying out octo-sts, though it might be overkill for our use case since we don't need the federation from non-GitHub platforms.

[jku]

I had a look. Some possible solutions:

1. octo-sts integrated in tuf-on-ci
   • requires no workflow changes in root-signing-staging and other users: this would be great for workflow maintainability
   • 👎 adds three steps to four composite actions in tuf-on-ci, complexity is non-trivial
   • 👎 is probably a bit too magical: just adding the .github/chainguard/tuf-on-ci.sts.yaml in root-signing-staging enables the account impersonation
2. octo-sts used in root-signing-staging workflows
   • requires changes in 6 workflows (add octo-sts step, modify token argument in existing step)
   • 👎 workflow maintenance is trickier in future as bringing in tuf-on-ci changes requires more careful merging
3. github app (without octo-sts) used in root-signing-staging workflows
   • requires changes in 6 workflows (add actions/create-github-app-token step, modify token argument in existing step)
   • 👎 workflow maintenance is trickier in future as bringing in tuf-on-ci changes requires more careful merging
   • 👎 we now store long lived private keys in GitHub secrets

I was really hoping the root-signing-setup did not diverge far from tuf-on-ci template workflows but... the last two options still seem most reasonable for now.

[haydentherapper]

I also found out about https://github.com/abcxyz/github-token-minter, which is similar to octo-sts, with the added benefit of Terraform configuration so that this could be replicated in other cloud environments for other deployments of TUF-on-CI.

[jku]

The most significant downside of PATs is their frequent expiration

Just a side note on this: the fine grained PATs can have a life time of up to 1 year. it's still annoying but we don't have use 3 month tokens if we're fine with a longer life time.

[jku]

Stuffing a private key in GH secrets really is the weirdest part of the GH App design... it's just so pointless: it seems to me we gain zero security with this exercise, the only benefit is that GH App does not force re-creating the private key regularly -- yay we can make the insecure GH secrets even longer lived

I still stand by 90% of this critique but Frederik pointed out that with the app at least we only expose short lived tokens to actions. This does make sense: if an action we use is compromised it still gets full token permissions but at least the lifetime of the token is limited

Let's look at using a GH app after the production migration is done

[jku]

Just to keep track of things: sigstore/TSC#51 (installing octo-sts in the org) did not happen