We are trying to figure out how Rancher Secrets could be used to improve security for a couple of Rancher environments that we are planning to set up. I’ve read the information at Rancher Secrets and after also reviewing much of the code think that I pretty much understand now how it works (both using AES encryption and using Vault). What I haven’t found out yet is whether there is a way to change the name of the encryption key (by default: “rancher”) to something else, ideally scoped by environment (“rancher-dev”, “rancher-staging”, “rancher-prod”, …). I noticed that the key name is a DynamicStringProperty in cattle, but have got no idea how I would change that per environment.
Background:
The Rancher Secrets API hosted with the Rancher Server uses the Key Name to reference the encryption key used by the AES encryption or Vault:
- If using the localkey backend (AES encryption), the environment variable
ENC_KEY_PATH specifies the folder name where encryption keys are stored, and the Key Name specifies the file name containing the encryption key.
- If using the vault backend (using Vault’s Transit backend), the environment variable
VAULT_ADDR specifies the URL of the Vault Server and VAULT_TOKEN specifies the access token used to access the Vault Transit encryption key who’s name is Key Name.
Since the environment variables above are Rancher (Secrets API) Server variables, they are used for all environments managed by the Rancher Server. Therefore it would be great, if the Key Name could be set per environment, so that someone with access to a development environment for example would not be able to decrypt a key encrypted in the production environment. It would also allow different access rules to be applied to the encryption key in Vault.
The TL;DR answer is no, not today.
Long answer:
The Secrets feature is really a Rancher construct. The Secrets API project is just an encryption endpoint that is only exposed to Cattle. Cattle uses a single key/backend at time configured globally for the Rancher installation. It can support moving from localkey to Vault backend.
Within Rancher, secrets are scoped to an environment. Meaning a user can only request a secret scoped to that environment when deploying a container. A secret called DB_PASSWORD in rancher-dev is not the same object as DB_PASSWORD in rancher-prod. The end user is never given the encrypted text, nor are they given access to the secrets API to decrypt it. Rancher is doing all the RBAC and access controls around the secrets. Another thing to clarify is that data transmitted to the host is encrypted (RSA/AES) exclusively for the host it is destined for.
That said, compromising the Rancher server leaves all of Rancher secrets vulnerable as mentioned in our documentation. In that case, having multiple keys etc would not help you since the user would have the tokens / keys to access the backends directly along with the encrypted text in the DB.
There are things coming down the pipe that will change the way this works along with where secrets are stored. In particular, we are looking to bring the secrets-bridge functionality as a feature of Rancher Secrets. Meaning Rancher will be able to help provide Vault tokens to containers, where the Vault servers are scoped to a Rancher environment.
1 Like
Thanks for the elaborate response.
The idea to have different encryption keys for different environments would be more of a segregation of duties thing. E.g. you could rotate keys for one envirionment without affecting other environments.
I like the “things coming down the pipe”. I already thought it might be great to combine the features of Rancher Secrets with the features of the Rancher Secrets Bridge. It would be really great to have at least a rough idea when this could become reality. Is there a road map for Rancher somewhere?
1 Like