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

管理Trident Protect 授權和存取控制

貢獻者 netapp-aruldeepa

Trident Protect 使用 Kubernetes 的角色為基礎的存取控制 (RBAC) 模型。預設情況下, Trident Protect 提供一個系統命名空間及其關聯的預設服務帳戶。如果您的組織擁有眾多使用者或特定的安全需求,則可以使用Trident Protect 的 RBAC 功能來更精細地控制對資源和命名空間的存取。

叢集管理員始終擁有對預設資源的存取權限。 `trident-protect`命名空間,並且可以存取所有其他命名空間中的資源。要控制對資源和應用程式的訪問,您需要建立額外的命名空間,並將資源和應用程式新增至這些命名空間。

請注意,預設情況下,任何使用者都無法建立應用程式資料管理變更請求 (CR)。 `trident-protect`命名空間。您需要在應用程式命名空間中建立應用程式資料管理 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. 將叢集角色綁定到工程服務帳戶:

    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 物件進行應用程式資料管理操作,並且不應該能夠存取指派的命名空間之外的任何資源,或建立他們無權存取的新資源。