2.2. 用于持久性卷加密的存储类

持久性卷(PV)加密可确保租户(应用程序)之间的隔离和保密性。在使用 PV 加密前,您必须为 PV 加密创建一个存储类。持久卷加密仅可用于 RBD PV。

OpenShift Data Foundation 支持在 HashiCorp Vault 中存储加密密码短语。您可以创建加密的存储类,使用外部密钥管理系统(KMS)进行持久性卷加密。在创建存储类前,您需要配置对 KMS 的访问。

注意

对于 PV 加密,您必须具有有效的 Red Hat OpenShift Data Foundation Advanced 订阅。如需更多信息,请参阅 OpenShift Data Foundation 订阅中的知识库文章

2.2.1. 访问密钥管理系统 (KMS) 的配置

取决于您的具体用例,需要使用以下方法之一配置对 KMS 的访问:

  • 使用 vaulttoken 允许用户使用令牌进行身份验证
  • 使用 vaulttenantsa (技术预览):允许用户使用 serviceaccounts 通过 Vault 进行身份验证
重要

使用 vaulttenantsa 访问 KMS 是一项技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

如需更多信息,请参阅技术预览功能支持范围

2.2.1.1. 使用 vaulttoken 配置对 KMS 的访问

先决条件

  • OpenShift 数据基础集群处于 Ready 状态。
  • 在外部密钥管理系统 (KMS) 上,

    • 确保存在具有令牌的策略,并且启用了 Vault 中的键值后端路径。
    • 确保您在 Vault 服务器上使用签名证书。

流程

在租户的命名空间中创建一个 secret。

  1. 在 OpenShift Container Platform web 控制台中进入 Workloads → Secrets
  2. Create → Key/value secret
  3. 输入 Secret Name 作为 ceph-csi-kms-token
  4. 输入 Key 作为 token
  5. 输入 Value

    它是来自 Vault 的令牌。您可以单击 Browse 来选择并上传含有令牌的文件,或者直接在文本框中输入令牌。

  6. 点击 Create
注意

只有在所有使用 ceph-csi-kms-token 的加密 PVC 已被删除后,才能删除令牌。

2.2.1.2. 使用 vaulttenantsa 配置对 KMS 的访问

先决条件

  • OpenShift 数据基础集群处于 Ready 状态。
  • 在外部密钥管理系统 (KMS) 上,

    • 确保策略存在,并且已启用 Vault 中的键值后端路径。
    • 确保您在 Vault 服务器上使用签名的证书。
  • 在租户命名空间中创建以下 serviceaccount,如下所示:

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
        name: ceph-csi-vault-sa
    EOF

流程

在 OpenShift Data Foundation 使用 Vault 进行身份验证之前,您需要配置 Kubernetes 身份验证方法。以下说明创建并配置 serviceAccountClusterRole 和 ClusterRoleBinding ,以允许 OpenShift Data Foundation 使用 Vault 进行身份验证。

  1. 将以下 YAML 应用到您的 Openshift 集群:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: rbd-csi-vault-token-review
    ---
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: rbd-csi-vault-token-review
    rules:
      - apiGroups: ["authentication.k8s.io"]
        resources: ["tokenreviews"]
        verbs: ["create", "get", "list"]
    
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: rbd-csi-vault-token-review
    subjects:
      - kind: ServiceAccount
        name: rbd-csi-vault-token-review
        namespace: openshift-storage
    roleRef:
      kind: ClusterRole
      name: rbd-csi-vault-token-review
      apiGroup: rbac.authorization.k8s.io
  2. 根据 OpenShift Container Platform 版本,执行以下之一:

    • 对于 OpenShift Container Platform 4.10:

      • 识别与上面创建的 serviceaccount(SA)关联的 secret 名称。

        $ VAULT_SA_SECRET_NAME=$(oc -n openshift-storage get sa <SA_NAME> -o jsonpath="{.secrets[]['name']}") | grep -o "[^[:space:]]-token-[^[:space:]]*"

        例如:

        $ VAULT_SA_SECRET_NAME=$(oc -n openshift-storage get sa rbd-csi-vault-token-review -o jsonpath="{.secrets[]['name']}" | grep -o "[^[:space:]]-token-[^[:space:]]*")
    • 对于 OpenShift Container Platform 4.11:

      • 为 serviceaccount 令牌和 CA 证书创建 secret。

        $ cat <<EOF | oc create -f -
        apiVersion: v1
        kind: Secret
        metadata:
          name: rbd-csi-vault-token-review-token
          namespace: openshift-storage
          annotations:
            kubernetes.io/service-account.name: "rbd-csi-vault-token-review"
        type: kubernetes.io/service-account-token
        data: {}
        EOF
        $ VAULT_SA_SECRET_NAME=rbd-csi-vault-token-review-token
  3. 从 secret 获取令牌和 CA 证书。

    $ SA_JWT_TOKEN=$(oc -n openshift-storage get secret "$VAULT_SA_SECRET_NAME" -o jsonpath="{.data.token}" | base64 --decode; echo)
    $ SA_CA_CRT=$(oc -n openshift-storage get secret "$VAULT_SA_SECRET_NAME" -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)
  4. 检索 OpenShift 集群端点。

    $ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")
  5. 使用前面步骤中收集的信息在 Vault 中设置 kubernetes 身份验证方法,如下所示:

    $ vault auth enable kubernetes
    $ vault write auth/kubernetes/config \
              token_reviewer_jwt="$SA_JWT_TOKEN" \
              kubernetes_host="$OCP_HOST" \
              kubernetes_ca_cert="$SA_CA_CRT"
  6. 在 Vault 中为租户命名空间创建一个角色:

    $ vault write "auth/kubernetes/role/csi-kubernetes" bound_service_account_names="ceph-csi-vault-sa" bound_service_account_namespaces=<tenant_namespace> policies=<policy_name_in_vault>

    csi-kubernetes 是 OpenShift Data Foundation 在 Vault 中寻找的默认角色名称。OpenShift Data Foundation 集群中租户命名空间中的默认服务帐户名称为 ceph-csi-vault-sa。这些默认值可以通过在租户命名空间中创建 ConfigMap 来覆盖。

    有关覆盖默认名称的更多信息,请参阅使用租户 ConfigMap 覆盖 Vault 连接详情

