Kubernetes Secrets

这篇文档主要是翻译自Kubernetes官方文档中对于Secrets的篇章。其中描述了Secrets常见的使用场景以及使用方法、配置等，以及Secrets使用部署时的一些注意事项和安全管理等。

背景信息

Kubernetes版本

[09:08:04 yhf@test ~]$ kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"c3dc785cf52536afd7b661728747292e848e74b7", GitTreeState:"clean", BuildDate:"2021-03-21T00:44:23Z", GoVersion:"go1.15.7", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0+f173eb4", GitCommit:"f173eb4a83e55734ee6808a1ed7674be9a4cd0bf", GitTreeState:"clean", BuildDate:"2021-02-11T22:10:37Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

定义

Secrets是Kubernetes内置的资源对象，用于存储管理像密码、OAuth tokens、SSH Keys等敏感信息。Secrets通过key-value对的形式将数据存储在data或stringData字段中。
注意：Secret中的数据是已base64编码格式存储的，对于具有访问API以及etcd权限的用户来说，其实相当于明文。用户可以对Secret启用REST加密以及配置RBAC访问策略进行限制。

概述

一个Pod可以通过以下3种方式使用Secret：

• Secret做为存储卷挂载到容器里面
• Secret中的数据可以做为容器的环境变量
• kubelet拉取镜像时使用Secret(针对Images Secret，拉取镜像时的认证信息)

Secret的name必须符合DNS Subdomain NamesRFC 1123的定义。

• 至多包含253字节
• 只能包含'小写字母或数字'，'-'，'.'
• 以字母数字开头
• 以字母或数字结尾

Secret中的数据存放在data或/和stringData字段中，这两个字段是可选的，data字段中的value需要使用base64编码，如果你不想使用base64编码，可以将你的内容存放到stringData字段。data和stringData的key只能包含'字母或数字'，'-'，'_'，'.'。stringData中的内容在Kubernetes内部会merge到data字段，如果有一个key同时出现在data字段和stringData字段，则优先使用stringData字段的内容。

Secret的类型

创建Secret的时候，可以指定一个type字段，该字段可以规范对Secret数据的处理。Kubernetes对一些场景提供了内置的类型。

Builtin Type	Usage
Opaque	arbitrary user-defined data(default)
kubernetes.io/service-account-token	service account token
kubernetes.io/dockercfg	serialized ~/.dockercfg file
kubernetes.io/dockerconfigjson	serialized ~/.docker/config.json file
kubernetes.io/basic-auth	credentials for basic authentication
kubernetes.io/ssh-auth	credentials for SSH authentication
kubernetes.io/tls	data for a TLS client or server
bootstrap.kubernetes.io/token	bootstrap token data

你也可以自己定义一个类型，填充到type字段。

Opaque secrets

Opaque是默认类型。

# Create a new secret named my-secret with keys for each file in folder bar
kubectl create secret generic my-secret --from-file=path/to/bar

# Create a new secret named my-secret with specified keys instead of names on disk
kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa
--from-file=ssh-publickey=path/to/id_rsa.pub

# Create a new secret named my-secret with key1=supersecret and key2=topsecret
kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

# Create a new secret named my-secret using a combination of a file and a literal
kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret

# Create a new secret named my-secret from an env file
kubectl create secret generic my-secret --from-env-file=path/to/bar.env

kubectl create secret generic empty-secret
kubectl get secret empty-secret

Service account token Secrets

kubernetes.io/service-account-token类型的secret用于保存ServiceAccount的token，想用这种类型的secret，需要添加kubernetes.io/service-account.name注释。

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token
data:
  # You can include additional key value pairs as you do with Opaque Secrets
  extra: YmFyCg==

当创建一个Pod的时候，Kubernetes自动为该Pod创建一个Service account token Secret，用于Pod内部访问Kubernetes API的认证权限。你可以查看Pod的automountServiceAccountToken和serviceAccountName字段查看相关Secret的名字。

Docker config Secrets

你可以使用以下2种中的任一种添加一个镜像仓库的认证信息

• kubernetes.io/dockercfg
• kubernetes.io/dockerconfigjson
  使用kubernetes.io/dockercfg类型的secret可以为老版本的docker命令行提供~/.dockercfg文件，你必须在data中将key设置为.dockercfg。
  使用kubernetes.io/dockerconfigjson类型的secret可以提供~/.docker/config.json文件，你必须在data中将key设置为.dockerconfigjson。

apiVersion: v1
kind: Secret
metadata:
  name: secret-dockercfg
type: kubernetes.io/dockercfg
data:
  .dockercfg: |
        "<base64 encoded ~/.dockercfg file>"

