Skip to main content

Managed secrets

A managed secret stores an encrypted connector or identity provider credential. The API accepts secret values on writes and omits them from reads.

Where to find them​

In the console, go to Managed secrets.

The list shows each secret's name and last update time. Replace a secret to change its value. Retrieve the source value from the system that issued it.

How they are protected​

The directory encrypts each value with a data key, then encrypts that data key with a key-encryption key (KEK) from a Kubernetes Secret. Both layers use AES-256. You configure this Secret with the Enterprise Manager's directory.kek values, as described in Encrypting stored credentials.

The encrypted values live in the Enterprise Manager's PostgreSQL database, and only the keys in the KEK Secret can decrypt them. Back up the Secret and the database together. A database restored without its matching Secret leaves every stored credential unreadable.

The Connector Gateway uses its own KEK for the OAuth tokens it stores in Redis. To rotate that key, see Rotate the Connector Gateway encryption key.

Rotating the key-encryption key​

The key-encryption key is versioned. Its Kubernetes Secret holds a map of version number to key, and the highest version present is the one used to encrypt new values:

{
  "1": "<BASE64_KEY_V1>",
  "2": "<BASE64_KEY_V2>"
}

To rotate the key, add a new highest-numbered entry and retain the earlier versions. The directory needs each previous version to decrypt values written with it.

Each key must contain exactly 32 bytes before base64 encoding. The directory refuses to start when the decoded length differs.

Restart the directory after adding a key version.

Re-encrypting after rotation​

Existing values retain their original key version until the next write. Update a credential to re-encrypt it immediately with the current version.

Next steps​