DEV Community

Cover image for How to store a secret on Kubernetes?
Omer Levi Hevroni
Omer Levi Hevroni

Posted on • Edited on

How to store a secret on Kubernetes?

At Soluto, we're using Kubernetes platform in production for more than a year. One of the challenges we faced is secrets management, which is not a simple task at all (did you experienced similar issues?). Kubernetes Secret object has its own limitations (especially, how to store the manifest files). We also tried various solutions (like Sealed Secrets and Helm Secrets to name a few), but none of them was a good fit for us. We wanted a solution that is:

  • GitOps (so it can support our decentralized ops culture)
  • Zero trust (once a secret is encrypted, there is no need and no way to decrypt it)

This is why we built Kamus - our secret encryption solution. Kamus let you seamlessly encrypt secrets, that can be decrypted only by the app running in production.
I'll be more than happy to answer any question you might have regarding Kamus, and of course - look forward to hearing your feedback!

Top comments (2)

Collapse
 
joehobot profile image
Joe Hobot

Hmm.. :) interesting!

Let me take a peek at it and let you know how it goes. By the way, we are kind of riding the same boat however sealed secrets is least amount of effort atm.

Have you tried anything like Vault etc?

Collapse
 
omerlh profile image
Omer Levi Hevroni

Sealed secret solved the problem in a different way. It let you create encrypted Kubernetes secrets, which has a few downsides:

  • If you want to mount the secrets as a file, you usually end up with a secret containing one entry config.secrets.json. The value is base64 encoded value of the JSON, and modifying it is a cumbersome process. Kamus supports native JSON file, where you can encrypt only the values.
    • Sealed Secret does not support "one-way encryption". To change a secret one must be able to decrypt the secret. Kamus does not require that.
    • Sealed secret use one key pair to encrypt all the secrets (as the master key). Kamus create one key per service account, and this key can be backed up by HSM.

One last comment regarding Vault. Vault has 2 options:

  • Secure key-value store. This is a common use case, and if you're already using it Kamus might not be of that value. If you don't use it currently, Vault has some overhead, including deploying and the need to manage additional permission model (Vault policies). Kamus has flattened, simple permission model, make it easier for devs to work with.
  • Encryption as a service. Similar to Kamus, but without the full flow. Kamus has support for full flow, from encryption to consuming by a pod. Kamus can add support to encrypt the secrets using Vault EAAS, it should be really simple. Currently, there is support for Azure KeyVault and GCP KMS (it took me ~3 hours to add the support for GCP KMS).