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 フェデレーションで動作することが検証済みです。

  • Vault
  • Azure Entra ID

10.5.1. Entra ID OpenID Connect について

Entra ID は、ユーザーとアクセス制御を一元管理するクラウドベースのアイデンティティーおよびアクセス管理サービスです。Entra ID は ID プロバイダーとして機能し、ユーザーアイデンティティーを確認して、アプリケーションに ID トークンを発行します。このトークンには重要なユーザー情報が含まれているため、アプリケーションはユーザーの認証情報を管理せずにユーザーの身元を確認できます。

Entra ID OpenID Connect (OIDC) を SPIRE と統合すると、有効期間の短い自動の暗号化アイデンティティーがワークロードに提供されます。SPIRE が発行したアイデンティティーは、静的なシークレットを使用せずにサービスをセキュアに認証するために、Entra ID に送信されます。

10.5.2. マネージド 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 発行者の設定 を参照してください。

手順

  1. 次のコマンドを実行して、参照先のシークレットを読み取る権限をルーターのサービスアカウントに付与するための Role を作成します。

    $ oc create role secret-reader \
      --verb=get,list,watch \
      --resource=secrets \
      --resource-name=$TLS_SECRET_NAME \
      -n zero-trust-workload-identity-manager
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、ルーターのサービスアカウントを、新しく作成した Role リソースにバインドする RoleBinding リソースを作成します。

    $ oc create rolebinding secret-reader-binding \
      --role=secret-reader \
      --serviceaccount=openshift-ingress:router \
      -n zero-trust-workload-identity-manager
    Copy to Clipboard Toggle word wrap
  3. 前のステップで生成した Secret を参照するように、SpireOIDCDIscoveryProvider カスタムリソース (CR) オブジェクトを設定します。

    $ oc patch SpireOIDCDiscoveryProvider cluster --type=merge -p='
    spec:
      externalSecretRef: ${TLS_SECRET_NAME}
    '
    Copy to Clipboard Toggle word wrap

検証

  1. SpireOIDCDiscoveryProvider CR で、ManageRouteReady 条件が True に設定されているかどうかを確認します。

    $ oc wait --for=jsonpath='{.status.conditions[?(@.type=="ManagedRouteReady")].status}'=True SpireOIDCDiscoveryProvider/cluster --timeout=120s
    Copy to Clipboard Toggle word wrap
  2. 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"
      ]
    }%
    Copy to Clipboard Toggle word wrap

10.5.2.1. マネージドルートの無効化

OIDC Discovery Provider サービスの公開動作を完全に制御する必要がある場合は、要件に応じてマネージドルートを無効にできます。

手順

  • OIDC Discovery Provider を手動で設定するには、managedRoutefalse に設定します。

    $ oc patch SpireOIDCDiscoveryProvider cluster --type=merge -p='
    spec:
      managedRoute: "false"
    Copy to Clipboard Toggle word wrap

10.5.3. Microsoft Azure での Entra ID の使用

Entra ID の設定が完了したら、Azure で動作するように Entra ID を設定できます。

前提条件

  • 公的に信頼された CA からの TLS 証明書を提供するように、SPIRE OIDC Discovery Provider ルートを設定した。

10.5.3.1. Azure アカウントの設定

