Hi, I'd like to propose adding support for signing Docker registry tokens using AWS KMS as an alternative to file-based private keys.
Motivation
In the current setup, the private key used to sign JWTs must be stored on disk (token.key). In production environments — especially in Kubernetes or ECS — this creates a risk: if the node or container is compromised, the signing key is exposed.
AWS KMS keeps the private key material inside a hardware security module (HSM) and never exposes it. Every signing operation goes through the KMS API, which also provides:
- Full audit trail via AWS CloudTrail
- Key rotation without redeploying instances
- No key distribution needed across replicas
Proposed config
The feature would be opt-in via a new kms_signer block under token, mutually exclusive with certificate/key:
token:
issuer: "my-registry"
expiration: 900
kms_signer:
key_id: "arn:aws:kms:us-east-1:123456789:key/xxxxxxxx"
region: "us-east-1" # optional, falls back to AWS default chainImplementation notes
- Supported key types: RSA (RS256) and ECDSA P-256 (ES256) — both compatible with the Docker token spec
- The public key and keyID (RFC 7638 thumbprint) are fetched from KMS at startup via GetPublicKey
- Signing uses MessageType=RAW so KMS handles the SHA-256 hash internally, consistent with the existing libtrust behaviour
- ECDSA signatures from KMS are in DER format and are converted to R||S as required by the JOSE spec
- AWS credentials are resolved via the standard chain (env vars,
~/.aws/credentials, IAM role) — no new credential config needed
- Existing file-based signing is unchanged
I already have a working implementation if you'd like to see a PR. Happy to adjust the design based on your feedback.
Hi, I'd like to propose adding support for signing Docker registry tokens using AWS KMS as an alternative to file-based private keys.
Motivation
In the current setup, the private key used to sign JWTs must be stored on disk (token.key). In production environments — especially in Kubernetes or ECS — this creates a risk: if the node or container is compromised, the signing key is exposed.
AWS KMS keeps the private key material inside a hardware security module (HSM) and never exposes it. Every signing operation goes through the KMS API, which also provides:
Proposed config
The feature would be opt-in via a new kms_signer block under token, mutually exclusive with certificate/key:
Implementation notes
~/.aws/credentials, IAM role) — no new credential config neededI already have a working implementation if you'd like to see a PR. Happy to adjust the design based on your feedback.