Skip to main content
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

管理 Trident Protect 授权和访问控制

PDF

Trident Protect 使用基于角色的访问控制 (RBAC) 的 Kubernetes 模型。默认情况下，Trident Protect 提供单个系统命名空间及其关联的默认服务帐户。如果您的组织有很多用户或特定的安全需求，您可以使用 Trident Protect 的 RBAC 功能对资源和命名空间的访问进行更精细的控制。

集群管理员始终可以访问默认 `trident-protect`命名空间中的资源，也可以访问所有其他命名空间中的资源。要控制对资源和应用程序的访问，需要创建其他命名空间，并向这些命名空间中添加资源和应用程序。

请注意，没有用户可以在默认 `trident-protect`命名空间中创建应用程序数据管理 CR。您需要在应用程序命名空间中创建应用程序数据管理 CR（作为最佳实践，在与其关联的应用程序相同的命名空间中创建应用程序数据管理 CR）。

备注

只有管理员应有权访问特权 Trident Protect 自定义资源对象，其中包括：

  • AppVault：需要存储区凭据数据

  • AutoSupportBundle：收集指标、日志和其他敏感 Trident Protect 数据

  • AutoSupportBundleSchedule：管理日志收集计划

作为最佳做法，请使用 RBAC 来限制管理员对特权对象的访问。

有关 RBAC 如何规范对资源和命名空间的访问的详细信息，请参见 "Kubernetes RBAC 文档"。

有关服务帐户的详细信息，请参阅 "Kubernetes 服务帐户文档"。

示例：管理两组用户的访问权限

例如，一个组织有一个集群管理员、一组工程用户和一组营销用户。集群管理员将完成以下任务，以创建一个环境，其中工程组和营销组各自只能访问分配给各自命名空间的资源。

步骤 1：创建一个命名空间以包含每个组的资源

创建命名空间可以在逻辑上分离资源，并更好地控制谁有权访问这些资源。

步骤

  1. 为工程组创建命名空间：

    kubectl create ns engineering-ns

  2. 为营销组创建命名空间：

    kubectl create ns marketing-ns

步骤 2：创建新的服务帐户以与每个命名空间中的资源进行交互

您创建的每个新命名空间都带有一个默认服务帐户，但您应该为每个用户组创建一个服务帐户，以便将来在必要时可以在组之间进一步划分权限。

步骤

  1. 为工程组创建服务帐户：

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: eng-user
  namespace: engineering-ns

  2. 为营销组创建服务帐户：

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: mkt-user
  namespace: marketing-ns

步骤 3：为每个新服务帐户创建密码

服务帐户密钥用于对服务帐户进行身份验证，如果遭到泄露，可以轻松删除并重新创建。

步骤

  1. 为工程服务帐户创建密钥：

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: eng-user
  name: eng-user-secret
  namespace: engineering-ns
type: kubernetes.io/service-account-token

  2. 为营销服务帐户创建密钥：

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: mkt-user
  name: mkt-user-secret
  namespace: marketing-ns
type: kubernetes.io/service-account-token

步骤 4：创建一个 RoleBinding 对象以将此 ClusterRole 对象绑定到每个新服务帐户

当你安装 Trident Protect 时，会创建一个默认的 ClusterRole 对象。你可以通过创建并应用一个 RoleBinding 对象，将此 ClusterRole 绑定到服务账户。

步骤

  1. 将 ClusterRole 绑定到工程服务帐户：

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: engineering-ns-tenant-rolebinding
  namespace: engineering-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

  2. 将 ClusterRole 绑定到营销服务帐户：

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: marketing-ns-tenant-rolebinding
  namespace: marketing-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: mkt-user
  namespace: marketing-ns

第 5 步：测试权限

测试权限是否正确。

步骤

  1. 确认工程用户可以访问工程资源：

    kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n engineering-ns

  2. 确认工程用户无法访问营销资源：

    kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n marketing-ns

第 6 步：授予 AppVault 对象访问权限

要执行备份和快照等数据管理任务，集群管理员需要将 AppVault 对象的访问权限授予单个用户。

步骤

  1. 创建并应用 AppVault 和密码组合 YAML 文件，该文件授予用户对 AppVault 的访问权限。例如，以下 CR 授予用户对 AppVault 的访问权限 eng-user：

    apiVersion: v1
data:
  accessKeyID: <ID_value>
  secretAccessKey: <key_value>
kind: Secret
metadata:
  name: appvault-for-eng-user-only-secret
  namespace: trident-protect
type: Opaque
---
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: appvault-for-eng-user-only
  namespace: trident-protect # Trident Protect system namespace
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: testbucket
      endpoint: 192.168.0.1:30000
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-for-eng-user-only-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-for-eng-user-only-secret
  providerType: GenericS3

  2. 创建并应用 Role CR，使集群管理员能够授予对命名空间中特定资源的访问权限。例如：

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: eng-user-appvault-reader
  namespace: trident-protect
rules:
- apiGroups:
  - protect.trident.netapp.io
  resourceNames:
  - appvault-for-enguser-only
  resources:
  - appvaults
  verbs:
  - get

  3. 创建并应用 RoleBinding CR 以将权限绑定到用户 eng-user。例如：

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: eng-user-read-appvault-binding
  namespace: trident-protect
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: eng-user-appvault-reader
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

  4. 验证权限是否正确。

    1. 尝试检索所有命名空间的 AppVault 对象信息：

      kubectl get appvaults -n trident-protect --as=system:serviceaccount:engineering-ns:eng-user

      此时将显示与以下内容类似的输出：

      Error from server (Forbidden): appvaults.protect.trident.netapp.io is forbidden: User "system:serviceaccount:engineering-ns:eng-user" cannot list resource "appvaults" in API group "protect.trident.netapp.io" in the namespace "trident-protect"

    2. 测试用户是否可以获取他们现在有权访问的 AppVault 信息：

      kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get appvaults.protect.trident.netapp.io/appvault-for-eng-user-only -n trident-protect

      此时将显示与以下内容类似的输出：

    yes
结果

您授予 AppVault 权限的用户应能够使用授权的 AppVault 对象进行应用程序数据管理操作，并且不应能够访问分配的命名空间之外的任何资源或创建他们无权访问的新资源。