Secrets: KCSA practice questions

A Secret is an object that holds a small amount of sensitive data such as a password, token or key, so that the value does not have to be written into a Pod specification or baked into a container image. Secrets resemble ConfigMaps but are intended for confidential data. Because Secrets exist independently of the Pods that use them, there is less chance of exposing the value while Pods are created, viewed or edited, and the kubelet stores a mounted Secret in a tmpfs on the node so it is not written to durable storage. ConfigMaps are meant for non-confidential configuration and get none of this handling.

Kubernetes does not make Secret values secret by itself. The values in the data field are base64-encoded, which is an encoding, not encryption; anyone who can read the object can decode them. When writing manifests by hand, the stringData field accepts plain strings and is merged into data on write. Individual Secrets are limited to 1 MiB. Common kubectl forms are kubectl create secret generic with --from-literal or --from-file, and kubectl create secret tls with --cert and --key, which produces a Secret of type kubernetes.io/tls; for that type the API server checks that the required keys are present. Reading one value back means selecting its key with a jsonpath query and piping it through base64 -d.

By default, Secrets are stored unencrypted in etcd. Anyone with API access to a Secret, and anyone with access to etcd, can read it. Less obviously, anyone allowed to create a Pod in a namespace can read every Secret in that namespace by mounting it, including indirectly through the ability to create a Deployment. Granting list or watch on Secrets also exposes their contents, not just their names. A privileged securityContext does not by itself grant access to Secrets through the API; access is decided by authorization.

Encryption at rest is configured on the kube-apiserver with --encryption-provider-config, which points at an EncryptionConfiguration file listing resources and providers. The first provider in the list encrypts new writes, and the others are tried in order when reading. The identity provider stores plain text, so a configuration whose first provider is identity provides no encryption. Providers such as aesgcm, aescbc and secretbox use local keys, while kms delegates key management to an external service or hardware module. Existing Secrets are only encrypted once they are rewritten, for example with kubectl get secrets --all-namespaces -o json | kubectl replace -f -.

The good-practice checklist follows from this: enable encryption at rest, give least-privilege RBAC access (restrict list and watch to system components), restrict etcd access to administrators, mount Secrets only into the containers that need them, and consider an external secret store provider.