共計 7817 個字符，預計需要花費 20 分鐘才能閱讀完成。
這篇“Vault 在 Kubernetes 中的應用場景是什么”文章的知識點大部分人都不太理解，所以丸趣 TV 小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Vault 在 Kubernetes 中的應用場景是什么”文章吧。
Vault 是什么？
如何在云上應用中管理和保護用戶的敏感信息是一個經常令開發者頭疼的問題，用戶的密碼口令，證書秘鑰等私密信息時常未經加密被隨意的放置在配置文件，代碼倉庫或是共享存儲里，而對于普通的開發者來說，設計和實現一套完整的秘鑰管理系統是一個很大的挑戰。且不論令人生畏的加解密算法，很多的云應用仍然將一些敏感配置信息僅僅經過 base64 等一些簡單的 hash 運算就放置在某個公共的配置中心上，而很多時候這些敏感信息會從應用的某行異常日志或是某段監控告警中泄露出去；不僅如此，對于一個集中式的秘鑰管理系統，如何面向用戶進行更細粒度的訪問鑒權也是一個難題。
Vault 的出現給了上述問題一個解決方案，它是 HashiCorp 公司（旗下還有 Vagrant，Terraform，Consul 等知名產品）維護的開源軟件，它的設計思想基于云原生背景下動態基礎設施的特點，在云上的不同網絡層以及不同的服務之間已經很難找到傳統的信任邊界，服務之間更加強調以身份（identity）為核心的認證和訪問控制，而不是像傳統靜態基礎設施中以 IP、主機地址作為信任憑證。為此 Vault 提供了以下幾個功能點：
Secret 存儲形式的多樣性，任意的 kv 形式敏感信息（如數據庫密碼，證書，ssh 登錄秘鑰，openapi 身份憑證等）；
存儲格式的多樣性，支持插件式的存儲引擎擴展，可對接如 AWS，Consul，NoSQL，KV，PKI，SSH 等多種插件引擎；
支持與各類平臺的認證對接，可動態生成認證憑據或配置信息；
支持基于 Shamir 算法的私鑰分割完成 Vault 后端的加封和解封操作，同時支持高可用的部署形態；
支持各類 secret 的動態生成，續租，撤銷和滾動更新；
完備的審計日志；
完備的 CLI 和 RESTful API
Vault 與 k8s 的集成
Vault 松耦合的架構使其支持與多種 secret 引擎和相應的存儲后端對接，同時支持與多種認證服務器的交互。
本節我們主要介紹 Vault 與 k8s 的集成。
Vault 在 Kubernetes 中的應用場景
Vault 作為企業級的 secret 管理工具，是一些大客戶在業務上云過程中的安全強需求，尤其是國外市場。在 Kubernetes 集群中主要有以下應用場景：
作為部署在 Kubernetes 集群中的應用對外提供秘鑰管理服務，支持與多家主流云廠商秘鑰服務以及多種 secrets 形式的對接，支持多種數據庫服務的存儲對接，同時支持多種認證形式的對接。
作為一個公共的加密服務（Encryption as a Service）而不做后端存儲的對接，幫助用戶應用剝離繁瑣的加密加解密邏輯。
面向政府、金融等對數據安全規格有很高要求的客戶，Vault 支持基于 Two-man 原則利用私鑰分割算法對后端服務進行加解封，并結合 k8s 的高可用部署形態為企業提供更加安全可靠的 secret 管理能力。
當然這里只是列舉了一些 Vault 原生提供的能力，作為一個在 Kubernetes 集群上直接運行的安全應用，任何一個面向 k8s 的應用工具都可以利用其安全能力。
安裝 Vault
Vault 支持 helm 化安裝，在其官方文檔中我們可以找到關于啟動參數的詳細配置說明，同時在阿里云容器服務的應用目錄 apphub 中我們也可以通過控制臺在 ACK 集群中方便的安裝 Vault
另外 Vault 的默認安裝也集成了其控制臺的安裝，通過負載均衡服務或 ingress 路由的方式我們可以在公網訪問其 UI，在 vault pod 的日志中我們可以找到登錄使用的 root token，在控制臺中可以方便的設定與存儲引擎和認證方式的對接，同時還可以進行基于策略的訪問控制配置。
認證方式的集成
當用戶希望在 k8s pod 的業務邏輯中與 Vault 服務端通訊，獲取需要的 secrets 時，首先 Vault 會對這個 pod 中的請求進行認證，那么這個 pod 中的 Vault 請求認證憑據應該如何獲取呢？如上所述，Vault 后端支持多種認證方式的對接，對于 Kubernetes，Vault 支持基于 K8s Service Account Token 的認證。
使用上，Vault 管理員首先需要在后端 enable kubernetes 的認證方式，生成一個與 Vault 交互的指定 sa，然后通過 CLI 或 API 將 sa token 和集群 ca，公網地址等信息寫入到 Vault 后端中，并配置與 vault 后端的 ACL 策略綁定。詳細步驟請參見官方文檔。
當然在 pod 應用中可以并不局限于一定使用基于 sa 的 kubernetes 認證方式。比如 [kubernetes-vault]( https://github.com/Boostport/kubernetes-vault
)。該項目使用 Vault 中的[AppRole](https://www.vaultproject.io/docs/auth/approle.html
) 認證方式，在該認證模式中，管理員可以為不同的 pod 創建不同的 Vault 原生 role 模型并綁定到對應的 policy 上，同時可以基于 role 創建 secret_id，secret_id 對應的 token 可作為與 Vault 進行認證的臨時憑證。kubernetes-vault 利用了 AppRole 的認證交互模式，首先已經完成安裝的 kubernetes-vault controller 會去 Watch 集群中所有 pod 的創建，當發現新建 pod 的部署模板中有指定 annotation 的 init-container 存在時，controller 會根據模板中指定的 vault role id 去 Vault 請求獲取其對應的 secret_id 并發送給 init-container 中 kubernetes-vault 的客戶端，在應用容器啟動前 kubernetes-vault 客戶端用 controller 返回的 secret_id 和 role_id 去 Vault 請求真正的 login token 并最終寫入到與應用 pod 共享的掛載目錄中；同時客戶端會根據 token 過期時間進行定時的輪轉，保證其可用性。
在社區也存在不少基于 k8s 與 Vault 進行認證對接的其他方案，其設計思路大同小異，基本都采用了通過 init-container 或 sidecar 方式引入一個額外的客戶端去 Vault 請求指定認證模式下的短時憑證并共享給業務容器使用。
在容器服務控制臺的應用目錄 apphub 中，我們同樣可以找到 kubernetes-vault，方便開發者使用 helm 直接在集群指定命名空間一鍵部署。Vault 也計劃在后續自己的官方版本 helm chart 中增加配置項以支持上述登錄認證 secret 的動態注入。
Vault 與阿里云 RAM 的集成
當我們在應用中需要訪問阿里云資源時，需要使用 RAM 賬號對應的 AK 或是 STS 臨時 credentials 作為訪問相應資源接口的憑證。如果使用賬號 AK，如何使其能夠被應用邏輯獲取的同時保證 AK 的安全性一直是一個頭疼的問題；如果使用臨時 sts token，由于其時效性，我們也需要在考慮安全性的同時思考如何進行臨時訪問憑證的輪轉。相比較兩種方式，使用 sts 臨時憑證的方式肯定在安全上是更為推薦的方式，同時對這種動態 secret 的安全管理也正是 Vault 的優勢所在。本節我們來介紹下 Vault 與阿里云 RAM 在認證方式和 secret 管理引擎上的集成。
認證方式的集成
首先在認證方式上，Vault 服務端的 role 模型可以與 RAM role 進行一對一的映射匹配，用戶可以使用 Vault 提供的 OpenAPI 或是 CLI，通過傳入扮演 RAM role 返回的臨時憑證調用 GetCallerIdentity 接口，然后 Vault 服務端會根據請求返回的角色 arn id 在其后端存儲中查找是否有對應的權限策略配置，如果存在則認證成功并返回一個可用于調用 Vault 其他后端接口的訪問 token。
Vault Secret 引擎與 RAM 的集成
當我們需要在業務應用邏輯中使用阿里云資源時，通常需要通過角色扮演的方式獲取一個 RAM 返回的臨時憑證，然后通過這個臨時憑證完成與 RAM 的鑒權過程。由于憑證的時效性，我們在保證其安全性的同時還要維護一個對應的秘鑰輪轉機制。Vault 的 secret 引擎實現了與阿里云 RAM 的對接插件，幫助我們安全、動態的管理 RAM 憑證，其主要步驟 如下:
1. 開啟后端引擎
2. 在 RAM 控制臺為 Vault 服務器創建專屬子賬號并綁定定制化權限策略
3. 獲取 Vault 子賬號對應的 AK 并通過 Vault CLI/API 寫入到后端指定路徑下
4. 在 Vault 后端寫入業務中希望獲取的 RAM 憑證所對應的策略定義或角色，其中策略定義支持 inline 和 remote 策略兩種形式，所謂 inline 模式是指直接在 api 請求中寫入策略模板，remote 模式指寫入 RAM 中存在的策略類型和名稱，比如：
$ vault write alicloud/role/policy-based \
remote_policies= name:AliyunOSSReadOnlyAccess,type:System \
remote_policies= name:AliyunRDSReadOnlyAccess,type:System角色模式需要用戶指定希望被扮演的角色 arn，另外需要 Vault 子賬號在該角色的受信實體里，一個示例如下：
$ vault write alibaba/role/role-based \
role_arn= acs:ram::5138828231865461:role/hastrustedactors5. 在具體的業務應用中，只需要通過調用 Vault 的 creds/policy-based 或 role-based 接口即可動態獲取相應的 RAM 訪問憑證，下面是一個角色扮演返回臨時 token 的 CLI 調用示例：
$ vault read alicloud/creds/role-based
Key Value
--- -----
lease_id alicloud/creds/role-based/f3e92392-7d9c-09c8-c921-575d62fe80d9
lease_duration 59m59s
lease_renewable false
access_key STS.L4aBSCSJVMuKg5U1vFDw
secret_key wyLTSmsyPGP1ohvvw8xYgB29dlGI8KMiH2pKCNZ9
security_token CAESrAIIARKAAShQquMnLIlbvEcIxO6wCoqJufs8sWwieUxu45hS9AvKNEte8KRUWiJWJ6Y+YHAPgNwi7yfRecMFydL2uPOgBI7LDio0RkbYLmJfIxHM2nGBPdml7kYEOXmJp2aDhbvvwVYIyt/8iES/R6N208wQh0Pk2bu+/9dvalp6wOHF4gkFGhhTVFMuTDRhQlNDU0pWTXVLZzVVMXZGRHciBTQzMjc0KgVhbGljZTCpnJjwySk6BlJzYU1ENUJuCgExGmkKBUFsbG93Eh8KDEFjdGlvbkVxdWFscxIGQWN0aW9uGgcKBW9zczoqEj8KDlJlc291cmNlRXF1YWxzEghSZXNvdXJjZRojCiFhY3M6b3NzOio6NDMyNzQ6c2FtcGxlYm94L2FsaWNlLyo=
expiration 2018-08-15T21:58:00Z如何在 k8s 應用中使用 Vault Secret
在了解了 Vault 的基本概念以及與 Kubernetes 的認證交互流程后，我們進入客戶最為關心的話題。如何在 k8s pod 應用中方便地獲取 Vault 服務端管理的 secret。社區針對此問題也有激烈的討論和不少相關解決方案，方案主要集中在兩個方向：
**[定時同步進程](https://github.com/hashicorp/vault/issues/7364
)**：使用一個同步進程定時地從 Vault 服務端獲取指定范圍的秘鑰更新并同步到 k8s 集群中的 secret 模型，代表的項目有 vaultingkube 和[secrets-manager]( https://github.com/tuenti/secrets-manager
)。其主要設計思想也不盡相同，以 secrets-manager 為例，首先用戶可以通過 CRD 定義在 Vault 中關注的 secret 數據源，然后 secrets-manager 對應的 controller 會在 Reconcile 函數中定時對比指定管理范圍內的 k8s secret 和 vault secret 的狀態，如果不一致則進行一次調協。而用戶在 pod 應用中可以直接引用原生 secret 模型中的內容獲取遠端 Vault 服務器中的秘鑰。
當然社區中也存在一些對這種秘鑰同步方案的質疑，比如認為該方案在秘鑰同步的傳輸過程和用戶 pod 使用原生 secret 的 rest 交互中會增加攻擊面，但是該方案在部署實施上比較友好，也得到了很多用戶的支持。
CSI 插件形式集成：該方案基于 CSI plugin 將 Vault 中的秘鑰通過 volume 的形式掛載到 pod 應用中。
secrets-store-csi-driver 通過實現一套基于 CSI 規范的 driver 機制可以對接不同廠商的后端存儲，而 Vault secret 的 driver(secrets-store.csi.k8s.com)允許 kubelet 將各類企業級秘鑰存儲中的 secret 通過 volume 掛載，一旦 attach 動作完成，秘鑰數據即掛載到了容器對應的文件系統中。在 CSI driver 的基礎上，不同的秘鑰管理后端可以實現定制化的 provider 去對接 CSI driver 框架中的規定接口。provider 的功能概括如下：
對接后端秘鑰管理系統，提供秘鑰獲取等必須的接口實現
適配當前 CSI driver 的接口定義
通過框架中的回調函數無需調用 Kubernetes API 即可將從后端獲取的秘鑰數據掛載到指定路徑下
HashiCorp 官方也基于此框架實現了一套對接 Vault 的 Provider。這里我們以此為例具體來看下在一個 k8s pod 應用中如何通過 CSI plugin 的方式使用 Vault 中管理的 secret 秘鑰。
1 首先我們創建一個開啟了 CSI 存儲插件的 ACK 集群，然后參考文檔在集群中部署 Vault 服務端，為了便于驗證這里我們使用 dev 模式省去 unseal 解封等流程，同時配置 provider 與 Vault 交互的認證模式和相應的訪問控制策略
然后通過 cli 向 Vault 后端寫入測試數據
2 通過官方提供的 helm 方式安裝 Secret Store CSI Driver，命令如下：
helm install . -n csi-secrets-store --namespace dev --set providers.vault.enabled=true安裝成功后如下圖所示：
3 在集群中創建 secretproviderclasses 實例用于 Secret Store CSI Driver 與 Vault 的參數對接，一個示例如下，注意這里的 vault 服務端地址可通過 kubectl get service vault 獲取。
4 最后我們來看下如何在應用 pod 中對接上述 provider 實例獲取對應的 Vault 秘鑰。這里 pod 對于上述 vault provider 的使用分為兩種方式：
1)如果 pod 運行的目標集群版本在 v1.15.0 以上，且集群 apiserver 和節點 kubelet manifest 配置均開啟了 CSIInlineVolume=true 的 feature-gates，則我們可以在 pod 中的 volume 字段內置聲明需要使用的 csi provider 實例。
kind: Pod
apiVersion: v1
metadata:
name: nginx-secrets-store-inline
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- name: secrets-store-inline
mountPath: /mnt/secrets-store
readOnly: true
volumes:
- name: secrets-store-inline
csi:
driver: secrets-store.csi.k8s.com
readOnly: true
volumeAttributes:
secretProviderClass: vault-foo2）如果目標集群不支持 CSI 的 Inline Volume 特性，我們需要首先創建使用 csi 的 pv 和對應的 pvc 實例，一個 pv 模板示例如下:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-vault
spec:
capacity:
storage: 1Gi
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Retain
csi:
driver: secrets-store.csi.k8s.com
readOnly: true
volumeHandle: kv
volumeAttributes:
providerName: vault
roleName: example-role
vaultAddress: http://172.21.12.21:8200
vaultSkipTLSVerify: true
objects: |
array:
- |
objectPath: /foo
objectName: bar
objectVersion: 在 pod 實例模板中引用指定 pvc 即可在 pod 中獲取到 vault，這里我們在 ACK 集群以 pv/pvc 模式為例創建一個 nginx 應用容器實例并在其中掛載上文中我們創建的 secretproviderclasses 實例：
相比于 secrets-manager 等采用 secret 定時同步的方式，使用 CSI 對接指定 Vault secret provider 實例的方式雖然在實施步驟上比較復雜，同時在應用中也無法動態獲取 Vault 后端 secret 的變更，但是該方案避免了 secret 在同步鏈路上頻繁傳輸的安全風險，同時也客服了之前 describe po 可能造成的秘鑰泄露，在整體安全性上要高出不少。大家可以根據實際應用場景選擇適合自己的方式。
以上就是關于“Vault 在 Kubernetes 中的應用場景是什么”這篇文章的內容，相信大家都有了一定的了解，希望丸趣 TV 小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注丸趣 TV 行業資訊頻道。
