Managing Repository Metadata Signing Keys

This document covers the generic process for managing repository metadata signing keys. For PackageCloud-specific implementation details, see manage PackageCloud repository metadata signing keys.

Overview

Repository metadata signing keys are used to sign repository metadata, giving users certainty that the metadata was generated by the repository provider. This process involves:

1. Requesting access to the key management system
2. Generating or extending GPG keys
3. Updating the key in the key management system
4. Cleaning up local copies

Prerequisites

• Member of the appropriate team (e.g., Distribution team for PackageCloud)
• Access to Okta for authentication
• GPG tools installed locally

Process

1. Request Access

Create an access request issue to obtain read/write access to the signing key:

1. Create access request issue
2. For System(s), specify Okta Group Membership.
3. For System Name, specify the appropriate group (e.g., Okta Group: Team - Distribution - Packagecloud Repository Metadata Signing Key).
4. For Justification for this access, provide context about the key update needed.
5. Follow the instructions in the issue to get your AR approved & actioned by the provisioners.

2. Generate or Extend GPG Key

Choose one of the following:

Generate a new GPG key pair if you are rotating the key:

• Follow the GPG key generation process for your system
• Export the private key in the appropriate format

Extend the expiry date if the current key is due to expire and you want to keep it:

• Obtain the existing private key from your key management system
• Import it locally
• Extend the expiration date
• Export the updated private key

The outcome of this step should be a new or extended private key ready for deployment.

3. Update Key in System

Deploy the key to your key management system. For system-specific instructions, see:

• PackageCloud
• Pulp

4. Validate Deployment

After deployment, validate that the key has been successfully updated. For system-specific validation steps, see:

• PackageCloud
• Pulp

5. Clean Up Local Copies

See purging local copies for detailed instructions on securely removing the private key from your local machine.

6. Revoke Access

Once the deployment is complete and validated, create an access change issue to revoke your temporary access:

1. Create access change issue
2. For System, specify Okta Group Membership.
3. For System Name, specify the appropriate group.
4. For Justification for this access change/removal, explain that the temporary access is no longer needed.
5. Assign the issue to the Okta provisioners as no approval is needed for access removal.