安全性

流程

1. 安装 AWS Secrets Manager 供应商并添加资源：

   1. 在 GitOps 仓库中，创建一个目录并添加 aws-provider.yaml 文件，使用以下配置来部署 AWS Secret Manager 供应商的资源：

      重要

      SSCSI 驱动程序的 AWS Secret Manager 供应商是一个上游供应商。

      此配置会根据上游 AWS 文档中提供的配置进行修改，以便它可以与 OpenShift Container Platform 正常工作。对此配置的更改可能会影响功能。

      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

      Copy to Clipboard Toggle word wrap

   2. 在 GitOps 仓库中添加 secret-provider-app.yaml 文件，为 AWS Secret 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 

      1

      
        syncPolicy:
          automated:
          prune: true
          selfHeal: true

      Copy to Clipboard Toggle word wrap

      1

      更新 repoURL 字段的值，以指向您的 GitOps 存储库。

2. 将资源与默认的 Argo CD 实例同步，以在集群中部署这些资源：

   1. 在部署应用程序的 openshift-cluster-csi-drivers 命名空间中添加标签，以便 openshift-gitops 命名空间中的 Argo CD 实例可以管理它：

      $ oc label namespace openshift-cluster-csi-drivers argocd.argoproj.io/managed-by=openshift-gitops

      Copy to Clipboard Toggle word wrap

   2. 将 GitOps 存储库中的资源应用到集群，包括您刚才推送的 aws-provider.yaml 文件：

      输出示例

      application.argoproj.io/argo-app created
      application.argoproj.io/secret-provider-app created
      ...

      Copy to Clipboard Toggle word wrap

流程

1. 运行以下命令，授予 csi-secrets-store-provider-aws 服务帐户的特权访问权限：

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

   Copy to Clipboard Toggle word wrap

   输出示例

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

   Copy to Clipboard Toggle word wrap

2. 授予服务帐户读取 AWS secret 对象的权限：

   1. 在 GitOps 仓库的命名空间范围的目录下创建一个 credentialsrequest-dir-aws 文件夹，因为凭据请求是命名空间范围的。例如，运行以下命令，在 dev 命名空间下创建一个 credentialsrequest-dir-aws 文件夹，它位于 /environments/dev/ 目录中：

      $ mkdir credentialsrequest-dir-aws

      Copy to Clipboard Toggle word wrap

   2. 使用 /environments/dev/credentialsrequest-dir-aws/ 路径中的凭证请求创建 YAML 文件，将 secret 挂载到 dev 命名空间中的部署 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

      Copy to Clipboard Toggle word wrap

      2

      secret 引用的命名空间。根据项目部署设置更新此 namespace 字段的值。

      1

      集群所在的区域中的 secret 的 ARN。& lt;aws_ secret_arn> 的 <aws_ region> 必须与集群区域匹配。如果不匹配，在集群所在的区域中创建 secret 复制。

      提示

      要查找集群区域，请运行以下命令：

      $ oc get infrastructure cluster -o jsonpath='{.status.platformStatus.aws.region}'

      Copy to Clipboard Toggle word wrap

      输出示例

      us-west-2

      Copy to Clipboard Toggle word wrap

   3. 运行以下命令来检索 OIDC 供应商：

      $ oc get --raw=/.well-known/openid-configuration | jq -r '.issuer'

      Copy to Clipboard Toggle word wrap

      输出示例

      https://<oidc_provider_name>

      Copy to Clipboard Toggle word wrap

      从输出中复制 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

      Copy to Clipboard Toggle word wrap

      输出示例

      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

      Copy to Clipboard Toggle word wrap

      从输出中复制 <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"
      		}
      	]
      }

      Copy to Clipboard Toggle word wrap

   6. 运行以下命令，使用角色 ARN 绑定服务帐户：

      $ oc annotate -n <namespace> sa/<app_service_account> eks.amazonaws.com/role-arn="<aws_role_arn>"

      Copy to Clipboard Toggle word wrap

      示例命令

      $ oc annotate -n dev sa/default eks.amazonaws.com/role-arn="<aws_role_arn>"

      Copy to Clipboard Toggle word wrap

      输出示例

      serviceaccount/default annotated

      Copy to Clipboard Toggle word wrap

