2.3. GitOps を使用して OpenShift で AWS Secrets Manager を設定する

このガイドでは、Secrets Store Container Storage Interface (SSCSI) Driver Operator で GitOps ワークフローを使用して、AWS Secrets Manager から OpenShift Container Platform の CSI ボリュームにシークレットをマウントする方法を例とともに説明します。

たとえば、SSCSI Driver Operator でシークレットストアプロバイダーとして AWS Secrets Manager を使用していることを考えてみましょう。次の例は、AWS Secrets Manager からのシークレットを使用する準備ができている GitOps リポジトリーのディレクトリー構造を示しています。

GitOps リポジトリーのディレクトリー構造の例

├── config
│   ├── argocd
│   │   ├── argo-app.yaml
│   │   ├── secret-provider-app.yaml


│   │   ├── ...
│   └── sscsid


│       └── aws-provider.yaml


├── environments
│   ├── dev


│   │   ├── apps
│   │   │   └── app-taxi


│   │   │       ├── ...
│   │   ├── credentialsrequest-dir-aws


│   │   └── env
│   │       ├── ...
│   ├── new-env
│   │   ├── ...

2: aws-provider.yaml ファイルを格納するディレクトリー。
3: AWS Secrets Manager プロバイダーをインストールし、そのリソースをデプロイする設定ファイル。
1: アプリケーションを作成し、AWS Secrets Manager のリソースをデプロイする設定ファイル。
4: デプロイメント Pod と認証情報リクエストを格納するディレクトリー。
5: SecretProviderClass リソースを格納するディレクトリー。シークレットストアプロバイダーを定義します。
6: credentialsrequest.yaml ファイルを格納するフォルダー。このファイルには、シークレットをデプロイメント Pod にマウントするための認証情報要求の設定が含まれます。

2.3.1. GitOps リポジトリーへの AWS Secrets Manager リソースの格納
リンクのコピー

宣言型およびバージョン管理されたシークレット管理のために、AWS Secrets Manager の設定を GitOps リポジトリーに格納できます。

重要

AWS Secrets Manager での SSCSI Driver Operator の使用は、ホストされたコントロールプレーンクラスターではサポートされていません。

前提条件

cluster-admin 権限でクラスターにアクセスできる。
OpenShift Container Platform Web コンソールにアクセスできる。
ccoctl バイナリーを抽出して準備している。
jq CLI ツールがインストールされている。
クラスターが AWS にインストールされ、AWS Security Token Service (STS) を使用している。
必要なシークレットを格納するように AWS Secrets Manager を設定している。
SSCSI Driver Operator がクラスターにインストールされている。
Red Hat OpenShift GitOps Operator がクラスターにインストールされている。
GitOps リポジトリーでシークレットを使用する準備ができている。
Argo CD 管理アカウントを使用して Argo CD インスタンスにログインしている。

手順

AWS Secrets Manager プロバイダーをインストールし、リソースを追加します。

GitOps リポジトリーでディレクトリーを作成し、aws-provider.yaml ファイルを次の設定に追加して、AWS Secrets Manager プロバイダーのリソースをデプロイします。

重要

SSCSI ドライバー用の AWS Secrets Manager プロバイダーは、アップストリームのプロバイダーです。

この設定は、OpenShift Container Platform で適切に動作するように、アップストリームの AWS ドキュメントで提供されている設定から変更されています。この設定を変更すると、機能に影響が出る場合があります。

aws-provider.yaml ファイルの例

