Docker / Kubernetes - Secrets

bogotobogo.com site search:

Secrets

Secrets are secure objects which store sensitive data, such as passwords, tokens, and ssh keys.

Storing sensitive data in Secrets is more secure than plaintext ConfigMaps or in Pod specifications.

Using Secrets gives us control over how sensitive data is used, and reduces the risk of exposing the data to unauthorized users.

Kubernetes keeps those info within a single central place (etcd), which may cause security issues as described Securing Kubernetes secrets : How to efficiently secure access to etcd and protect your secrets.

Creating a Secret

Picture from Secrets in Kubernetes

We create a Secret using the following command:

kubectl create secret [TYPE] [NAME] [DATA]

where [TYPE] can be one of the following:

generic: Create a Secret from a local file, directory, or literal value. For most Secrets, we use this generic type.
docker-registry: Creates a dockercfg Secret for use with a Docker registry. Used to authenticate against Docker registries.
tls: Create a TLS secret from the given public/private key pair. The public/private key pair must exist beforehand. The public key certificate must be .PEM encoded and match the given private key.

Picture from Secrets in Kubernetes

[DATA] can be one of the following:

a path to a directory containing one or more configuration files, indicated using the --from-file or --from-env-file flags
key-value pairs, each specified using --from-literal flags

Creating a Secret Using kubectl create secret

Suppose that some pods need to access a database. The username and password that the pods should use is in the files username.txt and password.txt on our local machine:

# Create files needed for rest of example.
$ echo -n 'admin' > ./username.txt
$ echo -n '1f2d1e2e67df' > ./password.txt

The kubectl create secret command packages these files into a Secret and creates the object on the Apiserver:

$ kubectl create secret generic db-user-pass \
--from-file=./username.txt --from-file=./password.txt
secret/db-user-pass created

We can check that the secret was created like this:

$ kubectl get secrets
NAME                     TYPE                                  DATA   AGE
db-user-pass             Opaque                                2      93s

$ kubectl describe secrets/db-user-pass
Name:         db-user-pass
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password.txt:  12 bytes
username.txt:  5 bytes

Creating a Secret Manually

We can also create a Secret in a file first, in json or yaml format, and then create that object. The Secret contains two maps: data and stringData.

The data field is used to store arbitrary data, encoded using base64. The stringData field is provided for convenience, and allows us to provide secret data as unencoded strings.

For example, to store two strings in a Secret using the data field, convert them to base64 as follows:

$ echo -n 'admin' | base64
YWRtaW4=

$ echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Write a Secret (mysecret.yaml) that looks like this:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Now create the Secret using kubectl apply:

$ kubectl apply -f mysecret.yaml
secret/mysecret created

Decoding a Secret

Secrets can be retrieved via the kubectl get secret command. For example, to retrieve the secret created in the previous section:

$ kubectl get secret mysecret -o yaml
apiVersion: v1
data:
  password: MWYyZDFlMmU2N2Rm
  username: YWRtaW4=
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="},"kind":"Secret","metadata":{"annotations":{},"name":"mysecret","namespace":"default"},"type":"Opaque"}
  creationTimestamp: "2019-03-27T03:46:06Z"
  name: mysecret
  namespace: default
  resourceVersion: "1071280"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: d9f73de9-5042-11e9-a4f4-080027c35fa9
type: Opaque

Decode the secrets:

$ echo 'YWRtaW4=' | base64 --decode
admin

$ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
1f2d1e2e67df

Using Secrets as Files (Volumes) from a Pod

Secrets can be mounted as data volumes or be exposed as environment variables to be used by a container in a pod.

Picture from Secrets in Kubernetes

They can also be used by other parts of the system, without being directly exposed to the pod.

To consume a Secret in a volume in a Pod:

Create a secret or use an existing one. Multiple pods can reference the same secret.
Modify our Pod definition to add a volume under .spec.volumes[]. Name the volume anything, and have a .spec.volumes[].secret.secretName field equal to the name of the secret object.
Add a .spec.containers[].volumeMounts[] to each container that needs the secret. Specify .spec.containers[].volumeMounts[].readOnly = true and .spec.containers[].volumeMounts[].mountPath to an unused directory name where we would like the secrets to appear.
Modify our image and/or command line so that the program looks for files in that directory. Each key in the secret data map becomes the filename under mountPath.

This is an example of a pod (mysecret-pod.yaml) that mounts a secret in a volume:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret

Each secret we want to use needs to be referred to in .spec.volumes.

Create the pod and check if our volume for the secret is properly mounted:

$ kubectl create -f mysecret-pod.yaml 
pod/mypod created

$ kubectl get po
NAME                      READY   STATUS      RESTARTS   AGE
mypod                     1/1     Running     0          26s

$ kubectl exec mypod ls /etc/foo
password
username

$ kubectl exec mypod cat /etc/foo/username
admin
$ kubectl exec mypod cat /etc/foo/password
1f2d1e2e67df

We can see inside the container that mounts a secret volume, the secret keys appear as files and the secret values are base-64 decoded and stored inside these files. The program in a container is responsible for reading the secrets from the files.

Using Secrets as Environment Variables

To use a secret in an environment variable in a pod:

Create a secret or use an existing one. Multiple pods can reference the same secret.
Modify our Pod definition in each container that we wish to consume the value of a secret key to add an environment variable for each secret key we wish to consume. The environment variable that consumes the secret key should populate the secret’s name and key in env[].valueFrom.secretKeyRef.
Modify our image and/or command line so that the program looks for values in the specified environment variables.

This is an example of a pod (secret-env-pod.yaml) that uses secrets from environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never

Create a pod and verify:

$ kubectl create -f secret-env-pod.yaml
pod/secret-env-pod created

$ kubectl get po
NAME             READY   STATUS    RESTARTS   AGE
secret-env-pod   1/1     Running   0          27s

$ kubectl exec secret-env-pod env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=secret-env-pod
SECRET_USERNAME=admin
SECRET_PASSWORD=1f2d1e2e67df
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
...

Inside a container that consumes a secret in an environment variables, the secret keys appear as normal environment variables containing the base-64 decoded values of the secret data.