3. 创建命名空间范围的 SecretProviderClass 资源来定义您的 secret 存储供应商。例如，您可以在 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"

      Copy to Clipboard Toggle word wrap

      1

      secret 供应商类的名称。

      2

      secret 供应商类的命名空间。命名空间必须与将使用 secret 的资源的命名空间匹配。

      3

      secret 存储供应商的名称。

      4

      指定特定于供应商的配置参数。

      5

      您在 AWS 中创建的 secret 名称。

   2. 在将此 YAML 文件推送到 GitOps 存储库后，验证命名空间范围的 SecretProviderClass 资源是否在 Argo CD UI 中的目标应用程序页面中填充。

      注意

      如果应用程序的 Sync Policy 没有设置为 Auto，您可以通过点 Argo CD UI 中的 Sync 来手动同步 SecretProviderClass 资源。

流程

1. 配置 GitOps 受管资源。例如，请考虑将卷挂载配置添加到 app-taxi 应用的部署中，且 100-deployment.yaml 文件位于 /environments/dev/apps/app-taxi/services/taxi/base/config/ 目录中。

   1. 将卷挂载添加到部署 YAML 文件中，并将容器 pod 配置为使用 secret 供应商类资源和挂载的 secret：

      YAML 文件示例

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

      1

      
      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" 

      2

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

      3

      
          status: {}
      # ...

      Copy to Clipboard Toggle word wrap

      1

      部署的命名空间。这必须与 secret 供应商类相同。

      2

      在卷挂载中挂载 secret 的路径。

      3

      secret 供应商类的名称。

   2. 将更新的资源 YAML 文件推送到 GitOps 存储库。
2. 在 Argo CD UI 中，点目标应用程序页面中的 REFRESH 以应用更新的部署清单。
3. 验证目标应用程序页面中都已成功同步所有资源。

4. 验证您是否可以从 pod 卷挂载中的 AWS Secret Manager 访问 secret：

   1. 列出 pod 挂载中的 secret：

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

      Copy to Clipboard Toggle word wrap

      示例命令

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

      Copy to Clipboard Toggle word wrap

      输出示例

      <secret_name>

      Copy to Clipboard Toggle word wrap

   2. 查看 pod 挂载中的 secret：

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

      Copy to Clipboard Toggle word wrap

      示例命令

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

      Copy to Clipboard Toggle word wrap

      输出示例

      <secret_value>

      Copy to Clipboard Toggle word wrap

流程