apiVersion: v1
kind: ServiceAccount
metadata:
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: csi-secrets-store-provider-aws-cluster-role
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: csi-secrets-store-provider-aws-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: csi-secrets-store-provider-aws-cluster-role
subjects:
- kind: ServiceAccount
  name: csi-secrets-store-provider-aws
  namespace: openshift-cluster-csi-drivers
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: openshift-cluster-csi-drivers
  name: csi-secrets-store-provider-aws
  labels:
    app: csi-secrets-store-provider-aws
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: csi-secrets-store-provider-aws
  template:
    metadata:
      labels:
        app: csi-secrets-store-provider-aws
    spec:
      serviceAccountName: csi-secrets-store-provider-aws
      hostNetwork: false
      containers:
        - name: provider-aws-installer
          image: public.ecr.aws/aws-secrets-manager/secrets-store-csi-driver-provider-aws:1.0.r2-50-g5b4aca1-2023.06.09.21.19
          imagePullPolicy: Always
          args:
              - --provider-volume=/etc/kubernetes/secrets-store-csi-providers
          resources:
            requests:
              cpu: 50m
              memory: 100Mi
            limits:
              cpu: 50m
              memory: 100Mi
          securityContext:
            privileged: true
          volumeMounts:
            - mountPath: "/etc/kubernetes/secrets-store-csi-providers"
              name: providervol
            - name: mountpoint-dir
              mountPath: /var/lib/kubelet/pods
              mountPropagation: HostToContainer
      tolerations:
      - operator: Exists
      volumes:
        - name: providervol
          hostPath:
            path: "/etc/kubernetes/secrets-store-csi-providers"
        - name: mountpoint-dir
          hostPath:
            path: /var/lib/kubelet/pods
            type: DirectoryOrCreate
      nodeSelector:
        kubernetes.io/os: linux

GitOps リポジトリーに secret-provider-app.yaml ファイルを追加して、アプリケーションを作成し、AWS Secrets Manager のリソースをデプロイします。

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

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: secret-provider-app
  namespace: openshift-gitops
spec:
  destination:
    namespace: openshift-cluster-csi-drivers
    server: https://kubernetes.default.svc
  project: default
  source:
    path: path/to/aws-provider/resources
    repoURL: https://github.com/<my-domain>/<gitops>.git


  syncPolicy:
    automated:
    prune: true
    selfHeal: true

1: repoURL フィールドの値を更新して、GitOps リポジトリーを指すようにします。

リソースをデフォルトの Argo CD インスタンスと同期して、それらをクラスターにデプロイします。
1. アプリケーションがデプロイされている openshift-cluster-csi-drivers namespace にラベルを追加し、openshift-gitops namespace の Argo CD インスタンスが管理できるようにします。
  $ oc label namespace openshift-cluster-csi-drivers argocd.argoproj.io/managed-by=openshift-gitops
2. プッシュした aws-provider.yaml ファイルを含む、GitOps リポジトリー内のリソースをクラスターに適用します。
  出力例
  application.argoproj.io/argo-app created application.argoproj.io/secret-provider-app created ...

Argo CD UI では、csi-secrets-store-provider-aws daemonset がリソースの同期を継続していることがわかります。この問題を解決するには、AWS Secrets Manager からシークレットをマウントするように SSCSI ドライバーを設定する必要があります。

2.3.2. AWS Secrets Manager からシークレットをマウントする SSCSI ドライバーの設定
リンクのコピー

シークレットをセキュアに格納および管理するには、GitOps ワークフローを使用し、シークレットを AWS Secrets Manager から OpenShift Container Platform の CSI ボリュームにマウントするように Secrets Store Container Storage Interface (SSCSI) Driver Operator を設定します。たとえば、/environments/dev/ ディレクトリーにある dev namespace のデプロイメント Pod にシークレットをマウントする場合などです。

前提条件

GitOps リポジトリーに AWS Secrets Manager リソースが格納されている。

手順

次のコマンドを実行して、csi-secrets-store-provider-aws サービスアカウントへの特権アクセスを付与します。

$ oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers

出力例

clusterrole.rbac.authorization.k8s.io/system:openshift:scc:privileged added: "csi-secrets-store-provider-aws"

サービスアカウントに AWS シークレットオブジェクトの読み取りを許可するアクセス許可を付与します。
1. 認証情報要求は namespace スコープであるため、GitOps リポジトリーの namespace スコープディレクトリーに credentialsrequest-dir-aws フォルダーを作成します。たとえば、次のコマンドを実行して、/environments/dev/ ディレクトリーにある dev namespace に credentialsrequest-dir-aws フォルダーを作成します。
  $ mkdir credentialsrequest-dir-aws
