Kubernetes Secrets

雲上清風、發表於2021-04-21

這篇文件主要是翻譯自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 '\n'去掉不必要的換行符。

然後可以建立一個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的容器中使用

建立一個Secret物件或使用已有的，多個Pod可以掛載同一個Secret。
在你的Pod申明.spec.volumes[]欄位中新增一個Volume，name是自定義的，但是.spec.volumes[].secret.secretName必須是Secret物件的名字。
在Pod的容器申明中新增一個.spec.containers[].volumeMounts[]，指定.spec.containers[].volumeMounts[].readOnly = true和一個未被使用的目錄.spec.containers[].volumeMounts[].mountPath。
更新部署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的容器

建立一個Secret物件或使用已有的，多個Pod可以掛載同一個Secret。
新增Pod申明環境變數env[].valueFrom.secretKeyRef。
更新部署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：

head -c 32 /dev/urandom | base64
將第1步獲得的key填充到上面的secret欄位中。
--encryption-provider-config指定為上面的EncryptionConfiguration。
重啟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 -

參考文件

附錄

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).

Azure KeyVault（四）另類在 .NET Core 上操作 Secrets 的類庫方法-----Azure.Security.KeyVault.Secrets
2022-03-08
ubuntu中使用機密資料Secrets
2018-10-18
Ubuntu
加密 K8s Secrets 的幾種方案
2023-09-18
加密K8S
Blazor 在開發環境儲存機密（User Secrets）
2022-04-08
Blazor開發環境
VUE 9個效能優化祕密？（vue-9-perf-secrets）
2019-04-01
Vue優化
【Azure Developer】使用 CURL 獲取 Key Vault 中 Secrets 中的值
2022-04-20
Developer
secrets 管理工具 Vault 的介紹、安裝及使用
2021-01-25
Azure KeyVault（三）通過 Microsoft.Azure.KeyVault 類庫在 .NET Core 上獲取 Secrets
2022-02-22
ROS
Kubernetes
2024-11-11
傲視Kubernetes(一)：Kubernetes簡介
2020-11-07
Serverless Kubernetes 和 Serverless on Kubernetes 的區別
2021-10-21
Server
淺入kubernetes(2)：Kubernetes 的組成
2021-01-04
傲視Kubernetes(三)：Kubernetes中的Pod
2020-12-13
Scattered Secrets：荷蘭人喜歡用常規單詞、足球隊或地名作為密碼
2019-08-07
密碼
Kubernetes PodSecurityPolicy
2024-03-11
配置 kubernetes
2019-10-14
Kubernetes Ingress
2024-09-18
Kubernetes命令
2018-04-02
Kubernetes – Images
2024-06-05
Kubernetes – Jobs
2024-06-05
Kubernetes – Namespaces
2024-06-05
namespace
kubernetes RBAC
2022-07-19
Kubernetes Namespaces
2021-03-02
namespace
容器、Docker與Kubernetes——Kubernetes的配置入門
2019-03-02
Docker
Kubernetes原始碼系列：Kubernetes目錄結構
2019-03-12
原始碼
kubernetes實踐之六十：Cabin-Manage Kubernetes
2018-06-21
Serverless Kubernetes入門：對kubernetes做減法
2019-12-12
Server
Kubernetes as Database: 使用kubesql查詢kubernetes資源
2020-05-24
DatabaseSQL
淺入kubernetes(1)：Kubernetes 入門基礎
2020-12-29
從0到1使用Kubernetes系列——Kubernetes入門
2018-08-29
Kubernetes: CentOS上如何安裝指定版本的Kubernetes
2018-09-21
CentOS
Kubernetes Replica Sets 和 Kubernetes Replica Controller的區別
2024-03-09
Controller
Kubernetes:05---安裝Kubernetes的系統要求
2020-12-26
kubernetes 1.25.9 install
2023-04-22
kubernetes 安裝
2020-03-15
安裝 kubernetes
2019-10-15
kubernetes之PDB
2019-06-07
kubernetes原生pipeline
2019-05-15