Signing Keys Configuration

Develocity Provenance Governor signs all published attestations using Dead Simple Signing Envelope (DSSE) for cryptographic integrity and authenticity. Signing keys are a best practice for any production deployment.

Signing keys are strongly recommended in production.

Without signing keys: Attestations are unsigned, cannot be reliably trusted, and policy validation cannot verify provenance integrity.
With signing keys: All attestations are DSSE-wrapped and cryptographically signed.

To enable signature validation in policies, you must also create a TrustedPublicKeys policy with your public key(s) (see verification).

Cheat Sheet: Key Naming & Property Conventions

Integration

Secret Key Pattern

ConfigMap Key Pattern

Required

Notes

Private Signing Key

signing.key.<KEY>.private-pem

n/a

Base64 PEM (see below for adding)

Public Signing Key

n/a

signing.key.<KEY>.public-pem

PEM block

application.yml key (alternate)

signing.keys[0].key

n/a

PEM private under array

Artifactory Instance

artifactory.instances.<NAME>.access-token

artifactory.instances.<NAME>.uri

For storing attestations

Basic Identity

basic.identities.<NAME>

n/a

bcrypt recommended

Use unique, timestamped or versioned KEY names for rotation: e.g. org1-20250220 or signing-key-v2. Use the same key name for both private and public components.

Generating and Configuring Signing Keys

You may use any of these supported signing algorithms for attestation generation:

Ed25519 (recommended): Small, fast, secure. Most deployments should use this.
ECDSA prime256v1: Standard elliptic curve, compatible with Artifactory.
RSA 2048: Larger signatures; legacy, use only if required.

Step 1: Generate a Key Pair

Ed25519 (Recommended)

openssl genpkey -algorithm Ed25519 -out private-key.pem
openssl pkey -in private-key.pem -pubout -out public-key.pem

ECDSA prime256v1

openssl ecparam -name prime256v1 -genkey -noout -out ec_private.key
openssl pkcs8 -topk8 -inform PEM -in ec_private.key -outform PEM -nocrypt -out private-key.pem
openssl ec -in ec_private.key -pubout -out public-key.pem

RSA 2048

openssl genrsa -out private-key.pem 2048
openssl rsa -in private-key.pem -pubout -out public-key.pem

Use naming patterns (timestamps/versions) in all filenames and secret keys for clarity and rotation (e.g. org1-20250315, signing-key-v2).

Step 2: Add Keys to Your Kubernetes Secrets

You can add keys in three ways:

Option A: application.yml (stringData)

apiVersion: v1
kind: Secret
metadata:
  name: secrets
  namespace: develocity-provenance-governor
type: Opaque
stringData:
  application.yml: |
    signing:
      keys:
        - key: |
            -----BEGIN PRIVATE KEY-----
            ...
            -----END PRIVATE KEY-----

Option B: Individual Properties (base64-encoded)

base64 -i private-key.pem | pbcopy
kubectl edit secret secrets --namespace develocity-provenance-governor

Then, under data::

data:
  signing.key.MY_KEY_NAME.private-pem: <PASTE_BASE64_PRIVATE_KEY>

For the public key:

cat public-key.pem | sed 's/^/    /' | pbcopy
kubectl edit configmap properties --namespace develocity-provenance-governor

And under data::

data:
  signing.key.MY_KEY_NAME.public-pem: |
    -----BEGIN PUBLIC KEY-----
    ...
    -----END PUBLIC KEY-----

Option C: Directory-Based Key Management (Recommended for Multiple/Rotating Keys)

When managing multiple signing keys, consider organizing them in a keys/ directory with descriptive, timestamped filenames for easy rotation:

mkdir -p keys/
cp private-key.pem keys/signing.key.20250401.private-pem
cp public-key.pem keys/signing.key.20250401.public-pem

Your keys directory should look like:

keys/
  signing.key.20250401.private-pem
  signing.key.20250401.public-pem

Create the Kubernetes secret from all files in the directory:

kubectl create secret generic signing-keys \
  --from-file="keys/" \
  --namespace develocity-provenance-governor \
  --dry-run=client -o yaml > signing-keys-secret.yaml

# Review and apply
cat signing-keys-secret.yaml
kubectl apply -f signing-keys-secret.yaml

This method is ideal for organizations with multiple keys or scheduled rotations, allowing bulk updates and version tracking.

Key Naming: Use a unique, date- or version-based key name (such as org1-20250315, signing-key-v3). Use the exact same key name for both private and public keys, and rotate as needed.

Verifying Key Loading in Logs

After updating your secrets/configmaps and restarting the deployment, you should see logs such as:

Signature support enabled, for key pair [name:MY_KEY_NAME:keyid:XXXXXX:signing-algorithm:ed25519]

Where MY_KEY_NAME matches your configured key, and keyid is a short digest fingerprint.

Signature Validation and TrustedPublicKeys Policy

Simply signing attestations doesn’t enable signature validation in policies: you must configure the set of trusted public keys.

Validation requires a TrustedPublicKeys policy including your public key, even when evaluating attestations from the same instance.

To enable signature validation:

Extract the public key PEM (from generation above).
Create a TrustedPublicKeys policy and add your public key:

apiVersion: policy.gradle.com/v1
kind: TrustedPublicKeys
metadata:
  name: my-gov-signing-keys
spec:
  keys:
    org1-20250315:
      pem: |
        -----BEGIN PUBLIC KEY-----
        ...
        -----END PUBLIC KEY-----

Deploy the policy to the policies ConfigMap.
Restart the deployment.

Policy evaluation will only validate signatures from keys listed in the TrustedPublicKeys policy.

Uploading Public Keys to Artifactory (Optional)

If you are using Artifactory for attestation storage and wish Artifactory to verify signatures:

Log in to Artifactory UI
Go to Administration → Security → Key Management → Public Keys
Click Add Keys, provide an alias (for human reference only), paste your public key
Save the key; the cryptographic match uses the key ID, not the alias.

Artifactory uses the cryptographic key, not the alias, for attestation verification.