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過期時間進行定時的輪轉，保證其可用性。下圖為kubernetes-vault工作流程圖：

在社區也存在不少基于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/hastrustedactors'

5.在具體的業務應用中，只需要通過調用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-foo"

2）如果目標集群不支持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可能造成的秘鑰泄露，在整體安全性上要高出不少。大家可以根據實際應用場景選擇適合自己的方式。