secrets 管理工具 Vault 的介紹、安裝及使用

原文：https://ryan4yin.space/posts/expirence-of-vault/

Vault 是 hashicorp 推出的 secrets 管理、加密即服務與權限管理工具。它的功能簡介以下：

1. secrets 管理：支持保存各類自定義信息、自動生成各種密鑰，vault 自動生成的密鑰還能自動輪轉(rotate)
2. 認證方式：支持接入各大雲廠商的帳號權限體系（好比阿里雲RAM子帳號體系）或者 LDAP 等進行身份驗證，不須要建立額外的帳號體系。
3. 權限管理：經過 policy，能夠設定很是細緻的 ACL 權限。
4. 密鑰引擎：也支持接入各大雲廠商的帳號體系（好比阿里雲RAM子帳號體系），實現 APIKey/APISecret 的自動輪轉。
5. 支持接入 kubernetes rbac 權限體系，經過 serviceaccount+role 爲每一個 Pod 單獨配置權限。

在使用 Vault 以前，咱們是以攜程開源的 Apollo 做爲微服務的分佈式配置中心。

Apollo 在國內很是流行。它功能強大，支持配置的繼承，也有提供 HTTP API 方便自動化。
缺點是權限管理和 secrets 管理比較弱，也不支持信息加密，不適合直接存儲敏感信息。所以咱們如今切換到了 Vault.

目前咱們本地的 CI/CD 流水線和雲上的微服務體系，都是使用的 Vault 作 secrets 管理.

1、Vault 基礎概念

首先看一下 Vault 的架構圖：

能夠看到，幾乎全部的組件都從屬於「安全屏障(security barrier)」，
Vault 能夠簡單地被劃分爲 Storage Backend、安全屏障(security barrier) 和 HTTP API 三個部分。

「安全屏障(security barrier)」是 Vault(金庫) 周圍的加密「鋼鐵」和「混凝土」，Storage Backend 和 Vault 之間的全部數據流動都須要通過「屏障(barrier)」。
barrier 確保只有加密數據會被寫入 Storage Backend，加密數據在通過 barrier 的過程當中被驗證與解密。
和銀行金庫(bank vault)很是相似，barrier 也必須先解封，才能容許讀取內部的數據。

1. 數據存儲及加密解密

Storage Backend(後端存儲): Vault 自身不存儲數據，所以須要爲它配置一個「Storage Backend」。
「Storage Backend」是不受信任的，只用於存儲加密數據。

Initialaztion(初始化): vault 在首次啓動時須要初始化，這一步生成一個「加密密鑰(encryption key)」用於加密數據，加密完成的數據才能被保存到 Storage Backend.

Unseal(解封): Vault 啓動後，由於不知道「加密密鑰(encryption key)」，它會進入「封印(sealed)」狀態，在「Unseal」前沒法進行任何操做。
「加密密鑰」被「master key」保護，咱們必須提供「master key」才能完成 Unseal 操做。
默認狀況下，vault 使用沙米爾密鑰共享算法
將「master key」分割成五個「Key Shares(分享密鑰)」，必需要提供其中任意三個「Key Shares」才能重建出「master key」從而完成 Unseal.

「Key Shares」的數量，以及重建「master key」最少須要的 key shares 數量，都是能夠調整的。
沙米爾密鑰共享算法也能夠關閉，這樣 master key 將被直接用於 Unseal.

2. 認證系統及權限系統

在解封完成後，Vault 就能夠開始處理請求了。

HTTP 請求進入後的整個處理流程都由 vault core 管理，core 會強制進行 ACL 檢查，並確保審計日誌(audit logging)完成記錄。

客戶端首次鏈接 vault 時，須要先完成身份認證，vault 的「auth methods」模塊有不少身份認證方法可選：

1. 用戶友好的認證方法，適合管理員使用：username/password、雲服務商、ldap
   1. 在建立 user 的時候，須要爲 user 綁定 policy，給予合適的權限。
2. 應用友好的方法：public/private keys、tokens、kubernetes、jwt

身份驗證請求流經 Core 並進入 auth methods，auth methods 肯定請求是否有效並返回「關聯策略(policies)」的列表。

ACL Policies 由 policy store 負責管理與存儲，由 core 進行 ACL 檢查。
ACL 的默認行爲是拒絕，這意味着除非明確配置 Policy 容許某項操做，不然該操做將被拒絕。

