Skip to main content
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

管理授權與存取控制

貢獻者

Trident Protect 採用 Kubernetes 角色型存取控制( RBAC )模式。根據預設, Trident Protect 提供單一系統命名空間及其相關的預設服務帳戶。如果組織有許多使用者或特定的安全需求,您可以使用 Trident Protect 的 RBAC 功能,更精細地控制對資源和命名空間的存取。

叢集管理員一律可以存取預設命名空間中的資源 trident-protect,也可以存取所有其他命名空間中的資源。若要控制對資源和應用程式的存取,您需要建立額外的命名空間,並將資源和應用程式新增至這些命名空間。

請注意,沒有使用者可以在預設命名空間中建立應用程式資料管理 CRS trident-protect 。您需要在應用程式命名空間中建立應用程式資料管理 CRS (最佳做法是在與其相關應用程式相同的命名空間中建立應用程式資料管理 CRS )。

註

只有系統管理員才能存取授權的 Trident 保護自訂資源物件,包括:

  • * AppVault* :需要儲存庫認證資料

  • * AutoSupportBundle * :收集指標,記錄及其他敏感的 Trident Protect 資料

  • * AutoSupportBundleSchedule* :管理記錄收集排程

最佳做法是使用 RBAC 來限制系統管理員存取權限物件。

如需 RBAC 如何規範資源和命名空間存取的詳細資訊,請參閱 "Kubernetes RBAC 文件"

如需服務帳戶的相關資訊,請參閱 "Kubernetes 服務帳戶文件"

範例:管理兩組使用者的存取權

例如,組織有叢集管理員,一組工程設計使用者,以及一組行銷使用者。叢集管理員將完成下列工作,以建立一個環境,其中工程群組和行銷群組各自只能存取指派給各自命名空間的資源。

步驟 1 :建立命名空間以包含每個群組的資源

建立命名空間可讓您以邏輯方式分隔資源,並更有效地控制誰有權存取這些資源。

步驟
  1. 為工程群組建立命名空間:

    kubectl create ns engineering-ns
  2. 為行銷群組建立命名空間:

    kubectl create ns marketing-ns

步驟 2 :建立新的服務帳戶,與每個命名空間中的資源互動

您所建立的每個新命名空間都有預設服務帳戶,但您應該為每個使用者群組建立服務帳戶,以便日後在必要時在群組之間進一步分割 Privileges 。

步驟
  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 物件。您可以建立並套用角色繫結物件,將此 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. 建立並套用角色 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 物件來執行應用程式資料管理作業,而且不應能夠存取指派命名空間以外的任何資源,或建立他們無法存取的新資源。