Secrets

Some settings are sensitive, like database passwords, or A P I keys. They need extra care. Kubernetes has a special object for them, called a secret. In this lesson, you will learn how secrets work, and, just as important, what they do not protect you from.

• Passwords need special care
• Secrets are a separate object
• Know their limits

Creating a Secret

Creating a secret looks like creating a config map. We give it a name, and a key and value pair. This one holds a password. Now, look at it in Y A M L. The value is not shown as plain text, it is encoded, in a format called base sixty four. But careful, this is not encryption. Anyone can decode it, with a single command, as we do here, and the password appears. Base sixty four exists only so that binary data fits in Y A M L.

kubectl create secret generic db-pass --from-literal=password=S3cr3t-demo
secret/db-pass created
kubectl get secret db-pass -o yaml | head -4
apiVersion: v1
data:
  password: UzNjcjN0LWRlbW8=
kind: Secret
kubectl get secret db-pass -o jsonpath='{.data.password}'
UzNjcjN0LWRlbW8=
kubectl get secret db-pass -o jsonpath='{.data.password}' | base64 -d
S3cr3t-demo

Keeping secrets really secret

So, how do you protect them for real? First, control who can read secrets, using access rules, which we cover in the security clip. Second, turn on encryption at rest, so that secrets are encrypted inside et see dee. Third, never commit secrets to Git in plain form. Use tools such as sealed secrets, or the external secrets operator, which fetch passwords from a vault, like those of your cloud provider. A secret object is a convenient container, but the real protection comes from these layers around it.

ConfigMap or Secret?

How do you choose between the two? Use a config map for anything that would not hurt if it leaked, such as a colour, a feature flag, or a public address. Use a secret for anything that would hurt, such as passwords, tokens, keys, and certificates. They are used in pods in exactly the same ways, so the choice is about meaning, and about the access rules attached to each.

Summary