轮替存储身份验证密钥和证书

Google Distributed Cloud (GDC) 气隙设备采用 ONTAP Select (OTS) 作为软件定义的存储供应商。OTS 具有自己的身份验证系统，其中每个身份（核心服务或客户端）都具有关联的名称和密钥。

本文档介绍了轮替身份验证密钥和证书的步骤，这些步骤必须针对以下情况执行：

  • 定期安排密钥轮替，以确保设备符合相关规定并安全无虞。
  • 密钥暴露。您应尽快轮换泄露的密钥。

准备工作

确保您拥有以下访问权限：

  • 对 ONTAP 集群的管理控制台访问权限
  • 管理 API 服务器的 Kubeconfig

轮替 IPsec 凭据 (PSK)

自 9.10.1 版起，ONTAP 支持基于证书的 IPsec 身份验证。此版本的 GDC 为 9.14.1，并使用预共享密钥。

对于设备，IPsec 针对两种类型的 OTS 流量实现：

  • 裸机主机与 SVM 之间的外部流量。
  • 工作器节点之间的内部流量。

我们将分别介绍这些方法。

前提条件

  • 对 ONTAP 集群的管理控制台访问权限
  • 新的预共享密钥
  • 管理 API 服务器的 Kubeconfig
  • 访问主机以更新 StrongSwan 配置

影响

在轮换 IPsec 政策期间，主机将无法连接到存储系统。连接会停滞或可能失败，具体取决于应用行为。如果可能，您可以在轮替期间暂停用户工作负载，但这并非强制要求。重置密钥后，连接应很快恢复。

适用于 OTS 外部流量的密钥轮替

如需验证轮换，请使用以下命令并比较输出结果：

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

输出：

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

验证您之前执行脚本的特定主机的 READY 字段是否为 true。

如果在验证期间发现任何错误，请手动轮替 PSK。

  1. 执行以下命令：

    export KUBECONFIG= #path to root-admin kubeconfig

    mgmt_ip="$(kubectl get storagecluster -A -o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

username="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.username}' | base64 -d)"

password="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.password}' | base64 -d)"

  2. 查看密码并将其复制到剪贴板：

    echo $password

  3. 登录 ONTAP 控制台：

    ssh $username@$mgmt_ip

    当系统提示输入密码时，粘贴上一步中复制的密码。

  4. 使用以下脚本进行凭据轮替：

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl get StorageEncryptionConnections -n gpc-system

    输出：

    NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

    对于要轮换的每个主机，您可以执行以下操作：

    export bm_host= //name of bm-host from above
export secret="${bm_host}-pre-shared-key"
export job_name="os-policy-config-host-ipsec-${bm_host}"
export ns="gpc-system"
export svm="$(kubectl get storageencryptionconnections "${bm_host}" -n "${ns}" -o jsonpath='{.spec.storageVirtualMachineRef.name}')"

    现在，确认您看到了存储加密连接的所有组件。对于管理员集群连接（无论是根管理员还是组织管理员），您都必须使用根管理员集群。

    kubectl get secrets -n "${ns}" "${secret}"
kubectl get jobs -n "${ns}" "${job_name}"

    如果这两个项目都存在，您可以继续执行下一步。如果不是，请停止并不要继续修改 IPsec。请联系技术支持团队。

    kubectl delete secrets -n "${ns}" "${secret}"
kubectl delete jobs "${job_name}" -n "${ns}"

    现在，使用 Management API 服务器删除 storageencryptionconnection

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl delete storageencryptionconnections "${bm_host}"

annotation_key="reconcile_annotation_key"
annotation_value="reconcile_annotation_value"

kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=merge -p "{\"metadata\":{\"annotations\":{\"$annotation_key\":\"$annotation_value\"}}}"
kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=json -p="[{\"op\": \"remove\", \"path\": \"/metadata/annotations/$annotation_key\"}]"

    针对 OTS 内部流量的密钥轮替

同样，如需验证轮换，请使用以下命令并比较输出：

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get secret ots-internal-pre-shared-key -n gpc-system

