轮替对象存储凭据

Google Distributed Cloud (GDC) 经过网闸隔离的设备对象存储由 OTS (ONTAP Select) 提供。OTS 有自己的对象存储用户管理系统。每个 OTS 对象存储用户凭据都以 Secret 形式存储在集群中。

本文档介绍了轮替 OTS 对象存储用户凭据的步骤。在以下情况下轮替对象存储用户凭据：

  • 定期安排密钥轮替，以轮替所有用户密钥。
  • 降低密钥泄露风险。您应尽快轮换泄露的用户密钥。

准备工作

请完成以下步骤：

  1. 确认您符合笔记本电脑前提条件。
  2. 确保您可以登录到 OTS 集群并运行 vserver object-store-server CLI 命令。
  3. 确保您可以使用 kubectl 以管理员身份登录基础架构集群和管理集群。

翻译 UID

每个对象存储用户都有一个访问密钥和密钥，这些密钥以 Kubernetes Secret 的形式存储，并由 Kubernetes 工作负载用于访问后端对象存储。轮换用户密钥包括更新所有密钥。

您可以使用以下命令登录到三个节点之一，以获取对象存储用户的列表：

vserver object-store-server user show

输出是一份 UID 列表，应类似于：

[
    "root",
    "k8ssa_gpc-system_inventory-export-images",
    "k8ssa_gpc-system_inventory-export-hardware",
    "k8su_test-user@example.com"
]

用户分为三种类型：

对象存储用户
UID 用户类型 密钥名称 Secret 命名空间
root 系统管理员 objectstorage-tenant-bucket-controller-standard-system-s3-sa gpc-system
objectstorage-tenant-bucket-controller-standard-user-s3-sa
objectstorage-tenant-bucket-controller-nearline-user-s3-sa
k8ssa_&ltnamespace>_&ltsa> Kubernetes 服务账号 object-storage-key-std-sa-&ltencoded-sa> &ltnamespace>
k8su_&ltusername> Kubernetes 用户 object-storage-key-std-user-&ltencoded-username> object-storage-access-keys

root 用户有三个相同的密文，与数据中心的结构相对应，其中包含多个存储类别和租户类别。相比之下，设备版仅提供一个层级的对象存储。与根用户关联的所有三个密钥必须同时轮换。

用户标识 (UID)（不包括 root 用户）应遵循 k8ssa_<namespace>_<sa> 或 k8su_<username> 格式。获取 <encoded-sa> 或 <encoded-username>：

echo -n 'UID_SUFFIX' | shasum -a 256 | cut -d " " -f 1 | xxd -r -p | base32 | awk '{print tolower($0)}' | sed 's/=*$//g'

将 UID 中的 UID_SUFFIX 替换为 <sa>，即可得到 <encoded-sa>。

将 UID 中的 UID_SUFFIX 替换为 <username>，即可得到 <encoded-username>。

轮替用户密钥

  1. 登录 OTS 集群。

  2. 获取对象存储用户 UID 的列表。

    vserver object-store-server user show

    结果是一个 UID 列表。您可以在转换 UID 中找到相关示例。针对列表中的每个 UID 重复执行以下步骤。

  3. 获取目标用户的旧访问密钥和密钥。

    set -privilege advanced
vserver object-store-server user show -user UID

    将 UID 替换为目标用户 UID。

  4. 为对象存储中的目标用户生成新的访问密钥和密钥。 完成此步骤后，旧密钥和新密钥会共存，并且都可以用于访问。

    vserver object-store-server user regenerate-keys -vserver root-admin -user UID

  5. 使用新的访问密钥和密钥更新 Kubernetes Secret。您只需更新根基础架构集群或管理集群中的 Secret，该 Secret 就会根据需要传播到其他集群。

    kubectl --kubeconfig KUBECONFIG patch secret -n SECRET_NAMESPACE SECRET_NAME --type='json' -p='[{"op": "replace", "path": "/data/access-key-id", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}, {"op": "replace", "path": "/data/secret-access-key", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}]'

    替换以下内容：

    • KUBECONFIG：kubeconfig 的路径。API 服务器必须是 root 用户的控制平面 API 服务器；否则，必须是管理 API 服务器。
    • SECRET_NAME：用户的 Secret 名称，可从转换 UID 部分推导得出。如果用户有多个 Kubernetes Secret（即，root 用户），请将每个 Secret 名称替换为相应值，然后运行该命令。
    • SECRET_NAMESPACE：用户的 Secret 命名空间，可从转换 UID 部分推导得出。
    • ACCESS_KEY：在上一步中生成的新访问密钥。
    • SECRET_KEY：在上一步中生成的新密钥。

  6. 使用该密钥的工作负载必须实现为自动刷新。如果不是，您必须重启工作负载，才能反映出密钥的更改。

    例如，对于 root 用户，您需要在基础架构集群中重启以下工作负载：

    kubectl --kubeconfig KUBECONFIG rollout restart deployment obj-bucket-cm-backend-controller -n obj-system

验证

按照对象存储创建存储桶和上传和下载对象中的说明，创建新存储桶并使用 RBAC 授予访问权限。如果成功创建了存储桶，并且正文拥有访问该存储桶的必要权限，则对象存储密钥轮换完成。