2.4. GitOps を使用して OpenShift 上のシークレットプロバイダーとして HashiCorp Vault を設定する

手順

1. Vault CSI プロバイダー用の Argo CD アプリケーションリソースを作成します。

   1. Vault CSI プロバイダーをデプロイするための Argo CD アプリケーションリソースを作成します。このリソースを GitOps リポジトリー (例: config/argocd/vault-secret-provider-app.yaml) に追加します。

      vault-secret-provider-app.yaml ファイルの例

      apiVersion: argoproj.io/v1alpha1
      kind: Application
      metadata:
        name: vault-secret-provider-app
        namespace: openshift-gitops
      spec:
        destination:
          namespace: vault-csi-provider
          server: https://kubernetes.default.svc
        project: default
        source:
          repoURL: https://helm.releases.hashicorp.com
          chart: vault
          targetRevision: 0.30.0
          helm:
            releaseName: vault
            values: |
              csi:
                enabled: true
              server:
                enabled: true
                dataStorage:
                   enabled: false
              injector:
                enabled: false
        syncPolicy:
          automated:
            prune: true
            selfHeal: true
          syncOptions:
          - CreateNamespace=true
        ignoreDifferences:
        - kind: DaemonSet
          group: apps
          jsonPointers:
            - /spec/template/spec/containers/0/securityContext/privileged

      Copy to Clipboard Toggle word wrap

      注記

      Helm 値の server.enabled: true および dataStorage.enabled: false 設定は、一時ストレージを使用して HashiCorp Vault サーバーインスタンスをデプロイします。このセットアップは、開発環境またはテスト環境に適しています。実稼働環境では、永続ボリューム (PV) を使用して dataStorage を有効にするか、外部の Vault クラスターを使用して server.enabled を false に設定することができます。Vault サーバーがすでにデプロイされている場合は、server.enabled を false に設定できます。

2. GitOps リポジトリーから vault-secret-provider-app.yaml ファイルをクラスターに適用します。

   $ oc apply -f vault-secret-provider-app.yaml

   Copy to Clipboard Toggle word wrap

   Vault CSI プロバイダーをデプロイした後、vault-csi-provider DaemonSet の実行に失敗する場合があります。この問題は、OpenShift Container Platform がデフォルトで特権コンテナーを制限するために発生します。さらに、Vault CSI プロバイダーと Secrets Store CSI ドライバーは、hostPath マウントへのアクセスを必要としますが、Pod が特権として実行されない限り、OpenShift Container Platform はこれをブロックします。

   1. OpenShift Container Platform の権限の問題を解決するには:

      1. vault-csi-provider DaemonSet にパッチを適用して、そのコンテナーが特権付きで実行されるようにします。

         $ oc patch daemonset vault-csi-provider -n vault-csi-provider --type=json --patch='[{"op":"add","path":"/spec/template/spec/containers/0/securityContext","value":{"privileged":true}}]

         Copy to Clipboard Toggle word wrap

      2. Secrets Store CSI ドライバーサービスアカウントに、OpenShift Container Platform の特権 Security Context Constraints (SCC) へのアクセス権を付与します。

         $ oc adm policy add-scc-to-user privileged \ system:serviceaccount:openshift-cluster-csi-drivers:secrets-store-csi-driver-operator

         Copy to Clipboard Toggle word wrap

      3. Vault CSI プロバイダーサービスアカウントに、OpenShift Container Platform の特権 Security Context Constraints (SCC) へのアクセス権を付与します。

         $ oc adm policy add-scc-to-user privileged \
         system:serviceaccount:vault-csi-provider:vault-csi-provider

         Copy to Clipboard Toggle word wrap
         注記

         Helm チャートで server.enabled が true に設定されている場合、Vault サーバー Pod は、OpenShift Container Platform がデフォルトでブロックする特定のユーザー ID (UID) またはグループ ID (GID) を使用して実行されます。

      4. Vault サーバーのサービスアカウントに必要な Security Context Constraints (SCC) 権限を付与します。

         $ oc adm policy add-scc-to-user anyuid  system:serviceaccount:vault-csi-provider:vault

         Copy to Clipboard Toggle word wrap

