10.5. Zero Trust Workload Identity Manager の OIDC フェデレーション
Zero Trust Workload Identity Manager は、SPIRE Server を OIDC プロバイダーとして機能させることで、OpenID Connect (OIDC) と統合します。これにより、ワークロードが、検証可能な JSON Web Tokens (SPIFFE Verifiable Identity Documents (JWT-SVIDs)) を、ローカルの SPIRE Agent から要求して受信できるようになります。その後、クラウドプロバイダーなどの外部システムが、SPIRE Server によって公開される OIDC 検出エンドポイントを使用して公開鍵を取得できるようになります。
Zero Trust Workload Identity Manager for Red Hat OpenShift は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、以下のリンクを参照してください。
以下のプロバイダーは、SPIRE OIDC フェデレーションで動作することが検証済みです。
- Azure Entra ID
- Vault
10.5.1. Entra ID OpenID Connect について リンクのコピーリンクがクリップボードにコピーされました!
Entra ID は、ユーザーとアクセス制御を一元管理するクラウドベースのアイデンティティーおよびアクセス管理サービスです。Entra ID は ID プロバイダーとして機能し、ユーザーアイデンティティーを確認して、アプリケーションに ID トークンを発行します。このトークンには重要なユーザー情報が含まれているため、アプリケーションはユーザーの認証情報を管理せずにユーザーの身元を確認できます。
Entra ID OpenID Connect (OIDC) を SPIRE と統合すると、有効期間の短い自動の暗号化アイデンティティーがワークロードに提供されます。SPIRE が発行したアイデンティティーは、静的なシークレットを使用せずにサービスをセキュアに認証するために、Entra ID に送信されます。
10.5.1.1. マネージド OIDC Discovery Provider ルートの外部証明書の設定 リンクのコピーリンクがクリップボードにコピーされました!
マネージドルートは、External Route Certificate 機能を使用して、tls.externalCertificate フィールドを、外部で管理される Transfer Layer Security (TLS) シークレットの名前に設定します。
前提条件
- Zero Trust Workload Identity Manager 0.2.0 以降がインストールされている。
- クラスターに SPIRE Server、SPIRE Agent、SPIFFEE CSI ドライバー、および SPIRE OIDC Discovery Provider オペランドがデプロイされている。
- cert-manager Operator for Red Hat OpenShift がインストールされている。詳細は、cert-manager Operator for Red Hat OpenShift のインストール を参照してください。
-
公に信頼された CA サービスで設定された
ClusterIssuerまたはIssuerが作成されている。たとえば、"Let’s Encrypt ACME" サービスを使用した、Automated Certificate Management Environment (ACME) タイプのIssuerなどです。詳細は、ACME 発行者の設定 を参照してください。
手順
次のコマンドを実行して、参照先のシークレットを読み取る権限をルーターのサービスアカウントに付与するための
Roleを作成します。$ oc create role secret-reader \ --verb=get,list,watch \ --resource=secrets \ --resource-name=$TLS_SECRET_NAME \ -n zero-trust-workload-identity-manager次のコマンドを実行して、ルーターのサービスアカウントを、新しく作成した Role リソースにバインドする
RoleBindingリソースを作成します。$ oc create rolebinding secret-reader-binding \ --role=secret-reader \ --serviceaccount=openshift-ingress:router \ -n zero-trust-workload-identity-manager次のコマンドを実行して、前のステップで生成したた Secret を参照するように
SpireOIDCDIscoveryProviderカスタムリソース (CR) オブジェクトを設定します。$ oc patch SpireOIDCDiscoveryProvider cluster --type=merge -p=' spec: externalSecretRef: ${TLS_SECRET_NAME} '
検証
SpireOIDCDiscoveryProviderCR で、次のコマンドを実行して、ManageRouteReady条件がTrueに設定されているかどうかを確認します。$ oc wait --for=jsonpath='{.status.conditions[?(@.type=="ManagedRouteReady")].status}'=True SpireOIDCDiscoveryProvider/cluster --timeout=120s次のコマンドを実行して、OIDC エンドポイントに HTTPS 経由でセキュアにアクセスできることを確認します。
$ curl https://$JWT_ISSUER_ENDPOINT/.well-known/openid-configuration { "issuer": "https://$JWT_ISSUER_ENDPOINT", "jwks_uri": "https://$JWT_ISSUER_ENDPOINT/keys", "authorization_endpoint": "", "response_types_supported": [ "id_token" ], "subject_types_supported": [], "id_token_signing_alg_values_supported": [ "RS256", "ES256", "ES384" ] }%
10.5.1.2. マネージドルートの無効化 リンクのコピーリンクがクリップボードにコピーされました!
OIDC Discovery Provider サービスの公開動作を完全に制御する必要がある場合は、要件に応じてマネージドルートを無効にできます。
手順
OIDC Discovery Provider を手動で設定するには、次のコマンドを実行して
managedRouteをfalseに設定します。$ oc patch SpireOIDCDiscoveryProvider cluster --type=merge -p=' spec: managedRoute: "false"
10.5.1.3. Microsoft Azure での Entra ID の使用 リンクのコピーリンクがクリップボードにコピーされました!
Entra ID の設定が完了したら、Azure で動作するように Entra ID を設定できます。
前提条件
- 公的に信頼された CA からの TLS 証明書を提供するように、SPIRE OIDC Discovery Provider ルートを設定した。
手順
次のコマンドを実行して、Azure にログインします。
$ az login次のコマンドを実行して、Azure サブスクリプションとテナントの変数を設定します。
$ export SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" -o tsv)1 $ export TENANT_ID=$(az account list --query "[?isDefault].tenantId" -o tsv)1 $ export LOCATION=centralus1 次のコマンドを実行して、リソースの変数名を定義します。
$ export NAME=ztwim1 $ export RESOURCE_GROUP="${NAME}-rg"1 $ export STORAGE_ACCOUNT="${NAME}storage"1 $ export STORAGE_CONTAINER="${NAME}storagecontainer"1 $ export USER_ASSIGNED_IDENTITY_NAME="${NAME}-identity"1 次のコマンドを実行してリソースグループを作成します。
$ az group create \ --name "${RESOURCE_GROUP}" \ --location "${LOCATION}"
10.5.1.4. Azure Blob Storage の設定 リンクのコピーリンクがクリップボードにコピーされました!
コンテンツを保存するために使用する新しいストレージアカウントを作成する必要があります。
手順
次のコマンドを実行して、コンテンツを保存するために使用する新しいストレージアカウントを作成します。
$ az storage account create \ --name ${STORAGE_ACCOUNT} \ --resource-group ${RESOURCE_GROUP} \ --location ${LOCATION} \ --encryption-services blob次のコマンドを実行して、新しく作成したストレージアカウントのストレージ ID を取得します。
$ export STORAGE_ACCOUNT_ID=$(az storage account show -n ${STORAGE_ACCOUNT} -g ${RESOURCE_GROUP} --query id --out tsv)次のコマンドを実行して、新しく作成したストレージアカウント内にストレージコンテナーを作成し、Blob のストレージをサポートするための場所を提供します。
$ az storage container create \ --account-name ${STORAGE_ACCOUNT} \ --name ${STORAGE_CONTAINER} \ --auth-mode login
10.5.1.5. Azure のユーザーマネージド ID の設定 リンクのコピーリンクがクリップボードにコピーされました!
新しいユーザーマネージド ID を作成し、そのユーザーマネージド ID に関連付けられている関連サービスプリンシパルのクライアント ID を取得する必要があります。
手順
次のコマンドを実行して、新しいユーザーマネージド ID を作成し、そのユーザーマネージド ID に関連付けられている関連サービスプリンシパルのクライアント ID を取得します。
$ az identity create \ --name ${USER_ASSIGNED_IDENTITY_NAME} \ --resource-group ${RESOURCE_GROUP}$ export IDENTITY_CLIENT_ID=$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -otsv)次のコマンドを実行して、Azure ユーザー割り当てマネージド ID の
CLIENT_IDを取得し、それを環境変数として保存します。$ export IDENTITY_CLIENT_ID=$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -otsv)次のコマンドを実行して、ユーザーマネージド ID に関連付けられているサービスプリンシパルにロールを関連付けます。
$ az role assignment create \ --role "Storage Blob Data Contributor" \ --assignee "${IDENTITY_CLIENT_ID}" \ --scope ${STORAGE_ACCOUNT_ID}
10.5.1.6. デモアプリケーションの作成 リンクのコピーリンクがクリップボードにコピーされました!
デモアプリケーションを使用すると、システム全体が動作するかどうかを確認できます。
手順
デモアプリケーションを作成するには、次の手順を実行します。
次のコマンドを実行して、アプリケーション名と namespace を設定します。
$ export APP_NAME=workload-app$ export APP_NAMESPACE=demo以下のコマンドを実行して namespace を作成します。
$ oc create namespace $APP_NAMESPACE次のコマンドを実行して、アプリケーションの Secret を作成します。
$ oc apply -f - << EOF apiVersion: v1 kind: Secret metadata: name: $APP_NAME namespace: $APP_NAMESPACE stringData: AAD_AUTHORITY: https://login.microsoftonline.com/ AZURE_AUDIENCE: "api://AzureADTokenExchange" AZURE_TENANT_ID: "${TENANT_ID}" AZURE_CLIENT_ID: "${IDENTITY_CLIENT_ID}" BLOB_STORE_ACCOUNT: "${STORAGE_ACCOUNT}" BLOB_STORE_CONTAINER: "${STORAGE_CONTAINER}" EOF
10.5.1.7. ワークロードアプリケーションのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
デモアプリケーションを作成したら、デプロイします。
前提条件
- デモアプリケーションが作成およびデプロイ済みである。
手順
アプリケーションをデプロイするには、以下に記載のコマンドブロック全体をコピーし、ターミナルに直接貼り付けます。Enter キーを押します。
$ oc apply -f - << EOF apiVersion: v1 kind: ServiceAccount metadata: name: $APP_NAME namespace: $APP_NAMESPACE --- kind: Deployment apiVersion: apps/v1 metadata: name: $APP_NAME namespace: $APP_NAMESPACE spec: selector: matchLabels: app: $APP_NAME template: metadata: labels: app: $APP_NAME deployment: $APP_NAME spec: serviceAccountName: $APP_NAME containers: - name: $APP_NAME image: "registry.redhat.io/ubi9/python-311:latest" command: - /bin/bash - "-c" - | #!/bin/bash pip install spiffe azure-cli cat << EOF > /opt/app-root/src/get-spiffe-token.py #!/opt/app-root/bin/python from spiffe import JwtSource import argparse parser = argparse.ArgumentParser(description='Retrieve SPIFFE Token.') parser.add_argument("-a", "--audience", help="The audience to include in the token", required=True) args = parser.parse_args() with JwtSource() as source: jwt_svid = source.fetch_svid(audience={args.audience}) print(jwt_svid.token) EOF chmod +x /opt/app-root/src/get-spiffe-token.py while true; do sleep 10; done envFrom: - secretRef: name: $APP_NAME env: - name: SPIFFE_ENDPOINT_SOCKET value: unix:///run/spire/sockets/spire-agent.sock securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: false runAsNonRoot: true seccompProfile: type: RuntimeDefault ports: - containerPort: 8080 protocol: TCP volumeMounts: - name: spiffe-workload-api mountPath: /run/spire/sockets readOnly: true volumes: - name: spiffe-workload-api csi: driver: csi.spiffe.io readOnly: true EOF
検証
次のコマンドを実行して、
workload-appPod が正常に実行されていることを確認します。$ oc get pods -n $APP_NAMESPACE出力例
NAME READY STATUS RESTARTS AGE workload-app-5f8b9d685b-abcde 1/1 Running 0 60sSPIFFE JWT Token (SVID-JWT) を取得します。
次のコマンドを実行して、Pod 名を動的に取得します。
$ POD_NAME=$(oc get pods -n $APP_NAMESPACE -l app=$APP_NAME -o jsonpath='{.items[0].metadata.name}')次のコマンドを実行して、Pod 内でスクリプトを実行します。
$ oc exec -it $POD_NAME -n $APP_NAMESPACE -- \ /opt/app-root/src/get-spiffe-token.py -a "api://AzureADTokenExchange"
10.5.1.8. SPIFFE アイデンティティーフェデレーションを使用した Azure の設定 リンクのコピーリンクがクリップボードにコピーされました!
SPIFFE アイデンティティーフェデレーションを使用して Azure を設定すると、デモアプリケーションに対するパスワード不要の自動認証を有効にできます。
手順
次のコマンドを実行して、ユーザーマネージド ID と、ワークロードアプリケーションに関連付けられている SPIFFE アイデンティティーの間で、アイデンティティーをフェデレーションします。
$ az identity federated-credential create \ --name ${NAME} \ --identity-name ${USER_ASSIGNED_IDENTITY_NAME} \ --resource-group ${RESOURCE_GROUP} \ --issuer https://$JWT_ISSUER_ENDPOINT \ --subject spiffe://$APP_DOMAIN/ns/$APP_NAMESPACE/sa/$APP_NAME \ --audience api://AzureADTokenExchange
10.5.1.9. アプリケーションワークロードが Azure Blob Storage 内のコンテンツにアクセスできることを確認する リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションワークロードが Azure Blob Storage にアクセスできるかどうかを確認できます。
前提条件
- Azure Blob Storage が作成済みである。
手順
次のコマンドを実行して、SPIFFE Workload API から JWT トークンを取得します。
$ oc rsh -n $APP_NAMESPACE deployment/$APP_NAME次のコマンドを実行して、
TOKENという名前の環境変数を作成してエクスポートします。$ export TOKEN=$(/opt/app-root/src/get-spiffe-token.py --audience=$AZURE_AUDIENCE)次のコマンドを実行して、Pod 内に含まれる Azure CLI にログインします。
$ az login --service-principal \ -t ${AZURE_TENANT_ID} \ -u ${AZURE_CLIENT_ID} \ --federated-token ${TOKEN}次のコマンドを実行して、アプリケーションワークロード Pod で新しいファイルを作成し、そのファイルを Blob Storage にアップロードします。
$ echo “Hello from OpenShift” > openshift-spire-federated-identities.txt次のコマンドを実行して、Azure Blog Storage にファイルをアップロードします。
$ az storage blob upload \ --account-name ${BLOB_STORE_ACCOUNT} \ --container-name ${BLOB_STORE_CONTAINER} \ --name openshift-spire-federated-identities.txt \ --file openshift-spire-federated-identities.txt \ --auth-mode login
検証
次のコマンドを実行して、含まれているファイルをリスト表示し、ファイルが正常にアップロードされたことを確認します。
$ az storage blob list \ --account-name ${BLOB_STORE_ACCOUNT} \ --container-name ${BLOB_STORE_CONTAINER} \ --auth-mode login \ -o table
10.5.2. Vault OpenID Connect について リンクのコピーリンクがクリップボードにコピーされました!
Vault OpenID Connect (OIDC) と SPIRE を組み合わせると、信頼できる OIDC プロバイダーとして SPIRE を Vault で使用して、セキュアな認証方法を実現できます。ワークロードは、一意の SPIFFE ID を持つローカル SPIRE Agent から JWT-SVID を要求します。次に、ワークロードはこのトークンを Vault に提示します。Vault はそれを SPIRE Server 上の公開鍵と照合して検証します。すべての条件が満たされた場合、Vault は有効期間の短い Vault トークンをワークロードに発行します。ワークロードはこのトークンを使用してシークレットにアクセスし、Vault 内でアクションを実行できます。
10.5.2.1. Vault のインストール リンクのコピーリンクがクリップボードにコピーされました!
Vault を OIDC として使用する前に、Vault をインストールする必要があります。
前提条件
- ルートを設定します。詳細は、ルート設定 を参照してください。
- Helm がインストールされている。
- Vault API からの出力を簡単に読み取るためのコマンドライン JSON プロセッサー。
- HashiCorp Helm リポジトリーが追加されている。
手順
vault-helm-value.yamlファイルを作成します。global: enabled: true openshift: true1 tlsDisable: true2 injector: enabled: false server: ui: enabled: true image: repository: docker.io/hashicorp/vault tag: "1.19.0" dataStorage: enabled: true3 size: 1Gi standalone: enabled: true4 config: | listener "tcp" { tls_disable = 15 address = "[::]:8200" cluster_address = "[::]:8201" } storage "file" { path = "/vault/data" } extraEnvironmentVars: {}helm installコマンドを実行します。$ helm install vault hashicorp/vault \ --create-namespace -n vault \ --values ./vault-helm-value.yaml次のコマンドを実行して、Vault サービスを公開します。
$ oc expose service vault -n vault次のコマンドを実行して、
VAULT_ADDR環境変数を設定し、新しいルートからホスト名を取得してエクスポートします。$ export VAULT_ADDR="http://$(oc get route vault -n vault -o jsonpath='{.spec.host}')"注記TLS が無効になっているため、先頭に
http://が追加されます。
検証
Vault インスタンスが実行されていることを確認するために、次のコマンドを実行します。
$ curl -s $VAULT_ADDR/v1/sys/health | jq出力例
{ "initialized": true, "sealed": true, "standby": true, "performance_standby": false, "replication_performance_mode": "disabled", "replication_dr_mode": "disabled", "server_time_utc": 1663786574, "version": "1.19.0", "cluster_name": "vault-cluster-a1b2c3d4", "cluster_id": "5e6f7a8b-9c0d-1e2f-3a4b-5c6d7e8f9a0b" }
10.5.2.2. Vault の初期化とアンシール リンクのコピーリンクがクリップボードにコピーされました!
新しくインストールされた Vault は、シールされた状態です。そのため、他のすべての暗号鍵を保護するプライマリー暗号鍵が起動時にサーバーメモリーにロードされません。アンシール (シールを解除) するには、Vault を初期化する必要があります。
Vault サーバーを初期化する手順は次のとおりです。
- Vault の初期化とアンシール
- キー/値 (KV) シークレットエンジンの有効化とテストシークレットの保存
- SPIRE での JSON Web Token (JWT) 認証の設定
- デモアプリケーションのデプロイ
- 認証とシークレットの取得
前提条件
- Vault が実行されていることを確認する。
- Vault が初期化されていないことを確認する。Vault サーバーを初期化できるのは 1 回だけです。
手順
次のコマンドを実行して、
vaultPod へのリモートシェルを開きます。$ oc rsh -n vault statefulset/vault次のコマンドを実行して、Vault を初期化し、アンシールキーとルートトークンを取得します。
$ vault operator init -key-shares=1 -key-threshold=1 -format=json次のコマンドを実行して、前のコマンドで受け取ったアンシールキーとルートトークンをエクスポートします。
$ export UNSEAL_KEY=<Your-Unseal-Key>$ export ROOT_TOKEN=<Your-Root-Token>次のコマンドを実行して、アンシールキーを使用して Vault をアンシールします。
$ vault operator unseal -format=json $UNSEAL_KEY-
exitと入力して Pod を終了します。
検証
Vault Pod の準備完了状態であることを確認するために、次のコマンドを実行します。
$ oc get pod -n vault出力例
NAME READY STATUS RESTARTS AGE vault-0 1/1 Running 0 65d
10.5.2.3. キー値シークレットエンジンの有効化とテストシークレットの保存 リンクのコピーリンクがクリップボードにコピーされました!
キー値シークレットエンジンを有効にして、認証情報を管理するためのセキュアな一元管理場所を確立します。
前提条件
- Vault が初期化およびアンシールされていることを確認する。
手順
次のコマンドを実行して、
VaultPod で別のシェルセッションを開きます。$ oc rsh -n vault statefulset/vault次のコマンドを実行して、この新しいセッション内でルートトークンを再度エクスポートし、ログインします。
$ export ROOT_TOKEN=<Your-Root-Token>$ vault login "${ROOT_TOKEN}"次のコマンドを実行して、
secret/パスでキー/値シークレットエンジンを有効にし、テストシークレットを作成します。$ export NAME=ztwim$ vault secrets enable -path=secret kv$ vault kv put secret/$NAME version=v0.1.0
検証
シークレットが正しく保存されていることを確認するために、次のコマンドを実行します。
$ vault kv get secret/$NAME
10.5.2.4. SPIRE での JSON Web Token 認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションが SPIFFE のアイデンティティーを使用して Vault にセキュアにログインできるように、JSON Web Token (JWT) 認証を設定する必要があります。
前提条件
- Vault が初期化およびアンシールされていることを確認する。
- テストシークレットがキー値シークレットエンジンに保存されていることを確認します。
手順
ローカルマシンで、次のコマンドを実行して SPIRE 認証局 (CA) バンドルを取得し、ファイルに保存します。
$ oc get cm -n zero-trust-workload-identity-manager spire-bundle -o jsonpath='{ .data.bundle\.crt }' > oidc_provider_ca.pemVault Pod シェルに戻り、次のコマンドを実行して一時ファイルを作成し、
oidc_provider_ca.pemの内容をそのファイルに貼り付けます。$ cat << EOF > /tmp/oidc_provider_ca.pem -----BEGIN CERTIFICATE----- <Paste-Your-Certificate-Content-Here> -----END CERTIFICATE----- EOF次のコマンドを実行して、JWT 設定に必要な環境変数を設定します。
$ export APP_DOMAIN=<Your-App-Domain>$ export JWT_ISSUER_ENDPOINT="oidc-discovery.$APP_DOMAIN"$ export OIDC_URL="https://$JWT_ISSUER_ENDPOINT"$ export OIDC_CA_PEM="$(cat /tmp/oidc_provider_ca.pem)"次のコマンドを実行して、新しい環境変数を作成します。
$ export ROLE="${NAME}-role"次のコマンドを実行して、JWT 認証方法を有効にします。
$ vault auth enable jwt次のコマンドを実行して、ODIC 認証方法を設定します。
$ vault write auth/jwt/config \ oidc_discovery_url=$OIDC_URL \ oidc_discovery_ca_pem="$OIDC_CA_PEM" \ default_role=$ROLE次のコマンドを実行して、
ztwim-policyという名前のポリシーを作成します。$ export POLICY="${NAME}-policy"次のコマンドを実行して、先ほど作成したシークレットへの読み取りアクセス権を付与します。
$ vault policy write $POLICY -<<EOF path "secret/$NAME" { capabilities = ["read"] } EOF次のコマンドを実行して、以下の環境変数を作成します。
$ export APP_NAME=client$ export APP_NAMESPACE=demo$ export AUDIENCE=$APP_NAME次のコマンドを実行して、特定の SPIFFE ID を持つワークロードにポリシーをバインドする JWT ロールを作成します。
$ vault write auth/jwt/role/$ROLE -<<EOF { "role_type": "jwt", "user_claim": "sub", "bound_audiences": "$AUDIENCE", "bound_claims_type": "glob", "bound_claims": { "sub": "spiffe://$APP_DOMAIN/ns/$APP_NAMESPACE/sa/$APP_NAME" }, "token_ttl": "24h", "token_policies": "$POLICY" } EOF
10.5.2.5. デモアプリケーションのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
デモアプリケーションをデプロイする場合は、SPIFFE アイデンティティーを使用して Vault で認証するシンプルなクライアントアプリケーションを作成します。
手順
ローカルマシンで、次のコマンドを実行してアプリケーションの環境変数を設定します。
$ export APP_NAME=client$ export APP_NAMESPACE=demo$ export AUDIENCE=$APP_NAME次のコマンドを実行して、Kubernetes マニフェストを適用し、デモアプリケーションの namespace、サービスアカウント、およびデプロイメントを作成します。このデプロイメントにより、SPIFFE CSI ドライバーソケットがマウントされます。
$ oc apply -f - <<EOF # ... (paste the full YAML from your provided code here) ... EOF
検証
次のコマンドを実行して、クライアントのデプロイメントが準備完了状態であることを確認します。
$ oc get deploy -n $APP_NAMESPACE出力例
NAME READY UP-TO-DATE AVAILABLE AGE frontend-app 2/2 2 2 120d backend-api 3/3 3 3 120d
10.5.2.6. 認証とシークレットの取得 リンクのコピーリンクがクリップボードにコピーされました!
デモアプリケーションを使用して SPIFFE Workload API から JWT トークンを取得し、それを使用して Vault にログインしてシークレットを取得します。
手順
実行中のクライアント Pod 内で次のコマンドを実行して、JWT-SVID を取得します。
$ oc -n $APP_NAMESPACE exec -it $(oc get pod -o=jsonpath='{.items[*].metadata.name}' -l app=$APP_NAME -n $APP_NAMESPACE) \ -- /opt/spire/bin/spire-agent api fetch jwt \ -socketPath /run/spire/sockets/spire-agent.sock \ -audience $AUDIENCE出力からトークンをコピーし、次のコマンドを実行してローカルマシン上で環境変数としてエクスポートします。
$ export IDENTITY_TOKEN=<Your-JWT-Token>次のコマンドを実行して、新しい環境変数を作成します。
$ export ROLE="${NAME}-role"次のコマンドを実行して、
curlを使用して JWT トークンを Vault ログインエンドポイントに送信し、Vault クライアントトークンを取得します。$ VAULT_TOKEN=$(curl -s --request POST --data '{ "jwt": "'"${IDENTITY_TOKEN}"'", "role": "'"${ROLE}"'"}' "${VAULT_ADDR}"/v1/auth/jwt/login | jq -r '.auth.client_token')
検証
次のコマンドを実行し、新しく取得した Vault トークンを使用してキー/値ストアからシークレットを読み取ります。
$ curl -s -H "X-Vault-Token: $VAULT_TOKEN" $VAULT_ADDR/v1/secret/$NAME | jq出力にシークレットの内容 (
"version": "v0.1.0") が表示されます。これにより、ワークフロー全体が成功したことを確認できます。