驗證方法

不同的組織對於安全性和驗證有不同的需求。Vault 反映了這種需求，提供了多種驗證方法。Spring Cloud Vault 支援令牌 (token) 和 AppId 驗證。

令牌驗證

令牌是 Vault 內驗證的核心方法。令牌驗證需要使用組態提供的靜態令牌。作為後備方案，也可以從 ~/.vault-token 檢索令牌，這是 Vault CLI 用於快取令牌的預設位置。

令牌驗證是預設的驗證方法。如果令牌洩露，未經授權的方即可存取 Vault，並可以存取目標用戶端的密鑰。
application.yml
spring.cloud.vault:
    authentication: TOKEN
    token: 00000000-0000-0000-0000-000000000000

  • authentication 將此值設定為 TOKEN 即可選取令牌驗證方法

  • token 設定要使用的靜態令牌。如果遺失或空白，則會嘗試從 ~/.vault-token 檢索令牌。

另請參閱

Vault Agent 驗證

自 0.11.0 版本以來，Vault 隨附了 Vault Agent 側車 (sidecar) 公用程式。Vault Agent 透過其 Auto-Auth 功能實作了 Spring Vault 的 SessionManager 功能。應用程式可以透過依賴在 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 驗證，它由兩個難以猜測的令牌組成。AppId 預設為靜態設定的 spring.application.name。第二個令牌是 UserId，它是應用程式決定的部分，通常與執行環境相關。IP 位址、Mac 位址或 Docker 容器名稱都是很好的範例。Spring Cloud Vault Config 支援 IP 位址、Mac 位址和靜態 UserId (例如透過系統屬性提供)。IP 和 Mac 位址以十六進位編碼的 SHA256 雜湊表示。

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

application.yml 使用 SHA256 IP 位址 UserId
spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: IP_ADDRESS

  • authentication 將此值設定為 APPID 即可選取 AppId 驗證方法

  • app-id-path 設定要使用的 AppId 掛載路徑

  • 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 開始)。

application.yml 使用 SHA256 Mac 位址 UserId
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 設定為類別名稱。此類別必須在您的類別路徑中，並且必須實作 org.springframework.cloud.vault.AppIdUserIdMechanism 介面和 createUserId 方法。Spring Cloud Vault 將透過每次使用 AppId 驗證以取得令牌時呼叫 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 驗證由兩個難以猜測的 (密鑰) 令牌組成：RoleId 和 SecretId。

Spring Vault 支援各種 AppRole 案例 (推播/提取模式和包裝)。

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

令牌

提供的 RoleId/SecretId

已提供

已提供

提供的 RoleId，沒有 SecretId

已提供

提供的 RoleId，提取 SecretId

已提供

已提供

已提供

提取 RoleId，提供的 SecretId

已提供

已提供

已提供

完整提取模式

已提供

已提供

已包裝

已提供

已包裝 RoleId，提供的 SecretId

已提供

已提供

提供的 RoleId，已包裝 SecretId

已提供

已提供
表 2. 提取/推播/包裝矩陣

RoleId

SecretId

支援

已提供

已提供

✅

已提供

提取

✅

已提供

已包裝

✅

已提供

不存在

✅

提取

已提供

✅

提取

提取

✅

提取

已包裝

❌

提取

不存在

❌

已包裝

已提供

✅

已包裝

提取

❌

已包裝

已包裝

✅

已包裝

不存在

❌
您仍然可以使用推播/提取/包裝模式的所有組合，方法是在內容中提供已組態的 AppRoleAuthentication Bean。Spring Cloud Vault 無法從組態屬性衍生所有可能的 AppRole 組合。
AppRole 驗證僅限於使用反應式基礎架構的簡單提取模式。尚不支援完整提取模式。將 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：設定提取模式的 AppRole 名稱。

  • app-role-path 設定要使用的 approle 驗證掛載路徑。

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

AWS-EC2 驗證

aws-ec2 驗證後端為 AWS EC2 執行個體提供安全的導入機制，允許自動檢索 Vault 令牌。與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證 (令牌、使用者名稱/密碼、用戶端憑證等)。相反地，它將 AWS 視為受信任的第三方，並使用以密碼編譯方式簽署的動態中繼資料資訊，這些資訊唯一地代表每個 EC2 執行個體。

使用 AWS-EC2 驗證的 application.yml
spring.cloud.vault:
    authentication: AWS_EC2