如果你没有一个docker json格式的配置文件，或者用kubectl来创建这种secret，使用以下命令

kubectl create secret docker-registry secret-tiger-docker 
  --docker-username=tiger 
  --docker-password=pass113 
  --docker-email=tiger@acme.com

该命令创建一个kubernetes.io/dockerconfigjson类型的secret。

Basic authentication Secret

kubernetes.io/basic-auth类型的secret提供基于用户密码的认证信息，data中需要包含username和password两个key。

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: t0p-Secret

这种类型的secret也可以用Opaque类型替代。

SSH authentication secrets

kubernetes.io/ssh-auth类型的secret用于保存SSH认证秘钥对。

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth
data:
  # the data is abbreviated in this example
  ssh-privatekey: |
          MIIEpQIBAAKCAQEAulqb/Y ...

这种类型的secret也可以用Opaque类型替代。使用这种类型的话，API Server会进行验证。
注意: 这样的SSH秘钥还需要像known_hosts文件才能访问。

TLS secrets

kubernetes.io/tls类型的secret用于保存TLS证书，PEM格式。使用这种类型的secret，data中需要有tls.key和tls.crt两个key。

apiVersion: v1
kind: Secret
metadata:
  name: secret-tls
type: kubernetes.io/tls
data:
  # the data is abbreviated in this example
  tls.crt: |
        MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
        MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

这种类型的secret也可以用Opaque类型替代。

使用kubectl命令创建tls类型的secret

kubectl create secret tls my-tls-secret 
  --cert=path/to/cert/file 
  --key=path/to/key/file

上面的两种方式中，数据中都不要包含PEM格式的首尾2行标识符(--------BEGIN CERTIFICATE----- and -------END CERTIFICATE----)。

Bootstrap token Secrets

bootstrap.kubernetes.io/token类型的secret用于node bootstrap，它将token保存在固定格式的ConfigMap中。
这种类型的secret通常部署在kube-system命名空间中，并且以bootstrap-token-<token-id>格式命名，token-id是6位字符串。

apiVersion: v1
kind: Secret
metadata:
  name: bootstrap-token-5emitj
  namespace: kube-system
type: bootstrap.kubernetes.io/token
data:
  auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
  expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
  token-id: NWVtaXRq
  token-secret: a3E0Z2lodnN6emduMXAwcg==
  usage-bootstrap-authentication: dHJ1ZQ==
  usage-bootstrap-signing: dHJ1ZQ==

• token-id: A random 6 character string as the token identifier. Required.
• token-secret: A random 16 character string as the actual token secret. Required.
• description: A human-readable string that describes what the token is used for. Optional.
• expiration: An absolute UTC time using RFC3339 specifying when the token should be expired. Optional.
• usage-bootstrap-: A boolean flag indicating additional usage for the bootstrap token.
• auth-extra-groups: A comma-separated list of group names that will be authenticated as in addition to the system:bootstrappers group.

apiVersion: v1
kind: Secret
metadata:
  # Note how the Secret is named
  name: bootstrap-token-5emitj
  # A bootstrap token Secret usually resides in the kube-system namespace
  namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
  auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
  expiration: "2020-09-13T04:39:10Z"
  # This token ID is used in the name
  token-id: "5emitj"
  token-secret: "kq4gihvszzgn1p0r"
  # This token can be used for authentication
  usage-bootstrap-authentication: "true"
  # and it can be used for signing
  usage-bootstrap-signing: "true"

创建Secret

kubectl命令创建

echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt

注意：-n参数确保不会追加额外的换行符到文件中，否则base64编码的时候也会将换行符编译进去，可能会在使用的时候出现问题。

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

默认情况下key即使文件名，你也可以指定key的名字，如下

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

--from-literal=<key>=<value>可以直接指定key-value对。注意，像$, , *, =, 以及!等的特殊字符会被shell给转义，因此需要将这些字符放到一个单引号中。如下

kubectl create secret generic dev-db-secret 
  --from-literal=username=devuser 
  --from-literal=password='S!B*d$zDsb='

以下是验证secret的相关命令行

kubectl get secrets
kubectl describe secrets/db-user-pass

为了查看Secret中的数据，需要将data中的内容解码。

kubectl get secret db-user-pass -o jsonpath='{.data}'
# base64解码
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode

以下是在线修改Secret命令

kubectl edit secrets mysecret

删除Secret

kubectl delete secret db-user-pass

Config文件创建

首先创建一个YAML或JSON格式的Secret对象文件。data字段中的value需要使用base64编码，stringData字段的value则不需要。