手順

1. Vault Pod にアクセスします。

   1. Vault が OpenShift Container Platform クラスター内で実行されている場合 (たとえば、vault-csi-provider namespace の vault-0 Pod として)、次のコマンドを実行して Pod 内の Vault CLI にアクセスします。

      $ oc exec -it vault-0 -n vault-csi-provider -- /bin/sh

      Copy to Clipboard Toggle word wrap

2. Vault を初期化します。

   1. Vault インスタンスがまだ初期化されていない場合は、次のコマンドを実行します。

      $ vault operator init

      Copy to Clipboard Toggle word wrap

      結果として、以下の出力が表示されます。

      5 Unseal Keys - required to unseal the Vault.
      Initial Root Token - required to log in and configure Vault.

      Copy to Clipboard Toggle word wrap
      重要

      これらの認証情報をセキュアに格納してください。Vault を封印解除するには、5 つの封印解除キーのうち少なくとも 3 つが必要です。キーを紛失した場合、格納されたシークレットへのアクセスは永久にブロックされます。

3. Vault を封印解除します。

   1. Vault は封印された状態で起動します。前の手順で取得した 5 つの封印解除キーのうち 3 つを使用するには、次のコマンドを実行します。

      $ vault operator unseal <Unseal Key 1>
        vault operator unseal <Unseal Key 2>
        vault operator unseal <Unseal Key 3>

      Copy to Clipboard Toggle word wrap

      封印が解除されると、Vault はアクティブになり、使用できるようになります。

4. Vault にログインします。

   1. ルートトークンを使用して Vault にログインするには、次のコマンドを実行します。

      $ vault login <Initial Root Token>

      Copy to Clipboard Toggle word wrap

      これにより、管理者はシークレットエンジンと認証方法を有効にして設定できるようになります。

5. Vault で Kubernetes 認証を有効にします。

   1. Vault で Kubernetes 認証を有効にするには、次のコマンドを実行します。

      $ vault auth enable kubernetes

      Copy to Clipboard Toggle word wrap

      これにより、Pod などの Kubernetes ワークロードがサービスアカウントを使用して Vault で認証できるようになります。

6. Vault で Kubernetes 認証方法を設定します。

   1. Kubernetes API と通信するように Vault を設定するには、次のコマンドを実行します。

      $ vault write auth/kubernetes/config \
      issuer="https://kubernetes.default.svc" \
      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

      Copy to Clipboard Toggle word wrap

      結果として、以下の出力が表示されます。

      Success! Data written to: auth/kubernetes/config

      Copy to Clipboard Toggle word wrap

      詳細は、以下のようになります。

      • <issuer> は、Kubernetes トークン発行者の URL の名前です。
      • <token_reviewer_jwt> は、Vault が Kubernetes TokenReview API を呼び出し、サービスアカウントトークンを検証するために使用する JSON Web Token (JWT) です。
      • <kubernetes_host> は、Vault が Kubernetes API サーバーと通信するために使用する URL です。
      • <kubernetes_ca_cert> は、Vault が Kubernetes API サーバーとのセキュアな通信に使用する CA 証明書です。

手順

1. KV シークレットエンジンを有効にする

   1. Key-Value (KV) バージョン 2 シークレットエンジンを使用して、バージョン管理をサポートする任意のシークレットを格納します。次のコマンドを実行して、secret/ パスで KV シークレットエンジンを有効にします。

      $ vault secrets enable -path=secret/ kv

      Copy to Clipboard Toggle word wrap