YAML 示例

  • 要创建一个使用 vaulttenantsa 方法进行 PV 保护的存储类,您必须编辑现有的 ConfigMap 或创建名为 csi-kms-connection-details 的配置映射,它将保存建立与 Vault 连接所需的所有信息。

    以下提供的 yaml 示例可用于更新或创建 csi-kms-connection-detail ConfigMap:

    apiVersion: v1
    data:
      vault-tenant-sa: |-
        {
          "encryptionKMSType": "vaulttenantsa",
          "vaultAddress": "<https://hostname_or_ip_of_vault_server:port>",
          "vaultTLSServerName": "<vault TLS server name>",
          "vaultAuthPath": "/v1/auth/kubernetes/login",
          "vaultAuthNamespace": "<vault auth namespace name>"
          "vaultNamespace": "<vault namespace name>",
          "vaultBackendPath": "<vault backend path name>",
          "vaultCAFromSecret": "<secret containing CA cert>",
          "vaultClientCertFromSecret": "<secret containing client cert>",
          "vaultClientCertKeyFromSecret": "<secret containing client private key>",
          "tenantSAName": "<service account name in the tenant namespace>"
        }
    metadata:
      name: csi-kms-connection-details

    encryptionKMSType

    设置为 vaulttenantsa,以使用服务帐户与 vault 进行身份验证。

    vaultAddress

    使用端口号的 vault 服务器的主机名或 IP 地址。

    vaultTLSServerName

    (可选) vault TLS 服务器名称

    vaultAuthPath

    (可选)在 Vault 中启用 kubernetes auth 方法的路径。默认路径为 kubernetes。如果在 kubernetes 之外的其他路径中启用了 auth 方法,则需要将此变量设置为 "/v1/auth/<path>/login"。

    vaultAuthNamespace

    (可选)启用 kubernetes auth 方法的 Vault 命名空间。

    vaultNamespace

    (可选)用于存储密钥的后端路径存在的 Vault 命名空间

    vaultBackendPath

    保存加密密钥的 Vault 中的后端路径

    vaultCAFromSecret

    包含来自 Vault 的 CA 证书的 OpenShift Data Foundation 集群中的 secret

    vaultClientCertFromSecret

    包含来自 Vault 的客户端证书的 OpenShift Data Foundation 集群中的 secret

    vaultClientCertKeyFromSecret

    包含来自 Vault 的客户端私钥的 OpenShift Data Foundation 集群中的 secret

    tenantSAName

    (可选)租户命名空间中的服务帐户名称。默认值为 ceph-csi-vault-sa。如果要使用其他名称,则必须相应地设置此变量。

2.2.2. 为持久性卷加密创建存储类

先决条件

根据您的用例,您必须确保为以下之一配置对 KMS 的访问:

