Secret of three forms

Secret

ConfigMapThe resource object is Kubernetesvery important among an object, in general, ConfigMapare used to store non-secure configuration information, if some of the security-relevant data related to the use of words ConfigMapis very wrong, because ConfigMapis called memory, we say this time we need to use another resource object: the Secret, Secretused to store sensitive information, such as passwords, OAuth tokens and ssh key, and so on, put that information Secretrather than in the Poddefinition or dockerthe mirror is more secure and flexible.

SecretThere are three types:

• Opaque: Secret base64 encoding format used to store passwords, keys and the like; however, data may be raw data obtained by decoding base64 -decode, all very weak encryption.
• kubernetes.io/dockerconfigjson: used to store authentication information of private docker registry.
• kubernetes.io/service-account-token: to be serviceaccountreferenced when serviceaccout created by default create Kubernetes corresponding secret. If the Pod serviceaccount, corresponding to the secret Pod automatically mounted directory /run/secrets/kubernetes.io/serviceaccountin.

Opaque Secret

Opaque type of data is a map type, required value is base64encoded format, for example, we create a user named admin, password admin321 Secret of the object, first of all we put this username and password do base64 encoding,

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

Then we can use the data after the encoding 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 secretcommand to view:

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

Which default-token-cty7pdefault-token-n9w2dis the default when you create a cluster secret created, cited serviceacount / default.

Use describethe command to view the 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 the use describecommand to view Datadoes not show directly, if you want to see the Datadetails inside, also we can export to YAMLfile 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

Created Secretafter the object, there are two ways to use it:

• In the form of environment variables
• Volume mount in the form of

Environment Variables

First, we test mode environment variable, the same, we use a simple busyboxmirroring 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 main environmental variables above defined secretKeyRefkeywords, and our last lesson configMapKeyRefis not to compare similar, one is from Secretobtaining objects, one is from the ConfigMapget object, created above Pod:

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

Then we look at Podthe log output:

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

We can see the output USERNAME and PASSWORD out two environment variables.

Volume mount

We use a similar Podcase to verify the Volumemount, 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 

Created Pod:

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

Then we look at the output log:

$ kubectl logs secret2-pod
password
username

We can see secretthe two key corresponding mount the file into two. Of course, if you want to mount the file specified above, it is not it also can be used on a class of methods: secretNameadd the following itemsspecified key and path, the lesson we can refer to the ConfigMapmethods to test next.

kubernetes.io/dockerconfigjson

In addition to the above Opaqueoutside of this type, since we can also create user docker registryauthentication Secret, use the direct kubectl createcommand to create, 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 

And then view the Secretlist:

$ 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

Note the above TYPEtype, myregistryis not corresponding kubernetes.io/dockerconfigjson, you can use the same describecommand to see the details:

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

Type:  kubernetes.io/dockerconfigjson

Data
==== .dockerconfigjson: 152 bytes 

The same can be seen that Datathe area did not show it directly, if you want to see, then you can use -o yamlto display output out:

$ 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

Can be above data.dockerconfigjsonthe following data to make a base64decoder, look inside the data what is it?

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

If we need to pull private warehouse dockermirror, then you need to use to top myregistrythis 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 private warehouse mirror 192.168.1.100:5000/test:v1, we need to create a private warehouse above for that Secret, and then in Podthe YAML file is specified imagePullSecrets, we will talk to you in detail later in a private warehouse built course.

kubernetes.io/service-account-token

Another Secrettype is kubernetes.io/service-account-tokenused for the serviceaccountreference. When serviceaccout created by default create Kubernetes corresponding secret. If the Pod serviceaccount, corresponding to the secret Pod automatically mounts the /run/secrets/kubernetes.io/serviceaccountdirectory.

Here we use a nginxmirror to verify, think about why it is not a busyboxmirror to verify? Of course, also possible, but we can not in commandthere to verify, because the token is needed Podafter running up will be mounted directly in commandthe command to see is certainly not token files.

$ 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 contrast with ConfigMap

Finally, we compare the next Secretand the ConfigMapsimilarities and differences between these two resource objects:

Same point:

• key / value form
• Belong to a particular namespace
• You can be exported to the environment variable
• Can be mounted through the directory / file format
• By configuring the information volume can be mounted hot update

difference:

• Secret may be associated ServerAccount
• Secret authentication information may be stored docker register is used in ImagePullSecret parameter for pull mirror private warehouse
• Secret Base64 encryption support
• Kubernetes.io/service-account-token,kubernetes.io/dockerconfigjson,Opaque Secret is divided into three types, but does not distinguish between types Configmap