输出：

NAME                          TYPE     DATA   AGE
ots-internal-pre-shared-key   Opaque   1      18m

kubectl get jobs -n gpc-system | grep os-policy-config-host-ipsec

输出：

os-policy-config-host-ipsec-bm-3d33bb857t5bh                Complete   1/1           17s        10m
os-policy-config-host-ipsec-bm-774fa8e6frgr7                Complete   1/1           30s        11m
os-policy-config-host-ipsec-bm-8e452fb29q5wd                Complete   1/1           23s        11m

验证所有作业是否都处于 Complete 状态。

kubectl get StorageEncryptionConnections -n gpc-system

输出：

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-3d33bb85   bm-3d33bb85        root-admin              10.4.4.0/24   bm-3d33bb85-pre-shared-key   True    6h16m
bm-774fa8e6   bm-774fa8e6        root-admin              10.4.4.0/24   bm-774fa8e6-pre-shared-key   True    16h
bm-8e452fb2   bm-8e452fb2        root-admin              10.4.4.0/24   bm-8e452fb2-pre-shared-key   True    21h

验证所有主机的 READY 字段是否为 true。

  1. 按列出的顺序删除第 2 步中的所有 CR

    • 删除内部流量的 Secret sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

    • 删除所有 3 个操作系统政策作业 sh kubectl delete jobs os-policy-config-host-ipsec-bm-3d33bb857t5bh -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-774fa8e6frgr7 -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-8e452fb29q5wd -n gpc-system

    • 删除所有三个 storageencryptionconnection sh kubectl delete StorageEncryptionConnections bm-3d33bb85-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-774fa8e6-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-8e452fb2-root-admin -n gpc-system

  2. 等待几分钟（约 3-5 分钟）。重复第 2 步，直到每个 CR 都处于 READY 或 Complete 状态。

轮替音量键

本部分介绍了轮替 OTS 卷凭据的手动步骤。

准备工作

请完成以下步骤：

  1. 验证您是否满足笔记本电脑前提条件。
  2. 确保您可以通过 BM01 或 BM02 登录 OTS 集群的控制台。

启动卷密钥轮替

在 OTS 控制台中，触发一次性密钥轮替：

volume encryption rekey start -vserver SVM_name -volume volume_name

以下命令会更改 SVMvs1 上 vol1 的加密密钥：

cluster1::> volume encryption rekey start -vserver vs1 -volume vol1

如需查看虚拟服务器和卷的名称，您可以使用 show 命令：

vserver show
volume show

验证批量密钥轮替

密钥轮替启动后，请检查重新生成密钥的状态：

volume encryption rekey show

显示重新生成密钥操作的状态：

cluster1::> volume encryption rekey show

Vserver   Volume   Start Time           Status
-------   ------   ------------------   ---------------------------
vs1       vol1     9/18/2017 17:51:41   Phase 2 of 2 is in progress.

重新生成密钥操作完成后，验证卷是否已启用加密：

volume show -is-encrypted true

在 cluster1 上显示加密卷：

cluster1::> volume show -is-encrypted true

Vserver  Volume  Aggregate  State  Type  Size  Available  Used
-------  ------  ---------  -----  ----  -----  --------- ----
vs1      vol1    aggr2     online    RW  200GB    160.0GB  20%

轮替外部 HSM 证书

本部分介绍如何轮替和更新 ONTAP 的外部 HSM 证书。

前提条件

  • 对 ONTAP 集群或相关 SVM 的管理员访问权限
  • 当前密码
  • kubectl 对相应集群的访问权限

