Kubernetes Secrets: How to create and use them safely

Secrets store sensitive data in Kubernetes: passwords, OAuth tokens, SSH keys, TLS certificates, and API keys. They work similarly to ConfigMaps but are intended for confidential values that should not appear in plain text in your application code or container images.

Before using Secrets, there is one critical thing to understand.

Create a Secret from a YAML file

Base64-encode your values first:

1echo -n "admin" | base64

Expected output:

1YWRtaW4=

1echo -n "passcode" | base64

Expected output:

1cGFzc2NvZGU=

Create a Secret manifest using the encoded values:

1apiVersion: v1
2kind: Secret
3metadata:
4  name: demo
5type: Opaque
6data:
7  username: YWRtaW4=
8  password: cGFzc2NvZGU=

Apply it:

1kubectl create -f sec.yaml

Verify the Secret was created:

1kubectl get secrets

Expected output:

1NAME   TYPE     DATA   AGE
2demo   Opaque   2      5s

Create a Secret imperatively

1kubectl create secret generic admin --from-literal=admin-user=admin --from-literal=dev-user=dev

Verify:

1kubectl get secrets

Use a Secret as a volume mount

Each key in the Secret becomes a file at the mount path. The file contents are the decoded value.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: secret-pod-volume
5spec:
6  containers:
7  - name: nginx
8    image: nginx
9    volumeMounts:
10    - name: secret-volume
11      mountPath: /etc/secrets
12  volumes:
13  - name: secret-volume
14    secret:
15      secretName: demo

1kubectl create -f pod2.yaml
2kubectl get pods

Exec into the pod and inspect the mounted files:

1kubectl exec -it secret-pod-volume -- sh

1ls /etc/secrets

Expected output:

1password  username

1cat /etc/secrets/username

Expected output:

1admin

Use a Secret as an environment variable

1apiVersion: v1
2kind: Pod
3metadata:
4  name: secret-env
5spec:
6  containers:
7  - name: busybox
8    image: busybox
9    command: ["env"]
10    env:
11    - name: ADMIN_USER
12      valueFrom:
13        secretKeyRef:
14          name: admin
15          key: admin-user
16    - name: DEV_USER
17      valueFrom:
18        secretKeyRef:
19          name: admin
20          key: dev-user
21  restartPolicy: Never

1kubectl create -f pod.yaml
2kubectl logs secret-env

Expected output:

1ADMIN_USER=admin
2DEV_USER=dev

Security best practices

Base64 encoding is not a security control. It is a data encoding format that any user with access to the Secret can reverse immediately. Treat Secrets as sensitive resources and apply the following practices.

• Restrict access with RBAC: Apply the principle of least privilege. Only the service accounts and users that genuinely need to read a Secret should have permission to do so. Avoid granting broad get or list permissions on Secrets across a namespace.
• Enable encryption at rest: By default, Secrets are stored unencrypted in etcd. Anyone with direct access to etcd can read them. Enable EncryptionConfiguration in your cluster to encrypt Secret values before they are written to etcd. For managed clusters like Civo, check your provider's documentation for encryption at rest settings.
• Use external secret stores for production: The most secure approach removes credentials from the cluster entirely and fetches them from a dedicated secrets management system at runtime.

External secret stores

Sealed Secrets encrypts your Secret manifests using a key held by a controller running in your cluster. The encrypted manifest is safe to commit to Git. When applied to the cluster, the controller decrypts it and creates a standard Kubernetes Secret. Sealed Secrets on GitHub

External Secrets Operator syncs secrets from external providers including HashiCorp Vault. Your credentials live in your secrets manager and the operator keeps the cluster in sync. external-secrets.io