認證方法

不同的組織對安全和認證有不同的要求。Vault 透過提供多種認證方法來體現這一需求。Spring Cloud Vault 支援 Token 和 AppId 認證。

Token 認證

Token 是 Vault 中最核心的認證方法。Token 認證需要在配置中提供一個靜態 Token。作為備選方案，Token 也可以從 ~/.vault-token 中檢索，這是 Vault CLI 用於快取 Token 的預設位置。

Token 認證是預設的認證方法。如果 Token 被洩露，未經授權的第三方將獲得對 Vault 的訪問許可權，並可以訪問目標客戶端的秘密。

application.yml

spring.cloud.vault:
    authentication: TOKEN
    token: 00000000-0000-0000-0000-000000000000

authentication 將此值設定為 TOKEN 會選擇 Token 認證方法
token 設定要使用的靜態 Token。如果缺失或為空，則將嘗試從 ~/.vault-token 檢索 Token。

另請參閱

Vault Agent 認證

自版本 0.11.0 起，Vault 附帶了一個名為 Vault Agent 的 sidecar 工具。Vault Agent 實現了 Spring Vault 的 SessionManager 功能，並具有 Auto-Auth 特性。應用程式可以透過依賴在 localhost 上執行的 Vault Agent 來重用快取的會話憑據。Spring Vault 可以傳送不帶 X-Vault-Token 請求頭的請求。停用 Spring Vault 的認證基礎設施可以停用客戶端認證和會話管理。

application.yml

spring.cloud.vault:
    authentication: NONE

authentication 將此值設定為 NONE 會停用 ClientAuthentication 和 SessionManager。

另請參閱：Vault 文件：Agent

AppId 認證

Vault 支援 AppId 認證，它由兩個難以猜測的 Token 組成。AppId 預設使用靜態配置的 spring.application.name。第二個 Token 是 UserId，它由應用程式決定，通常與執行時環境相關。IP 地址、Mac 地址或 Docker 容器名稱都是很好的例子。Spring Cloud Vault Config 支援 IP 地址、Mac 地址和靜態 UserId（例如透過系統屬性提供）。IP 和 Mac 地址以 Hex 編碼的 SHA256 雜湊值表示。

基於 IP 地址的 UserId 使用本地主機的 IP 地址。

使用 SHA256 IP 地址 UserId 的 application.yml

spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: IP_ADDRESS

authentication 將此值設定為 APPID 會選擇 AppId 認證方法
app-id-path 設定要使用的 AppId mount 路徑
user-id 設定 UserId 方法。可能的值包括 IP_ADDRESS, MAC_ADDRESS 或實現自定義 AppIdUserIdMechanism 的類名

從命令列生成 IP 地址 UserId 的相應命令是

$ echo -n 192.168.99.1 | sha256sum

包含 echo 的換行符會導致不同的雜湊值，因此請確保包含 -n 標誌。

基於 Mac 地址的 UserId 從繫結到本地主機的裝置獲取其網路裝置。配置還允許指定一個 network-interface 提示來選擇正確的裝置。network-interface 的值是可選的，可以是介面名稱或介面索引（從 0 開始）。

使用 SHA256 Mac 地址 UserId 的 application.yml

spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: MAC_ADDRESS
        network-interface: eth0

network-interface 設定獲取物理地址的網路介面

從命令列生成 IP 地址 UserId 的相應命令是

$ echo -n 0AFEDE1234AC | sha256sum

Mac 地址指定為大寫且不含冒號。包含 echo 的換行符會導致不同的雜湊值，因此請確保包含 -n 標誌。

自定義 UserId

UserId 生成是一個開放機制。您可以將 spring.cloud.vault.app-id.user-id 設定為任意字串，配置的值將用作靜態 UserId。

更高階的方法允許您將 spring.cloud.vault.app-id.user-id 設定為一個類名。該類必須位於您的 classpath 中，並且必須實現 org.springframework.cloud.vault.AppIdUserIdMechanism 介面和 createUserId 方法。每次使用 AppId 認證以獲取 Token 時，Spring Cloud Vault 都將透過呼叫 createUserId 來獲取 UserId。

application.yml

spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: com.examlple.MyUserIdMechanism

MyUserIdMechanism.java

public class MyUserIdMechanism implements AppIdUserIdMechanism {