说明

  1. 备份旧的 HSM 证书：

    kubectl get secret aa-aa-external-hsm-creds -n gpc-system -o yaml > external-hsm-creds-old.yaml

  2. 在 Kubernetes 中更新 HSM 证书 Secret：

    1. 复制旧的 Secret YAML 文件： sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

    2. 使用新的 HSM 凭据（包括服务器 CA 证书、公共客户端证书和客户端的私钥）更新新的 external-hsm-creds-new.yaml 文件。

    3. 应用更改并更新 HSM Secret 对象。

      kubectl apply -f external-hsm-creds-new.yaml

  3. 在 ONTAP 中更新 HSM 证书：

    1. 登录 ONTAP CLI。

    2. 安装新的服务器 CA 证书：

      cluster::> security certificate install -type server-ca -vserver <>

    3. 安装新的客户端证书：

      cluster::> security certificate install -type client -vserver <>

    4. 更新密钥管理器配置以使用新安装的证书：

      cluster::> security key-manager external modify -vserver <> -client-cert <> -server-ca-certs <>

验证

  1. 通过密钥管理器状态验证更改：

    cluster::> security key-manager external show-status

    检查密钥服务器是否仍处于 Available 状态。

轮替存储管理员凭据

本部分介绍如何轮替和设置存储管理员用户和密码。

前提条件

  • 对 ONTAP 集群或相关 SVM 的管理员访问权限
  • 当前密码
  • kubectl 对相应集群的访问权限

说明

  1. 首先运行以下命令，然后按照生成的提示操作：

    cluster::> security login password

  2. 更新了密钥以匹配：

    • 选项 1（互动式）：

      kubectl edit secret -n <netapp_namespace> netapp_credential

      使用编辑器将密码更改为新的 base64 编码值。

    • 选项 2（包含 jq 依赖项的补丁）：

      k get secret -n <netapp_namespace> netapp_credential -o json | jq '.data["password"]="<new-base64-encoded-password>"' | kubectl apply -f -

轮替 ONTAP 紧急访问凭据

在文件和块存储设置期间，系统会创建四个紧急访问用户账号，可用于直接访问 ONTAP。这些凭据可以作为 Management API 服务器中的 Secret 获取。使用这些凭据后，需要轮替它们。

在设置过程中，系统会创建两种类型的 Secret：第 1 级和第 2 级。1 级为 storage-root-level1 and storage-root-level1-backup。2 级为 storage-root-level2 and storage-root-level2-backup。2 级密钥需要存储在保险箱中，每个级别都有两个密钥，即正常密钥和备用密钥。虽然软件可以同时处理常规密钥和备份密钥的删除，但我们建议一次只轮换其中一个合作伙伴密钥，以增加一层安全性。

虽然 1 级 Secret 会在 90 天后自动轮替，但 2 级 Secret 不会。如果使用任何类型的 Secret，都必须按照以下流程手动轮换。

前提条件

  • 所需访问权限：管理 API 服务器

验证

  1. 您可以通过检查密钥是否仍标记为待删除来验证密钥轮替。如果不是，则表示密文已轮替。按照以下说明中的第 1 步进行检查。

  2. 如果密钥是 2 级密钥，请将其复制到实体介质上，然后存放在保险箱中。然后，应使用注解 "disk.gdc.goog/persisted" 将该 Secret 标记为持久。

     kubectl annotate secrets
 <secret_name> -n gpc-system disk.gdc.goog/persisted=''

如果在验证期间发现任何错误，请按照以下说明手动轮换密钥。

说明

  1. 检查 Secret 是否已标记为待删除：

    1. 运行以下命令：

      kubectl get secret <secret_name> -n gpc-system -o yaml

    2. 如果响应中存在 deletionTimestamp 字段（如本例所示），则表示相应 Secret 已标记为待删除。否则，则不是。

      apiVersion: v1
data:
  password: KFZbQTJdYjIwSUtVVV1aNytJJVM=
  username: cm9vdC1sdmwy
immutable: true
kind: Secret
metadata:
  annotations:
    cluster-name: aa-aa-stge01
  creationTimestamp: "2022-12-21T05:03:02Z"
  deletionGracePeriodSeconds: 0
  deletionTimestamp: "2022-12-21T14:42:13Z"
  finalizers:
  - ontap.storage.private.gdc.goog/breakglass-finalizer
  labels:
    breakglass-secret: "true"
  name: storage-root-level2
  namespace: gpc-system
  resourceVersion: "591897"
  uid: 6f331f8a-bf48-4d59-9725-6c99c5e766f7
