Gérer les niveaux dans Antrea

Dans Antrea, un niveau se compose de certaines stratégies réseau regroupées de manière hiérarchique. Une définition de ressource personnalisée NetworkPolicy native Antrea ou ClusterNetworkPolicy inclut une référence facultative au niveau auquel elle appartient. Lors du filtrage du trafic réseau, les stratégies réseau Antrea associées à des niveaux dans un ordre supérieur (qui ont une valeur de priorité numérique faible) sont appliquées en premier. Pour plus d'informations sur les différents types de niveaux dans Antrea, reportez-vous à la section Définition de ressource personnalisée de stratégie réseau Antrea.

Configurer les paramètres d’accès basé sur les rôles sur les niveaux

L'accès basé sur les rôles à un niveau est conçu pour s'assurer que seuls les utilisateurs autorisés peuvent référencer un niveau dans les stratégies natives Antrea. Il permet à un administrateur de cluster d'attacher les stratégies réseau Antrea à un niveau de haute priorité et empêche un utilisateur normal d'attacher les stratégies réseau Antrea au niveau. Cette fonctionnalité permet à l'administrateur de cluster d'appliquer des stratégies de sécurité dans un cluster, qui ne peut pas être remplacé par un utilisateur normal.

Autoriser un utilisateur à modifier un niveau

Antrea fournit six niveaux avec des priorités statiques. Par défaut, seuls les administrateurs Kubernetes peuvent créer des niveaux personnalisés dans Antrea. Pour fournir aux utilisateurs des autorisations leur permettant de créer des niveaux et de modifier les priorités des niveaux, configurez les paramètres ClusterRole et ClusterRoleBinding dans le contexte du cluster de charge de travail.

Basculez vers le contexte du cluster de charge de travail :
```
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
```

Créez un fichier YAML ClusterRoleBinding, comme indiqué dans l'exemple suivant (l'utilisateur securityops a la possibilité de lire, créer, supprimer et mettre à jour les ressources de niveau) :

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

Appliquez les définitions :

kubectl apply -f ClusterRoleBinding.yaml

Fournir des autorisations à un utilisateur pour référencer un niveau dans une stratégie réseau Antrea

Par défaut, n'importe quel utilisateur peut attacher une stratégie réseau Antrea à n'importe quel niveau. Pour fournir des autorisations à un ensemble d'utilisateurs pour référencer un niveau dans une stratégie réseau Antrea et bloquer tous les autres utilisateurs, créez une définition de ressource personnalisée TierEntitlement et attribuez le droit aux utilisateurs autorisés via une définition de ressource personnalisée TierEntitlementBinding.

Basculez vers le contexte du cluster de charge de travail :
```
kubectl config use-context *WORKLOAD-CLUSTER-CONTEXT*
```
Créez un fichier YAML TierEntitlement CRD, comme indiqué dans l'exemple suivant :
```
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
  name: emergency-edit
spec:
  tiers:          ["emergency"]
  permission:     "edit"
```
Remarque
Edit est la seule autorisation valide ici. Elle permet aux utilisateurs autorisés de créer, supprimer, mettre à jour et corriger les stratégies natives Antrea qui appartiennent aux niveaux répertoriés.
Appliquez le CRD :
```
kubectl apply -f TierEntitlement.yaml
```

Créez un fichier YAML TierEntitlementBinding CRD pour associer le droit d'accès aux utilisateurs, comme indiqué dans cet exemple :

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

Dans cet exemple, le droit de niveau emergency-edit a été attribué aux utilisateurs spécifiés sous le champ subjects. Les utilisateurs pris en charge qui peuvent être spécifiés sous subjects sont Utilisateur, Groupe et ServiceAccount. Pour plus d'informations, reportez-vous à la section Utilisation de l'autorisation RBAC.

Appliquez le CRD :

kubectl apply -f TierEntitlementBinding.yaml

Dans les deux exemples de fichiers YAML ci-dessus, le niveau emergency est contrôlé par le droit de niveau emergency-edit. Certaines autorisations sont accordées aux utilisateurs auxquels le droit d'emergency-edit est attribué, tandis que d'autres utilisateurs (appelés normalUser) ne peuvent pas effectuer certaines actions. Par exemple :

L'utilisateur securityops peut créer une stratégie Antrea ClusterNetworkPolicy (ACNP) ou une stratégie réseau Antrea (ANP), qui fait référence au niveau emergency dans sa spécification.
L'utilisateur securityops peut mettre à jour ou corriger une stratégie ACNP ou ANP existante, et ajouter une référence au niveau emergency dans sa spécification (si l'utilisateur securityops a l'autorisation de modifier une référence au niveau existant).
L'utilisateur securityops peut mettre à jour ou corriger une stratégie ACNP ou ANP existante, et supprimer la référence au niveau emergency de sa spécification.
L'utilisateur securityops peut supprimer une stratégie ACNP ou ANP existante, qui dispose d'une référence au niveau emergency dans sa spécification.
L'utilisateur securityops peut obtenir les détails d'une stratégie ACNP ou ANP existante, qui dispose d'une référence au niveau emergency dans sa spécification.
L'autorisation normalUser, qui tente de créer une stratégie ACNP ou ANP, qui fait référence au niveau emergency dans sa spécification, se voit refuser l'autorisation.
L'autorisation est refusée au normalUser qui tente de supprimer une stratégie ACNP ou ANP, qui fait référence au niveau emergency dans sa spécification.
L'autorisation est refusée au normalUser, qui tente de mettre à jour ou de corriger une stratégie ACNP ou ANP qui fait référence au niveau emergency dans sa spécification.

Remarque
Pour savoir comment définir des stratégies réseau de cluster pour Antrea, reportez-vous à la section Définir des stratégies réseau de cluster pour Antrea.