  @Override
  public String createUserId() {
    String userId = ...
    return userId;
  }
}

另請參閱：Vault 文件：使用 App ID 認證後端

AppRole 認證

AppRole 旨在用於機器認證，類似於已棄用（自 Vault 0.6.1 起）的 AppId 認證。AppRole 認證由兩個難以猜測（秘密）的 Token 組成：RoleId 和 SecretId。

Spring Vault 支援各種 AppRole 場景（推/拉模式和 wrapped 模式）。

RoleId 和可選的 SecretId 必須透過配置提供，Spring Vault 不會查詢或建立自定義 SecretId。

包含 AppRole 認證屬性的 application.yml

spring.cloud.vault:
    authentication: APPROLE
    app-role:
        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

以下場景及其所需的配置詳情是支援的

表 1. 配置
方法	RoleId	SecretId	RoleName	Token
提供的 RoleId/SecretId	提供	提供
提供 RoleId，不含 SecretId	提供
提供 RoleId，Pull SecretId	提供		提供	提供
Pull RoleId，提供的 SecretId		提供	提供	提供
完全 Pull 模式			提供	提供
Wrapped				提供
Wrapped RoleId，提供的 SecretId		提供		提供
提供的 RoleId，wrapped SecretId	提供			提供

表 2. Pull/Push/Wrapped 矩陣
RoleId	SecretId	支援
提供	提供	✅
提供	Pull	✅
提供	Wrapped	✅
提供	缺失	✅
Pull	提供	✅
Pull	Pull	✅
Pull	Wrapped	❌
Pull	缺失	❌
Wrapped	提供	✅
Wrapped	Pull	❌
Wrapped	Wrapped	✅
Wrapped	缺失	❌

您仍然可以透過在上下文中提供配置好的 AppRoleAuthentication bean 來使用推/拉/wrapped 模式的所有組合。Spring Cloud Vault 無法從配置屬性中推匯出所有可能的 AppRole 組合。

AppRole 認證僅限於使用響應式基礎設施的簡單拉取（pull）模式。完全拉取模式尚不受支援。將 Spring Cloud Vault 與 Spring WebFlux 堆疊一起使用會啟用 Vault 的響應式自動配置，可以透過設定 spring.cloud.vault.reactive.enabled=false 來停用它。

包含所有 AppRole 認證屬性的 application.yml

spring.cloud.vault:
    authentication: APPROLE
    app-role:
        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
        secret-id: 1696536f-1976-73b1-b241-0b4213908d39
        role: my-role
        app-role-path: approle

role-id 設定 RoleId。
secret-id 設定 SecretId。如果 AppRole 配置為不需要 SecretId（參見 bind_secret_id），則可以省略 SecretId。
role: 在拉取（pull）模式下設定 AppRole 名稱。
app-role-path 設定要使用的 approle 認證 mount 路徑。

另請參閱：Vault 文件：使用 AppRole 認證後端

AWS-EC2 認證

aws-ec2 認證後端為 AWS EC2 例項提供了一種安全的引入機制，允許自動檢索 Vault Token。與大多數 Vault 認證後端不同，此後端不需要首先部署或配置安全敏感憑據（Token、使用者名稱/密碼、客戶端證書等）。相反，它將 AWS 視為一個可信第三方，並使用唯一代表每個 EC2 例項的經過加密簽名的動態元資料資訊。

使用 AWS-EC2 認證的 application.yml

spring.cloud.vault:
    authentication: AWS_EC2

AWS-EC2 認證預設啟用 nonce，以遵循首次使用信任（Trust On First Use，TOFU）原則。任何意外獲得 PKCS#7 身份元資料訪問許可權的第三方都可以對 Vault 進行認證。

在首次登入期間，Spring Cloud Vault 會生成一個 nonce，該 nonce 與例項 Id 一起儲存在認證後端中。重新認證需要傳送相同的 nonce。任何其他第三方沒有該 nonce，並可以在 Vault 中觸發警報以供進一步調查。

nonce 儲存在記憶體中，並在應用程式重啟時丟失。您可以使用 spring.cloud.vault.aws-ec2.nonce 配置一個靜態 nonce。

AWS-EC2 認證角色是可選的，預設使用 AMI。您可以透過設定 spring.cloud.vault.aws-ec2.role 屬性來配置認證角色。