在經過 auth methods 完成了身份認證，而且返回的「關聯策略」也沒毛病以後，「token store」將會生成並管理一個新的 token，
這個 token 會被返回給客戶端，用於進行後續請求。
相似 web 網站的 cookie，token 也都存在一個 lease 租期或者說有效期，這增強了安全性。

token 關聯了相關的策略 policies，策略將被用於驗證請求的權限。
請求通過驗證後，將被路由到 secret engine。若是 secret engine 返回了一個 secret（由 vault 自動生成的 secret），
Core 會將其註冊到 expiration manager，並給它附加一個 lease ID。lease ID 被客戶端用於更新(renew)或吊銷(revoke)它獲得的 secret.
若是客戶端容許租約(lease)到期，expiration manager 將自動吊銷這個 secret.

Core 負責處理審覈代理(audit brok)的請求及響應日誌，將請求發送到全部已配置的審覈設備(audit devices)。

3. Secret Engine

Secret Engine 是保存、生成或者加密數據的組件，它很是靈活。

有的 Secret Engines 只是單純地存儲與讀取數據，好比 kv 就能夠看做一個加密的 Redis。
而其餘的 Secret Engines 則鏈接到其餘的服務並按需生成動態憑證。
還有些 Secret Engines 提供「加密即服務(encryption as a service)」 - transit、證書管理等。

經常使用的 engine 舉例：

1. AliCloud Secrets Engine: 基於 RAM 策略動態生成 AliCloud Access Token，或基於 RAM 角色動態生成 AliCloud STS 憑據
   • Access Token 會自動更新(Renew)，而 STS 憑據是臨時使用的，過時後就失效了。
2. kv: 鍵值存儲，可用於存儲一些靜態的配置。它必定程度上能替代掉攜程的 Apollo 配置中心。
3. Transit Secrets Engine: 提供加密即服務的功能，它只負責加密和解密，不負責存儲。主要應用場景是幫 app 加解密數據，可是數據仍舊存儲在 MySQL 等數據庫中。

2、部署 Vault

官方建議經過 Helm 部署 vault，大概流程：

1. 使用 helm/docker 部署運行 vault.
2. 初始化/解封 vault: vault 安全措施，每次重啓必須解封(可設置自動解封).

1. docker-compose 部署

推薦用於本地開發測試環境，或者其餘不須要高可用的環境。

docker-compose.yml 示例以下：

version: '3.3'
services:
  vault:
    # 文檔：https://hub.docker.com/_/vault
    image: vault:1.6.0
    container_name: vault
    ports:
      # rootless 容器，內部不能使用標準端口 443
      - "443:8200"
    restart: always
    volumes:
      # 審計日誌存儲目錄，默認不寫審計日誌，啓用 `file` audit backend 時必須提供一個此文件夾下的路徑
      - ./logs:/vault/logs
      # 當使用 file data storage 插件時，數據被存儲在這裏。默認不往這寫任何數據。
      - ./file:/vault/file
      # 配置目錄，vault 默認 `/valut/config/` 中全部以 .hcl/.json 結尾的文件
      # config.hcl 文件內容，參考 cutom-vaules.yaml
      - ./config.hcl:/vault/config/config.hcl
      # TLS 證書
      - ./certs:/certs
    # vault 須要鎖定內存以防止敏感值信息被交換(swapped)到磁盤中
    # 爲此須要添加以下能力
    cap_add:
      - IPC_LOCK
    # 必須手動設置 entrypoint，不然 vault 將以 development 模式運行
    entrypoint: vault server -config /vault/config/config.hcl

config.hcl 內容以下：

ui = true

// 使用文件作數據存儲（單節點）
storage "file" {
  path    = "/vault/file"
}

listener "tcp" {
  address = "[::]:8200"

  tls_disable = false
  tls_cert_file = "/certs/server.crt"
  tls_key_file  = "/certs/server.key"
}

將如上兩份配置保存在同一非文件夾內，同時在 ./certs 中提供 TLS 證書 server.crt 和私鑰 server.key。

而後 docker-compose up -d 就能啓動運行一個 vault 實例。