手順

  1. 次のコマンドを実行して、Azure にログインします。

    $ az login
    Copy to Clipboard Toggle word wrap
  2. Azure サブスクリプションとテナントの変数を設定します。

    $ export SUBSCRIPTION_ID=$(az account list --query "[?isDefault].id" -o tsv) 
    1
    
    $ export TENANT_ID=$(az account list --query "[?isDefault].tenantId" -o tsv) 
    2
    
    $ export LOCATION=centralus 
    3
    Copy to Clipboard Toggle word wrap
    1
    一意のサブスクリプション識別子。
    2
    Azure Active Directory インスタンスの ID。
    3
    リソースを作成する Azure リージョン。
  3. リソースの変数名を定義します。

    $ export NAME=ztwim 
    1
    
    $ export RESOURCE_GROUP="${NAME}-rg" 
    2
    
    $ export STORAGE_ACCOUNT="${NAME}storage" 
    3
    
    $ export STORAGE_CONTAINER="${NAME}storagecontainer" 
    4
    
    $ export USER_ASSIGNED_IDENTITY_NAME="${NAME}-identity" 
    5
    Copy to Clipboard Toggle word wrap
    1
    すべてのリソースのベース名。
    2
    リソースグループの名前。
    3
    ストレージアカウントの名前。
    4
    ストレージコンテナーの名前。
    5
    マネージド ID の名前。
  4. リソースグループを作成します。

    $ az group create \
      --name "${RESOURCE_GROUP}" \
      --location "${LOCATION}"
    Copy to Clipboard Toggle word wrap

10.5.3.2. Azure Blob Storage の設定

手順

  1. コンテンツを保存するために使用する新しいストレージアカウントを作成します。

    $ az storage account create \
      --name ${STORAGE_ACCOUNT} \
      --resource-group ${RESOURCE_GROUP} \
      --location ${LOCATION} \
      --encryption-services blob
    Copy to Clipboard Toggle word wrap
  2. 新しく作成したストレージアカウントのストレージ ID を取得します。

    $ export STORAGE_ACCOUNT_ID=$(az storage account show -n ${STORAGE_ACCOUNT} -g ${RESOURCE_GROUP} --query id --out tsv)
    Copy to Clipboard Toggle word wrap
  3. 新しく作成したストレージアカウント内にストレージコンテナーを作成し、Blob のストレージをサポートするための場所を提供します。

    $ az storage container create \
      --account-name ${STORAGE_ACCOUNT} \
      --name ${STORAGE_CONTAINER} \
      --auth-mode login
    Copy to Clipboard Toggle word wrap

10.5.3.3. Azure のユーザーマネージド ID の設定

手順

  1. 新しいユーザーマネージド 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)
    Copy to Clipboard Toggle word wrap
  2. ユーザーマネージド ID に関連付けられているサービスプリンシパルにロールを関連付けます。

    $ az role assignment create \
      --role "Storage Blob Data Contributor" \
      --assignee "${IDENTITY_CLIENT_ID}" \
      --scope ${STORAGE_ACCOUNT_ID}
    Copy to Clipboard Toggle word wrap

10.5.3.4. デモアプリケーションの作成

手順

  1. アプリケーション名と namespace を設定します。

    $ export APP_NAME=workload-app
    $ export APP_NAMESPACE=demo
    Copy to Clipboard Toggle word wrap
  2. namespace を作成します。

    $ oc create namespace $APP_NAMESPACE
    Copy to Clipboard Toggle word wrap
  3. アプリケーションの 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
    Copy to Clipboard Toggle word wrap

10.5.3.5. ワークロードアプリケーションのデプロイ

手順

  1. アプリケーションをデプロイするには、以下に記載のコマンドブロック全体をコピーし、ターミナルに直接貼り付けます。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
    Copy to Clipboard Toggle word wrap

検証

  1. workload-app Pod が正常に実行されていることを確認します。

    $ oc get pods -n $APP_NAMESPACE
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             READY     STATUS      RESTARTS      AGE
    workload-app-5f8b9d685b-abcde    1/1       Running     0             60s
    Copy to Clipboard Toggle word wrap

  2. SPIFFE JWT Token (SVID-JWT) を取得します。

    # Get the pod name dynamically
    $ POD_NAME=$(oc get pods -n $APP_NAMESPACE -l app=$APP_NAME -o jsonpath='{.items[0].metadata.name}')
    
    # Execute the script inside the pod
    $ oc exec -it $POD_NAME -n $APP_NAMESPACE -- \
      /opt/app-root/src/get-spiffe-token.py -a "api://AzureADTokenExchange"
    Copy to Clipboard Toggle word wrap

