Kubernetes Secrets Operations

Internal

• Kubernetes Operations
• Cluster Configuration Concepts

Inspecting Secrets

kubectl get secrets

kubectl get secret mysecret -o yaml

The value of the secret is base64-encoded and it can be retrieved with:

echo '....' | base64 --decode

kubectl describe secret secret-name

Create a Secret

With kubectl CLI

Creating a Secret Using kubectl create secret

From File

Declare the secret content in one (or more) file(s) on the local filesystem. The file name will become a secret's data map key. Multiple files can be added to the same secret. When the secret is exposed to a pod, the content will be available as volume files with the same name.

echo -n "test-user" > ./username.txt
echo -p "test-password" > ./password.txt

kubectl create secret generic username-and-password --from-file=./username.txt --from-file=./password.txt

This will create the following secret:

Name:         username-and-password
Namespace:    test
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password.txt:  17 bytes
username.txt:  9 bytes

From Literal

The secret's data map key followed by "=" followed by value can be specified on command line with --from-literal=.

kubectl create secret generic red --from-literal=key1=somevalue --from-literal=key2=someothervalue

From Env File

A key-value (env) file can be used as source for secrets with --from-env-file=. The keys in the key-value file become the keys in the secret's data map.

kubectl create secret generic green --from-env-file=./test.txt

where test.txt:

key1=value1
key2=value2

Special Character Handling

Special characters such as '$', '*' and '!' require escaping (\).

From a Manifest

Creating a Secret Manually

TODO

The secret's data map key/value pairs can be specified in the manifest. The value must be base64-encoded before being written in the manifest.

apiVersion: v1
kind: Secret
metadata:
  name: blue
type: Opaque
data:
  shape: c3F1YXJl
  size: bGFyZ2U=

Alternatively, the values can be specified in clear as part of the "stringData" map; they will be encoded by Kubernetes when the secret is created:

apiVersion: v1
kind: Secret
metadata:
  name: blue
type: Opaque
stringData:
  shape: square
  size: large

Creating Secrets with a Generator

Creating a Secret from Generator

TODO

Consume a Secret

Consume a Secret as a File

Modify the pod to add a new .spec.volumes[] volume, whose .spec.volumes[].secret.secretName must match the name of the secret to be exposed to the pod. Then under the container's "volumeMounts" add a volume mount whose name is the name of the "secret" volume. Specify spec.containers[].volumeMounts[].readOnly = true. Even if I don't specify readOnly=true, when trying to edit the content of the file I get "Warning: Changing a readonly file". If there are multiple containers in the pod, each container will need its own volumeMounts mount, but only one .spec.volumes[] volume is needed per pod.

When the pod deploys, each key/value entry of the secret's data map is exposed as a file, where the file name is given by the key and the file content is filled with decoded value from the secret.

In the example below, assuming that the "blue" secret has a key named "shape" with a "large" value, the pod sees a /etc/blue/shape file and the content of the file is "large" text.

kind: Pod
...
spec:
  containers:
  - name: ...
    volumeMounts:    
    - name: secret-volume
      mountPath: /etc/blue
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: blue

Project a Secret Key to a Specific Path

TODO: Projection of secret keys to specific paths