Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to create Secret objects in K8S, many people may not know much about it. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Preface

Secret can be used to store sensitive information such as passwords and keys, so as to avoid disclosure problems caused by keys directly placed in Pod's YAML definition file or container image.

The key is stored in the Secret object using Base64 encoding, and is automatically decoded into plaintext after the Pod is mounted.

Create a Secret through kubectl

Create a username / password file

Echo-n 'username' >. / username.txtecho-n' password' >. / password.txt

Write to Secret object

# kubectl create secret generic db-info-from-file=./username.txt-from-file=./password.txtsecret/db-info created

Check Secret

# kubectl get secretNAME TYPE DATA AGEdb-info Opaque 2 106s

View the details of the db-info you just wrote

# kubectl describe secret db-infoName: db-infoNamespace: defaultLabels: Annotations: Type: OpaqueData====username.txt: 8 bytespassword.txt: 8 bytes

View the value of the key

# kubectl get secret db-info-o yaml creates a Secret through YAML

First, Base64 encode the value to be saved.

# echo-n 'username' | base64 dXNlcm5hbWU=# echo-n' password' | base64cGFzc3dvcmQ=

# cat secret.yaml

ApiVersion: v1kind: Secretmetadata: name: mysecrettype: Opaquedata: username: base64 coding password: base64 coding

Create secret

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

View

# kubectl get secretNAME TYPE DATA AGEmysecret Opaque 2 2m5s

View the value of the key

# kubectl get secret mysecret-o yaml

Edit secret

Kubectl edit secrets mysecret uses Secret in Pod

Mount Secret into Pod as a volume

Each file name in the volume corresponds to a key name in Secret

The value of Secret is stored in the volume file in plaintext after base64 decoding

Support for real-time dynamic updates

ApiVersion: v1kind: Podmetadata: name: mypodspec: containers:-name: mypod image: redis volumeMounts:-name: foo mountPath: "/ etc/foo" readOnly: true volumes:-name: foo secret: secretName: mysecret

In the above example

Map the secret object named mysecret to a volume and the volume name is foo

Mount the volume named foo to the path / etc/foo in Pod

Username/password two key in mysecret, which are mapped to files respectively.

Multiple Pod can share a single volume.

You can go to Pod to view the contents of these two files

# kubectl exec-it mypod-- ls / etc/foo/password username# kubectl exec-it mypod-- cat / etc/foo/usernameadmin# kubectl exec-it mypod-- cat / etc/foo/passwordpassword

The Secret object decouples the important key from the Pod.

It has the following characteristics:

The Secret object needs to be created before the Pod that references it.

The Secret object and the Pod that references it must be in the same namespace.

The single size of a Secret object is limited to 1m.

The data in the Secret object is stored in etcd as plain text.

In addition to mounting as a volume, it can also be used in Pod in the form of environment variables.

The problem with using the form of environment variables is that secret cannot be dynamically updated in real time.

Official safety recommendations:

The administrator should turn on static encryption (v1.13 or above) for cluster data.

Administrators should restrict access to etcd to admin users.

The Secret data in the API server is on the disk used by etcd; the disk used by etcd should be erased / shredded when it is no longer in use.

If the etcd is running within a cluster, the administrator should ensure that communication between the etcd is encrypted using SSL/TLS.

The base64 code contained in the YAML of secret is reversible, so do not add it to the code base or disclose it.

Prevents the application from writing to the log after reading the data in the secret, resulting in disclosure.

All users who can run the Pod can read the secret value in the mounted volume.

Root users on any node can read any Secret in the API server by impersonating kubelet. Sending Secret data to nodes that actually need Secret can limit the impact of root account vulnerabilities on nodes, which is still planned.

After reading the above, do you have any further understanding of how to create Secret objects in K8S? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.