10.5.3.6. 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
    Copy to Clipboard Toggle word wrap

手順

  1. SPIFFE Workload API から JWT トークンを取得し、Pod 内に含まれている Azure CLI にログインします。

    $ oc rsh -n $APP_NAMESPACE deployment/$APP_NAME
    
    $ export TOKEN=$(/opt/app-root/src/get-spiffe-token.py --audience=$AZURE_AUDIENCE)
    $ az login --service-principal \
      -t ${AZURE_TENANT_ID} \
      -u ${AZURE_CLIENT_ID} \
      --federated-token ${TOKEN}
    Copy to Clipboard Toggle word wrap
  2. アプリケーションワークロード Pod を使用して新しいファイルを作成し、そのファイルを Blob Storage にアップロードします。

    $ echo “Hello from OpenShift” > openshift-spire-federated-identities.txt
    $ 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
    Copy to Clipboard Toggle word wrap

検証

  • 含まれているファイルをリスト表示して、ファイルが正常にアップロードされたことを確認します。

    $ az storage blob list \
      --account-name ${BLOB_STORE_ACCOUNT} \
      --container-name ${BLOB_STORE_CONTAINER} \
      --auth-mode login \
      -o table
    Copy to Clipboard Toggle word wrap

10.5.4. 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.5. Vault のインストール

Vault を OIDC として使用する前に、Vault をインストールする必要があります。

前提条件

  • ルートを設定します。詳細は、ルート設定 を参照してください。
  • Helm がインストールされている。
  • Vault API からの出力を簡単に読み取るためのコマンドライン JSON プロセッサー。
  • HashiCorp Helm リポジトリーが追加されている。

手順

  1. vault-helm-value.yaml ファイルを作成します。

    global:
      enabled: true
      openshift: true 
    1
    
      tlsDisable: true 
    2
    
    injector:
      enabled: false
    server:
      ui:
        enabled: true
      image:
        repository: docker.io/hashicorp/vault
        tag: "1.19.0"
      dataStorage:
        enabled: true 
    3
    
        size: 1Gi
      standalone:
        enabled: true 
    4
    
        config: |
          listener "tcp" {
            tls_disable = 1 
    5
    
            address = "[::]:8200"
            cluster_address = "[::]:8201"
          }
          storage "file" {
            path = "/vault/data"
          }
      extraEnvironmentVars: {}
    Copy to Clipboard Toggle word wrap
    1
    OpenShift 固有のセキュリティーコンテキストのデプロイメントを最適化します。
    2
    チャートによって作成される Kubernetes オブジェクトの TLS を無効にします。
    3
    Vault データを保存するための 1Gi の永続ボリュームを作成します。
    4
    1 つの Vault Pod をデプロイします。
    5
    Vault サーバーに TLS を使用しないように指示します。
  2. helm install コマンドを実行します。

    $ helm install vault hashicorp/vault \
      --create-namespace -n vault \
      --values ./vault-helm-value.yaml
    Copy to Clipboard Toggle word wrap
  3. Vault サービスを公開します。

    $ oc expose service vault -n vault
    Copy to Clipboard Toggle word wrap
  4. VAULT_ADDR 環境変数を設定して、新しいルートからホスト名を取得してエクスポートします。

    $ export VAULT_ADDR="http://$(oc get route vault -n vault -o jsonpath='{.spec.host}')"
    Copy to Clipboard Toggle word wrap
    注記

    TLS が無効になっているため、先頭に http:// が追加されます。

検証

  • Vault インスタンスが実行されていることを確認するために、次のコマンドを実行します。

    $ curl -s $VAULT_ADDR/v1/sys/health | jq
    Copy to Clipboard Toggle word wrap

    出力例

    {
      "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"
    }
    Copy to Clipboard Toggle word wrap

