Kubernetes中的Secret配置
Secret 概覽
Secret 是一種包含少量敏感資訊例如密碼、token 或 key 的物件。這樣的資訊可能會被放在 Pod spec 中或者映象中；將其放在一個 secret 物件中可以更好地控制它的用途，並降低意外暴露的風險。
使用者可以建立 secret，同時系統也建立了一些 secret。
要使用 secret，pod 需要引用 secret。Pod 可以用兩種方式使用 secret：作為 volume
中的檔案被掛載到 pod 中的一個或者多個容器裡，或者當 kubelet 為 pod 拉取映象時使用。
物件型別用來儲存敏感資訊，例如密碼、OAuth 令牌和 ssh key。將這些資訊放在 secret
中比放在
pod的定義中或者 docker 映象中來說更加安全和靈活。參閱 Secret 設計文件
獲取更多詳細資訊。
內建 secret
SERVICE ACCOUNT 使用 API 憑證自動建立和附加 SECRET
Kubernetes 自動建立包含訪問 API 憑據的 secret，並自動修改您的 pod 以使用此型別的 secret。
如果需要，可以禁用或覆蓋自動建立和使用API憑據。但是，如果您需要的只是安全地訪問 apiserver，我們推薦這樣的工作流程。
參閱 Service Account
文件獲取關於 Service Account 如何工作的更多資訊。
建立您自己的 Secret
使用 KUBECTL 建立 SECRET
假設有些 pod 需要訪問資料庫。這些 pod 需要使用的使用者名稱和密碼在您本地機器的 ./username.txt
和 ./password.txt
檔案裡。
# Create files needed for rest of example. $ echo -n "admin" > ./username.txt $ echo -n "1f2d1e2e67df" > ./password.txt
kubectl create secret
命令將這些檔案打包到一個 Secret 中並在 API server 中建立了一個物件。
$ kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt secret "db-user-pass" created
您可以這樣檢查剛建立的 secret：
$ kubectl get secrets NAME TYPE DATA AGE db-user-pass Opaque 2 51s $ kubectl describe secrets/db-user-pass Name: db-user-pass Namespace: default Labels: Annotations: Type: Opaque Data ==== password.txt: 12 bytes username.txt: 5 bytes
請注意，預設情況下， get
和 describe
命令都不會顯示檔案的內容。這是為了防止將 secret 中的內容被意外暴露給從終端日誌記錄中刻意尋找它們的人。
請參閱 解碼 secret
瞭解如何檢視它們的內容。
手動建立 SECRET
您也可以先以 json 或 yaml 格式在檔案中建立一個 secret 物件，然後建立該物件。
每一項必須是 base64 編碼：
$ echo -n "admin" | base64 YWRtaW4= $ echo -n "1f2d1e2e67df" | base64 MWYyZDFlMmU2N2Rm
現在可以像這樣寫一個 secret 物件：
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm
資料欄位是一個對映。它的鍵必須匹配 DNS_SUBDOMAIN
，前導點也是可以的。這些值可以是任意資料，使用 base64 進行編碼。
使用 kubectl create
建立 secret：
$ kubectl create -f ./secret.yaml secret "mysecret" created
編碼注意：secret 資料的序列化 JSON 和 YAML 值使用 base64 編碼成字串。換行符在這些字串中無效，必須省略。當在Darwin/OS X上使用 base64
實用程式時，使用者應避免使用 -b
選項來拆分長行。另外，對於 Linux使用者如果 -w
選項不可用的話，應該新增選項 -w 0
到 base64
命令或管道 base64 | tr -d 'n'
。
解碼 SECRET
可以使用 kubectl get secret
命令獲取 secret。例如，獲取在上一節中建立的 secret：
$ kubectl get secret mysecret -o yaml apiVersion: v1 data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm kind: Secret metadata: creationTimestamp: 2016-01-22T18:41:56Z name: mysecret namespace: default resourceVersion: "164619" selfLink: /api/v1/namespaces/default/secrets/mysecret uid: cfee02d6-c137-11e5-8d73-42010af00002 type: Opaque
解碼密碼欄位：
$ echo "MWYyZDFlMmU2N2Rm" | base64 --decode 1f2d1e2e67df
使用 Secret
Secret 可以作為資料卷被掛載，或作為環境變數暴露出來以供 pod 中的容器使用。它們也可以被系統的其他部分使用，而不直接暴露在 pod 內。例如，它們可以儲存憑據，系統的其他部分應該用它來代表您與外部系統進行互動。
在 POD 中使用 SECRET 檔案
在 Pod 中的 volume 裡使用 Secret：
- 建立一個 secret 或者使用已有的 secret。多個 pod 可以引用同一個 secret。
- 修改您的 pod 的定義在
spec.volumes[]
下增加一個 volume。可以給這個 volume 隨意命名，它的spec.volumes[].secret.secretName
必須等於 secret 物件的名字。 - 將
spec.containers[].volumeMounts[]
加到需要用到該 secret 的容器中。指定spec.containers[].volumeMounts[].readOnly = true
和spec.containers[].volumeMounts[].mountPath
為您想要該 secret 出現的尚未使用的目錄。 - 修改您的映象並且／或者命令列讓程式從該目錄下尋找檔案。Secret 的
data
對映中的每一個鍵都成為了mountPath
下的一個檔名。
這是一個在 pod 中使用 volume 掛在 secret 的例子：
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
您想要用的每個 secret 都需要在 spec.volumes
中指明。
如果 pod 中有多個容器，每個容器都需要自己的 volumeMounts
配置塊，但是每個 secret 只需要一個 spec.volumes
。
您可以打包多個檔案到一個 secret 中，或者使用的多個 secret，怎樣方便就怎樣來。
向特性路徑對映 SECRET 金鑰
我們還可以控制 Secret key 對映在 volume 中的路徑。您可以使用 spec.volumes[].secret.items
欄位修改每個 key 的目標路徑：
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
將會發生什麼呢：
username
secret 儲存在/etc/foo/my-group/my-username
檔案中而不是/etc/foo/username
中。password
secret 沒有被影射
如果使用了 spec.volumes[].secret.items
，只有在 items
中指定的 key 被影射。要使用 secret 中所有的 key，所有這些都必須列在 items
欄位中。所有列出的金鑰必須存在於相應的 secret 中。否則，不會建立卷。
SECRET 檔案許可權
您還可以指定 secret 將擁有的許可權模式位檔案。如果不指定，預設使用 0644
。您可以為整個保密卷指定預設模式，如果需要，可以覆蓋每個金鑰。
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: 256
然後，secret 將被掛載到 /etc/foo
目錄，所有通過該 secret volume 掛載建立的檔案的許可權都是 0400
。
請注意，JSON 規範不支援八進位制符號，因此使用 256 值作為 0400 許可權。如果您使用 yaml 而不是 json 作為 pod，則可以使用八進位制符號以更自然的方式指定許可權。
您還可以是用對映，如上一個示例，併為不同的檔案指定不同的許可權，如下所示：
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: 511
在這種情況下，導致 /etc/foo/my-group/my-username
的檔案的許可權值為 0777
。由於 JSON 限制，必須以十進位制格式指定模式。
請注意，如果稍後閱讀此許可權值可能會以十進位制格式顯示。
從 VOLUME 中消費 SECRET 值
在掛載的 secret volume 的容器內，secret key 將作為檔案，並且 secret 的值使用 base-64 解碼並存儲在這些檔案中。這是在上面的示例容器內執行的命令的結果：
$ ls /etc/foo/ username password $ cat /etc/foo/username admin $ cat /etc/foo/password 1f2d1e2e67df
容器中的程式負責從檔案中讀取 secret。
掛載的 SECRET 被自動更新
當已經在 volume 中消被消費的 secret 被更新時，被對映的 key 也將被更新。
Kubelet 在週期性同步時檢查被掛載的 secret 是不是最新的。但是，它正在使用其基於本地 ttl 的快取來獲取當前的 secret 值。結果是，當 secret 被更新的時刻到將新的 secret 對映到 pod 的時刻的總延遲可以與 kubelet 中的secret 快取的 kubelet sync period + ttl 一樣長。
SECRET 作為環境變數
將 secret 作為 pod 中的環境變數使用：
- 建立一個 secret 或者使用一個已存在的 secret。多個 pod 可以引用同一個 secret。
- 在每個容器中修改您想要使用 secret key 的 Pod 定義，為要使用的每個 secret key 新增一個環境變數。消費secret key 的環境變數應填充 secret 的名稱，並鍵入
env[x].valueFrom.secretKeyRef
。 - 修改映象並／或者命令列，以便程式在指定的環境變數中查詢值。
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 值
在一個消耗環境變數 secret 的容器中，secret key 作為包含 secret 資料的 base-64 解碼值的常規環境變數。這是從上面的示例在容器內執行的命令的結果：
$ echo $SECRET_USERNAME admin $ echo $SECRET_PASSWORD 1f2d1e2e67df
使用 IMAGEPULLSECRET
imagePullSecret 是將包含 Docker（或其他）映象登錄檔密碼的 secret 傳遞給 Kubelet 的一種方式，因此可以代表您的 pod 拉取私有映象。
手動指定 IMAGEPULLSECRET
imagePullSecret 的使用在 映象文件
中說明。
安排 imagePullSecrets 自動附加
您可以手動建立 imagePullSecret，並從 serviceAccount 引用它。使用該 serviceAccount 建立的任何 pod 和預設使用該 serviceAccount 的 pod 將會將其的 imagePullSecret 欄位設定為服務帳戶的 imagePullSecret 欄位。有關該過程的詳細說明，請參閱 將 ImagePullSecrets 新增到服務帳戶
。
自動掛載手動建立的 SECRET
手動建立的 secret（例如包含用於訪問 github 帳戶的令牌）可以根據其服務帳戶自動附加到 pod。請參閱 使用 PodPreset 向 Pod 中注入資訊
以獲取該程序的詳細說明。
詳細
限制
驗證 secret volume 來源確保指定的物件引用實際上指向一個型別為 Secret 的物件。因此，需要在依賴於它的任何 pod 之前建立一個 secret。
Secret API 物件駐留在名稱空間中。它們只能由同一名稱空間中的 pod 引用。
每個 secret 的大小限制為1MB。這是為了防止建立非常大的 secret 會耗盡 apiserver 和 kubelet 的記憶體。然而，建立許多較小的 secret 也可能耗盡記憶體。更全面得限制 secret 對記憶體使用的更全面的限制是計劃中的功能。
Kubelet 僅支援從 API server 獲取的 Pod 使用 secret。這包括使用 kubectl 建立的任何 pod，或間接通過 replication controller 建立的 pod。它不包括通過 kubelet --manifest-url
標誌，其 --config
標誌或其 REST API 建立的pod（這些不是建立 pod 的常用方法）。
必須先建立 secret，除非將它們標記為可選項，否則必須在將其作為環境變數在 pod 中使用之前建立 secret。對不存在的 secret 的引用將阻止其啟動。
通過 secretKeyRef
對不存在於命名的 key 中的 key 進行引用將阻止該啟動。
用於通過 envFrom
填充環境變數的 secret，這些環境變數具有被認為是無效環境變數名稱的 key 將跳過這些鍵。該 pod 將被允許啟動。將會有一個事件，其原因是 InvalidVariableNames
，該訊息將包含被跳過的無效鍵的列表。該示例顯示一個 pod，它指的是包含2個無效鍵，1badkey 和 2alsobad 的預設/mysecret ConfigMap。
$ kubectl get events LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names.
Secret 與 Pod 生命週期的聯絡
通過 API 建立的 Pod 時，不會檢查應用的 secret 是否存在。一旦 Pod 被排程，kubelet 就會嘗試獲取該 secret 的值。如果獲取不到該 secret，或者暫時無法與 API server 建立連線，kubelet 將會定期重試。Kubelet 將會報告關於 pod 的事件，並解釋它無法啟動的原因。一旦獲取的 secret，kubelet將建立並裝載一個包含它的卷。在安裝所有pod的卷之前，都不會啟動 pod 的容器。
使用案例
使用案例：包含 ssh 金鑰的 pod
建立一個包含 ssh key 的 secret：
$ 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
安全性注意事項：傳送自己的 ssh 金鑰之前要仔細思考：叢集的其他使用者可能有權訪問該金鑰。使用您想要共享 Kubernetes 群集的所有使用者可以訪問的服務帳戶，如果它們遭到入侵，可以撤銷。
現在我們可以建立一個使用 ssh 金鑰引用 secret 的pod，並在一個卷中使用它：
kind: Pod apiVersion: v1 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"
當容器中的命令執行時，金鑰的片段將可在以下目錄：
/etc/secret-volume/ssh-publickey /etc/secret-volume/ssh-privatekey
然後容器可以自由使用金鑰資料建立一個 ssh 連線。
使用案例：包含 prod/test 憑據的 pod
下面的例子說明一個 pod 消費一個包含 prod 憑據的 secret，另一個 pod 使用測試環境憑據消費 secret。
建立 secret：
$ kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11 secret "prod-db-secret" created $ kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests secret "test-db-secret" created
建立 pod ：
apiVersion: v1 kind: List items: - kind: Pod apiVersion: v1 metadata: name: prod-db-client-pod labels: name: prod-db-client spec: volumes: - name: secret-volume secret: secretName: prod-db-secret containers: - name: db-client-container image: myClientImage volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume" - kind: Pod apiVersion: v1 metadata: name: test-db-client-pod labels: name: test-db-client spec: volumes: - name: secret-volume secret: secretName: test-db-secret containers: - name: db-client-container image: myClientImage volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume"
這兩個容器將在其檔案系統上顯示以下檔案，其中包含每個容器環境的值：
/etc/secret-volume/username
/etc/secret-volume/password
請注意，兩個 pod 的 spec 配置中僅有一個欄位有所不同；這有助於使用普通的 pod 配置模板建立具有不同功能的 pod。您可以使用兩個 service account 進一步簡化基本 pod spec：一個名為 prod-user
擁有 prod-db-secret
，另一個稱為 test-user
擁有 test-db-secret
。然後，pod spec 可以縮短為，例如：
kind: Pod apiVersion: v1 metadata: name: prod-db-client-pod labels: name: prod-db-client spec: serviceAccount: prod-db-client containers: - name: db-client-container image: myClientImage
使用案例：secret 卷中以點號開頭的檔案
為了將資料“隱藏”起來（即檔名以點號開頭的檔案），簡單地說讓該鍵以一個點開始。例如，當如下 secret 被掛載到卷中：
kind: Secret apiVersion: v1 metadata: name: dotfile-secret data: .secret-file: dmFsdWUtMg0KDQo= --- kind: Pod apiVersion: v1 metadata: name: secret-dotfiles-pod spec: volumes: - name: secret-volume secret: secretName: dotfile-secret containers: - name: dotfile-test-container image: gcr.io/google_containers/busybox command: - ls - "-l" - "/etc/secret-volume" volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume"
Secret-volume
將包含一個單獨的檔案，叫做 .secret-file
， dotfile-test-container
的 /etc/secret-volume/.secret-file
路徑下將有該檔案。
注意
以點號開頭的檔案在 ls -l
的輸出中被隱藏起來了；列出目錄內容時，必須使用 ls -la
才能檢視它們。
使用案例：Secret 僅對 pod 中的一個容器可見
考慮以下一個需要處理 HTTP 請求的程式，執行一些複雜的業務邏輯，然後使用 HMAC 簽署一些訊息。因為它具有複雜的應用程式邏輯，所以在伺服器中可能會出現一個未被注意的遠端檔案讀取漏洞，這可能會將私鑰暴露給攻擊者。
這可以在兩個容器中分為兩個程序：前端容器，用於處理使用者互動和業務邏輯，但無法看到私鑰；以及可以看到私鑰的簽名者容器，並且響應來自前端的簡單簽名請求（例如通過本地主機網路）。
使用這種分割方法，攻擊者現在必須欺騙應用程式伺服器才能進行任意的操作，這可能比使其讀取檔案更難。
最佳實踐
客戶端使用 secret API
當部署與 secret API 互動的應用程式時，應使用諸如 RBAC
之類的 授權策略
來限制訪問。
Secret 的重要性通常不盡相同，其中許多可能只對 Kubernetes 叢集內（例如 service account 令牌）和對外部系統造成影響。即使一個應用程式可以理解其期望的與之互動的 secret 的權力，但是同一名稱空間中的其他應用程式也可以使這些假設無效。
由於這些原因，在名稱空間中 watch
和 list
secret 的請求是非常強大的功能，應該避免這樣的行為，因為列出 secret 可以讓客戶端檢查所有 secret 是否在該名稱空間中。在群集中 watch
和 list
所有 secret 的能力應該只保留給最有特權的系統級元件。
需要訪問 secrets API 的應用程式應該根據他們需要的 secret 執行 get
請求。這允許管理員限制對所有 secret 的訪問，同時設定 白名單訪問
應用程式需要的各個例項。
為了提高迴圈獲取的效能，客戶端可以設計引用 secret 的資源，然後 watch
資源，在引用更改時重新請求 secret。此外，還提出了一種 ”批量監控“ API
來讓客戶端 watch
每個資源，該功能可能會在將來的 Kubernetes 版本中提供。
安全屬性
保護
因為 secret
物件可以獨立於使用它們的 pod
而建立，所以在建立、檢視和編輯 pod 的流程中 secret 被暴露的風險較小。系統還可以對 secret
物件採取額外的預防措施，例如避免將其寫入到磁碟中可能的位置。
只有當節點上的 pod 需要用到該 secret 時，該 secret 才會被髮送到該節點上。它不會被寫入磁碟，而是儲存在 tmpfs 中。一旦依賴於它的 pod 被刪除，它就被刪除。
在大多數 Kubernetes 專案維護的發行版中，使用者與 API server 之間的通訊以及從 API server 到 kubelet 的通訊都受到 SSL/TLS 的保護。通過這些通道傳輸時，secret 受到保護。
節點上的 secret 資料儲存在 tmpfs 卷中，因此不會傳到節點上的其他磁碟。
同一節點上的很多個 pod 可能擁有多個 secret。但是，只有 pod 請求的 secret 在其容器中才是可見的。因此，一個 pod 不能訪問另一個 Pod 的 secret。
Pod 中有多個容器。但是，pod 中的每個容器必須請求其掛載卷中的 secret 卷才能在容器內可見。這可以用於 在 Pod 級別構建安全分割槽
。
風險
- API server 的 secret 資料以純文字的方式儲存在 etcd 中；因此：
- 管理員應該限制 admin 使用者訪問 etcd；
- API server 中的 secret 資料位於 etcd 使用的磁碟上；管理員可能希望在不再使用時擦除/粉碎 etcd 使用的磁碟
- 如果您將 secret 資料編碼為 base64 的清單（JSON 或 YAML）檔案，共享該檔案或將其檢入程式碼庫，這樣的話該密碼將會被洩露。 Base64 編碼不是一種加密方式，一樣也是純文字。
- 應用程式在從卷中讀取 secret 後仍然需要保護 secret 的值，例如不會意外記錄或傳送給不信任方。
- 可以建立和使用 secret 的 pod 的使用者也可以看到該 secret 的值。即使 API server 策略不允許使用者讀取 secret 物件，使用者也可以執行暴露 secret 的 pod。
- 如果運行了多個副本，那麼這些 secret 將在它們之間共享。預設情況下，etcd 不能保證與 SSL/TLS 的對等通訊，儘管可以進行配置。
- 目前，任何節點的 root 使用者都可以通過模擬 kubelet 來讀取 API server 中的任何 secret。只有向實際需要它們的節點發送 secret 才能限制單個節點的根漏洞的影響，該功能還在計劃中。
參考地址：
https://github.com/rootsongjc/kubernetes.github.io/blob/master/docs/concepts/configuration/secret.md
https://www.colabug.com/1660620.html