base64编码如下

echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64

注意：为了避免base64编码的时候出现不必要的换行符，base64命令在Darwin/macOS系统中不要带-b参数，而在Linux环境中需要加上-w 0，如果不支持-w参数，可以使用base64 | tr -d ' '去掉不必要的换行符。

然后可以创建一个Secret配置如下

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

在某些场景中，你可以不想或不能使用base64编码，而直接使用stringData字段存储数据，但是在创建或更新Secret对象的时候，Kubernetes会自动将这些数据转换为base64格式。
这方面的一个实际示例可能是，您正在部署一个使用Secret存储配置文件的应用程序，并且希望在部署过程中填充该配置文件的部分内容。
比如，如果你的应该需要用到以下内容

apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"

你可以使用以下Secret配置

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  config.yaml: |
    apiUrl: "https://my.api.com/api/v1"
    username: <user>
    password: <password>

前面也说了，如果一个key同时出现在data和stringData字段，则是以stringData字段的数据为准。

创建了配置文件之后，就可以部署Secret对象了。

kubectl apply -f ./secret.yaml

Kustomize创建

首先创建Kustomization文件。你可以创建一个带secretGenerator字段的kustomization.yaml文件。

secretGenerator:
- name: db-user-pass
  files:
  - username.txt
  - password.txt

其中username.txt和password.txt是关联的前期目录下的文件./username.txt和./password.txt。
你也可以在secretGenerator直接定义Secret的key-value对。

secretGenerator:
- name: db-user-pass
  literals:
  - username=admin
  - password=1f2d1e2e67df

文件创建好之后，就可以创建Secret对象了。

kubectl apply -k .

使用Secrets

Secrets可以当做数据卷或者环境变量挂载到Pod中的容器中使用，也可以当成其它系统的认证信息使用。比如，Secret可以当成外部系统存储认证信息的对象。

以文件形式挂载到Pod的容器中使用

1. 创建一个Secret对象或使用已有的，多个Pod可以挂载同一个Secret。
2. 在你的Pod申明.spec.volumes[]字段中添加一个Volume，name是自定义的，但是.spec.volumes[].secret.secretName必须是Secret对象的名字。
3. 在Pod的容器申明中添加一个.spec.containers[].volumeMounts[]，指定.spec.containers[].volumeMounts[].readOnly = true和一个未被使用的目录.spec.containers[].volumeMounts[].mountPath。
4. 更新部署Pod

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

将key映射到指定路径
以下配置表示mysecret这个Secret对象中的keyusername会被映射到容器的/etc/foo/my-group/my-username文件。

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
      items:
      - key: username
        path: my-group/my-username

Secret文件权限
你可以给挂载到容器里的Secret文件赋予相应的权限，默认是0644。你也可以给整个Volume赋予一个权限，而不是给每个Secret文件赋权。

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

注意：在json格式中不支持这种0400八进制的数字，所以需要转换成十进制256。如果是yaml格式可以支持八进制。

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username
        mode: 0777

自动更新Secret Volume数据
当Secrets对象中的数据变化之后，挂载它的Pod的容器中的数据也会自动发生变化。Kubelet组件会定时去检测secret是否有更新。但是Kubelet会在本地保存一个secret数据的缓存，Kubelet检测的时候从缓存中比对数据是否有更新，所以检测的时候可能会因为缓存未更新而有延迟。Kubelet参数ConfigMapAndSecretChangeDetectionStrategy配置检测的策略，可以配置策略有基于缓存的watch(默认)、基于TTL、直接从API server获取数据。因此，Secret更新周期是Kubelet的检测周期+缓存过期时间(等于watch延迟、TTL缓存时间、0)。
注意：如果Pod使用的subPath，则自动更新策略失效。

以环境变量形式注入Pod的容器

1. 创建一个Secret对象或使用已有的，多个Pod可以挂载同一个Secret。
2. 新增Pod申明环境变量env[].valueFrom.secretKeyRef。
3. 更新部署Pod

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

注意：Secret数据更新时，注入到Pod容器中的环境变量不会因此更新。

不可变的Secrets

FEATURE STATE: Kubernetes v1.21 [stable]
Kubernetes的feature特性 Immutable Secrets and ConfigMaps可以设置不可变的Secrets和ConfigMaps对象。可以ImmutableEphemeralVolumes设置为true打开该特性，从Kubernetes v1.19之后默认开启。
不可变的Secrets和ConfigMaps有以下好处：

• 防止数据意外修改。
• 关闭Kubelet对API server的watch，提升API性能。

apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
immutable: true

