Introduction to Kubernetes Secrets

Secret overview

When studying in the previous article ConfigMap, we said that ConfigMapthis resource object is Kubernetesa very important object. Generally, ConfigMapit is used to store some non-secure configuration information. If it involves some security-related data, it ConfigMapis very inappropriate to use it. Because ConfigMapit is called storage, we said that we need to use another resource object at this time: Secret, Secretwhich is used to store sensitive information, such as passwords, OAuth tokens and ssh keys, etc., and put these information in the middle Secretthan in It is safer and more flexible Podin the definition or dockerimage.

SecretThere are three types:

• Opaque: Secret in base64 encoding format, used to store passwords, keys, etc.; but the data can also be decoded by base64 –decode to get the original data, all encryption is very weak.
• kubernetes.io/dockerconfigjson: Used to store authentication information for private docker registries.
• kubernetes.io/service-account-token: Used for serviceaccountreference, when serviceaccout is created, Kubernetes will create the corresponding secret by default. If the Pod uses serviceaccount, the corresponding secret will be automatically mounted in the Pod directory /run/secrets/kubernetes.io/serviceaccount.

Opaque Secret

The data of Opaque type is a map type, and the value is required to be base64encoded. For example, let’s create a Secret object whose username is admin and password is admin321. First, we encode the username and password in base64.

$ echo -n "admin" | base64
YWRtaW4=
$ echo -n "admin321" | base64
YWRtaW4zMjE=

Then we can use the encoded data above to write a YAMLfile: (secret-demo.yaml)

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

Then we can use the same kubectlcommand to create:

$ kubectl create -f secret-demo.yaml
secret "mysecret" created

Use get secretthe command to view:

$ kubectl get secret
NAME                  TYPE                                  DATA      AGE
default-token-n9w2d   kubernetes.io/service-account-token   3         33d
mysecret              Opaque                                2         40s

Among them default-token-cty7pdefault-token-n9w2dis the secret created by default when creating a cluster, which is referenced by serviceacount/default.

Use describethe command to view details:

$ kubectl describe secret mysecret
Name:         mysecret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password:  8 bytes
username:  5 bytes

We can see that the information describeviewed by the command Datais not directly displayed. If we want to see Datathe detailed information inside, we can also output it into YAMLa file for viewing:

$ kubectl get secret mysecret -o yaml
apiVersion: v1
data:
  password: YWRtaW4zMjE=
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: 2018-06-19T15:27:06Z
  name: mysecret
  namespace: default
  resourceVersion: "3694084"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: 39c139f5-73d5-11e8-a101-525400db4df7
type: Opaque

After creating Secretan object, there are two ways to use it:

• in the form of environment variables
• Mount as Volume

environment variable

