Yes, I get it about the heading. The pun was fully intended. Of course I am a 'pun star'! I think it's high time I added it to my resume!!

Kubernetes secrets are API objects that are used to store sensitive data such as passwords, tokens, keys and certificates - as objects. These objects are stored in the cluster and referred to by pods for use by applications. Secrets are one aspect of the many ways by which we decouple software applications in kubernetes.

Pods are the basic unit of deployment in kubernetes, pods encapsulate containers and contain other extra data that might be needed by the container image to run effectively. Since pods are frequently destroyed, recreated, viewed and edited, secrets offer a way to prevent sensitive data from being exposed - since they are created independent of pods.

Secrets grant us the ability to create safer and flexible configurations. Since no sensitive data is included as part of the pod manifest or pod spec, we can safely share our configurations.

Secrets are usually encoded in base64. This means that they are not encrypted by default. You can however set up encryption in your cluster or utilize tools like Hashicorp Vault for externally storing them. Base64 encoded secrets are stored in the etcd data store. Secrets are also namespaced objects. What this means is that secrets can only be referenced by pods that share the same namespace with it.

It is also important to note that if a pod references a secret and that secret is unavailable or not in the same namespace with the pod, the pod will fail to startup. However, the kubelet will continue to retry starting the pod
and if the secret becomes available within the pod's namespace, the pod will be created. Secrets in kubernetes can optionally be marked as immutable. This means that the secret cannot be modified. To update the secret, the kubernetes administrator must have to destroy and create a new secret containing the updated values.

Secrets can be created in kubernetes either imperatively through the command line or in a declarative manner through manifests. According to the documentation, there are three secret types in kubernetes:

• docker-registry: Creates a secret for use with a Docker registry.

• generic: Creates a secret from a local file, directory or literal value.

• tls: Creates a TLS secret

To create a secret imperatively:

kubectl create secret mysecret --from-literal=username=kelvin

In the above code, we created a generic secret named mysecret and assigned it a literal value of username.

We can also assign more than one value to a secret:

kubectl create secret mysecret --from-literal=username=kelvin \
--from-literal=password=mypass

Here we are assigning both username and password values to the secret.

Using Secrets In Pods

It is one thing to create secrets, it is yet another thing to reference them in your Pod Spec or pod manifest.

Secrets can be referenced by two major methods.

• Environmental variables: Secrets can be read into environmental variables and exposed to the underlying application. The application will then refer to the data just as it would any other environmental variable.

• Volumes: Secrets can also be referenced as volumes or tmpfs mounted files, exposed into the file system of the container. The container image application will then read the data in this file as if it was reading from any other file in its file system.

While secrets referenced as environmental variables cannot be updated without destroying and recreating a pod, volume-based secrets can be updated in real-time.

Secrets are a very important aspect of kubernetes. Understanding how secrets work and how to use them is a major skill that every DevOps Engineer or kubernetes administrator must have in their tool box.

Connect with me on Linkedin