- Take me to Video Tutorials
In this section, we will take a look at secrets in kubernetes
-
One way is to move the app properties/envs into a configmap. But the configmap stores data into a plain text format. It is definitely not a right place to store a password.
apiVersion: v1 kind: ConfigMap metadata: name: app-config data: DB_Host: mysql DB_User: root DB_Password: paswrd
-
Secrets are used to store sensitive information. They are similar to configmaps but they are stored in an encrypted format or a hashed format.
-
The Imperative way
$ kubectl create secret generic app-secret --from-literal=DB_Host=mysql --from-literal=DB_User=root --from-literal=DB_Password=paswrd $ kubectl create secret generic app-secret --from-file=app_secret.properties
-
The Declarative way
Generate a hash value of the password and pass it to secret-data.yaml definition value as a value to DB_Password variable. $ echo -n "mysql" | base64 $ echo -n "root" | base64 $ echo -n "paswrd"| base64
Create a secret definition file and run
kubectl create
to deploy itapiVersion: v1 kind: Secret metadata: name: app-secret data: DB_Host: bX1zcWw= DB_User: cm9vdA== DB_Password: cGFzd3Jk
$ kubectl create -f secret-data.yaml
-
To view secrets
$ kubectl get secrets
-
To describe secret
$ kubectl describe secret
-
To view the values of the secret
$ kubectl get secret app-secret -o yaml
- To decode secrets
$ echo -n "bX1zcWw=" | base64 --decode $ echo -n "cm9vdA==" | base64 --decode $ echo -n "cGFzd3Jk" | base64 --decode
-
To inject a secret to a pod add a new property
envFrom
followed bysecretRef
name and then create the pod-definitionapiVersion: v1 kind: Secret metadata: name: app-secret data: DB_Host: bX1zcWw= DB_User: cm9vdA== DB_Password: cGFzd3Jk
apiVersion: v1 kind: Pod metadata: name: simple-webapp-color spec: containers: - name: simple-webapp-color image: simple-webapp-color ports: - containerPort: 8080 envFrom: - secretRef: name: app-secret
$ kubectl create -f pod-definition.yaml
Additional Notes: A Note on Secrets
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 concept of safety of the 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.
Secrets are not encrypted, so it is not safer in that sense. However, some best practices around using secrets make it safer. As in best practices like:
- Not checking-in secret object definition files to source code repositories.
- Enabling Encryption at Rest for Secrets so they are stored encrypted in ETCD.
Also the way kubernetes handles secrets. Such as:
- A secret is only sent to a node if a pod on that node requires it.
- Kubelet stores the secret into 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
Having said that, there are other better ways of handling sensitive data like passwords in Kubernetes, such as using tools like Helm Secrets, HashiCorp Vault. I hope to make a lecture on these in the future.