type: Opaque

  2. 使用密钥访问 ONTAP 后，轮替密钥：

    1. 检查合作伙伴凭据是否存在且未被标记为需要删除。 如果该应用被标记为待删除，请勿继续操作，并日后返回到这些步骤。

    2. 如果正在轮换 2 级密钥，则必须通过添加 disk.gdc.goog/persisted 注解来标记合作伙伴密钥为持久密钥：

      kubectl annotate secrets
<secret_name> -n gpc-system disk.gdc.goog/persisted=''

    3. 使用以下命令从集群中删除 Secret：

      kubectl delete
secret <secret_name> -n gpc-system

    4. 此时，删除流程将开始（您可以通过检查相应 Secret 是否被标记为待删除来确认）。删除并重新生成密钥可能需要近一个小时的时间。

轮替存储管理员和 SVM 证书

这些证书是由 GDC 安装到 ONTAP 系统中的服务器证书。

存储管理员（也称为集群管理员）账号有一个证书。其名称以 ONTAP 系统的主机名为前缀，并具有尾随的唯一哈希值。它安装在集群管理员 vserver 中。GDC 在内部使用此证书执行管理任务。

此外，还为 ONTAP SVM 定义了多个服务器端证书。 这些证书可确保与 SVM 通信的客户端的真实性。

所有证书都可以使用相同的流程进行轮替。由于根管理员集群中存在根 CA 证书不匹配的情况，对于下表中列出的集群和 SVM 证书，轮替需要轮替相应列表中的所有证书。这意味着，如果需要轮换任何集群证书，则还必须轮换所有其他集群证书。SVM 证书也是如此。实现自动化证书管理后，此限制将得到解决。

前提条件

  • 对 ONTAP 集群或相关 SVM 的管理员访问权限
  • 对相应 Kubernetes 集群的 kubectl 访问权限
  • 重新安装客户端 CA 证书安装步骤中概述的客户端 CA 证书。

证书与 Kubernetes Secret 之间的映射

对于 ONTAP 中安装的每个证书，管理 API 服务器中都有一个包含证书详细信息的相应 Kubernetes Secret。GDC 会生成证书，而替换证书的过程非常简单：删除与给定证书对应的 Secret，系统会立即重新生成证书。然后，您可以手动将新证书安装到 ONTAP 中，以替换旧证书。

使用 kubectl get secrets -n <namespace> -s <secret> -o yaml 检查 Kubernetes 中的证书，并验证该证书是否与从 security certificate show -vserver <svm_name> 中看到的 ONTAP 中的详细信息相符。命名空间将始终为“gpc-system”，您可以参阅上表了解 Secret 名称。

您还可以通过检查以下内容来查看证书与 Secret 的映射：

kubectl get certificates -n <namespace>

相关集群证书

ONTAP 通用名称 Vserver K8S 证书名称 Kubernetes Secret 名称 说明
无 <hostname> <hostname>-admin-cert <hostname>-admin-cert-secret 集群管理员证书
无 <hostname> <hostname>-server-cert <hostname>-server-cert-secret 由 GDC 签发者签名的服务器证书用作 ONTAP 服务器证书
无 <hostname> <hostname>-read-only-cert <hostname>-read-only-cert-secret 只读监控访问权限

相关 SVM 证书

Vserver K8S 证书名称 Kubernetes Secret 名称 说明
root-admin root-admin-server-cert root-admin-server-cert-secret 由 GDC 颁发者签名的服务器证书用作 SVM 服务器证书
root-admin root-admin-s3-server-cert root-admin-s3-server-cert-secret 由 GDC 签发者签名的服务器证书用作 ONTAP S3 服务器证书
root-admin root-admin-client-cert root-admin-client-cert-secret SVM 管理员访问权限
root-admin root-admin-s3-identity-client-cert root-admin-s3-identity-client-cert-secret S3 身份访问权限