10.5.6. Vault の初期化

新しくインストールされた Vault は、シールされた状態です。そのため、他のすべての暗号鍵を保護するプライマリー暗号鍵が起動時にサーバーメモリーにロードされません。アンシール (シールを解除) するには、Vault を初期化する必要があります。

Vault サーバーを初期化する手順は次のとおりです。

  1. Vault の初期化とアンシール
  2. キー/値 (KV) シークレットエンジンの有効化とテストシークレットの保存
  3. SPIRE での JSON Web Token (JWT) 認証の設定
  4. デモアプリケーションのデプロイ
  5. 認証とシークレットの取得

前提条件

  • Vault が実行されていることを確認する。
  • Vault が初期化されていないことを確認する。Vault サーバーを初期化できるのは 1 回だけです。

10.5.6.1. Vault の初期化とアンシール

手順

  1. vault Pod へのリモートシェルを開きます。

    $ oc rsh -n vault statefulset/vault
    Copy to Clipboard Toggle word wrap
  2. Vault を初期化して、アンシールキーと root トークンを取得します。

    $ vault operator init -key-shares=1 -key-threshold=1 -format=json
    Copy to Clipboard Toggle word wrap
  3. 前のコマンドで受け取ったアンシールキーと root トークンをエクスポートします。

    $ export UNSEAL_KEY=<Your-Unseal-Key>
    $ export ROOT_TOKEN=<Your-Root-Token>
    Copy to Clipboard Toggle word wrap
  4. アンシールキーを使用して Vault をアンシールします。

    $ vault operator unseal -format=json $UNSEAL_KEY
    Copy to Clipboard Toggle word wrap
  5. Exit と入力して Pod を終了します。

検証

  • Vault Pod の準備完了状態であることを確認するために、次のコマンドを実行します。

    $ oc get pod -n vault
    Copy to Clipboard Toggle word wrap

    出力例

    NAME        READY        STATUS      RESTARTS     AGE
    vault-0     1/1          Running     0            65d
    Copy to Clipboard Toggle word wrap

10.5.6.2. キー値シークレットエンジンの有効化とテストシークレットの保存

手順

  1. Vault Pod で別のシェルセッションを開きます。

    $ oc rsh -n vault statefulset/vault
    Copy to Clipboard Toggle word wrap
  2. この新しいセッション内で root トークンを再度エクスポートし、ログインします。

    $ export ROOT_TOKEN=<Your-Root-Token>
    $ vault login "${ROOT_TOKEN}"
    Copy to Clipboard Toggle word wrap
  3. secret/ パスでキー/値シークレットエンジンを有効にし、テストシークレットを作成します。

    $ export NAME=ztwim
    $ vault secrets enable -path=secret kv
    $ vault kv put secret/$NAME version=v0.1.0
    Copy to Clipboard Toggle word wrap

検証

  • シークレットが正しく保存されていることを確認するために、次のコマンドを実行します。

    $ vault kv get secret/$NAME
    Copy to Clipboard Toggle word wrap

10.5.6.3. SPIRE での JSON Web Token 認証の設定

アプリケーションが SPIFFE のアイデンティティーを使用して Vault にセキュアにログインできるように、JSON Web Token (JWT) 認証を設定する必要があります。