2. 經過 helm 部署 vault {#install-by-helm}

推薦用於生產環境

經過 helm 部署：

# 添加 valut 倉庫
helm repo add hashicorp https://helm.releases.hashicorp.com
# 查看 vault 版本號
helm search repo hashicorp/vault -l | head
# 下載某個版本號的 vault
helm pull hashicorp/vault --version  0.9.0 --untar

參照下載下來的 ./vault/values.yaml 編寫 custom-values.yaml，
部署一個以 mysql 爲後端存儲的 HA vault，配置示例以下:

global:
  # enabled is the master enabled switch. Setting this to true or false
  # will enable or disable all the components within this chart by default.
  enabled: true
  # TLS for end-to-end encrypted transport
  tlsDisable: false

injector:
  # True if you want to enable vault agent injection.
  enabled: true

  replicas: 1

  # If multiple replicas are specified, by default a leader-elector side-car
  # will be created so that only one injector attempts to create TLS certificates.
  leaderElector:
    enabled: true
    image:
      repository: "gcr.io/google_containers/leader-elector"
      tag: "0.4"
    ttl: 60s

  # If true, will enable a node exporter metrics endpoint at /metrics.
  metrics:
    enabled: false

  # Mount Path of the Vault Kubernetes Auth Method.
  authPath: "auth/kubernetes"

  certs:
    # secretName is the name of the secret that has the TLS certificate and
    # private key to serve the injector webhook. If this is null, then the
    # injector will default to its automatic management mode that will assign
    # a service account to the injector to generate its own certificates.
    secretName: null

    # caBundle is a base64-encoded PEM-encoded certificate bundle for the
    # CA that signed the TLS certificate that the webhook serves. This must
    # be set if secretName is non-null.
    caBundle: ""

    # certName and keyName are the names of the files within the secret for
    # the TLS cert and private key, respectively. These have reasonable
    # defaults but can be customized if necessary.
    certName: tls.crt
    keyName: tls.key

server:
  # Resource requests, limits, etc. for the server cluster placement. This
  # should map directly to the value of the resources field for a PodSpec.
  # By default no direct resource request is made.

  # authDelegator enables a cluster role binding to be attached to the service
  # account.  This cluster role binding can be used to setup Kubernetes auth
  # method.  https://www.vaultproject.io/docs/auth/kubernetes.html
  authDelegator:
    enabled: true

  # Enables a headless service to be used by the Vault Statefulset
  service:
    enabled: true
    # clusterIP controls whether a Cluster IP address is attached to the
    # Vault service within Kubernetes.  By default the Vault service will
    # be given a Cluster IP address, set to None to disable.  When disabled
    # Kubernetes will create a "headless" service.  Headless services can be
    # used to communicate with pods directly through DNS instead of a round robin
    # load balancer.
    # clusterIP: None

    # Configures the service type for the main Vault service.  Can be ClusterIP
    # or NodePort.
    #type: ClusterIP

    # If type is set to "NodePort", a specific nodePort value can be configured,
    # will be random if left blank.
    #nodePort: 30000

    # Port on which Vault server is listening
    port: 8200
    # Target port to which the service should be mapped to
    targetPort: 8200


  # This configures the Vault Statefulset to create a PVC for audit
  # logs.  Once Vault is deployed, initialized and unseal, Vault must
  # be configured to use this for audit logs.  This will be mounted to
  # /vault/audit
  # See https://www.vaultproject.io/docs/audit/index.html to know more
  auditStorage:
    enabled: false
    # Size of the PVC created
    size: 10Gi
    # Name of the storage class to use.  If null it will use the
    # configured default Storage Class.
    storageClass: null
    # Access Mode of the storage device being used for the PVC
    accessMode: ReadWriteOnce
    # Annotations to apply to the PVC
    annotations: {}

  # Run Vault in "HA" mode. There are no storage requirements unless audit log
  # persistence is required.  In HA mode Vault will configure itself to use Consul
  # for its storage backend.  The default configuration provided will work the Consul
  # Helm project by default.  It is possible to manually configure Vault to use a
  # different HA backend.
  ha:
    enabled: true
    replicas: 3

    # Set the api_addr configuration for Vault HA
    # See https://www.vaultproject.io/docs/configuration#api_addr
    # If set to null, this will be set to the Pod IP Address
    apiAddr: null

    # config is a raw string of default configuration when using a Stateful
    # deployment. Default is to use a Consul for its HA storage backend.
    # This should be HCL.
    
    # Note: Configuration files are stored in ConfigMaps so sensitive data 
    # such as passwords should be either mounted through extraSecretEnvironmentVars
    # or through a Kube secret.  For more information see: 
    # https://www.vaultproject.io/docs/platform/k8s/helm/run#protecting-sensitive-vault-configurations
    config: |
      ui = true

      listener "tcp" {
        address = "[::]:8200"
        cluster_address = "[::]:8201"

        tls_disable = false
        tls_cert_file = "/etc/certs/vault.crt"
        tls_key_file  = "/etc/certs/vault.key"
      }

      storage "mysql" {
        address = "<host>:3306"
        username = "<username>"
        password = "<password>"
        database = "vault"
        ha_enabled = "true"
      }

      service_registration "kubernetes" {}

      # Example configuration for using auto-unseal, using Google Cloud KMS. The
      # GKMS keys must already exist, and the cluster must have a service account
      # that is authorized to access GCP KMS.
      #seal "gcpckms" {
      #   project     = "vault-helm-dev-246514"
      #   region      = "global"
      #   key_ring    = "vault-helm-unseal-kr"
      #   crypto_key  = "vault-helm-unseal-key"
      #}

# Vault UI
ui:
  # True if you want to create a Service entry for the Vault UI.
  #
  # serviceType can be used to control the type of service created. For
  # example, setting this to "LoadBalancer" will create an external load
  # balancer (for supported K8S installations) to access the UI.
  enabled: true
  publishNotReadyAddresses: true
  # The service should only contain selectors for active Vault pod
  activeVaultPodOnly: false
  serviceType: "ClusterIP"
  serviceNodePort: null
  externalPort: 8200

如今使用自定義的 custom-values.yaml 部署 vautl:

kubectl create namespace vault
# 安裝/升級 valut
helm upgrade --install vault ./vault --namespace vault -f custom-values.yaml

3. 初始化(initalize)並解封(unseal) vault

官方文檔：Initialize and unseal Vault - Vault on Kubernetes Deployment Guide

經過 helm 部署 vault，默認會部署一個三副本的 StatefulSet，可是這三個副本都會處於 NotReady 狀態（docker 方式部署的也同樣）。
接下來還須要手動初始化(initalize)並解封(unseal) vault，才能 Ready:

1. 第一步：從三個副本中隨便選擇一個，運行 vault 的初始化命令：kubectl exec -ti vault-0 -- vault operator init
   1. 初始化操做會返回 5 個 unseal keys，以及一個 Initial Root Token，這些數據很是敏感很是重要，必定要保存到安全的地方！
2. 第二步：在每一個副本上，使用任意三個 unseal keys 進行解封操做。
   1. 一共有三個副本，也就是說要解封 3*3 次，才能完成 vault 的完整解封！

# 每一個實例都須要解封三次！
## Unseal the first vault server until it reaches the key threshold
$ kubectl exec -ti vault-0 -- vault operator unseal # ... Unseal Key 1
$ kubectl exec -ti vault-0 -- vault operator unseal # ... Unseal Key 2
$ kubectl exec -ti vault-0 -- vault operator unseal # ... Unseal Key 3

這樣就完成了部署，可是要注意，vault 實例每次重啓後，都須要從新解封！也就是從新進行第二步操做！

4. 設置自動解封

每次重啓都要手動解封全部 vault 實例，實在是很麻煩，在雲上自動擴縮容的狀況下，vault 實例會被自動調度，這種狀況就更麻煩了。

爲了簡化這個流程，能夠考慮配置 auto unseal 讓 vault 自動解封。

自動解封目前有兩種方法：

1. 使用阿里雲/AWS/Azure 等雲服務提供的密鑰庫來管理 encryption key，阿里雲的相關配置方法：alicloudkms Seal
2. 若是你不想用雲服務，那能夠考慮 autounseal-transit

簡單起見，也能夠寫個 crontab 或者在 CI 平臺上加個定時任務去執行解封命令，以實現自動解封。

3、Vault 自身的配置管理

Vault 自己是一個複雜的 secrets 工具，它提供了 Web UI 和 CLI 用於手動管理與查看 Vault 的內容。

可是做爲一名 DevOps，咱們固然更喜歡自動化的方法，這有兩種選擇:

• 使用 vault 的 sdk: python-hvac
• 使用 terraform-provider-vault 或者 pulumi-vault 實現 vault 配置的自動化管理。

Web UI 適合手工操做，而 sdk/terraform-provider-vault 則適合用於自動化管理 vault.

咱們的測試環境就是使用 pulumi-vault 完成的自動化配置 vault policy 和 kubernetes role，而後自動化注入全部測試用的 secrets.

1. 使用 pulumi 自動化配置 vault

使用 pulumi 管理 vault 配置的優點是很大的，由於雲上資源的敏感信息（數據庫帳號密碼、資源 ID、RAM子帳號）都是 pulumi 建立的。

再結合使用 pulumi_valut，就能實現敏感信息自動生成後，當即保存到 vault 中，實現徹底自動化。

後續微服務就能夠經過 kubernetes 認證，直接從 vault 讀取敏感信息。

或者是寫入到本地的 vault 中留作備份，在須要的時候，管理員能登入進去查看相關敏感信息。

1.1 Token 的生成

pulumi_vault 自己挺簡單的，聲明式的配置嘛，直接用就是了。

可是它必定要求提供 VAULT_TOKEN 做爲身份認證的憑證（實測 userpass/approle 都不能直接使用，會報錯 no vault token found），並且 pulumi 還會先生成臨時用的 child token，而後用這個 child token
進行後續的操做。

首先安全起見，確定不該該直接提供 root token！root token 應該封存，除了緊急狀況不該該啓用。

那麼應該如何生成一個權限有限的 token 給 vault 使用呢？
個人方法是建立一個 userpass 帳號，經過 policy 給予它有限的權限。
而後先手動(或者自動)登陸獲取到 token，再將 token 提供給 pulumi_vault 使用。

這裏面有個坑，就是必須給 userpass 帳號建立 child token 的權限：

path "local/*" {
  capabilities = ["read", "list"]
}

// 容許建立 child token
path "auth/token/create" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

不給這個權限，pulumi_vault 就會一直報錯。。

4、在 Kubernetes 中使用 vault 注入敏感配置

1. 部署並配置 vault agent

前面提到過 vault 支持經過 Kubernetes 的 ServiceAccount + Role 爲每一個 Pod 單獨分配權限。

首先啓用 Vault 的 Kubernetes 身份驗證:

# 配置身份認證須要在 vault pod 中執行，啓動 vault-0 的交互式會話
kubectl exec -n vault -it vault-0 -- /bin/sh
export VAULT_TOKEN='<your-root-token>'
export VAULT_ADDR='http://localhost:8200'
 
# 啓用 Kubernetes 身份驗證
vault auth enable kubernetes

# kube-apiserver API 配置，vault 須要經過 kube-apiserver 完成對 serviceAccount 的身份驗證
vault write auth/kubernetes/config \
    token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
    kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

1.1 使用集羣外部的 valut 實例

若是你沒這個需求，請跳過這一節。

詳見 Install the Vault Helm chart configured to address an external Vault

kubernetes 也能夠和外部的 vault 實例集成，集羣中只部署 vault-agent.

這適用於多個 kubernetes 集羣以及其餘 APP 共用一個 vault 實例的狀況，好比咱們本地的多個開發測試集羣，就都共用着同一個 vault 實例，方便統一管理應用的 secrets.

首先，使用 helm chart 部署 vault-agent，接入外部的 vault 實例。使用的 custom-values.yaml 示例以下：

global:
  # enabled is the master enabled switch. Setting this to true or false
  # will enable or disable all the components within this chart by default.
  enabled: true
  # TLS for end-to-end encrypted transport
  tlsDisable: false

injector:
  # True if you want to enable vault agent injection.
  enabled: true

  replicas: 1

  # If multiple replicas are specified, by default a leader-elector side-car
  # will be created so that only one injector attempts to create TLS certificates.
  leaderElector:
    enabled: true
    image:
      repository: "gcr.io/google_containers/leader-elector"
      tag: "0.4"
    ttl: 60s

  # If true, will enable a node exporter metrics endpoint at /metrics.
  metrics:
    enabled: false

  # External vault server address for the injector to use. Setting this will
  # disable deployment of a  vault server along with the injector.
  # TODO 這裏的 https ca.crt 要怎麼設置？mTLS 又該如何配置？
  externalVaultAddr: "https://<external-vault-url>"

  # Mount Path of the Vault Kubernetes Auth Method.
  authPath: "auth/kubernetes"

  certs:
    # secretName is the name of the secret that has the TLS certificate and
    # private key to serve the injector webhook. If this is null, then the
    # injector will default to its automatic management mode that will assign
    # a service account to the injector to generate its own certificates.
    secretName: null

    # caBundle is a base64-encoded PEM-encoded certificate bundle for the
    # CA that signed the TLS certificate that the webhook serves. This must
    # be set if secretName is non-null.
    caBundle: ""

    # certName and keyName are the names of the files within the secret for
    # the TLS cert and private key, respectively. These have reasonable
    # defaults but can be customized if necessary.
    certName: tls.crt
    keyName: tls.key

部署命令和 經過 helm 部署 vault 一致，只要更換 custom-values.yaml 就行。

vault-agent 部署完成後，第二步是爲 vault 建立 serviceAccount、secret 和 ClusterRoleBinding，以容許 vault 審查 kubernetes 的 token, 完成對 pod 的身份驗證. yaml 配置以下：

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vault-auth
  namespace: vault
---
apiVersion: v1
kind: Secret
metadata:
  name: vault-auth
  namespace: vault
  annotations:
    kubernetes.io/service-account.name: vault-auth
type: kubernetes.io/service-account-token
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: role-tokenreview-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - kind: ServiceAccount
    name: vault-auth
    namespace: vault

如今在 vault 實例這邊，啓用 kubernetes 身份驗證，在 vault 實例內，執行以下命令：

vault 實例內顯然沒有 kubectl 和 kubeconfig，簡便起見，下列的 vault 命令也能夠經過 Web UI 完成。

export VAULT_TOKEN='<your-root-token>'
export VAULT_ADDR='http://localhost:8200'
 
# 啓用 Kubernetes 身份驗證
vault auth enable kubernetes
 
# kube-apiserver API 配置，vault 須要經過 kube-apiserver 完成對 serviceAccount 的身份驗證
# TOKEN_REVIEW_JWT: 就是咱們前面建立的 secret `vault-auth`
TOKEN_REVIEW_JWT=$(kubectl -n vault get secret vault-auth -o go-template='{{ .data.token }}' | base64 --decode)
# kube-apiserver 的 ca 證書
KUBE_CA_CERT=$(kubectl -n vault config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}' | base64 --decode)
# kube-apiserver 的 url
KUBE_HOST=$(kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.server}')

vault write auth/kubernetes/config \
        token_reviewer_jwt="$TOKEN_REVIEW_JWT" \
        kubernetes_host="$KUBE_HOST" \
        kubernetes_ca_cert="$KUBE_CA_CERT"

這樣，就完成了 kubernetes 與外部 vault 的集成！

2. 關聯 k8s rbac 權限系統和 vault

接下來須要作的事：

2. 經過 vault policy 定義好每一個 role（微服務）能訪問哪些資源。
3. 爲每一個微服務生成一個 role，這個 role 須要綁定對應的 vault policy 及 kubernetes serviceaccount
   1. 這個 role 是 vault 的 kubernetes 插件自身的屬性，它和 kubernetes role 沒有半毛錢關係。
4. 建立一個 ServiceAccount，並使用這個 使用這個 ServiceAccount 部署微服務

其中第一步和第二步均可以經過 vault api 自動化完成.
第三步能夠經過 kubectl 部署時完成。

方便起見，vault policy / role / k8s serviceaccount 這三個配置，都建議和微服務使用相同的名稱。

上述配置中，role 起到一個承上啓下的做用，它關聯了 k8s serviceaccount 和 vault policy 兩個配置。

好比建立一個名爲 my-app-policy 的 vault policy，內容爲:

# 命名規則："<engine-name>/data/<path>/*"
path "my-app/data/*" {
   # 只讀權限
   capabilities = ["read", "list"]
}

而後在 vault 中建立 k8s role my-app-role:

1. 關聯 k8s default 名字空間中的 serviceaccount my-app-account，並建立好這個 serviceaccount.
2. 關聯 vault token policy，這就是前面建立的 my-app-policy
3. 設置 token period（有效期）

這以後，每一個微服務就能經過 serviceaccount 從 vault 中讀取 my-app 中的全部信息了。

3. 部署 Pod

參考文檔：https://www.vaultproject.io/docs/platform/k8s/injector

下一步就是將配置注入到微服務容器中，這須要使用到 Agent Sidecar Injector。
vault 經過 sidecar 實現配置的自動注入與動態更新。

具體而言就是在 Pod 上加上一堆 Agent Sidecar Injector 的註解，若是配置比較多，也可使用 configmap 保存，在註解中引用。

須要注意的是 vault-inject-agent 有兩種運行模式：

1. init 模式: 僅在 Pod 啓動前初始化一次，跑完就退出（Completed）
2. 常駐模式: 容器不退出，持續監控 vault 的配置更新，維持 Pod 配置和 vualt 配置的同步。

示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-app
  name: my-app
  namespace: default
spec:
  minReadySeconds: 3
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-configmap: my-app-vault-config  # vault 的 hcl 配置
        vault.hashicorp.com/agent-init-first: 'true'  # 是否提早初始化
        vault.hashicorp.com/agent-inject: 'true'
        vault.hashicorp.com/agent-limits-cpu: 250m
        vault.hashicorp.com/agent-requests-cpu: 100m
        vault.hashicorp.com/secret-volume-path: /app/secrets
      labels:
        app: my-app
    spec:
      containers:
      - image: registry.svc.local/xx/my-app:latest
        imagePullPolicy: IfNotPresent
        # 此處省略若干配置...
      serviceAccountName: my-app-account

常見錯誤：

• vault-agent(sidecar) 報錯: namespace not authorized
  • auth/kubernetes/config 中的 role 沒有綁定 Pod 的 namespace
• vault-agent(sidecar) 報錯: permission denied
  • 檢查 vault 實例的日誌，應該有對應的錯誤日誌，極可能是 auth/kubernetes/config 沒配對，vault 沒法驗證 kube-apiserver 的 tls 證書，或者使用的 kubernetes token 沒有權限。
• vault-agent(sidecar) 報錯: service account not authorized
  • auth/kubernetes/config 中的 role 沒有綁定 Pod 使用的 serviceAccount

4. vault agent 配置

vault-agent 的配置，須要注意的有：

1. 若是使用 configmap 提供完整的 config.hcl 配置，注意 agent-init

vautl-agent 的 template 說明：

目前來講最流行的配置文件格式應該是 json/yaml，以 json 爲例，
對每一個微服務的 kv 數據，能夠考慮將它全部的個性化配置都保存在 <engine-name>/<service-name>/ 下面，而後使用以下 template 注入配置(注意這裏使用了自定義的左右分隔符 [[ 和 ]])：

{
    [[ range secrets "<engine-name>/metadata/<service-name>/" ]]
        "[[ printf "%s" . ]]": 
        [[ with secret (printf "<engine-name>/<service-name>/%s" .) ]]
        [[ .Data.data | toJSONPretty ]],
        [[ end ]]
    [[ end ]]
}

template 的詳細語法參見: https://github.com/hashicorp/consul-template#secret

注意：v2 版本的 kv secrets，它的 list 接口有變動，所以在遍歷 v2 kv secrets 時，
必需要寫成 range secrets "<engine-name>/metadata/<service-name>/"，也就是中間要插入 metadata。
官方文檔徹底沒提到這一點，我經過 wireshark 抓包調試，對照官方的 KV Secrets Engine - Version 2 (API) 才搞明白這個。

這樣生成出來的內容將是 json 格式，不過有個不兼容的地方：最後一個 secrets 的末尾有逗號 ,
渲染出的效果示例：

{
    "secret-a": {
  "a": "b",
  "c": "d"
},
    "secret-b": {
  "v": "g",
  "r": "c"
},
}

由於存在尾部逗號(trailing comma)，直接使用 json 標準庫解析它會報錯。
那該如何去解析它呢？我在萬能的 stackoverflow 上找到了解決方案：yaml 徹底兼容 json 語法，而且支持尾部逗號！

以 python 爲例，直接 yaml.safe_load() 就能完美解析 vault 生成出的 json 內容。

5、使用 vault 管理阿里雲的 RAM 帳號體系

vault 能夠接入各大雲廠商的帳號體系，顯然能夠用於管理阿里雲的， 實現 ACCESS_KEY/SECRET_KEY 的自動輪轉。

具體配置方法，待續。。。