Antrea での階層の管理

Antrea では、階層は階層的な方法でグループ化された特定のネットワークポリシーで構成されます。Antrea ネイティブの NetworkPolicy または ClusterNetworkPolicy カスタムリソース定義 (CRD) には、それが属する階層へのオプションの参照が含まれています。ネットワークトラフィックのフィルタリング中に、優先順位の高い階層（優先順位の値が低い）に関連付けられている Antrea NetworkPolicies が最初に適用されます。Antrea のさまざまなタイプの階層の詳細については、「Antrea Network Policy CRDs」を参照してください。

階層でのロールベースのアクセス設定の構成

階層へのロールベースのアクセスは、承認されたユーザーのみが Antrea ネイティブのポリシーの階層を参照できるように設計されています。これにより、クラスタ管理者は Antrea NetworkPolicies を優先度の高い階層に接続でき、通常のユーザーが Antrea NetworkPolicies を階層に接続できなくなります。この機能は、クラスタ管理者がクラスタ内にセキュリティポリシーを適用し、通常のユーザーがオーバーライドできないようにするのに役立ちます。

階層を編集するための権限をユーザーに提供する

Antrea は、固定の優先順位を持つ 6 つの階層を提供します。デフォルトでは、Kubernetes 管理者のみが Antrea でカスタム階層を作成できます。新しい階層を作成し、階層の優先順位を編集する権限をユーザーに付与するには、ワークロードクラスタコンテキストで ClusterRole および ClusterRoleBinding 設定を構成します。

ワークロードクラスタコンテキストに切り替えます。
```
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
```

次の例に示すように、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

定義を適用します。

kubectl apply -f ClusterRoleBinding.yaml

Antrea ネットワークポリシーの階層を参照する権限をユーザーに提供する

デフォルトでは、任意のユーザーが任意の階層に Antrea ネットワークポリシーを適用できます。Antrea ネットワークポリシーの階層を参照する権限を一連のユーザーに提供し、他のすべてのユーザーをブロックするには、TierEntitlement CRD を作成し、TierEntitlementBinding CRD を介して許可されたユーザーに資格を割り当てます。

ワークロードクラスタコンテキストに切り替えます。
```
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
```
次の例に示すように、TierEntitlement CRD YAML ファイルを作成します。
```
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
  name: emergency-edit
spec:
  tiers:          ["emergency"]
  permission:     "edit"
```
注
ここで有効な権限は Edit のみです。これにより、資格のあるユーザーは、リストされた階層に属する Antrea ネイティブポリシーを作成、削除、更新、およびパッチ適用できます。
CRD を適用します。
```
kubectl apply -f TierEntitlement.yaml
```

次の例に示すように、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 で指定できるサポート対象のユーザーは、User、Group、および ServiceAccount です。詳細については、「Using RBAC Authorization」を参照してください。

CRD を適用します。

kubectl apply -f TierEntitlementBinding.yaml

上記の 2 つのサンプル YAML ファイルでは、emergency 階層は emergency-edit 階層資格によって制御されます。emergency-edit 資格が割り当てられているユーザーには特定の権限が付与されますが、他のユーザー（normalUser）は特定のアクションを実行できません。例：

securityops ユーザーは、仕様内に emergency 階層への参照を持つ Antrea ClusterNetworkPolicy (ACNP) または Antrea NetworkPolicy (ANP) を作成できます。
securityops ユーザーは、既存の ACNP または ANP を更新またはパッチ適用し、仕様内の emergency 階層への参照を追加できます（securityops ユーザーに既存の階層への参照を編集する権限がある場合）。
securityops ユーザーは、既存の ACNP または ANP を更新またはパッチ適用し、emergency 階層への参照をその仕様から削除できます。
securityops ユーザーは、仕様内に emergency 階層への参照を持つ既存の ACNP または ANP を削除できます。
securityops ユーザーは、仕様内に emergency 階層への参照を持つ既存の ACNP または ANP の詳細を取得できます。
仕様内に emergency 階層への参照を持つ ACNP または ANP を作成しようとする normalUser は、権限が拒否されます。
仕様内に emergency 階層への参照を持つ ACNP または ANP を削除しようとする normalUser は、権限が拒否されます。
仕様内に emergency 階層への参照を持つ ACNP または ANP を更新またはパッチ適用しようとする normalUser は、権限を拒否されます。

注
Antrea のクラスタネットワークポリシーを設定する方法については、「Antrea のクラスタネットワークポリシーの設定」を参照してください。

Antrea での階層の管理

階層でのロールベースのアクセス設定の構成

階層を編集するための権限をユーザーに提供する

Antrea ネットワーク ポリシーの階層を参照する権限をユーザーに提供する

Antrea ネットワークポリシーの階層を参照する権限をユーザーに提供する