Good Practices for handling service account GPG keys

[josecelano]

WIP: defining the scope for the discussion.

This discussion originated here.

Sometimes you want to sign things automatically on a CI/CD pipeline. In the GitHub environment we usually sign commits with:

• A user's GPG key.
• A service GitHub account. For example a Bot account.

The GPG private key is a signing key. Ideally a subkey.

You can handle the GPG keys used by automated tasks in different ways. Some ideas we have discussed:

1. One organization bot account (one single bot with many GPG keys)
2. One bot account per user (each organization member has their own bots)

We want to discuss the pros and cons of both options or find other alternatives.

The initial list of pros and cons for those two cases:

One organization bot account

How it works

• The organization has a bot account (GitHub account).
• All org admins have access to that account.
• The bot account has an SSH and GPG key for each maintainer.
• Maintainers can give admins their public primary GPG keys so that admins can add them to the bot accounts.
• Maintainers (and external collaborators and in general users with "Write" access) can create and sign commits on behave of the org bot.

Pros

• TODO

Cons

• TODO

One bot account per user

How it works

TODO

Pros

• TODO

Cons

• TODO

Notes

• We are not discussing whether to use bots (as maintainers) or not. We are discussing alternatives if you use bots (identities who sign commits automatically).
• We are not going to describe how to rotate GPG keys (with expiration date, revoking the GPG key and creating a new signing subkey).
• Explain how to:
  • Add new GPG keys for users with "write" permission.
  • Delete GPG keys when the user has no longer "write" access.
  • Replace GPG keys on the repos (secrets) affected when there is a new "writer" or a "writer" was removed.