流程

  1. 在 OpenShift Web 控制台中,进入 StorageStorageClasses
  2. Create Storage Class
  3. 输入存储类 NameDescription
  4. Reclaim Policy 选择 DeleteRetain。默认情况下,选择 Delete
  5. 选择 ImmediateWaitForFirstConsumer 作为卷绑定模式WaitForConsumer 设置为默认选项。
  6. 选择 RBD Provisioner openshift-storage.rbd.csi.ceph.com,这是用于调配持久卷的插件。
  7. 选择 存储池,其中卷数据将存储到列表中或创建新池。
  8. 选中 Enable encryption 复选框。有两个选项可用来设置 KMS 连接详情:

    • 选择现有的 KMS 连接 :从下拉列表中选择现有 KMS 连接。该列表填充自 csi-kms-connection-details ConfigMap 中的连接详情。
    • 创建新的 KMS 连接 :这仅适用于 vaulttoken

      1. 默认情况下,Key Management Service Provider 设置为 Vault。
      2. 输入唯一的连接名称 , Vault 服务器的主机地址('https://<hostname 或 ip>'),端口号和令牌
      3. 展开 Advanced Settings,以根据您的 Vault 配置输入其他设置和证书详情。

        1. 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
        2. 可选:输入 TLS Server NameVault Enterprise Namespace
        3. 上传对应的 PEM 编码证书文件,以提供 CA 证书客户端证书客户端私钥
        4. 点击 Save
      4. 点击 Save
  9. 点击 Create
  10. 如果 HashiCorp Vault 设置不允许自动检测后端路径使用的 Key/Value(KV)secret 引擎 API 版本,编辑 ConfigMap 以添加 vaultBackend 参数。

    注意

    vaultBackend 是一个可选参数,添加到 configmap 中,以指定与后端路径关联的 KV secret 引擎 API 版本。确保值与为后端路径设置的 KV secret 引擎 API 版本匹配,否则可能会导致持久性卷声明(PVC)创建过程中失败。

    1. 识别新创建的存储类使用的 encryptionKMSID。

      1. 在 OpenShift Web 控制台中,导航到 StorageStorage Classes
      2. Storage class name → YAML 标签页。
      3. 捕获存储类使用的 encryptionKMSID

        例如:

        encryptionKMSID: 1-vault
    2. 在 OpenShift Web 控制台中,导航到 WorkloadsConfigMaps
    3. 要查看 KMS 连接详情,请单击点击 csi-kms-connection-details
    4. 编辑 ConfigMap。

      1. 点击 Action 菜单 (⋮)Edit ConfigMap
      2. 根据之前标识的 encryptionKMSID 配置的后端,添加 vaultBackend 参数。

        您可以为 KV secret engine API 版本 1 分配 kv,为 KV secret engine API 版本 2 分配 kv-v2

        例如:

         kind: ConfigMap
         apiVersion: v1
         metadata:
           name: csi-kms-connection-details
         [...]
         data:
           1-vault: |-
             {
               "encryptionKMSType": "vaulttokens",
               "kmsServiceName": "1-vault",
               [...]
               "vaultBackend": "kv-v2"
             }
           2-vault: |-
             {
               "encryptionKMSType": "vaulttenantsa",
               [...]
               "vaultBackend": "kv"
             }
      3. 点 Save

后续步骤

  • 存储类可用于创建加密的持久性卷。如需更多信息,请参阅管理持久性卷声明

    重要

    红帽与技术合作伙伴合作,将本文档作为为客户提供服务。但是,红帽不为 HashiCorp 产品提供支持。有关此产品的技术协助,请联系 HashiCorp

2.2.2.1. 使用租户 ConfigMap 覆盖 Vault 连接详情

可以通过在 Openshift 命名空间中创建 ConfigMap 来为每个租户重新配置 Vault 连接详情,其配置选项与 openshift-storage 命名空间中的 csi-kms-connection-details ConfigMap 中设置的值不同。ConfigMap 需要位于租户命名空间中。租户命名空间中的 ConfigMap 中的值将覆盖在该命名空间中创建的加密持久性卷的 csi-kms-connection-details ConfigMap 中设置的值。

流程

  1. 确保您位于租户命名空间中。
  2. Workloads → ConfigMaps
  3. Create ConfigMap
  4. 以下是 yaml 示例。给定租户命名空间要覆盖的值可以在 data 部分下指定,如下所示:

    ---
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ceph-csi-kms-config
    data:
      vaultAddress: "<vault_address:port>"
      vaultBackendPath: "<backend_path>"
      vaultTLSServerName: "<vault_tls_server_name>"
      vaultNamespace: "<vault_namespace>"
  5. 编辑完 yaml 后,点 Create