2. シークレットを Vault に格納します。

   1. KV バージョン 2 シークレットエンジンを使用してシークレットを格納します。次のコマンドを実行して、シークレットデータ、ユーザー名、およびパスワードを secret/demo/config パスに格納します。

      $ vault kv put secret/demo/config username="demo-user" password="demo-pass"

      Copy to Clipboard Toggle word wrap

3. Vault ポリシーを作成します。

   1. シークレットへの読み取りアクセスを付与するポリシーを作成するには、次のコマンドを実行します。

      $ vault policy write demo-app-policy -<<EOF
      path "secret/demo/config" {
        capabilities = ["read"]
      }
      EOF

      Copy to Clipboard Toggle word wrap

      この demo-app-policy は、secret/demo/config のシークレットへの読み取りアクセス権を付与し、後で Kubernetes ロールにリンクされます。

4. Vault で Kubernetes 認証ロールを作成します。

   1. Kubernetes サービスアカウントを Vault ポリシーにバインドするロールを作成するには、次のコマンドを実行します。

      $ vault write auth/kubernetes/role/app \ bound_service_account_names=demo-app-sa \ bound_service_account_namespaces=demo-app \ policies=demo-app-policy \ ttl=24h

      Copy to Clipboard Toggle word wrap

      これにより、サービスアカウントを使用するすべての Pod が Vault に対して認証し、シークレットを取得できるようになります。

      詳細は、以下のようになります。

      • <bound_service_account_names> は、Vault が信頼する Kubernetes サービスアカウントの名前です。
      • <bound_service_account_namespaces> は、サービスアカウントが配置されている namespace の名前です。
      • <policies> は、アタッチされている Vault ポリシーの名前です。
      • <ttl> は、トークンに対して発行される Time-to-live 値です。

手順

1. SecretProviderClass を作成します。

   1. アプリケーションのマニフェストディレクトリーに SecretProviderClass リソースを作成します (例: environments/dev/apps/demo-app/manifest/secretProviderClass.yaml)。このリソースは、Secrets Store CSI ドライバーが Vault からシークレットを取得する方法を定義します。

      vault-secret-provider-app.yaml ファイルの例

      apiVersion: secrets-store.csi.x-k8s.io/v1
        kind: SecretProviderClass
           metadata:
               name: demo-app-creds
               namespace: demo-app
       spec:
              provider: vault 

      1

      
              parameters:
                    vaultAddress: http://vault.vault-csi-provider:8200 # <name>.<namespace>:port 

      2

      
                    roleName: app 

      3

      
              objects: | 

      4

      
                 - objectName: "demoAppUsername"
                   secretPath: "secret/demo/config"
                   secretKey: "username"
                - objectName: "demoAppPassword"
                  secretPath: "secret/demo/config"
                   secretKey: "password"

      Copy to Clipboard Toggle word wrap

      1

      <provider: vault>: HashiCorp Vault の名前を指定します。

      2

      <vaultAddress>: Vault サーバーのネットワークアドレスを指定します。クラスター内サービスや外部 URL など、Vault のセットアップに基づいてこれを調整します。

      3

      <roleName>: アプリケーションサービスアカウントによって使用される Vault Kubernetes 認証ロールを指定します。取得するシークレットと、それらをファイル名にマップする方法を定義する配列を記述します。

      4

      <objects>: 取得するシークレットと、それらをファイル名にマップする方法を定義する配列を指定します。KV v2 の secretPath には /data/ が含まれます。

2. ServiceAccount などのアプリケーションを作成します。

   1. アプリケーションワークロード用の Kubernetes ServiceAccount を作成します。ServiceAccount 名は、Vault Kubernetes 認証ロールで定義された bound_service_account_names 値と一致する必要があります。マニフェストを GitOps リポジトリー (例: environments/dev/apps/demo-app/manifest/serviceAccount.yaml) に格納します。

      ServiceAccount.yaml ファイルの例

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: demo-app-sa
        namespace: demo-app

      Copy to Clipboard Toggle word wrap