手順

  1. ローカルマシンで、SPIRE 認証局 (CA) バンドルを取得し、ファイルに保存します。

    $ oc get cm -n zero-trust-workload-identity-manager spire-bundle -o jsonpath='{ .data.bundle\.crt }' > oidc_provider_ca.pem
    Copy to Clipboard Toggle word wrap
  2. Vault Pod シェルに戻り、一時ファイルを作成し、oidc_provider_ca.pem の内容をそこに貼り付けます。

    $ cat << EOF > /tmp/oidc_provider_ca.pem
    -----BEGIN CERTIFICATE-----
    <Paste-Your-Certificate-Content-Here>
    -----END CERTIFICATE-----
    EOF
    Copy to Clipboard Toggle word wrap
  3. 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)"
    Copy to Clipboard Toggle word wrap
  4. JWT 認証方法を有効にし、OIDC プロバイダーの詳細を使用して認証方法を設定します。

    $ export ROLE="${NAME}-role"
    $ vault auth enable jwt
    $ vault write auth/jwt/config \
      oidc_discovery_url=$OIDC_URL \
      oidc_discovery_ca_pem="$OIDC_CA_PEM" \
      default_role=$ROLE
    Copy to Clipboard Toggle word wrap
  5. 先ほど作成したシークレットへの読み取りアクセスを許可する ztwim-policy という名前のポリシーを作成します。

    $ export POLICY="${NAME}-policy"
    $ vault policy write $POLICY -<<EOF
    path "secret/$NAME" {
        capabilities = ["read"]
    }
    EOF
    Copy to Clipboard Toggle word wrap
  6. 特定の SPIFFE ID を持つワークロードにポリシーをバインドする JWT ロールを作成します。

    $ export APP_NAME=client
    $ export APP_NAMESPACE=demo
    $ export AUDIENCE=$APP_NAME
    $ 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
    Copy to Clipboard Toggle word wrap

10.5.6.4. デモアプリケーションのデプロイ

これにより、SPIFFE アイデンティティーを使用して Vault で認証するシンプルなクライアントアプリケーションが作成されます。

手順

  1. ローカルマシンで、アプリケーションの環境変数を設定します。

    $ export APP_NAME=client
    $ export APP_NAMESPACE=demo
    $ export AUDIENCE=$APP_NAME
    Copy to Clipboard Toggle word wrap
  2. Kubernetes マニフェストを適用して、デモアプリケーションの namespace、サービスアカウント、およびデプロイメントを作成します。このデプロイメントでは、SPIFFE CSI ドライバーソケットがマウントされます。

    $ oc apply -f - <<EOF
    # ... (paste the full YAML from your provided code here) ...
    EOF
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、クライアントのデプロイメントが準備完了状態であることを確認します。

    $ oc get deploy -n $APP_NAMESPACE
    Copy to Clipboard Toggle word wrap

    出力例

    NAME             READY        UP-TO-DATE      AVAILABLE     AGE
    frontend-app     2/2          2               2             120d
    backend-api      3/3          3               3             120d
    Copy to Clipboard Toggle word wrap

10.5.6.5. 認証とシークレットの取得

デモアプリケーションを使用して SPIFFE Workload API から JWT トークンを取得し、それを使用して Vault にログインしてシークレットを取得します。

手順

  1. 実行中のクライアント 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
    Copy to Clipboard Toggle word wrap
  2. 出力からトークンをコピーし、ローカルマシン上で環境変数としてエクスポートします。

    $ export IDENTITY_TOKEN=<Your-JWT-Token>
    Copy to Clipboard Toggle word wrap
  3. curl を使用して JWT トークンを Vault ログインエンドポイントに送信し、Vault クライアントトークンを取得します。

    $ export ROLE="${NAME}-role"
    $ VAULT_TOKEN=$(curl -s --request POST --data '{ "jwt": "'"${IDENTITY_TOKEN}"'", "role": "'"${ROLE}"'"}' "${VAULT_ADDR}"/v1/auth/jwt/login | jq -r '.auth.client_token')
    Copy to Clipboard Toggle word wrap

検証

  • 新しく取得した Vault トークンを使用して、キー/値ストアからシークレットを読み取ります。

    $ curl -s -H "X-Vault-Token: $VAULT_TOKEN" $VAULT_ADDR/v1/secret/$NAME | jq
    Copy to Clipboard Toggle word wrap

    出力にシークレットの内容 ("version": "v0.1.0") が表示されます。これにより、ワークフロー全体が成功したことを確認できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat