Vault是什么？

如何在云上應(yīng)用中管理和保護(hù)用戶的敏感信息是一個經(jīng)常令開發(fā)者頭疼的問題，用戶的密碼口令，證書秘鑰等私密信息時常未經(jīng)加密被隨意的放置在配置文件，代碼倉庫或是共享存儲里，而對于普通的開發(fā)者來說，設(shè)計和實現(xiàn)一套完整的秘鑰管理系統(tǒng)是一個很大的挑戰(zhàn)。且不論令人生畏的加解密算法，很多的云應(yīng)用仍然將一些敏感配置信息僅僅經(jīng)過base64等一些簡單的hash運(yùn)算就放置在某個公共的配置中心上，而很多時候這些敏感信息會從應(yīng)用的某行異常日志或是某段監(jiān)控告警中泄露出去；不僅如此，對于一個集中式的秘鑰管理系統(tǒng)，如何面向用戶進(jìn)行更細(xì)粒度的訪問鑒權(quán)也是一個難題。

Vault的出現(xiàn)給了上述問題一個解決方案，它是HashiCorp公司（旗下還有Vagrant，Terraform，Consul等知名產(chǎn)品）維護(hù)的開源軟件，它的設(shè)計思想基于云原生背景下動態(tài)基礎(chǔ)設(shè)施的特點，在云上的不同網(wǎng)絡(luò)層以及不同的服務(wù)之間已經(jīng)很難找到傳統(tǒng)的信任邊界，服務(wù)之間更加強(qiáng)調(diào)以身份（identity）為核心的認(rèn)證和訪問控制，而不是像傳統(tǒng)靜態(tài)基礎(chǔ)設(shè)施中以IP、主機(jī)地址作為信任憑證。為此Vault提供了以下幾個功能點：

Secret存儲形式的多樣性，任意的kv形式敏感信息（如數(shù)據(jù)庫密碼，證書，ssh登錄秘鑰，openapi身份憑證等）；

存儲格式的多樣性，支持插件式的存儲引擎擴(kuò)展，可對接如AWS，Consul，NoSQL，KV，PKI，SSH等多種插件引擎；

支持與各類平臺的認(rèn)證對接，可動態(tài)生成認(rèn)證憑據(jù)或配置信息；

支持基于Shamir算法的私鑰分割完成Vault后端的加封和解封操作，同時支持高可用的部署形態(tài)；

支持各類secret的動態(tài)生成，續(xù)租，撤銷和滾動更新；

完備的審計日志；

完備的CLI和RESTful API

Vault與k8s的集成

Vault松耦合的架構(gòu)使其支持與多種secret引擎和相應(yīng)的存儲后端對接，同時支持與多種認(rèn)證服務(wù)器的交互。 本節(jié)我們主要介紹Vault與k8s的集成。

Vault在Kubernetes中的應(yīng)用場景

Vault作為企業(yè)級的secret管理工具，是一些大客戶在業(yè)務(wù)上云過程中的安全強(qiáng)需求，尤其是國外市場。在Kubernetes集群中主要有以下應(yīng)用場景：

作為部署在Kubernetes集群中的應(yīng)用對外提供秘鑰管理服務(wù)，支持與多家主流云廠商秘鑰服務(wù)以及多種secrets形式的對接，支持多種數(shù)據(jù)庫服務(wù)的存儲對接，同時支持多種認(rèn)證形式的對接。

作為一個公共的加密服務(wù)（Encryption as a Service）而不做后端存儲的對接，幫助用戶應(yīng)用剝離繁瑣的加密加解密邏輯。

面向政府、金融等對數(shù)據(jù)安全規(guī)格有很高要求的客戶，Vault支持基于Two-man原則利用私鑰分割算法對后端服務(wù)進(jìn)行加解封，并結(jié)合k8s的高可用部署形態(tài)為企業(yè)提供更加安全可靠的secret管理能力。 當(dāng)然這里只是列舉了一些Vault原生提供的能力，作為一個在Kubernetes集群上直接運(yùn)行的安全應(yīng)用，任何一個面向k8s的應(yīng)用工具都可以利用其安全能力。