包含配置的角色的 application.yml

spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server

包含所有 AWS EC2 認證屬性的 application.yml

spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server
        aws-ec2-path: aws-ec2
        identity-document: http://...
        nonce: my-static-nonce

authentication 將此值設定為 AWS_EC2 會選擇 AWS EC2 認證方法
role 設定嘗試登入時使用的角色名稱。
aws-ec2-path 設定要使用的 AWS EC2 mount 路徑
identity-document 設定 PKCS#7 AWS EC2 身份文件的 URL
nonce 用於 AWS-EC2 認證。空的 nonce 預設為生成 nonce

另請參閱：Vault 文件：使用 aws 認證後端

AWS-IAM 認證

aws 後端為 AWS IAM 角色提供了一種安全的認證機制，允許基於執行中應用程式的當前 IAM 角色自動與 Vault 進行認證。與大多數 Vault 認證後端不同，此後端不需要首先部署或配置安全敏感憑據（Token、使用者名稱/密碼、客戶端證書等）。相反，它將 AWS 視為一個可信第三方，並使用呼叫方使用其 IAM 憑據簽名的 4 條資訊來驗證呼叫方是否確實在使用該 IAM 角色。

執行中應用程式的當前 IAM 角色會自動計算。如果您在 AWS ECS 上執行應用程式，則應用程式將使用分配給執行中容器的 ECS 任務的 IAM 角色。如果您在 EC2 例項上直接執行應用程式，則使用的 IAM 角色將是分配給該 EC2 例項的角色。

使用 AWS-IAM 認證時，您必須在 Vault 中建立一個角色並將其分配給您的 IAM 角色。空的 role 預設為當前 IAM 角色的友好名稱。

包含必需的 AWS-IAM 認證屬性的 application.yml

spring.cloud.vault:
    authentication: AWS_IAM

包含所有 AWS-IAM 認證屬性的 application.yml

spring.cloud.vault:
    authentication: AWS_IAM
    aws-iam:
        region: aws-global
        role: my-dev-role
        aws-path: aws
        server-name: some.server.name
        endpoint-uri: https://sts.eu-central-1.amazonaws.com

region 設定 AWS 區域名稱。如果未提供，區域將由 AWS 預設設定確定。
role 設定嘗試登入時使用的角色名稱。此角色應繫結到您的 IAM 角色。如果未提供，則當前 IAM 使用者的友好名稱將用作 Vault 角色。
aws-path 設定要使用的 AWS mount 路徑
server-name 設定用於 X-Vault-AWS-IAM-Server-ID 請求頭的值，以防止某些型別的重放攻擊。
endpoint-uri 設定用於 iam_request_url 引數的 AWS STS API 的值。

AWS-IAM 需要 AWS Java SDK v2 依賴項（software.amazon.awssdk:auth），因為認證實現使用 AWS SDK 型別處理憑據和請求籤名。

另請參閱：Vault 文件：使用 aws 認證後端

Azure MSI 認證

azure 認證後端為 Azure VM 例項提供了一種安全的引入機制，允許自動檢索 Vault Token。與大多數 Vault 認證後端不同，此後端不需要首先部署或配置安全敏感憑據（Token、使用者名稱/密碼、客戶端證書等）。相反，它將 Azure 視為一個可信第三方，並使用可以繫結到 VM 例項的託管服務身份和例項元資料資訊。

包含必需的 Azure 認證屬性的 application.yml

spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role

包含所有 Azure 認證屬性的 application.yml

spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role
        azure-path: azure
        metadata-service: http://169.254.169.254/metadata/instance…
        identity-token-service: http://169.254.169.254/metadata/identity…

role 設定嘗試登入時使用的角色名稱。
azure-path 設定要使用的 Azure mount 路徑
metadata-service 設定訪問例項元資料服務的 URI
identity-token-service 設定訪問身份 Token 服務的 URI

Azure MSI 認證從例項元資料服務獲取有關虛擬機器（訂閱 Id、資源組、VM 名稱）的環境詳細資訊。Vault 伺服器的 Resource Id 預設值為 vault.hashicorp.com。要更改此設定，請相應地設定 spring.cloud.vault.azure-msi.identity-token-service。

另請參閱

TLS 證書認證

cert 認證後端允許使用由 CA 簽名或自簽名的 SSL/TLS 客戶端證書進行認證。