验证

Vserver 证书

在所有证书轮换完毕后，验证与轮换的服务器证书关联的每个集群的 Trident 后端是否仍成功连接。

  1. 执行以下操作：

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl get tridentbackendconfigs -n netapp-trident

    输出应如下所示：

    NAME                                   BACKEND NAME   BACKEND UUID                           PHASE   STATUS
netapp-trident-backend-tbc-ontap-san   iscsi-san      a46ce1c7-26da-42c9-b475-e5e37a0911f8   Bound   Success

  2. 验证 PHASE 为 Bound 且 Status 为 Success。

根管理员证书

为了测试管理员证书，我们可以创建一个新的测试 StorageVirtualMachine，并查看 GDC 是否能够正确协调它。相关步骤如下：

  1. 列出现有的 StorageVirtualMachine，然后选择一个进行克隆以作为测试。
  2. 提取其 Kubernetes 规范。
  3. 修改定义以更改名称并删除不必要的字段。
  4. 应用测试定义。
  5. 等待 StorageVirtualMachine 状态变为 Ready。
  6. 删除测试 StorageVirtualMachine。
  7. 从 ONTAP 中删除实际的 SVM。

示例

此示例使用 GDC NetApp 命名空间 gpc-system，并将 organization-root-user 临时克隆到名为 test-svm 的新 SVM。

  1. 列出 SVM：

    kubectl get storagevirtualmachines -n ngpc-system

    输出：

    NAME                      AGE
organization-root-admin   13d

  2. 提取规范：

    kubectl get storagevirtualmachines -n gpc-system -o yaml > svm.yaml

  3. 修改规范，使其类似于以下内容：

    apiVersion: system.gpc.gke.io/v1alpha1
kind: StorageVirtualMachine
metadata:
  labels:
    ontap.storage.gpc.gke.io/role: user
  name: test-svm
  namespace: netapp-alatl12-gpcstge02
spec:
  aggregates:
  - alatl12-gpcstge02-c1-aggr1
  - alatl12-gpcstge02-c2-aggr1
  clusterName: alatl12-gpcstge02
  iscsiTarget:
    port: a0a-4
    subnetName: root-svm-data
  nasServer:
    port: a0a-4
    subnetName: root-svm-data
  svmNetwork:
    port: e0M
    subnetName: Default

  4. 将其应用于集群：

    kubectl create -f svm.yaml

  5. 等待新 SVM 准备就绪。定期观察以下命令的输出：

    kubectl get storagevirtualmachines -n gpc-system test-svm

    成功标志：

      Conditions:
    Last Transition Time:  2022-03-30T21:30:27Z
    Message:
    Observed Generation:   1
    Reason:                SVMCreated
    Status:                True
    Type:                  Ready

    或 AnsibleJobSucceed。

  6. 删除 SVM 资源：

    kubectl delete storagevirtualmachines -n gpc-system test-svm

  7. 从 ONTAP 中完全删除。删除资源不会将其从 ONTAP 中移除。

    登录 NetApp 控制台并删除 SVM：

    alatl12-gpcstge02::> vserver delete test-svm

    输出：

    Warning: When Vserver "test-svm" is deleted,
        the following objects are automatically removed as well:
        LIFs: 7
        Routes: 2
        Admin-created login accounts: 2
        Do you want to continue? {y|n}: y
[Job 3633] Success

如果在验证期间发现任何错误，请按照以下说明手动轮换 ONTAP 证书。

说明

如果上述 ONTAP 证书名称不适用，则无需在 ONTAP 中轮换任何内容。检查 Kubernetes 中的证书和 Secret，然后删除该 Secret。

  1. 生成新证书，并参考上表获取 Secret 名称：

    kubectl get certificates -n <namespace>

    $ kubectl patch Certificates <cert_name> -n gpc-system \
 --type=merge -p "{\"spec\":{\"privateKey\": {\"rotationPolicy\": \"Always\"}}}"