安裝Vault

Vault支持helm化安裝，在其官方文檔中我們可以找到關(guān)于啟動參數(shù)的詳細(xì)配置說明，同時在阿里云容器服務(wù)的應(yīng)用目錄apphub中我們也可以通過控制臺在ACK集群中方便的安裝Vault

另外Vault的默認(rèn)安裝也集成了其控制臺的安裝，通過負(fù)載均衡服務(wù)或ingress路由的方式我們可以在公網(wǎng)訪問其UI，在vault pod的日志中我們可以找到登錄使用的root token，在控制臺中可以方便的設(shè)定與存儲引擎和認(rèn)證方式的對接，同時還可以進(jìn)行基于策略的訪問控制配置。

認(rèn)證方式的集成

當(dāng)用戶希望在k8s pod的業(yè)務(wù)邏輯中與Vault服務(wù)端通訊，獲取需要的secrets時，首先Vault會對這個pod中的請求進(jìn)行認(rèn)證，那么這個pod中的Vault請求認(rèn)證憑據(jù)應(yīng)該如何獲取呢？如上所述，Vault后端支持多種認(rèn)證方式的對接，對于Kubernetes，Vault支持基于K8s Service Account Token的認(rèn)證。

使用上，Vault管理員首先需要在后端enable kubernetes的認(rèn)證方式，生成一個與Vault交互的指定sa，然后通過CLI或API將sa token和集群ca，公網(wǎng)地址等信息寫入到Vault后端中，并配置與vault后端的ACL策略綁定。詳細(xì)步驟請參見官方文檔。

