Kubernetes Secrets

• 2021 年 4 月 21 日
• 筆記
• Kubernetes, 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對一些場景提供了內置的類型。

你也可以自己定義一個類型，填充到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 \
  [email protected]

該命令創建一個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 '\n'去掉不必要的換行符。

然後可以創建一個Secret配置如下

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

在某些場景中，你可以不想或不能使用base64編碼，而直接使用stringData欄位存儲數據，但是在創建或更新Secret對象的時候，Kubernetes會自動將這些數據轉換為base64格式。
這方面的一個實際示例可能是，您正在部署一個使用Secret存儲配置文件的應用程式，並且希望在部署過程中填充該配置文件的部分內容。
比如，如果你的應該需要用到以下內容

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

你可以使用以下Secret配置

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  config.yaml: |
    apiUrl: "//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是一個有序列表。加密的時候只有第一列有效，解密的時候會挨個嘗試。

每一種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 -

參考文檔

//kubernetes.io/docs/concepts/configuration/secret/
//kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kubectl/
//kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-kustomize/
//kubernetes.io/docs/tasks/configmap-secret/managing-secret-using-config-file/
//github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/secrets.md
//kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#secret-v1-core
//kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
//kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names
//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 [//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 [//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='//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 [//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).