Pod的imagePullSecrets字段是kubelet用于拉取私有镜像的认证信息的Secret对象存储。

其它注意信息

• Secret对象需要在使用它的Pod之前创建，否则Pod无法启动。
• Pod不能夸namespace使用Secret。
• 单个Secret对象限制1MB大小，这是为了防止API server和Kubelet缓存占用内存太大。当然创建大量的小容量的Secret同样会消耗API server和Kubelet大量内存。
• Secret到容器后只可在该容器可见，该Pod所在的其它容器是不可见的。

使用示例

做为容器环境变量

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  USER_NAME: YWRtaW4=
  PASSWORD: MWYyZDFlMmU2N2Rm

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - secretRef:
          name: mysecret
  restartPolicy: Never

SSH keys

kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
  labels:
    name: secret-test
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: ssh-key-secret
  containers:
  - name: ssh-test-container
    image: mySshImage
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

最佳实践

• 你应该设置合理的RBAC以限制访问Secret。
• 不要watch或list所有的Secrets，应该加上相应的标签或名称过滤。最好使用get

安全属性

• Secret做为挂载卷时会在主机上创建一个tmpfs文件系统的临时卷，主机的root用户有权限查看。
• 使用Secret的Pod有权查看该Secret的数据。
• 你可以启用encryption at rest，这样Secrets数据存储在etcd中是加密的。

Encrypting Secret Data at Rest

条件

• etcd v3.0或以上版本
• FEATURE STATE: Kubernetes v1.13 [beta]

配置

首先配置kube-apiserver进程参数--encryption-provider-config。示例如下

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - identity: {}
    - aesgcm:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - aescbc:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - secretbox:
        keys:
        - name: key1
          secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=

providers是一个有序列表。加密的时候只有第一列有效，解密的时候会挨个尝试。

Name	Encryption	Strength	Speed	Key Length	Other Considerations
identity	None	N/A	N/A	N/A	Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
aescbc	AES-CBC with PKCS#7 padding	Strongest	Fast	32-byte	The recommended choice for encryption at rest but may be slightly slower than secretbox.
secretbox	XSalsa20 and Poly1305	Strong	Faster	32-byte	A newer standard and may not be considered acceptable in environments that require high levels of review.
aesgcm	AES-GCM with random nonce	Must be rotated every 200k writes	Fastest	16, 24, or 32-byte	Is not recommended for use except when an automated key rotation scheme is implemented.
kms	Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS)	Strongest	Fast	32-bytes	The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. Configure the KMS provider

每一种provider支持多种keys。

示例

加密数据配置，第一个provider会被用来加密etcd数据。

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: <BASE 64 ENCODED SECRET>
    - identity: {}

根据以下步骤创建一个新Secret：

1. head -c 32 /dev/urandom | base64
2. 将第1步获得的key填充到上面的secret字段中。
3. --encryption-provider-config指定为上面的EncryptionConfiguration。
4. 重启kube-apiserver。

验证

配置完成后，所有新创建或者更新的Secrets对象都会以加密方式存储。

kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
# [...]是连接etcd的其它参数。

看到数据以k8s:enc:aescbc:v1:开头的时候就是加密的了。

确保所有Secrets都是加密存储

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

参考文档

https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kubectl/
https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kustomize/
https://kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-config-file/
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/secrets.md
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#secret-v1-core
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#secret-v1-core

附录

Secret命令帮助

[08:43:55 yhf@test ~]$ kubectl create secret generic --help
Create a secret based on a file, directory, or specified literal value.

 A single secret may package one or more key/value pairs.

 When creating a secret based on a file, the key will default to the basename of the file, and the value will default to
the file content. If the basename is an invalid key or you wish to chose your own, you may specify an alternate key.

 When creating a secret based on a directory, each file whose basename is a valid key in the directory will be packaged
into the secret. Any directory entries except regular files are ignored (e.g. subdirectories, symlinks, devices, pipes,
etc).

Examples:
  # Create a new secret named my-secret with keys for each file in folder bar
  kubectl create secret generic my-secret --from-file=path/to/bar

  # Create a new secret named my-secret with specified keys instead of names on disk
  kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa
--from-file=ssh-publickey=path/to/id_rsa.pub

  # Create a new secret named my-secret with key1=supersecret and key2=topsecret
  kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

  # Create a new secret named my-secret using a combination of a file and a literal
  kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret

  # Create a new secret named my-secret from an env file
  kubectl create secret generic my-secret --from-env-file=path/to/bar.env

Options:
      --allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in