1. 为 Vault CSI 供应商创建 Argo CD 应用程序资源。

   1. 创建 Argo CD Application 资源来部署 Vault CSI 供应商。将此资源添加到 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. 将 vault-secret-provider-app.yaml 文件从 GitOps 存储库应用到集群：

   $ 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 Driver 需要访问 hostPath 挂载，OpenShift Container Platform 块会因为 pod 以特权方式运行。

   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 Driver 服务帐户对 OpenShift Container Platform 中特权安全上下文约束(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 Provider 服务帐户授予 OpenShift Container Platform 中特权安全性上下文约束(SCC)的访问权限。

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

         Copy to Clipboard Toggle word wrap
         注意

         如果在 Helm Chart 中将 server.enabled 设为 true，则 Vault 服务器 Pod 默认使用 OpenShift Container Platform 块的特定用户 ID (UID)或组 ID (GID)运行。

      4. 为 Vault 服务器服务帐户授予所需的安全性上下文约束(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 命名空间中的 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，至少需要 3 个非密封密钥。如果密钥丢失，则永久阻止对存储的 secret 的访问。

3. 非密封 Vault.

   1. Vault 以密封状态启动。运行以下命令使用上一步中获取的五个 Unseal Keys 的三个内容：

      $ 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. 要使用 root 令牌登录到 Vault，请运行以下命令：

      $ vault login <Initial Root Token>

      Copy to Clipboard Toggle word wrap

      这为管理员提供了启用和配置 secret 引擎和身份验证方法的访问权限。

5. 在 Vault 中启用 Kubernetes 身份验证。

   1. 运行以下命令，以在 Vault 中启用 Kubernetes 身份验证。

      $ vault auth enable kubernetes

      Copy to Clipboard Toggle word wrap

      这允许 Kubernetes 工作负载（如 pod）使用其服务帐户通过 Vault 进行身份验证。

6. 在 Vault 中配置 Kubernetes 验证方法。

   1. 要配置 Vault 以便与 Kubernetes API 通信，请运行以下命令：

      $ 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 > 是一个 JSON Web Token (JWT)，Vault 用来调用 Kubernetes TokenReview API，用于验证服务帐户令牌。
      • <kubernetes_host > 是 Vault 用于与 Kubernetes API 服务器通信的 URL。
      • <kubernetes_ca_cert > 是 Vault 用于安全与 Kubernetes API 服务器通信的 CA 证书。

流程

1. 启用 KV Secrets Engine

   1. 使用 Key-Value (KV)版本 2 secret 引擎来存储支持版本控制的任意 secret。运行以下命令在路径 secret/ 中启用 KV secret 引擎：

      $ vault secrets enable -path=secret/ kv

      Copy to Clipboard Toggle word wrap

2. 在 Vault 中存储机密。

   1. 使用 KV Version 2 secret 引擎存储 secret。运行以下命令，将 secret 数据、用户名和密码存储在路径 secret/demo/config ：

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

      Copy to Clipboard Toggle word wrap

3. 创建 Vault 策略。

   1. 要创建授予对 secret 的读取访问权限的策略，请运行以下命令：

      $ 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

      这允许使用服务帐户向 Vault 进行身份验证并检索该 secret。

      其中：

      • <bound_service_account_names > 是 Vault 信任的 Kubernetes 服务帐户的名称。
      • <bound_service_account_namespaces > 是服务帐户所在的命名空间的名称。
      • <policies > 是附加的 Vault 策略的名称。
      • &lt;TTL > 是为令牌发布的生存时间 值。

流程

1. 创建 SecretProviderClass。

   1. 在应用程序的清单目录中创建一个 SecretProviderClass 资源，如 environments/dev/apps/demo-app/manifest/secretProviderClass.yaml。此资源定义 Secret Store CSI 驱动程序如何从 Vault 检索 secret。

      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 服务器的网络地址。根据您的 Vault 设置，如 in-cluster 服务或外部 URL 来调整它。

      3

      <roleName >- 指定应用程序服务帐户使用的 Vault Kubernetes 身份验证角色。描述定义要检索哪些 secret 以及如何将其映射到文件名的数组。

      4

      &lt;objects>- 指定定义要检索哪些 secret 以及如何将其映射到文件名的数组。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 卷挂载 secret。将更新的清单存储在 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 - 分配 Kubernetes ServiceAccount 名称，如 demo-app-sa，供应用 Pod 使用。此 ServiceAccount 是使用 HashiCorp Vault 进行身份验证的基础，因为它链接到授予授予检索所需 secret 权限的 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. 定义 Argo CD 应用程序资源以部署应用程序组件，如 ServiceAccount、SecretProviderClass 和来自 GitOps 存储库的 Deployment。将 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 命名空间中运行。运行以下命令:

      $ oc get pods -n demo-app

      Copy to Clipboard Toggle word wrap

2. 打开 Shell 会话。

   1. 使用应用容器集的名称打开 shell 会话。将 <your-app-pod-name& gt; 替换为实际的 pod 名称。

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

      Copy to Clipboard Toggle word wrap

3. 验证挂载的 secret。

   1. 要验证 secret 是否挂载到预期的路径中，请运行以下命令：

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

      Copy to Clipboard Toggle word wrap

      验证挂载的 secret 文件 demoAppUsername 和 demoAppPassword 是否包含来自 Vault 的预期值。