2. /environments/dev/credentialsrequest-dir-aws/ パスに認証情報リクエスト用の次の設定を含む YAML ファイルを作成し、dev namespace のデプロイメント Pod にシークレットをマウントします。
  credentialsrequest.yaml ファイルの例
  apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: aws-provider-test namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - action: - "secretsmanager:GetSecretValue" - "secretsmanager:DescribeSecret" effect: Allow resource: "<aws_secret_arn>"
  1
  secretRef: name: aws-creds namespace: dev
  2
  serviceAccountNames: - default
  2
  シークレット参照の namespace。プロジェクトのデプロイメント設定に従って、この namespace フィールドの値を更新します。
  1
  クラスターが置かれているリージョンのシークレットの ARN。<aws_secret_arn> の <aws_region> は、クラスターのリージョンと一致する必要があります。一致しない場合は、クラスターが置かれているリージョンにシークレットのレプリケーションを作成します。
  ヒント
  クラスターリージョンを見つけるには、次のコマンドを実行します。
  
  $ oc get infrastructure cluster -o jsonpath='{.status.platformStatus.aws.region}'
  
  出力例
  
  us-west-2
3. 次のコマンドを実行して、OIDC プロバイダーを取得します。
  $ oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'
  出力例
  https://<oidc_provider_name>
  次のステップで使用するために、出力から OIDC プロバイダー名 <oidc_provider_name> をコピーします。
4. ccoctl ツールを使用して、次のコマンドを実行して認証情報リクエストを処理します。
  $ ccoctl aws create-iam-roles \ --name my-role --region=<aws_region> \ --credentials-requests-dir=credentialsrequest-dir-aws \ --identity-provider-arn arn:aws:iam::<aws_account>:oidc-provider/<oidc_provider_name> --output-dir=credrequests-ccoctl-output
  出力例
  2023/05/15 18:10:34 Role arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds created 2023/05/15 18:10:34 Saved credentials configuration to: credrequests-ccoctl-output/manifests/my-namespace-aws-creds-credentials.yaml 2023/05/15 18:10:35 Updated Role policy for Role my-role-my-namespace-aws-creds
  次のステップで使用するために、出力から <aws_role_arn> をコピーします。たとえば、arn:aws:iam::<aws_account_id>:role/my-role-my-namespace-aws-creds です。