the template. Only applies to golang and jsonpath output formats.
      --append-hash=false: Append a hash of the secret to its name.
      --dry-run='none': Must be "none", "server", or "client". If client strategy, only print the object that would be
sent, without sending it. If server strategy, submit server-side request without persisting the resource.
      --field-manager='kubectl-create': Name of the manager used to track field ownership.
      --from-env-file='': Specify the path to a file to read lines of key=val pairs to create a secret (i.e. a Docker
.env file).
      --from-file=[]: Key files can be specified using their file path, in which case a default name will be given to
them, or optionally with a name and file path, in which case the given name will be used.  Specifying a directory will
iterate each named file in the directory that is a valid secret key.
      --from-literal=[]: Specify a key and literal value to insert in secret (i.e. mykey=somevalue)
  -o, --output='': Output format. One of:
json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.
      --save-config=false: If true, the configuration of current object will be saved in its annotation. Otherwise, the
annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
      --template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The
template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
      --type='': The type of secret to create
      --validate=true: If true, use a schema to validate the input before sending it

Usage:
  kubectl create secret generic NAME [--type=string] [--from-file=[key=]source] [--from-literal=key1=value1]
[--dry-run=server|client|none] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

[08:44:23 yhf@test ~]$ kubectl create secret tls --help
Create a TLS secret from the given public/private key pair.

 The public/private key pair must exist before hand. The public key certificate must be .PEM encoded and match the given
private key.

Examples:
  # Create a new TLS secret named tls-secret with the given key pair:
  kubectl create secret tls tls-secret --cert=path/to/tls.cert --key=path/to/tls.key

Options:
      --allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in
the template. Only applies to golang and jsonpath output formats.
      --append-hash=false: Append a hash of the secret to its name.
      --cert='': Path to PEM encoded public key certificate.
      --dry-run='none': Must be "none", "server", or "client". If client strategy, only print the object that would be
sent, without sending it. If server strategy, submit server-side request without persisting the resource.
      --field-manager='kubectl-create': Name of the manager used to track field ownership.
      --key='': Path to private key associated with given certificate.
  -o, --output='': Output format. One of:
json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.
      --save-config=false: If true, the configuration of current object will be saved in its annotation. Otherwise, the
annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
      --template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The
template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
      --validate=true: If true, use a schema to validate the input before sending it

Usage:
  kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]
[options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

[08:45:04 yhf@test ~]$ kubectl create secret docker-registry --help
Create a new secret for use with Docker registries.

  Dockercfg secrets are used to authenticate against Docker registries.

  When using the Docker command line to push images, you can authenticate to a given registry by running:
      '$ docker login DOCKER_REGISTRY_SERVER --username=DOCKER_USER --password=DOCKER_PASSWORD --email=DOCKER_EMAIL'.

 That produces a ~/.dockercfg file that is used by subsequent 'docker push' and 'docker pull' commands to authenticate
to the registry. The email address is optional.

  When creating applications, you may have a Docker registry that requires authentication.  In order for the
  nodes to pull images on your behalf, they have to have the credentials.  You can provide this information
  by creating a dockercfg secret and attaching it to your service account.

Examples:
  # If you don't already have a .dockercfg file, you can create a dockercfg secret directly by using:
  kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER
--docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

Options:
      --allow-missing-template-keys=true: If true, ignore any errors in templates when a field or map key is missing in
the template. Only applies to golang and jsonpath output formats.
      --append-hash=false: Append a hash of the secret to its name.
      --docker-email='': Email for Docker registry
      --docker-password='': Password for Docker registry authentication
      --docker-server='https://index.docker.io/v1/': Server location for Docker registry
      --docker-username='': Username for Docker registry authentication
      --dry-run='none': Must be "none", "server", or "client". If client strategy, only print the object that would be
sent, without sending it. If server strategy, submit server-side request without persisting the resource.
      --field-manager='kubectl-create': Name of the manager used to track field ownership.
      --from-file=[]: Key files can be specified using their file path, in which case a default name will be given to
them, or optionally with a name and file path, in which case the given name will be used.  Specifying a directory will
iterate each named file in the directory that is a valid secret key.
  -o, --output='': Output format. One of:
json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.
      --save-config=false: If true, the configuration of current object will be saved in its annotation. Otherwise, the
annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
      --template='': Template string or path to template file to use when -o=go-template, -o=go-template-file. The
template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
      --validate=true: If true, use a schema to validate the input before sending it

Usage:
  kubectl create secret docker-registry NAME --docker-username=user --docker-password=password --docker-email=email
[--docker-server=string] [--from-literal=key1=value1] [--dry-run=server|client|none] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).