要啟用 cert 認證，您需要

使用 SSL，參見 Vault 客戶端 SSL 配置
配置包含客戶端證書和私鑰的 Java Keystore
將 spring.cloud.vault.authentication 設定為 CERT

application.yml

spring.cloud.vault:
    authentication: CERT
    ssl:
        key-store: classpath:keystore.jks
        key-store-password: changeit
        key-store-type: JKS
        cert-auth-path: cert

另請參閱：Vault 文件：使用 Cert 認證後端

Cubbyhole 認證

Cubbyhole 認證使用 Vault 原語提供一個安全的認證工作流程。Cubbyhole 認證使用 Token 作為主要登入方法。一個臨時 Token 被用來從 Vault 的 Cubbyhole secret 後端獲取第二個，即登入 VaultToken。登入 Token 通常具有更長的生命週期，用於與 Vault 互動。登入 Token 將從儲存在 /cubbyhole/response 的 wrapped 響應中檢索。

建立 wrapped token

Token 建立的 Response Wrapping 需要 Vault 0.6.0 或更高版本。

建立和儲存 tokens

$ vault token-create -wrap-ttl="10m"
Key                            Value
---                            -----
wrapping_token:                397ccb93-ff6c-b17b-9389-380b01ca2645
wrapping_token_ttl:            0h10m0s
wrapping_token_creation_time:  2016-09-18 20:29:48.652957077 +0200 CEST
wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

application.yml

spring.cloud.vault:
    authentication: CUBBYHOLE
    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

另請參閱

GCP-GCE 認證

gcp 認證後端允許使用現有的 GCP (Google Cloud Platform) IAM 和 GCE 憑據進行 Vault 登入。

GCP GCE (Google Compute Engine) 認證為服務賬戶建立一個 JSON Web Token (JWT) 形式的簽名。透過例項身份識別從 GCE 元資料服務獲取 Compute Engine 例項的 JWT。該 API 建立一個可用於確認例項身份的 JSON Web Token。

與大多數 Vault 認證後端不同，此後端不需要首先部署或配置安全敏感憑據（Token、使用者名稱/密碼、客戶端證書等）。相反，它將 GCP 視為一個可信第三方，並使用唯一代表每個 GCP 服務賬戶的經過加密簽名的動態元資料資訊。

包含必需的 GCP-GCE 認證屬性的 application.yml

spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        role: my-dev-role

包含所有 GCP-GCE 認證屬性的 application.yml

spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        gcp-path: gcp
        role: my-dev-role
        service-account: [email protected]

role 設定嘗試登入時使用的角色名稱。
gcp-path 設定要使用的 GCP mount 路徑
service-account 允許將服務賬戶 Id 覆蓋為特定值。預設為 default 服務賬戶。

另請參閱

GCP-IAM 認證

gcp 認證後端允許使用現有的 GCP (Google Cloud Platform) IAM 和 GCE 憑據進行 Vault 登入。

GCP IAM 認證為服務賬戶建立一個 JSON Web Token (JWT) 形式的簽名。透過呼叫 GCP IAM 的 projects.serviceAccounts.signJwt API 獲取服務賬戶的 JWT。呼叫方向 GCP IAM 進行認證，從而證明其身份。此 Vault 後端將 GCP 視為一個可信第三方。

IAM 憑據可以從執行時環境獲取（特別是 GOOGLE_APPLICATION_CREDENTIALS 環境變數）、Google Compute 元資料服務，或透過外部提供（例如 JSON 或 base64 編碼）。JSON 是首選格式，因為它包含呼叫 projects.serviceAccounts.signJwt 所需的專案 ID 和服務賬戶識別符號。

包含必需的 GCP-IAM 認證屬性的 application.yml

spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        role: my-dev-role

包含所有 GCP-IAM 認證屬性的 application.yml

spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        credentials:
            location: classpath:credentials.json
            encoded-key: e+KApn0=
        gcp-path: gcp
        jwt-validity: 15m
        project-id: my-project-id
        role: my-dev-role
        service-account-id: [email protected]