First, let's test the way of environment variables. Similarly, let's use a simple busyboxmirror to test: (secret1-pod.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: secret1-pod
spec:
  containers:
  - name: secret1
    image: busybox
    command: [ "/bin/sh", "-c", "env" ]
    env:
    - name: USERNAME
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: username
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: password

The keywords defined in the above environment variables are similar to secretKeyRefthose in our last lesson . One is obtained from the object, and the other is obtained from the object. Create the above :configMapKeyRefSecretConfigMapPod

$ kubectl create -f secret1-pod.yaml
pod "secret1-pod" created

Then we view Podthe log output:

$ kubectl logs secret1-pod
...
USERNAME=admin
PASSWORD=admin321
...

You can see that there are two environment variables, USERNAME and PASSWORD, outputted.

Volume mount

Similarly, we use one Podto verify Volumethe mount and create a Podfile: (secret2-pod.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: secret2-pod
spec:
  containers:
  - name: secret2
    image: busybox
    command: ["/bin/sh", "-c", "ls /etc/secrets"]
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets
  volumes:
  - name: secrets
    secret:
     secretName: mysecret

create Pod:

$ kubectl create -f secret-pod2.yaml
pod "secret2-pod" created

Then we look at the output log:

$ kubectl logs secret2-pod
password
username

You can see secretthat the two keys are mounted into two corresponding files. Of course, if you want to mount to a specified file, can you also use the method of the previous lesson: secretNameadd itemsthe specified key and path below, you can refer to the ConfigMapmethod in the previous lesson to test it.

kubernetes.io/dockerconfigjson

In addition to the above Opaquetypes, we can also create user docker registryauthentication Secret, kubectl createjust use the command to create it directly, as follows:

$ kubectl create secret docker-registry myregistry --docker-server=DOCKER_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
secret "myregistry" created

Then view Secretthe list:

$ kubectl get secret
NAME                  TYPE                                  DATA      AGE
default-token-n9w2d   kubernetes.io/service-account-token   3         33d
myregistry            kubernetes.io/dockerconfigjson        1         15s
mysecret              Opaque                                2         34m

Pay attention to whether the above TYPEtypes myregistryare corresponding kubernetes.io/dockerconfigjson, and you can also use describethe command to view detailed information:

$ kubectl describe secret myregistry
Name:         myregistry
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  kubernetes.io/dockerconfigjson

Data
====
.dockerconfigjson:  152 bytes

In the same way, you can see that Datathe area is not directly displayed. If you want to view it, you can use it -o yamlto output and display it:

$ kubectl get secret myregistry -o yaml
apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0=
kind: Secret
metadata:
  creationTimestamp: 2018-06-19T16:01:05Z
  name: myregistry
  namespace: default
  resourceVersion: "3696966"
  selfLink: /api/v1/namespaces/default/secrets/myregistry
  uid: f91db707-73d9-11e8-a101-525400db4df7
type: kubernetes.io/dockerconfigjson

data.dockerconfigjsonYou can decode the data above and below base64to see what the data inside is like?

$ echo eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0= | base64 -d
{
    
    "auths":{
    
    "DOCKER_SERVER":{
    
    "username":"DOCKER_USER","password":"DOCKER_PASSWORD","email":"DOCKER_EMAIL","auth":"RE9DS0VSX1VTRVI6RE9DS0VSX1BBU1NXT1JE"}}}

If we need to pull dockerthe image in the private warehouse, we need to use myregistrythe above Secret:

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: foo
    image: 192.168.1.100:5000/test:v1
  imagePullSecrets:
  - name: myregistrykey

We need to pull the mirror of the private warehouse 192.168.1.100:5000/test:v1, we need to create a private warehouse as above Secret, and then Podspecify it in the YAML file imagePullSecrets, we will explain in detail in the course of private warehouse construction later.

kubernetes.io/service-account-token

Another Secrettype is kubernetes.io/service-account-token, for being serviceaccountreferenced. When serviceaccout is created, Kubernetes will create the corresponding secret by default. If the Pod uses serviceaccount, the corresponding secret will be automatically mounted in the Pod /run/secrets/kubernetes.io/serviceaccountdirectory.

Here we use a nginxmirror image to verify it. Think about it, why not use busyboxa mirror image to verify it? Of course, it is also possible, but we can’t commandverify it in it, because the token Podwill be mounted after it is running. If commandyou check it directly in the command, there must be no token file.

$ kubectl run secret-pod3 --image nginx:1.7.9
deployment.apps "secret-pod3" created
$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
...
secret-pod3-78c8c76db8-7zmqm   1/1       Running   0          13s
...
$ kubectl exec secret-pod3-78c8c76db8-7zmqm ls /run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token
$ kubectl exec secret-pod3-78c8c76db8-7zmqm cat /run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tbjl3MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjMzY2FkOWQxLTU5MmYtMTFlOC1hMTAxLTUyNTQwMGRiNGRmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.0FpzPD8WO_fwnMjwpGIOphdVu4K9wUINwpXpBOJAQ-Tawd0RTbAUHcgYy3sEHSk9uvgnl1FJRQpbQN3yVR_DWSIlAtbmd4dIPxK4O7ZVdd4UnmC467cNXEBqL1sDWLfS5f03d7D1dw1ljFJ_pJw2P65Fjd13reKJvvTQnpu5U0SDcfxj675-Z3z-iOO3XSalZmkFIw2MfYMzf_WpxW0yMFCVkUZ8tBSTegA9-NJZededceA_VCOdKcUjDPrDo-CNti3wZqax5WPw95Ou8RJDMAIS5EcVym7M2_zjGiqHEL3VTvcwXbdFKxsNX-1VW6nr_KKuMGKOyx-5vgxebl71QQ

Secret vs. ConfigMap

Finally, let's compare the similarities Secretand ConfigMapdifferences with these two resource objects:

Same point:

• The form of key/value
• belong to a specific namespace
• can be exported to environment variables
• Can be mounted in the form of directory/file
• The configuration information mounted through the volume can be hot updated

difference:

• Secret can be associated with ServerAccount
• Secret can store the authentication information of docker register, which is used in the parameter of ImagePullSecret to pull the image of the private warehouse
• Secret supports Base64 encryption
• Secret is divided into three types: kubernetes.io/service-account-token, kubernetes.io/dockerconfigjson, and Opaque, while Configmap does not distinguish between types

---