管理 Antrea 中的階層

在 Antrea 中，階層是由某些網路原則組成，且這些原則依階層方式分組。Antrea 原生 NetworkPolicy 或 ClusterNetworkPolicy 自訂資源定義 (CRD) 中包含一個對其所屬階層的選用參考。在篩選網路流量期間，與較高順序階層 (其數字優先順序值較低) 相關聯的 Antrea NetworkPolicy 會先強制執行。如需 Antrea 中各種類型的階層的詳細資訊，請參閱 Antrea 網路原則 CRD。

設定階層上的角色型存取設定

「對階層進行角色型存取」旨在確保只有獲授權的使用者，才可以在 Antrea 原生原則中參考階層。它可讓叢集管理員將 Antrea NetworkPolicy 連結至高優先順序階層，並阻止一般使用者將 Antrea NetworkPolicy 連結至階層。此功能有助於叢集管理員強制執行安全原則，而讓一般使用者無法覆寫。

提供權限給使用者編輯階層

Antrea 提供六個具有靜態優先順序的階層。依預設，只有 Kubernetes 管理員可以在 Antrea 中建立自訂階層。若要提供權限給使用者，使其有權建立新階層和編輯階層的優先順序，請在工作負載叢集內容中，設定 ClusterRole 和 ClusterRoleBinding 設定。

1. 切換為工作負載叢集內容：

   kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
   

2. 建立 ClusterRoleBinding YAML 檔案，如以下範例所示 (使 securityops 使用者能夠讀取、建立、刪除及更新階層資源)：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: tier-edit
   rules:
   - apiGroups: ["crd.antrea.io"]
     resources: ["tiers"]
     verbs: ["get", "list", "create", "patch", "update", "delete"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: tier-bind
   subjects:
   - kind: User
     name: securityops # Name is case sensitive
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: tier-edit
     apiGroup: rbac.authorization.k8s.io
   

3. 套用定義：

   kubectl apply -f ClusterRoleBinding.yaml
   

提供權限給使用者，使其有權在 Antrea 網路原則中參考階層

依預設，任何使用者都可以將 Antrea 網路原則連結至任何階層。若要提供權限給一組使用者，使其有權在 Antrea 網路原則中參考階層，並封鎖所有其他使用者，請建立 TierEntitlement CRD，並透過 TierEntitlementBinding CRD，將權利指派給允許的使用者。

1. 切換為工作負載叢集內容：

   kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
   

2. 建立 TierEntitlement CRD YAML 檔案，如以下範例所示：

   apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
   kind: TierEntitlement
   metadata:
     name: emergency-edit
   spec:
     tiers:          ["emergency"]
     permission:     "edit"
   

   附註

   Edit 是此處唯一有效的權限。它允許具有權利的使用者建立、刪除、更新及修補屬於所列階層的 Antrea 原生原則。

3. 套用 CRD：

   kubectl apply -f TierEntitlement.yaml
   

4. 建立 TierEntitlementBinding CRD YAML 檔案，將權利關聯至使用者，如以下範例所示：

   apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
   kind: TierEntitlementBinding
   metadata:
     name: emergency-sec-bind
   spec:
     subjects:                                       
     - kind:           User
       name:           securityops
       apiGroup:       rbac.authorization.k8s.io
     - kind:           Group
       name:           security-admins
       apiGroup:       rbac.authorization.k8s.io
     - kind:           ServiceAccount
       name:           network-admins
       namespace:      kube-system
     tierEntitlement:    emergency-edit     
   

   在此範例中，已將 emergency-edit 階層權利指派給 subjects 欄位之下所指定的使用者。可以指定於 subjects 下的支援使用者為使用者、群組和服務帳戶。如需詳細資訊，請參閱使用 RBAC 授權。

5. 套用 CRD：

   kubectl apply -f TierEntitlementBinding.yaml
   

在上面的兩個範例 YAML 檔案中，emergency 階層受 emergency-edit 階層權利控制。獲指派 emergency-edit 權利的使用者被授與某些權限，而其他使用者 (稱為 normalUser) 則無法執行某些動作。例如：

• securityops 使用者可以建立 Antrea ClusterNetworkPolicy (ACNP) 或 Antrea NetworkPolicy (ANP)，其規格中有一個對 emergency 階層的參考。
• securityops 使用者可以更新或修補現有的 ACNP 或 ANP，並在其規格中新增對 emergency 階層的參考 (如果 securityops 使用者有權編輯對現有階層的參考)。
• securityops 使用者可以更新或修補現有的 ACNP 或 ANP，並從其規格中移除對 emergency 階層的參考。
• securityops 使用者可以刪除其規格中參考了 emergency 階層的現有 ACNP 或 ANP。
• securityops 使用者可以針對其規格中參考了 emergency 階層的現有 ACNP 或 ANP，取得其詳細資料。
• 如果 normalUser 嘗試建立一個在其規格中參考了 emergency 階層的 ACNP 或 ANP，則其權限會被拒絕。
• 如果 normalUser 嘗試刪除一個在其規格中參考了 emergency 階層的 ACNP 或 ANP，則其權限會被拒絕。
• 如果 normalUser 嘗試更新或修補一個在其規格中參考了 emergency 階層的 ACNP 或 ANP，則其權限會被拒絕。

附註

若要瞭解如何為 Antrea 設定叢集網路原則，請參閱為 Antrea 設定叢集網路原則。