AWS-EC2 驗證預設啟用 nonce 以遵循首次信任 (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 掛載路徑

  • identity-document 設定 PKCS#7 AWS EC2 身份文件的 URL

  • nonce 用於 AWS-EC2 驗證。空白 nonce 預設為 nonce 產生

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

AWS-IAM 驗證

aws 後端為 AWS IAM 角色提供安全的驗證機制，允許基於正在執行應用程式的目前 IAM 角色自動驗證 Vault。與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證 (令牌、使用者名稱/密碼、用戶端憑證等)。相反地，它將 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 掛載路徑

  • server-name 設定用於 X-Vault-AWS-IAM-Server-ID 標頭的值，以防止某些類型的重播攻擊。

  • endpoint-uri 設定用於 AWS STS API 的值，該 API 用於 iam_request_url 參數。

AWS-IAM 需要 AWS Java SDK v2 相依性 (software.amazon.awssdk:auth)，因為驗證實作使用 AWS SDK 類型進行憑證和請求簽署。

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

Azure MSI 驗證

azure 驗證後端為 Azure VM 執行個體提供安全的導入機制，允許自動檢索 Vault 令牌。與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證 (令牌、使用者名稱/密碼、用戶端憑證等)。相反地，它將 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 掛載路徑

  • metadata-service 設定存取執行個體中繼資料服務的 URI

  • identity-token-service 設定存取身分令牌服務的 URI

Azure MSI 驗證從執行個體中繼資料服務取得虛擬機器的環境詳細資訊 (訂用帳戶 ID、資源群組、VM 名稱)。Vault 伺服器的資源 ID 預設為 vault.hashicorp.com。若要變更此設定，請相應地設定 spring.cloud.vault.azure-msi.identity-token-service。

另請參閱

TLS 憑證驗證

cert 驗證後端允許使用 SSL/TLS 用戶端憑證進行驗證，這些憑證可以由 CA 簽署或自行簽署。

若要啟用 cert 驗證，您需要

  1. 使用 SSL，請參閱 Vault 用戶端 SSL 組態

  2. 組態包含用戶端憑證和私密金鑰的 Java Keystore

  3. 將 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 驗證使用令牌作為主要登入方法。臨時令牌用於從 Vault 的 Cubbyhole 密鑰後端取得第二個登入 VaultToken。登入令牌通常具有較長的生命週期，並用於與 Vault 互動。登入令牌將從儲存在 /cubbyhole/response 的包裝回應中檢索。

建立包裝令牌

令牌建立的回應包裝需要 Vault 0.6.0 或更高版本。
建立和儲存令牌
$ 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) 簽名。Compute Engine 執行個體的 JWT 是從 GCE 中繼資料服務使用 執行個體識別 取得的。此 API 建立一個 JSON Web Token，可用於確認執行個體身分。

與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證 (令牌、使用者名稱/密碼、用戶端憑證等)。相反地，它將 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 掛載路徑

  • service-account 允許將服務帳戶 ID 覆寫為特定值。預設為 default 服務帳戶。

另請參閱

GCP-IAM 驗證

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

GCP IAM 驗證以服務帳戶的形式建立 JSON Web Token (JWT) 簽名。服務帳戶的 JWT 是透過呼叫 GCP IAM 的 projects.serviceAccounts.signJwt API 取得的。呼叫者對 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 JSON 格式的 OAuth2 帳戶私密金鑰的 base64 編碼內容。

  • gcp-path 設定要使用的 GCP 掛載路徑

  • jwt-validity 組態 JWT 令牌有效性。預設為 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 憑證需要 OAuth 2 令牌來維護令牌生命週期。所有 API 都是同步的，因此 GcpIamAuthentication 不支援反應式使用所需的 AuthenticationSteps。

另請參閱

Kubernetes 驗證

Kubernetes 驗證機制 (自 Vault 0.8.3 起) 允許使用 Kubernetes 服務帳戶令牌對 Vault 進行驗證。驗證是基於角色的，並且角色繫結到服務帳戶名稱和命名空間。

包含 Pod 服務帳戶的 JWT 令牌的檔案會自動掛載在 /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 掛載路徑。

  • service-account-token-file 設定包含 Kubernetes 服務帳戶令牌的檔案位置。預設為 /var/run/secrets/kubernetes.io/serviceaccount/token。

另請參閱

Pivotal CloudFoundry 驗證

pcf 驗證後端為在 Pivotal 的 CloudFoundry 執行個體內執行的應用程式提供安全的導入機制，允許自動檢索 Vault 令牌。與大多數 Vault 驗證後端不同，此後端不需要首先部署或佈建安全性敏感的憑證 (令牌、使用者名稱/密碼、用戶端憑證等)，因為身分佈建由 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 掛載路徑。

  • instance-certificate 設定 PCF 執行個體身分憑證的路徑。預設為 ${CF_INSTANCE_CERT} 環境變數。

  • instance-key 設定 PCF 執行個體身分金鑰的路徑。預設為 ${CF_INSTANCE_KEY} 環境變數。

PCF 驗證需要 BouncyCastle (bcpkix-jdk15on) 位於類別路徑中，以進行 RSA PSS 簽署。

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

ACL 需求

本節說明 Spring Vault 存取的路徑，以便您可以從所需的功能衍生您的政策宣告。

功能 關聯的 HTTP 動詞

建立

POST/PUT

讀取

GET

更新

POST/PUT

刪除

DELETE

清單

LIST (GET)

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

驗證

登入：POST auth/$authMethod/login

KeyValue 掛載探索

GET sys/internal/ui/mounts/$mountPath

SecretLeaseContainer

SecretLeaseContainer 使用不同的路徑，具體取決於已組態的租約端點。

LeaseEndpoints.Legacy

  • 撤銷：PUT sys/revoke

  • 續約：PUT sys/renew

LeaseEndpoints.Leases (SysLeases)

  • 撤銷：PUT sys/leases/revoke

  • 續約：PUT sys/leases/renew

會期管理

  • 令牌查詢：GET auth/token/lookup-self

  • 續約：POST auth/token/renew-self

  • 撤銷：POST auth/token/revoke-self