Kubernetes Secrets: Safety and Best Practices

Luke Hebert

- 2 minutes read - 309 words

Kubernetes Secrets store sensitive data in base64-encoded format, which is not really encrypted. While they offer some protections over plain-text storage, their safety depends largely on the practices surrounding them, such as encryption at rest and proper access controls. For more robust secret management, consider tools like Helm Secrets or HashiCorp Vault.

Base64 Encoding

Remember that secrets encode data in base64 format. Anyone with the base64-encoded secret can easily decode it. As such, the secrets can be considered not very safe.

The Confusion Around “Safety”

The concept of the safety of Secrets is a bit confusing in Kubernetes. The kubernetes documentation page and a lot of blogs out there refer to secrets as a “safer option” to store sensitive data. They are safer than storing in plain text, as they reduce the risk of accidentally exposing passwords and other sensitive data. In my opinion, it’s not the secret itself that is safe; it is the practices around it.

Best Practices

Secrets are not encrypted, so they are not safer in that sense. However, some best practices around using secrets make them safer, such as:

  • Not checking in secret object definition files to source code repositories.
  • Enabling Encryption at Rest for Secrets so they are stored encrypted in etcd.

How Kubernetes Handles Secrets

Kubernetes also provides some built-in protections:

  • A secret is only sent to a node if a pod on that node requires it.
  • Kubelet stores the secret in a tmpfs so that the secret is not written to disk storage.
  • Once the pod that depends on the secret is deleted, kubelet will delete its local copy of the secret data as well.

Read about the protections and risks of using secrets here.

Alternatives

Having said that, there are better ways of handling sensitive data like passwords in Kubernetes, such as using tools like Helm Secrets or HashiCorp Vault.