$ kubectl delete secret -n <namespace> <secret_name>

  2. 查看给定虚拟服务器的已安装证书（对于在 ONTAP 中安装的证书，未标记为“不适用”）：

    cluster::> security certificate show -vserver <svm_name> -type server

  3. 检查 Kubernetes 中匹配的 Secret（请参阅上表）：

    kubectl get certificates -n <namespace>

  4. 如果对匹配结果满意，请通过删除 Secret 来生成新证书：

    kubectl delete secret -n <namespace> <secret_name>

  5. 重新检查密文，看看是否已重新生成新证书。 确认后，在 ONTAP 中创建新的服务器证书。仅针对带有“server-cert”后缀的上述证书执行以下步骤。

  6. 使用 kubectl 和其他工具直接提取新的 TLS 证书正文，并将其安装到 ONTAP 中：

    $ gdch_cert_details -n <namespace> -s <secret_name>

cluster::> security certificate install -vserver <svm_name> -type server

    第一个提示将是：

    Please enter Certificate: Press <Enter> when done

    您应在此处输入 tls.crt。如果 tls.crt 中有多个证书块，请输入第一个块，并将剩余的证书块保留为中间证书，以便在下一步中参考。

  7. 系统会提示：Please enter Private Key: Press <Enter> when done。 粘贴 tls.key 文件的内容，然后按 Enter 键。

    接下来，系统会提示：Do you want to continue entering root and/or intermediate certificates {y|n}:如果您的 tls.crt 文件仅包含一个证书，请输入 N 并按 Enter 键。否则，请输入 Y 并按 Enter 键。

    如果您输入了 Y：系统会提示您输入中间证书。从 tls.crt 文件中逐个粘贴，每次粘贴后按 Enter 键。最后，粘贴 ca.crt 文件中的根证书，然后按 Enter 键。

    如果您输入了 N：（在此提示中，无需针对证书采取进一步操作）

    然后，ONTAP 将返回一个序列号。请记录此编号，因为它表示新证书和 CA 的序列号。在后续步骤中，此序列号将称为 <new\_server\_serial> 和 <new\_ca>。如果您要配置 S3 服务器证书，请勿按照以下证书步骤操作。

  8. 查看虚拟服务器和集群的 SSL 配置的当前状态。请准备好服务器证书颁发 CA、服务器证书通用名称和服务器证书序列号，因为下文中会分别将它们称为 <old\_server\_common\_name>、<old\_ca> 和 <old\_server\_serial>：

    cluster::> security ssl show -vserver <vserver>

    此命令会返回 SSL 信息，其中包含旧服务器证书信息。您可以在修改 SSL 配置后参考此信息，以确保其已更新。

  9. 修改 SSL 配置：

    cluster::> security ssl modify -server-enabled -client-enabled true -vserver <svm_name> -serial <new_server_serial> -ca <new_ca>

  10. 查看虚拟服务器和集群的 SSL 配置的新状态。这应该具有现在已安装的服务器证书的更新序列号：

    cluster::> security ssl show -vserver <vserver>

  11. 验证上一步后，删除旧服务器证书：

    cluster::> security certificate delete -vserver <svm_name> -common-name <old_server_common_name> -ca <old_ca> -type server -serial <old_server_serial>

客户端 CA 证书

  1. 使用以下命令从 gpc-system 命名空间中的 trust-store-internal-only ConfigMap 中提取所有 CA 证书：

    kubectl get cm -n gpc-system trust-store-internal-only -o jsonpath='{.data.ca\.crt}'

  2. 对于在上一步中检索到的每个 CA 证书，请在 ONTAP 集群上执行以下命令：

    cluster::> security certificate install -vserver <svm_name> -type client-ca

    系统会提示您： Please enter Certificate: Press <Enter> when done. 粘贴在第 1 步中检索到的每个证书块，然后按 Enter 键。 针对每个 CA 证书重复执行此安装命令。

轮替 Harvest 证书

