GPG Keys for Repository Metadata Signing

Packagecloud, the application that powers packages.gitlab.com, supports two different types of GPG signatures: packages and repository metadata.

This document is concerned with repository metadata signing keys. For package signing, see manage package signing keys.

Repository Metadata

Packagecloud signs repository metadata using a private key that is either generated by Packagecloud or generated externally and configured in the app. This is a security feature that gives our users certainty that the repository metadata was generated by us.

We manage the key externally so we provide the private key to Packagecloud using a Kubernetes secret. This secret is synced from Vault, which is ultimately where the key lives and where any changes need to take place. Read on to find out how to make changes to the key (e.g., due to expiry extension or key rotation).

Location of the Key

The private key lives in Vault under the path k8s/ops-gitlab-gke/packagecloud/gpg.

Process

This process should be carried out by a member of the Distribution team.

Create AR to request read/write access to the secret in Vault:
1. Create access request issue
2. For System(s), specify Okta Group Membership.
3. For System Name, specify: Okta Group: Team - Distribution - Packagecloud Repository Metadata Signing Key.
4. For Justification for this access, specify:
```
Temporary group membership required to update the Packagecloud repository metadata
signing key in Vault. Process outlined in https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/packagecloud/manage-repository-metadata-signing-keys.md.
```
5. Follow the instructions in the issue to get your AR approved & actioned by the provisioners.
Generate GPG keys pair OR extend expiry date on existing keys

If you are looking to rotate the key, then you should generate a new GPG key pair.

If the current key is due to expire soon and you are happy to keep the existing key, then you can just extend the expiry. You will need to import the existing private key, which you can obtain by going to https://vault.gitlab.net (sign-in using Okta) and accessing k8s/ops-gitlab-gke/packagecloud/gpg. If you see an access denied message then you will need to reach out to #it_help and confirm that you were added to the correct group.

The outcome of this step should be a new or extended private key.
Once your AR has been actioned, update the secret in Vault:
1. Open https://vault.gitlab.net and sign-in using Okta.
2. Head to the path: k8s/ops-gitlab-gke/packagecloud/gpg.
3. Click on Create new version.
4. Update the value of private_key with the contents of your exported private key.
5. Click Save.
6. Take note of the version of the secret (next to Create new version). You’ll need this next!
Update gitlab-helmfiles:
1. Update version to the new version number from the previous step: here and here.
2. Update secretName to match: here.
3. File an MR with the above changes and have someone in #infrastructure-lounge review/approve/merge it for you.

Validation:

Once the gitlab-helmfiles CI pipeline has finished, you’re ready to do a quick test:

$ curl -s https://packages.gitlab.com/gpg.key | gpg --show-key
pub   rsa4096 2020-03-02 [SC] [expires: 2024-03-01]
      F6403F6544A38863DAA0B6E03F01618A51312F3F
uid                      GitLab B.V. (package repository signing key) <[email protected]>
sub   rsa4096 2020-03-02 [E] [expires: 2024-03-01]

Check that the fingerprint & expiry matches your new/extended key.

Create AR to revoke read/write access to the secret in Vault:
1. Create access change issue
2. For System, specify Okta Group Membership.
3. For System Name, specify: Okta Group.
4. For Other details, specify: Group Name: Team - Distribution - Packagecloud Repository Metadata Signing Key.
5. For Justification for this access change/removal, specify:
```
Temporary group membership no longer required. See
https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/packagecloud/manage-repository-metadata-signing-keys.md for more info.
```
6. Assign the issue to the Okta provisioners as no approval is needed for access removal.
Clean up after yourself.