role 設定嘗試登入時使用的角色名稱。
credentials.location 憑據資源的路徑，該資源包含 JSON 格式的 Google 憑據。
credentials.encoded-key OAuth2 賬戶私鑰的 base64 編碼內容，為 JSON 格式。
gcp-path 設定要使用的 GCP mount 路徑
jwt-validity 配置 JWT Token 的有效期。預設為 15 分鐘。
project-id 允許將專案 Id 覆蓋為特定值。預設為從獲取的憑據中提取的專案 Id。
service-account 允許將服務賬戶 Id 覆蓋為特定值。預設為從獲取的憑據中提取的服務賬戶。

GCP IAM 認證需要 Google Cloud Java SDK 依賴項（com.google.apis:google-api-services-iam 和 com.google.auth:google-auth-library-oauth2-http），因為認證實現使用 Google API 進行憑據和 JWT 簽名。

Google 憑據需要一個維護 Token 生命週期長的 OAuth 2 Token。所有 API 都是同步的，因此 GcpIamAuthentication 不支援響應式使用所需的 AuthenticationSteps。

另請參閱

Kubernetes 認證

Kubernetes 認證機制（自 Vault 0.8.3 起）允許使用 Kubernetes Service Account Token 與 Vault 進行認證。認證是基於角色的，角色繫結到服務賬戶名稱和名稱空間。

包含 pod 服務賬戶的 JWT token 的檔案會自動掛載到 /var/run/secrets/kubernetes.io/serviceaccount/token。

包含所有 Kubernetes 認證屬性的 application.yml

spring.cloud.vault:
    authentication: KUBERNETES
    kubernetes:
        role: my-dev-role
        kubernetes-path: kubernetes
        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

role 設定角色。
kubernetes-path 設定要使用的 Kubernetes mount 路徑。
service-account-token-file 設定包含 Kubernetes Service Account Token 的檔案的位置。預設為 /var/run/secrets/kubernetes.io/serviceaccount/token。

另請參閱

Pivotal CloudFoundry 認證

pcf 認證後端為在 Pivotal 的 CloudFoundry 例項中執行的應用程式提供了一種安全的引入機制，允許自動檢索 Vault Token。與大多數 Vault 認證後端不同，此後端不需要首先部署或配置安全敏感憑據（Token、使用者名稱/密碼、客戶端證書等），因為身份提供由 PCF 本身處理。相反，它將 PCF 視為一個可信第三方，並使用託管例項身份。

包含必需的 PCF 認證屬性的 application.yml

spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role

包含所有 PCF 認證屬性的 application.yml

spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role
        pcf-path: path
        instance-certificate: /etc/cf-instance-credentials/instance.crt
        instance-key: /etc/cf-instance-credentials/instance.key

role 設定嘗試登入時使用的角色名稱。
pcf-path 設定要使用的 PCF mount 路徑。
instance-certificate 設定 PCF 例項身份證書的路徑。預設為 ${CF_INSTANCE_CERT} 環境變數。
instance-key 設定 PCF 例項身份金鑰的路徑。預設為 ${CF_INSTANCE_KEY} 環境變數。

PCF 認證需要 classpath 中包含 BouncyCastle (bcpkix-jdk15on) 才能進行 RSA PSS 簽名。

另請參閱：Vault 文件：使用 pcf 認證後端

ACL 要求

本節解釋了 Spring Vault 訪問哪些路徑，以便您可以根據所需能力推導您的策略宣告。

能力關聯的 HTTP 動詞

能力	關聯的 HTTP 動詞
建立	`POST`/`PUT`
讀取	`GET`
更新	`POST`/`PUT`
刪除	`DELETE`
列出	`LIST` (`GET`)

建立

POST/PUT

讀取

GET

更新

POST/PUT

刪除

DELETE

列出

LIST (GET)

另請參閱 www.vaultproject.io/guides/identity/policies。

認證

登入：POST auth/$authMethod/login

KeyValue Mount 發現

GET sys/internal/ui/mounts/$mountPath

SecretLeaseContainer

SecretLeaseContainer 根據配置的 lease endpoint 使用不同的路徑。

LeaseEndpoints.Legacy

撤銷：PUT sys/revoke
續期：PUT sys/renew

LeaseEndpoints.Leases (SysLeases)

撤銷：PUT sys/leases/revoke
續期：PUT sys/leases/renew

會話管理

Token 查詢：GET auth/token/lookup-self
續期：POST auth/token/renew-self
撤銷：POST auth/token/revoke-self