收获证书生成取决于 <hostname>-read-only-cert-secret。 请确保 <hostname>-read-only-cert-secret 已旋转，然后再继续。

  1. 查看 Harvest pod 的已安装证书：

    export KUBECONFIG= #path to root-admin kubeconfig

    cluster_name="$(kubectl get storagecluster -A -o jsonpath='{.items[0].metadata.name}')"
secret_name="$cluster_name"-read-only-cert-secret

    export TLS_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.crt}')"

    export TLS_KEY="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.key}')"

    export CA_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.ca\.crt}')"

  2. 修补 Harvest 凭据 Secret 以提供更新后的证书：

    $ kubectl patch secret \
-n gpc-system netapp-harvest-configuration-credential \
-p "{\"data\":{\"tls.crt\":\"${TLS_CRT:?}\",\"tls.key\":\"${TLS_KEY:?}\",\"ca.crt\":\"${CA_CRT:?}\"}}"

  3. 重启 Harvest 服务以加载更新后的配置：

    kubectl delete pod -n gpc-system -l 'app=harvest.netapp.io'

轮替文件系统证书

运行以下命令以重新生成 file-storage-webhooks-serving-cert 和 file-observability-backend-target-cert 证书

kubectl delete secret file-storage-webhooks-serving-cert -n file-system
kubectl delete secret file-observability-backend-target-cert -n file-system

重启 pod 以加载更新后的配置：

kubectl delete pod -n file-system -l 'app=file-observability-backend-controller'
kubectl delete pod file-storage-backend-controller -n file-system

轮替 Trident 和 ONTAP 证书

Trident 必须与 ONTAP 通信。这是使用之前定义的客户端证书 <svm\_name>-client-cert-secret> 通过 Trident 后端配置的。客户端证书轮换不是 Trident 的一部分，但 Trident 依赖于此证书的部分内容，因此需要更新。

说明

对于 CA 证书更新：

  1. 导出 KUBECONFIG 以指向相关 Trident 组件的特定集群的 kubeconfig。每个集群都将配置 Trident。

  2. 从 client-cert secret 中获取经过 base64 编码的 CA 证书，并将其存储为变量：

    ca_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.ca\.crt}')

  3. 修补 tridentBackendConfig 对象：

    kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"trustedCACertificate\":\"$ca_cert\"}}"

对于实际的客户端证书和密钥：

  1. 从 client-cert secret 中获取 base64 编码的 TLS 证书，并将其存储为变量：

    tls_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.crt}')

  2. 从 client-cert secret 中获取经过两次 base64 编码的 TLS 密钥，并将其存储为变量：

    tls_key=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.key}' | base64 -w 0)

  3. 使用私钥更新后端 Secret：

    kubectl patch secrets netapp-trident-backend-tbc-ontap -n netapp-trident --type=merge -p "{\"data\":{\"clientPrivateKey\": \"$tls_key\"}}"

  4. 使用 TLS 证书修补后端配置：

    kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"clientCertificate\":\"$tls_cert\"}}"

轮替 Trident 控制器证书

Trident 容器必须与 Trident Operator 通信。 此通信是通过 HTTPS 完成的，并且需要管理服务器和客户端证书。

验证

确认 DaemonSet 和部署（如适用）均处于健康状态。

如果在验证期间发现任何错误，请按照以下说明手动轮换服务器和客户端证书。

说明

服务器和客户端证书在 ONTAP 端都没有对应的证书。 这些数据严格包含在集群中。

  1. 删除与即将过期的证书对应的 Secret。

    kubectl delete secret -n netapp-trident <secret_name>

  2. 重启 netapp-trident-csi daemonset：

    kubectl rollout restart daemonset netapp-trident-csi -n netapp-trident

  3. 对于服务器证书轮替，您还需要重启 netapp-trident-csi 部署：

    kubectl rollout restart deployments netapp-trident-csi -n netapp-trident

Trident CA 证书

CA 证书用于为签署 Trident 服务器和客户端证书提供证书授权机构。