當(dāng)然在pod應(yīng)用中可以并不局限于一定使用基于sa的kubernetes認(rèn)證方式。比如[kubernetes-vault]( https://github.com/Boostport/kubernetes-vault)。該項目使用Vault中的[AppRole](https://www.vaultproject.io/docs/auth/approle.html)認(rèn)證方式，在該認(rèn)證模式中，管理員可以為不同的pod創(chuàng)建不同的Vault原生role模型并綁定到對應(yīng)的policy上，同時可以基于role創(chuàng)建secret_id，secret_id對應(yīng)的token可作為與Vault進(jìn)行認(rèn)證的臨時憑證。kubernetes-vault利用了AppRole的認(rèn)證交互模式，首先已經(jīng)完成安裝的kubernetes-vault controller會去Watch集群中所有pod的創(chuàng)建，當(dāng)發(fā)現(xiàn)新建pod的部署模板中有指定annotation的init-container存在時，controller會根據(jù)模板中指定的vault role id去Vault請求獲取其對應(yīng)的secret_id并發(fā)送給init-container中kubernetes-vault的客戶端，在應(yīng)用容器啟動前kubernetes-vault客戶端用controller返回的secret_id和role_id去Vault請求真正的login token并最終寫入到與應(yīng)用pod共享的掛載目錄中；同時客戶端會根據(jù)token過期時間進(jìn)行定時的輪轉(zhuǎn)，保證其可用性。下圖為kubernetes-vault工作流程圖：

在社區(qū)也存在不少基于k8s與Vault進(jìn)行認(rèn)證對接的其他方案，其設(shè)計思路大同小異，基本都采用了通過init-container或sidecar方式引入一個額外的客戶端去Vault請求指定認(rèn)證模式下的短時憑證并共享給業(yè)務(wù)容器使用。 在容器服務(wù)控制臺的應(yīng)用目錄apphub中，我們同樣可以找到kubernetes-vault，方便開發(fā)者使用helm直接在集群指定命名空間一鍵部署。Vault也計劃在后續(xù)自己的官方版本helm chart中增加配置項以支持上述登錄認(rèn)證secret的動態(tài)注入。

Vault與阿里云RAM的集成

當(dāng)我們在應(yīng)用中需要訪問阿里云資源時，需要使用RAM賬號對應(yīng)的AK或是STS臨時credentials作為訪問相應(yīng)資源接口的憑證。如果使用賬號AK，如何使其能夠被應(yīng)用邏輯獲取的同時保證AK的安全性一直是一個頭疼的問題；如果使用臨時sts token，由于其時效性，我們也需要在考慮安全性的同時思考如何進(jìn)行臨時訪問憑證的輪轉(zhuǎn)。相比較兩種方式，使用sts臨時憑證的方式肯定在安全上是更為推薦的方式，同時對這種動態(tài)secret的安全管理也正是Vault的優(yōu)勢所在。本節(jié)我們來介紹下Vault與阿里云RAM在認(rèn)證方式和secret管理引擎上的集成。

認(rèn)證方式的集成

首先在認(rèn)證方式上，Vault服務(wù)端的role模型可以與RAM role進(jìn)行一對一的映射匹配，用戶可以使用Vault提供的OpenAPI或是CLI，通過傳入扮演RAM role返回的臨時憑證調(diào)用GetCallerIdentity接口，然后Vault服務(wù)端會根據(jù)請求返回的角色arn id在其后端存儲中查找是否有對應(yīng)的權(quán)限策略配置，如果存在則認(rèn)證成功并返回一個可用于調(diào)用Vault其他后端接口的訪問token。

Vault Secret引擎與RAM的集成

當(dāng)我們需要在業(yè)務(wù)應(yīng)用邏輯中使用阿里云資源時，通常需要通過角色扮演的方式獲取一個RAM返回的臨時憑證，然后通過這個臨時憑證完成與RAM的鑒權(quán)過程。由于憑證的時效性，我們在保證其安全性的同時還要維護(hù)一個對應(yīng)的秘鑰輪轉(zhuǎn)機(jī)制。Vault的secret引擎實現(xiàn)了與阿里云RAM的對接插件，幫助我們安全、動態(tài)的管理RAM憑證，其主要步驟 如下:

1.開啟后端引擎

2.在RAM控制臺為Vault服務(wù)器創(chuàng)建專屬子賬號并綁定定制化權(quán)限策略

3.獲取Vault子賬號對應(yīng)的AK并通過Vault CLI/API寫入到后端指定路徑下

4.在Vault后端寫入業(yè)務(wù)中希望獲取的RAM憑證所對應(yīng)的策略定義或角色，其中策略定義支持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.在具體的業(yè)務(wù)應(yīng)用中，只需要通過調(diào)用Vault的creds/policy-based或role-based接口即可動態(tài)獲取相應(yīng)的RAM訪問憑證，下面是一個角色扮演返回臨時token的CLI調(diào)用示例：

$?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應(yīng)用中使用Vault Secret

在了解了Vault的基本概念以及與Kubernetes的認(rèn)證交互流程后，我們進(jìn)入客戶最為關(guān)心的話題。如何在k8s pod應(yīng)用中方便地獲取Vault服務(wù)端管理的secret。社區(qū)針對此問題也有激烈的討論和不少相關(guān)解決方案，方案主要集中在兩個方向：

**[定時同步進(jìn)程](https://github.com/hashicorp/vault/issues/7364)**：使用一個同步進(jìn)程定時地從Vault服務(wù)端獲取指定范圍的秘鑰更新并同步到k8s集群中的secret模型，代表的項目有vaultingkube 和[secrets-manager]( https://github.com/tuenti/secrets-manager) 。其主要設(shè)計思想也不盡相同，以secrets-manager為例，首先用戶可以通過CRD定義在Vault中關(guān)注的secret數(shù)據(jù)源，然后secrets-manager對應(yīng)的controller會在Reconcile函數(shù)中定時對比指定管理范圍內(nèi)的k8s secret和vault secret的狀態(tài)，如果不一致則進(jìn)行一次調(diào)協(xié)。而用戶在pod應(yīng)用中可以直接引用原生secret模型中的內(nèi)容獲取遠(yuǎn)端Vault服務(wù)器中的秘鑰。 當(dāng)然社區(qū)中也存在一些對這種秘鑰同步方案的質(zhì)疑，比如認(rèn)為該方案在秘鑰同步的傳輸過程和用戶pod使用原生secret的rest交互中會增加攻擊面，但是該方案在部署實施上比較友好，也得到了很多用戶的支持。

CSI插件形式集成：該方案基于CSI plugin將Vault中的秘鑰通過volume的形式掛載到pod應(yīng)用中。secrets-store-csi-driver 通過實現(xiàn)一套基于CSI規(guī)范的driver機(jī)制可以對接不同廠商的后端存儲，而Vault secret的driver(secrets-store.csi.k8s.com)允許kubelet將各類企業(yè)級秘鑰存儲中的secret通過volume掛載，一旦attach動作完成，秘鑰數(shù)據(jù)即掛載到了容器對應(yīng)的文件系統(tǒng)中。在CSI driver的基礎(chǔ)上，不同的秘鑰管理后端可以實現(xiàn)定制化的provider去對接CSI driver框架中的規(guī)定接口。provider的功能概括如下：

對接后端秘鑰管理系統(tǒng)，提供秘鑰獲取等必須的接口實現(xiàn)

適配當(dāng)前CSI driver的接口定義

通過框架中的回調(diào)函數(shù)無需調(diào)用Kubernetes API即可將從后端獲取的秘鑰數(shù)據(jù)掛載到指定路徑下

HashiCorp官方也基于此框架實現(xiàn)了一套對接Vault的Provider。這里我們以此為例具體來看下在一個k8s pod應(yīng)用中如何通過CSI plugin的方式使用Vault中管理的secret秘鑰。

1 首先我們創(chuàng)建一個開啟了CSI存儲插件的ACK集群，然后參考文檔在集群中部署Vault服務(wù)端，為了便于驗證這里我們使用dev模式省去unseal解封等流程，同時配置provider與Vault交互的認(rèn)證模式和相應(yīng)的訪問控制策略

然后通過cli向Vault后端寫入測試數(shù)據(jù)

2 通過官方提供的helm方式安裝Secret Store CSI Driver，命令如下：

helm?install?.?-n?csi-secrets-store?--namespace?dev?--set?providers.vault.enabled=true

安裝成功后如下圖所示：

3 在集群中創(chuàng)建secretproviderclasses實例用于Secret Store CSI Driver與Vault的參數(shù)對接，一個示例如下，注意這里的vault服務(wù)端地址可通過kubectl get service vault獲取。

4 最后我們來看下如何在應(yīng)用pod中對接上述provider實例獲取對應(yīng)的Vault秘鑰。這里pod對于上述vault provider的使用分為兩種方式：

1)如果pod運(yùn)行的目標(biāo)集群版本在v1.15.0以上，且集群apiserver和節(jié)點kubelet manifest配置均開啟了 CSIInlineVolume=true的feature-gates，則我們可以在pod中的volume字段內(nèi)置聲明需要使用的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）如果目標(biāo)集群不支持CSI的Inline Volume特性，我們需要首先創(chuàng)建使用csi的pv和對應(yīng)的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模式為例創(chuàng)建一個nginx應(yīng)用容器實例并在其中掛載上文中我們創(chuàng)建的secretproviderclasses實例：

相比于secrets-manager等采用secret定時同步的方式，使用CSI對接指定Vault secret provider實例的方式雖然在實施步驟上比較復(fù)雜，同時在應(yīng)用中也無法動態(tài)獲取Vault后端secret的變更，但是該方案避免了secret在同步鏈路上頻繁傳輸?shù)陌踩L(fēng)險，同時也客服了之前describe po可能造成的秘鑰泄露，在整體安全性上要高出不少。大家可以根據(jù)實際應(yīng)用場景選擇適合自己的方式。