Skip to content

Overview

Secrets are essential for the operation of production applications. Although it may be convenient, it is a bad security practice to embed secrets such as passwords, API tokens in source code or yaml files. Unintended exposure of secrets is one of the top risks that should be properly addressed.

Kubernetes Secrets

Kubernetes provides an object called Secret that can be used to store application sensitive data. Kubernetes Secrets can be injected into a Pod either as an environment variable or mounted as a file.

Storing sensitive data in a Kubernetes Secret does not automatically make it secure. By default, all data in Kubernetes Secrets is stored as a plaintext encoded with base64. Secrets are stored in the cluster's etc database. Depending on how the cluster was provisioned, the etc database may be encrypted.

Here is an example of a Kubernetes Secret YAML with a sensitive "username" and "password" encoded in base64 format.

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: bXktYXBw
  password: Mzk1MjgkdmRnN0pi

Challenges

Multi Cluster Deployments

It is operationally challenging, cumbersome and insecure to manually provision and manage secrets on every cluster esp. with a fleet of Kubernetes clusters.

No Dangling Secrets

It is a poor security practice to leave Secrets orphaned on Kubernetes clusters long after the workload has been removed from the cluster.

Dynamic Retrieval of Secrets

Instead of statically provisioning secrets on a cluster and risk exposure, the workload pods should dynamically retrieve secrets from a central secrets management system based on the cluster's identity.

Operational Complexity

It is operationally cumbersome and challenging to retrofit applications to securely communicate with Secrets Management solutions .