证书名称 命名空间 Secret 说明
netapp-trident-csi-cert netapp-trident netapp-trident-csi-cert Trident CA 证书

验证

您会看到密钥已重新生成。为了使客户端和服务器证书生效，您还可以在轮换此证书后，按照上述说明轮换 Trident 控制器证书。

如果在验证期间发现任何错误，请按照以下说明手动轮替 CA 证书。

说明

如需轮换此密钥，您只需从 Kubernetes 中删除相应 Secret：

kubectl delete secret -n netapp-trident <secret_name>

Trident CSI 节点和 SVM（数据）

这是一组 SVM 范围的 iSCSI CHAP 凭据，用于启用对数据平面进行块访问。此限制不适用于文件协议。

管理 API 服务器

命名空间 Secret 说明
gpc-system <组织>-<type>-svm-credential Trident 设置所需的 SVM 配置

组织管理员和 Management API 服务器

命名空间 Secret 说明
gpc-system <组织>-<type>-svm-credential Trident 设置所需的 SVM 配置
netapp-trident netapp-trident-backend-tbc-ontap 管理 Trident 后端所需的 Secret

验证

  1. 验证后端是否仍配置成功：

    #export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl get tridentBackendConfigs -n netapp-trident

  2. 验证后端状态是否为 Success。

如果在验证期间发现任何错误，请按照以下说明手动轮换密钥。

说明

为启动器密钥和目标启动器密钥生成一个长度为 16 且不含特殊字符的新随机字符串：

#export kubeconfig of Management API server
export KUBECONFIG= #path to root-admin kubeconfig

initiator_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

target_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

kubectl patch secrets -n gpc-system "$org-$type-svm-credential" --type=merge -p "{\"data\":{\"initiatorSecret\": \"$initiator_secret\", \"targetSecret\": \"$target_secret\"}}"

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl patch secrets -n netapp-trident netapp-trident-backend-tbc-ontap --type=merge -p "{\"data\":{\"chapInitiatorSecret\": \"$initiator_secret\", \"chapTargetInitiatorSecret\": \"$target_secret\"}}"

Trident AES 密钥

AES 密钥由 Trident 在内部使用，用于加密 iSCSI CHAP 凭据，以供 Trident 内部使用。它是一个随机字符序列，长度必须为 32 字节。

运行 Trident 的集群（可以是根/组织管理员/用户/系统集群）

命名空间 Secret 说明
netapp-trident netapp-trident-aes-key Trident 加密 iSCSI CHAP 凭据所需的 AES 密钥

验证

  1. 验证后端是否仍配置成功：

    #export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl get tridentBackendConfigs -n netapp-trident

  2. 验证后端状态是否为 Success。

  3. 尝试创建测试卷：

    1. 创建一个 YAML 文件，其中包含 PVC 信息：

      echo "
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard-rwo" > pvc.yaml

    2. 将其应用于 Kubernetes 集群：

      kubectl apply -f pvc.yaml

  4. 验证 CSI 日志中是否没有因 iSCSI 加密而导致的错误：

    kubectl logs deploy/netapp-trident-csi -n netapp-trident -c trident-main | grep "Error encrypting"

    如果没有错误，您将看不到返回的任何日志。

  5. 清理文件和 PVC：

    kubectl delete -f pvc.yaml
rm -f pvc.yaml

如果在验证期间发现任何错误，请按照以下说明手动轮替密钥。

说明

在轮替此密钥之前，请确保集群中没有包含 PV 的待处理 pod。如果有，请等待它们完全预配后再轮换密钥。

为 aesKey 生成一个长度为 32 且不含特殊字符的新随机字符串：

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

aes_key=$(head /dev/random | tr -dc A-Za-z0-9 | head -c32 | base64)

#save old key just in case of errors
old_key=$(kubectl get secrets -n netapp-trident "netapp-trident-aes-key" -o jsonpath='{.data.aesKey}')

kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$aes_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

回滚

  1. 如果出现错误，则回滚到上次使用的凭据：

    kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$old_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

  2. 重新完成验证步骤。