5. AWS のロールポリシーをチェックして、ロールポリシー内の "Resource" の <aws_region> がクラスターリージョンと一致していることを確認します。
  ロールポリシーの例
  { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:<aws_region>:<aws_account_id>:secret:my-secret-xxxxxx" } ] }
6. 次のコマンドを実行して、ロール ARN を持つサービスアカウントをバインドします。
  $ oc annotate -n <namespace> sa/<app_service_account> eks.amazonaws.com/role-arn="<aws_role_arn>"
  コマンドの例
  $ oc annotate -n dev sa/default eks.amazonaws.com/role-arn="<aws_role_arn>"
  出力例
  serviceaccount/default annotated
namespace スコープの SecretProviderClass リソースを作成し、シークレットストアプロバイダーを定義します。たとえば、GitOps リポジトリーの /environments/dev/apps/app-taxi/services/taxi/base/config ディレクトリーに SecretProviderClass リソースを作成します。
1. ターゲットのデプロイメントが GitOps リポジトリーにあるのと同じディレクトリーに、secret-provider-class-aws.yaml ファイルを作成します。
  secret-provider-class-aws.yaml の例
  apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: my-aws-provider
  1
  namespace: dev
  2
  spec: provider: aws
  3
  parameters:
  4
  objects: | - objectName: "testSecret"
  5
  objectType: "secretsmanager"
  1
  シークレットプロバイダークラスの名前。
  2
  シークレットプロバイダークラスの namespace。namespace は、シークレットを使用するリソースの namespace と一致する必要があります。
  3
  シークレットストアプロバイダーの名前。
  4
  プロバイダー固有の設定パラメーターを指定します。
  5
  AWS で作成したシークレット名。
2. この YAML ファイルを GitOps リポジトリーにプッシュした後、namespace スコープの SecretProviderClass リソースが Argo CD UI のターゲットアプリケーションページに設定されていることを確認します。
  注記
  アプリケーションの Sync Policy が Auto に設定されていない場合は、Argo CD UI で Sync をクリックして、SecretProviderClass リソースを手動で同期できます。

2.3.3. マウントされたシークレットを使用するための GitOps 管理リソースの設定
リンクのコピー

ボリュームマウント設定をデプロイメントに追加し、マウントされたシークレットを使用するようにコンテナー Pod を設定して、GitOps 管理リソースを設定する必要があります。

前提条件

GitOps リポジトリーに AWS Secrets Manager リソースが格納されている。
AWS Secrets Manager からシークレットをマウントするように Secrets Store Container Storage Interface (SSCSI) ドライバーが設定されている。

手順

GitOps 管理リソースを設定します。たとえば、app-taxi アプリケーションのデプロイメントにボリュームのマウント設定を追加し、100-deployment.yaml ファイルが /environments/dev/apps/app-taxi/services/taxi/base/config/ ディレクトリーにあるとします。

デプロイメント YAML ファイルにボリュームマウントを追加し、シークレットプロバイダークラスリソースおよびマウントされたシークレットを使用するようにコンテナー Pod を設定します。

サンプル YAML ファイル

apiVersion: apps/v1
kind: Deployment
metadata:
  name: taxi
  namespace: dev


spec:
  replicas: 1
  template:
    metadata:
# ...
    spec:
      containers:
        - image: nginxinc/nginx-unprivileged:latest
          imagePullPolicy: Always
          name: taxi
          ports:
            - containerPort: 8080
          volumeMounts:
            - name: secrets-store-inline
              mountPath: "/mnt/secrets-store"


              readOnly: true
          resources: {}
    serviceAccountName: default
    volumes:
      - name: secrets-store-inline
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: "my-aws-provider"


    status: {}
# ...

1: デプロイメントの namespace。これは、シークレットプロバイダークラスと同じ namespace である必要があります。
2: ボリュームマウントにシークレットをマウントするパス。
3: シークレットプロバイダークラスの名前。

更新されたリソース YAML ファイルを GitOps リポジトリーにプッシュします。

Argo CD UI で、ターゲットアプリケーションページで REFRESH をクリックし、更新されたデプロイメントマニフェストを適用します。
ターゲットアプリケーションページですべてのリソースが正常に同期されていることを確認します。

Pod ボリュームマウントの AWS Secrets Manager からシークレットにアクセスできることを確認します。

Pod マウント内のシークレットをリスト表示します。

$ oc exec <deployment_name>-<hash> -n <namespace> -- ls /mnt/secrets-store/

コマンドの例

$ oc exec taxi-5959644f9-t847m -n dev -- ls /mnt/secrets-store/

出力例

<secret_name>

Pod マウントのシークレットを表示します。

$ oc exec <deployment_name>-<hash> -n <namespace> -- cat /mnt/secrets-store/<secret_name>

コマンドの例

$ oc exec taxi-5959644f9-t847m -n dev -- cat /mnt/secrets-store/testSecret

出力例

<secret_value>

2.3. GitOps を使用して OpenShift で AWS Secrets Manager を設定する

2.3.1. GitOps リポジトリーへの AWS Secrets Manager リソースの格納
リンクのコピー

2.3.2. AWS Secrets Manager からシークレットをマウントする SSCSI ドライバーの設定
リンクのコピー

2.3.3. マウントされたシークレットを使用するための GitOps 管理リソースの設定
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.3. GitOps を使用して OpenShift で AWS Secrets Manager を設定する

2.3.1. GitOps リポジトリーへの AWS Secrets Manager リソースの格納リンクのコピーリンクがクリップボードにコピーされました!

2.3.2. AWS Secrets Manager からシークレットをマウントする SSCSI ドライバーの設定リンクのコピーリンクがクリップボードにコピーされました!

2.3.3. マウントされたシークレットを使用するための GitOps 管理リソースの設定リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.3.1. GitOps リポジトリーへの AWS Secrets Manager リソースの格納
リンクのコピー

2.3.2. AWS Secrets Manager からシークレットをマウントする SSCSI ドライバーの設定
リンクのコピー

2.3.3. マウントされたシークレットを使用するための GitOps 管理リソースの設定
リンクのコピー