3. アプリケーションのデプロイメントを作成します。

   1. 指定された ServiceAccount を使用するようにアプリケーションのデプロイメントを変更し、CSI ボリュームを使用してシークレットをマウントします。更新されたマニフェストを GitOps リポジトリー (例: environments/dev/apps/demo-app/manifest/deployment.yaml) に格納します。

      deployment.yaml ファイルの例

      apiVersion: apps/v1
      kind: Deployment
      metadata:
         name: app
         namespace: demo-app
         labels:
           app: demo
      spec:
         replicas: 1
         selector:
           matchLabels:
              app: demo
         template:
            metadata:
             labels:
               app: demo
         spec:
              serviceAccountName: demo-app-sa 

      1

      
              containers:
                 - name: app
                   image: nginxinc/nginx-unprivileged:latest
                   volumeMounts: 

      2

      
                   - name: vault-secrets
                     mountPath: /mnt/secrets-store
                     readOnly: true
         volumes: 

      3

      
              - name: vault-secrets
                csi:
                  driver: secrets-store.csi.k8s.io
                  readOnly: true
                  volumeAttributes:
                  secretProviderClass: demo-app-creds

      Copy to Clipboard Toggle word wrap

      1

      serviceAccountName: アプリケーション Pod で使用される Kubernetes ServiceAccount 名 (例: demo-app-sa) を割り当てます。この ServiceAccount は、必要なシークレットを取得するための権限を付与する Vault ロールにリンクされているため、HashiCorp Vault による認証に不可欠です。

      2

      volumeMounts: vault-secrets ボリュームを /mnt/secrets-store ディレクトリーのコンテナーにマウントします。

      3

      volumes: secrets-store.csi.k8s.io ドライバーを使用して vault-secrets ボリュームを定義し、demo-app-creds SecretProviderClass を参照します。

4. ワークロード用の Argo CD アプリケーションを定義します。

   1. GitOps リポジトリーから ServiceAccount、SecretProviderClass、Deployment などのアプリケーションコンポーネントをデプロイするための Argo CD アプリケーションリソースを定義します。Argo CD マニフェストをディレクトリーの場所 (例: environments/dev/apps/demo-app/argocd/demo-app.yaml) に格納します。

      demo-app.yaml ファイルの例

      apiVersion: argoproj.io/v1alpha1
      kind: Application
      metadata:
        name: demo-app
        namespace: openshift-gitops
      spec:
        project: default
        source:
          repoURL: https://your-git-repo-url.git
          targetRevision: HEAD
          path: environments/dev/apps/demo-app/manifest
        destination:
          server: https://kubernetes.default.svc
          namespace: demo-app
        syncPolicy:
          automated:
            prune: true
            selfHeal: true
          syncOptions:
            - CreateNamespace=true

      Copy to Clipboard Toggle word wrap

手順

1. Pod のステータスを確認します。

   1. Argo CD アプリケーションが同期され、すべてのリソースがデプロイされたら、アプリケーション Pod が demo-app namespace で正常に実行されていることを確認します。以下のコマンドを実行します。

      $ oc get pods -n demo-app

      Copy to Clipboard Toggle word wrap

2. シェルセッションを開きます。

   1. アプリケーション Pod の名前を使用してシェルセッションを開きます。<your-app-pod-name> は、実際の Pod 名に置き換えます。

      $ oc exec -it <your-app-pod-name> -n demo-app -- sh

      Copy to Clipboard Toggle word wrap

3. マウントされたシークレットを検証します。

   1. シークレットが想定するパスにマウントされていることを確認するには、次のコマンドを実行します。

      $ ls -l /mnt/secrets-store
        cat /mnt/secrets-store/demoAppUsername
        cat /mnt/secrets-store/demoAppPassword

      Copy to Clipboard Toggle word wrap

      マウントされたシークレットファイル demoAppUsername と demoAppPassword に、Vault からの想定値が含まれていることを確認します。