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

管理Trident Protect 的授权和访问控制

贡献者 netapp-aruldeepa
PDF

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

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

请注意，默认情况下，任何用户都无法创建应用程序数据管理变更请求 (CR)。 `trident-protect`命名空间。您需要在应用程序命名空间中创建应用程序数据管理 CR（最佳实践是在与其关联的应用程序相同的命名空间中创建应用程序数据管理 CR）。

备注

只有管​​理员才能访问受Trident Protect 保护的自定义资源对象，其中包括：

  • AppVault：需要存储桶凭证数据

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

  • 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. 将集群角色绑定到工程服务帐户：

    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. 将集群角色绑定到营销服务帐户：

    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. 创建并应用角色 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. 创建并应用角色绑定 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 对象进行应用程序数据管理操作，并且不应该能够访问分配的命名空间之外的任何资源，或者创建他们无权访问的新资源。