Skip to main content
Some actions your vendor takes need your explicit, cryptographic consent: a break glass request, or an operational command your vendor runs against your environment. You consent by signing the request with a private key that only you hold, and the controller running in your environment verifies your signature before it acts. This page covers how you set up and manage that signing key. Setup is one-time, and the same key is reused for every request you approve.

​
Why you hold the key

Your signature is your consent. The private key lives only in your environment and never travels to us, so:
  • We cannot forge an approval. The controller verifies every signature against the public key you pinned, using a key we never hold.
  • We cannot act without you. No signed request means no action - the controller refuses it.
  • Even if our systems were fully compromised, an attacker still could not approve anything in your name, because the key is not on our side to steal.

​
The keypair

PropertyValue
AlgorithmEd25519
Private keyLives only in your own secret store - the same backends you already use for application secrets. Your browser never touches it.
Public keyPinned into the controller’s secret store in your own environment, at a path the controller reads to verify your signatures. The public key is non-secret, but it never has to leave your environment - and we never see the private key.

​
Setting it up

The first time you approve something, the approval page detects you have no key yet and walks you through these steps, generating the exact commands for your environment. You only do this once.
1

Generate the keypair

On your workstation, generate an Ed25519 keypair. The private key stays on your machine in this step.
openssl genpkey -algorithm Ed25519 -out private.pem
openssl pkey -in private.pem -pubout -out public.pem
2

Store the private key

Save the private key into your own secret store. This is where it lives from now on - not on your laptop, and never with us.
3

Pin the public key

Write the public key to the location the controller reads, so it can verify the requests you sign. The approval page polls until it sees the pinned key, then continues.
Where the keys live, by environment:
The private key goes into a Kubernetes Secret in your namespace; the public key is pinned as a separate Secret the controller reads.
# private key - stays in your cluster
kubectl create secret generic signing-key -n <namespace> --from-file=private.pem

# public key - pinned for the controller to verify against
kubectl create secret generic signing-pubkey -n <namespace> --from-file=public.pem
The exact secret names and paths are supplied by the approval page for your environment. These are the same secret stores described in Credentials and Secrets; your signing key is stored exactly like your application secrets.
Signing key setup is available on AWS and Kubernetes environments today. Support for other environments is on the roadmap.

​
Signing a request

When you approve a request, the approval page gives you a short script to run on a host that can read your key store. The script fetches your private key, signs the request’s canonical bytes locally with openssl pkeyutl, and submits only the resulting signature. Your private key never enters the browser and never travels to us. We receive the signature, not the key. See Break Glass for what a request looks like when you review and sign it.

​
Rotating your key

Rotate your signing key whenever you’d rotate any sensitive key - a retired workstation, a suspected laptop compromise, an employee with access leaving, or routine policy.
1

Generate a fresh keypair

Run the same generate step on the new workstation.
2

Pin the new public key

Pin it the same way as the initial setup. You can pin the new key alongside the old one or replace it.
3

Retire the old key

Leave it pinned and prior approvals signed with it keep verifying until they expire, or unpin it and they stop verifying immediately. Either way, the historical record stays intact: each past signature records the key fingerprint it was signed with and continues to verify against that fingerprint, not whatever is pinned now.

​
Recovery

Because the private key lives in your own secret store (not only on a laptop), it survives workstation loss: any workstation with access to your secret store can fetch it and resume signing. If the secret itself is deleted, generate a fresh keypair and pin it - the setup flow is the same as the first time.

​
What we guarantee

  • Your private key never leaves your environment - it lives in your secret store and is read only on the host where you sign.
  • We never see or store your private key - we receive signatures, never key material.
  • You can rotate or remove it at any time without coordinating with us.