Ajout d'attributs de sécurité aux ressources liées au cluster et application de stratégies ZPR

Découvrez comment ajouter des attributs de sécurité ZPR aux ressources liées au cluster et comment appliquer des stratégies Zero Trust Packet Routing (ZPR) avec Kubernetes Engine (OKE).

L'utilisation de Zero Trust Packet Routing (ZPR) avec Kubernetes Engine vous permet d'implémenter un contrôle d'accès de niveau fin et avec le moins de privilèges sur les interactions entre les ressources liées au cluster et d'autres ressources OCI. ZPR est particulièrement utile dans les environnements où les données sensibles ou les opérations critiques sont distribuées entre plusieurs ressources OCI, et où une séparation stricte et un contrôle de l'accès aux ressources sont requis. L'utilisation de ZPR vous aide à atténuer les risques associés aux accès non autorisés et à garantir que seuls les flux de trafic explicitement autorisés entre les ressources protégées prennent en charge les besoins de conformité et les stratégies de sécurité de l'organisation.

Vous pouvez utiliser Zero Trust Packet Routing (ZPR) ainsi que des groupes de sécurité réseau et des listes de sécurité pour gérer l'accès réseau aux ressources OCI. Pour ce faire, définissez des stratégies ZPR qui régissent la façon dont les ressources communiquent les unes avec les autres, puis ajoutez des attributs de sécurité ZPR à ces ressources. Pour plus d'informations, reportez-vous à la section Zero Trust Packet Routing.

L'utilisation de ZPR est facultative. Vous pouvez continuer à utiliser OKE sans affecter d'attributs de sécurité ZPR. Les contrôles de sécurité réseau existants, tels que les groupes de sécurité réseau, les listes de sécurité et les stratégies réseau Kubernetes, continuent à fonctionner avec OKE. ZPR ajoute une autre couche d'application réseau pour les ressources qui ont des attributs de sécurité et des stratégies ZPR correspondantes.

Attention

Si une adresse possède un attribut de sécurité Zero Trust Packet Routing (ZPR), le trafic vers l'adresse doit satisfaire aux stratégies ZPR, ainsi qu'à toutes les règles de groupe de sécurité réseau et de liste de sécurité. Par exemple, si vous utilisez déjà des groupes de sécurité réseau et que vous ajoutez un attribut de sécurité à une adresse sans créer également de stratégie ZPR autorisant le trafic requis, le trafic vers l'adresse est bloqué. Ensuite, une stratégie ZPR doit autoriser explicitement le trafic vers l'adresse.

Lors de la migration de clusters existants pour utiliser ZPR, créez et testez les stratégies ZPR requises avant de supprimer les règles de groupe de sécurité réseau ou de liste de sécurité existantes. Par défaut, les ressources avec des attributs de sécurité ZPR ne peuvent pas communiquer avec des ressources qui n'ont pas d'attributs de sécurité ZPR, sauf si une stratégie ZPR autorise explicitement ce trafic.

Pour utiliser ZPR avec Kubernetes Engine, vous ajoutez des attributs de sécurité aux ressources de cluster prises en charge dans une location dans laquelle ZPR est disponible. Une fois l'attribut de sécurité ajouté à une ressource, celle-ci ne peut accéder à d'autres ressources OCI que si l'accès est autorisé par une stratégie ZPR.

Les attributs de sécurité sont définis dans un espace de noms d'attribut de sécurité. Pour ajouter un attribut de sécurité à une ressource liée au cluster, une stratégie IAM doit accorder au groupe auquel vous appartenez l'accès à l'espace de noms dans lequel l'attribut de sécurité est défini. Pour plus d'informations, reportez-vous à Stratégies IAM requises.

Pour qu'une ressource liée au cluster avec des attributs de sécurité ZPR puisse accéder à une autre ressource, une stratégie ZPR appropriée doit exister. Si des attributs de sécurité ont également été ajoutés à l'autre ressource, créez une stratégie ZPR qui autorise l'accès aux adresses avec ces attributs de sécurité. Si l'autre ressource n'a pas d'attributs de sécurité ZPR ou ne peut pas avoir d'attributs de sécurité ZPR car le type de ressource n'est pas pris en charge par ZPR, créez une stratégie ZPR qui autorise l'accès à l'aide d'une adresse IP, d'un bloc CIDR ou d'une expression d'adresse de service pris en charge. Sans stratégie ZPR appropriée, l'accès est bloqué au niveau du réseau et des erreurs de connexion peuvent se produire. Pour plus d'informations, reportez-vous à Stratégies ZPR requises.

Notez les points suivants :

Pour afficher les ressources liées au cluster auxquelles des attributs de sécurité ont été ajoutés, utilisez la page Console ZPR (reportez-vous à la section Liste des ressources protégées dans la documentation ZPR).
Après avoir ajouté des attributs de sécurité à une ressource liée au cluster, vous pouvez utiliser des outils tels que l'analyseur de chemin réseau, le cas échéant, pour aider à déboguer les problèmes de connectivité réseau.
Si un attribut de sécurité est supprimé de l'espace de noms de l'attribut de sécurité (à l'aide de la console, de l'interface de ligne de commande ou de l'API ZPR) après avoir été ajouté à une ressource liée au cluster, enlevez l'attribut de sécurité supprimé de la ressource. Sinon, les stratégies ZPR qui référencent l'attribut de sécurité supprimé risquent de ne plus autoriser le trafic attendu.

La façon dont vous ajoutez ou supprimez des attributs de sécurité dans ou à partir des ressources liées au cluster prises en charge dépend de la ressource, comme indiqué dans le tableau suivant :


Ressource	Où appliquer les attributs de sécurité	Comment appliquer des attributs de sécurité	Résultat
Adresse d'API Kubernetes du cluster	Console, CLI, API	Définir la propriété d'attribut de sécurité d'adresse du cluster (`securityAttributes` dans l'API)	Les attributs de sécurité s'appliquent uniquement à l'adresse d'API Kubernetes du cluster. Ces attributs ne s'appliquent pas aux noeuds de processus actif, aux pods, aux équilibreurs de charge ou aux autres ressources de cluster. Reportez-vous à Ajout d'attributs de sécurité à l'adresse d'API Kubernetes d'un cluster.
Cartes d'interface réseau virtuelles principales des instances de calcul de noeud géré	Console, CLI, API	Définition de la propriété Attribut de sécurité de carte d'interface réseau virtuelle de la carte d'interface réseau virtuelle principale du pool de noeuds (`securityAttributes` dans l'API)	Les attributs de sécurité s'appliquent aux cartes d'interface réseau virtuelles principales des instances de calcul qui soutiennent les noeuds gérés dans le pool de noeuds. Ces attributs sont utilisés pour le trafic au niveau du noeud, tel que le trafic de kubelet, le trafic d'agent Oracle Cloud et le trafic des pods qui utilisent le réseau hôte. Reportez-vous à Ajout d'attributs de sécurité aux cartes d'interface réseau virtuelles principales des noeuds gérés.
Cartes d'interface réseau virtuelles secondaires des instances de calcul de noeud géré	Console, CLI, API	Définition de la propriété Attribut de sécurité de carte d'interface réseau virtuelle des cartes d'interface réseau virtuelles secondaires du pool de noeuds (`securityAttributes` dans l'API)	Les attributs de sécurité s'appliquent aux cartes d'interface réseau virtuelles secondaires des instances de calcul qui soutiennent les noeuds gérés dans le pool de noeuds. Si vous définissez plusieurs cartes d'interface réseau virtuelles secondaires pour un pool de noeuds gérés, toutes les cartes d'interface réseau virtuelles secondaires du pool doivent utiliser le même ensemble d'attributs de sécurité. Reportez-vous à Ajout d'attributs de sécurité aux cartes d'interface réseau virtuelles secondaires des noeuds gérés.
Trafic de pod de noeud autogéré	Création d'instance de calcul	Indiquez les attributs de sécurité ZPR pour les cartes d'interface réseau virtuelles secondaires lors de la création de l'instance de calcul. Ne spécifiez pas d'attributs de sécurité ZPR pour les cartes d'interface réseau virtuelles secondaires dans une configuration d'instance.	Les attributs de sécurité s'appliquent aux cartes d'interface réseau virtuelles secondaires utilisées pour le trafic de pod. Reportez-vous à Utilisation des noeuds autogérés.
Services Kubernetes de type `LoadBalancer`	Annotation dans le manifeste de service	Ajoutez l'annotation `oci.oraclecloud.com/security-attributes` au manifeste de service.	Le moteur Kubernetes provisionne les équilibreurs de charge et les équilibreurs de charge réseau avec les attributs de sécurité. Reportez-vous à Ajout d'attributs de sécurité aux équilibreurs de charge et aux équilibreurs de charge réseau provisionnés pour les services Kubernetes de type LoadBalancer.
Equilibreurs de charge de contrôleur d'entrée natif	Annotation dans le manifeste `IngressClass`	Ajoutez l'annotation `oci-native-ingress.oraclecloud.com/security-attributes` au manifeste.	Le contrôleur d'entrée natif OCI provisionne les équilibreurs de charge avec les attributs de sécurité indiqués. Reportez-vous à Ajout d'attributs de sécurité aux équilibreurs de charge provisionnés par le contrôleur d'entrée natif OCI.
Cible de montage File Storage créée par le module d'extension de volume CSI	Paramètre dans le manifeste `StorageClass`	Ajoutez le paramètre `securityAttributes` au manifeste.	Le module d'extension de volume CSI crée la cible de montage avec les attributs de sécurité spécifiés. Reportez-vous à Ajout d'attributs de sécurité aux cibles de montage de service File Storage créées par le module d'extension de volume CSI.

Notez que les attributs de sécurité ZPR ne sont pas hérités par toutes les ressources d'un cluster. Vous affectez des attributs de sécurité séparément pour chaque type de ressource pris en charge. Les attributs de sécurité d'adresse de cluster s'appliquent uniquement à l'adresse d'API Kubernetes. Les attributs de sécurité de pool de noeuds s'appliquent aux cartes d'interface réseau virtuelles de noeud et de pod pour les noeuds de ce pool. Les équilibreurs de charge, les équilibreurs de charge entrants natifs et les cibles de montage File Storage nécessitent leur propre configuration d'attribut de sécurité.

Prérequis et limites

Avant d'utiliser Zero Trust Packet Routing (ZPR) avec Kubernetes Engine, vérifiez les prérequis et limitations suivants :

Les attributs de sécurité ZPR sont pris en charge avec les pools de noeuds gérés et les noeuds autogérés, mais pas avec les pools de noeuds virtuels.
Les attributs de sécurité ZPR sont pris en charge lors de la création de clusters et lors de la mise à jour de clusters existants, à condition que l'adresse d'API Kubernetes du cluster soit intégrée à votre propre VCN (connu sous le nom de "cluster natif VCN"). Vous ne pouvez pas utiliser les attributs de sécurité ZPR avec des clusters dont les adresses d'API Kubernetes ne sont pas intégrées à votre propre VCN. Reportez-vous à Migration vers des clusters natifs VCN.
Le cluster Kubernetes doit utiliser le module d'extension CNI de mise en réseau de pod natif OCI VCN pour la mise en réseau de pods. Les attributs de sécurité ZPR ne sont pas pris en charge avec les clusters qui utilisent le module d'extension CNI flannel. En outre, la version du module d'extension CNI de mise en réseau de pod natif OCI VCN doit prendre en charge les attributs de sécurité ZPR. Si la version du module complémentaire ne prend pas en charge les attributs de sécurité ZPR, Kubernetes Engine vous empêche d'utiliser ZPR ou échoue au lancement du noeud avant la création de l'instance de calcul.
Le cluster Kubernetes doit exécuter Kubernetes version 1.32 ou ultérieure.
Les espaces de noms d'attribut de sécurité appropriés, contenant les attributs de sécurité ZPR que vous souhaitez affecter aux ressources OKE, doivent déjà exister. Vous créez et gérez des espaces de noms d'attribut de sécurité et des attributs de sécurité dans le service Zero Trust Packet Routing (ZPR). Voir Création d'un espace de noms d'attribut de sécurité et Création d'un attribut de sécurité.
Les stratégies ZPR appropriées autorisant le trafic requis doivent déjà exister. L'affectation des mêmes attributs de sécurité à deux ressources ne leur permet pas automatiquement de communiquer. Vous devez créer des stratégies ZPR qui autorisent les chemins de communication requis. Vous créez et gérez des stratégies ZPR dans le service Zero Trust Packet Routing (ZPR) (reportez-vous à Création d'une stratégie ZPR).
Les droits d'accès IAM appropriés pour utiliser les espaces de noms d'attribut de sécurité ZPR requis doivent exister. OCI IAM permet d'accéder aux attributs de sécurité pour les ressources liées au cluster, telles que les adresses d'API Kubernetes, les cartes d'interface réseau virtuelles de noeud et les équilibreurs de charge. Pour plus d'informations, reportez-vous à Stratégies IAM requises.
Si vous affectez des attributs de sécurité aux équilibreurs de charge, aux équilibreurs de charge réseau ou aux cartes d'interface réseau virtuelles de pod, les stratégies IAM requises doivent également autoriser les composants Kubernetes Engine qui provisionnent ces ressources à attacher les attributs de sécurité indiqués. Par exemple, Cloud Controller Manager et le contrôleur d'entrée natif OCI nécessitent une stratégie IAM appropriée pour attacher les attributs de sécurité demandés aux ressources qu'ils créent, par exemple :
```
Allow any-user to use security-attribute-namespace in tenancy where request.principal.type = 'cluster'
```
Pour plus d'informations, reportez-vous à Stratégies IAM requises.
ZPR ne remplace pas les stratégies réseau Kubernetes et n'applique pas le trafic entre les pods sur le même noeud de processus actif. Pour contrôler le trafic pod-to-pod au sein d'un cluster, y compris le trafic entre pods sur le même noeud de processus actif, utilisez les stratégies réseau Kubernetes.
Les attributs de sécurité ZPR sont pris en charge lors du provisionnement des demandes de volume persistant avec les systèmes de fichiers du service File Storage, mais pas avec les volumes de blocs du service Block Volume.

Stratégies IAM requises

Stratégie IAM requise pour ajouter des attributs de sécurité aux ressources liées au cluster

Pour pouvoir ajouter un attribut de sécurité à une ressource liée au cluster, une stratégie IAM doit accorder au groupe auquel vous appartenez le droit d'utiliser l'espace de noms d'attribut de sécurité contenant l'attribut de sécurité. Par exemple, en utilisant la syntaxe suivante :

Allow group <group-name> to use security-attribute-namespaces in tenancy

Si vous utilisez l'instruction de stratégie Allow group <group-name> to use security-attribute-namespaces in tenancy pour accorder aux utilisateurs l'accès aux espaces de noms d'attribut de sécurité, cette instruction de stratégie accorde au groupe le droit d'utiliser tous les espaces de noms d'attribut de sécurité dans la location. Si vous pensez que ce droit est trop permissif, vous pouvez restreindre les espaces de noms d'attribut de sécurité auxquels le groupe a accès en incluant une clause Where dans l'instruction. Par exemple :

Allow group <group-name> to use security-attribute-namespaces in tenancy where target.security-attribute-namespace.name = 'oke-san'

Si vous incluez une clause Where, vous devez également inclure une seconde instruction dans la stratégie pour permettre au groupe d'inspecter tous les espaces de noms d'attribut de sécurité dans la location (avec la console). Par exemple :

Allow group <group-name> to inspect security-attribute-namespaces in tenancy

Lorsque des attributs de sécurité ont été ajoutés à une ressource liée au cluster, la ressource ne peut accéder à d'autres ressources OCI que si l'accès est autorisé par une stratégie ZPR.

Si aucune stratégie IAM appropriée n'existe pour utiliser l'espace de noms d'attribut de sécurité, vous ne pouvez pas ajouter l'attribut de sécurité à une ressource liée au cluster. L'attribut de sécurité n'est pas affiché dans la console et les tentatives d'ajout de l'attribut de sécurité à l'aide de l'interface de ligne de commande OCI ou de l'API échouent.

Stratégies IAM requises pour permettre aux clusters et aux pools de noeuds d'accéder aux espaces de noms d'attribut de sécurité

Lorsque vous ajoutez des attributs de sécurité à une ressource de cluster ou à un pool de noeuds, une stratégie IAM appropriée doit accorder au cluster ou au pool de noeuds l'accès aux espaces de noms d'attribut de sécurité nécessaires. Par exemple :

Allow any-user to use security-attribute-namespace in compartment <compartment_name> where request.principal.type = 'cluster'

Allow any-user to manage security-attribute-namespace in compartment <compartment_name> where request.principal.type = 'nodepool'

Stratégies ZPR requises

Stratégies ZPR requises pour permettre aux ressources liées au cluster d'accéder à d'autres ressources

Lorsque vous ajoutez un attribut de sécurité à une ressource liée au cluster, la ressource ne peut accéder à d'autres ressources que si une stratégie ZPR accorde l'accès à ces ressources.

Si aucune stratégie ZPR appropriée n'existe déjà, vous devez en créer une. Par exemple, en utilisant la syntaxe suivante :

in <vcn-security-attribute> VCN allow <application-security-attribute> endpoints to connect to <destination-security-attribute> endpoints

où :

<vcn-security-attribute> est un attribut de sécurité (et une valeur) qui a été ajouté au VCN dans lequel réside le sous-réseau de la ressource. Par exemple, VCN-Network:myVCN.
<application-security-attribute> est l'attribut (et la valeur) de sécurité que vous avez ajouté à la ressource liée au cluster. Par exemple, oke-cluster:myclusterA
<destination-security-attribute> est un attribut de sécurité (et une valeur) qui a été ajouté à la ressource à laquelle la ressource liée au cluster doit accéder. Par exemple, DB-Server:App1

Par exemple :

in VCN-Network:myVCN VCN allow oke-cluster:myclusterA endpoints to connect to DB-Server:App1 endpoints

Pour plus d'informations sur les stratégies, la syntaxe et les exemples ZPR, reportez-vous à Stratégie Zero Trust Packet Routing dans la documentation ZPR.

Stratégies ZPR requises lorsque des attributs de sécurité sont ajoutés aux cartes d'interface réseau virtuelles principales des noeuds gérés

Lorsque vous indiquez des attributs de sécurité ZPR pour les cartes d'interface réseau virtuelles principales des instances de calcul qui soutiennent des noeuds gérés dans un pool de noeuds gérés, les stratégies ZPR supplémentaires suivantes sont requises pour permettre aux noeuds gérés de rejoindre le cluster :

in zpr-cni.sensitivity:42 VCN allow zpr-cni.sensitivity:42 endpoints to connect to 'all-endpoints'

in zpr-cni.sensitivity:42 VCN allow all-endpoints to connect to zpr-cni.sensitivity:42 endpoints with protocol = 'tcp/443'

in zpr-cni.sensitivity:42 VCN allow zpr-cni.sensitivity:42 endpoints to connect to 'osn-services-ip-addresses'

Ajout d'attributs de sécurité à l'adresse d'API Kubernetes d'un cluster

Vous pouvez ajouter des attributs de sécurité ZPR à l'adresse d'API Kubernetes lorsque vous créez un cluster ou en mettant à jour un cluster existant. Les attributs de sécurité d'adresse de cluster s'appliquent uniquement à l'adresse d'API Kubernetes. Ces attributs de sécurité ne s'appliquent pas aux noeuds de processus actif, aux pods, aux équilibreurs de charge ou aux autres ressources liées au cluster.

Avant d'ajouter des attributs de sécurité à l'adresse d'API Kubernetes, assurez-vous qu'une stratégie ZPR autorise les clients autorisés à accéder à l'adresse. Par exemple, créez une stratégie ZPR qui autorise l'accès à partir de clients qui utilisent kubectl.

Pour ajouter des attributs de sécurité à l'adresse d'API Kubernetes d'un nouveau cluster lors de la création du cluster à l'aide de la console, reportez-vous à Utilisation de la console pour créer un cluster avec des paramètres définis de manière explicite dans le workflow Création personnalisée.

Pour ajouter ou enlever des attributs de sécurité de l'adresse d'API Kubernetes d'un cluster existant à l'aide de la console, procédez comme suit :
1. Sur la page de liste Clusters, sélectionnez le cluster avec l'adresse d'API Kubernetes à laquelle ajouter ou enlever des attributs de sécurité. Si vous avez besoin d'aide pour trouver la page de liste ou le cluster, reportez-vous à Liste des clusters.
  L'onglet Sécurité affiche les attributs de sécurité qui ont déjà été ajoutés à l'adresse d'API Kubernetes du cluster (le cas échéant).
2. Pour ajouter un attribut de sécurité à l'adresse d'API Kubernetes du cluster, procédez comme suit :
  
  Dans l'onglet Sécurité, sélectionnez Ajouter, puis dans la boîte de dialogue Ajouter des attributs de sécurité :
  
  Sélectionnez l'espace de noms d'attribut de sécurité qui contient l'attribut de sécurité.
  
  Sélectionnez l'attribut de sécurité.
  
  Entrez la valeur de l'attribut de sécurité.
  
  Pour ajouter plusieurs attributs de sécurité à l'adresse d'API Kubernetes du cluster, sélectionnez Ajouter et sélectionnez des attributs de sécurité supplémentaires (jusqu'à cinq au maximum).
  
  Sélectionnez Ajout d'attributs de sécurité.
3. Pour enlever un attribut de sécurité de l'adresse d'API Kubernetes du cluster, procédez comme suit :
  
  Dans l'onglet Sécurité, sélectionnez Supprimer dans le menu Actions (trois points) en regard de l'attribut de sécurité à supprimer.
  
  Confirmez la suppression de l'attribut de sécurité.
Les attributs de sécurité affichés dans l'onglet Sécurité du cluster s'appliquent désormais à l'adresse d'API Kubernetes du cluster.
Utilisez la commande oci ce cluster create et les paramètres requis pour créer un cluster :
oci ce cluster create --compartment-id <compartment-ocid> --kubernetes-version <kubernetes-version> --name <cluster-name> --vcn-id <vcn-ocid> [OPTIONS]
Utilisez la commande oci ce cluster update et les paramètres requis pour mettre à jour un cluster :
oci ce cluster update --cluster-id <cluster-ocid> [OPTIONS]
Afin d'obtenir la liste complète des indicateurs et d'options de variable pour les commandes d'interface de connexion OCI, reportez-vous à Référence de ligne de commandes.
Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à la documentation relative à l'API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

Utilisez les opérations d'API suivantes pour ajouter ou enlever des attributs de sécurité à ou à partir de l'adresse d'API Kubernetes d'un cluster :
- CreateCluster
- UpdateCluster

Ajout d'attributs de sécurité aux cartes d'interface réseau virtuelles principales des noeuds gérés

Vous pouvez indiquer des attributs de sécurité ZPR pour les cartes d'interface réseau virtuelles principales des instances de calcul qui soutiennent les noeuds gérés dans un pool de noeuds gérés. Vous indiquez ces attributs de sécurité lors de la création d'un pool de noeuds gérés ou en mettant à jour un pool de noeuds gérés existant. Les attributs de sécurité des cartes d'interface réseau virtuelles principales s'appliquent aux nouvelles instances de calcul qui démarrent dans le pool de noeuds. Ces attributs de sécurité sont utilisés pour le trafic au niveau du noeud, tel que le trafic de kubelet, le trafic d'agent Oracle Cloud et le trafic des pods qui utilisent le réseau hôte. Ces attributs de sécurité ne s'appliquent pas aux cartes d'interface réseau virtuelles secondaires utilisées pour le trafic de pod ni aux autres ressources liées au cluster.

Lorsque vous mettez à jour les attributs de sécurité d'un pool de noeuds gérés, les modifications s'appliquent uniquement aux nouveaux noeuds de processus actif. Les noeuds de processus actif existants et leurs cartes d'interface réseau virtuelles ne sont pas mis à jour. Pour appliquer les attributs de sécurité mis à jour aux charges globales existantes, remplacez les noeuds de processus actif dans le pool de noeuds (reportez-vous à Terminaison et remplacement de noeuds de processus actif). Le remplacement de volume d'initialisation n'applique pas les attributs de sécurité de pool de noeuds mis à jour. Les noeuds de processus actif doivent être remplacés.

Pour ajouter des attributs de sécurité aux cartes d'interface réseau virtuelles principales des noeuds gérés lors de la création d'un cluster à l'aide de la console, reportez-vous à Utilisation de la console pour créer un cluster avec des paramètres définis de manière explicite dans le workflow Création personnalisée.

Pour ajouter des attributs de sécurité aux cartes d'interface réseau virtuelles principales des noeuds gérés lors de la création d'un pool de noeuds gérés à l'aide de la console, reportez-vous à Création d'un pool de noeuds gérés.

Pour ajouter ou enlever des attributs de sécurité pour les cartes d'interface réseau virtuelles principales des noeuds gérés dans un pool de noeuds gérés existant à l'aide de la console, procédez comme suit :
1. Sur la page de liste Clusters, sélectionnez le nom du cluster à modifier. Si vous avez besoin d'aide pour trouver la page de liste ou le cluster, reportez-vous à Liste des clusters.
2. Sélectionnez l'onglet Pools de noeuds, puis le nom du pool de noeuds à modifier.
  L'onglet Sécurité affiche les attributs de sécurité qui ont été configurés pour les cartes d'interface réseau virtuelles principales des noeuds gérés dans le pool de noeuds, le cas échéant.
3. Pour ajouter un attribut de sécurité pour les cartes d'interface réseau virtuelles principales des noeuds gérés, procédez comme suit :
  
  Dans l'onglet Sécurité, dans la section Attributs de sécurité de la carte d'interface réseau virtuelle principale, sélectionnez Ajouter, puis dans la boîte de dialogue Ajouter des attributs de sécurité :
  
  Sélectionnez l'espace de noms d'attribut de sécurité qui contient l'attribut de sécurité.
  
  Sélectionnez l'attribut de sécurité.
  
  Entrez la valeur de l'attribut de sécurité.
  
  Pour ajouter plusieurs attributs de sécurité à la carte d'interface réseau virtuelle principale du pool de noeuds, sélectionnez Ajouter et sélectionnez des attributs de sécurité supplémentaires (jusqu'à cinq au maximum).
  
  Sélectionnez Ajout d'attributs de sécurité.
4. Pour enlever un attribut de sécurité de la carte d'interface réseau virtuelle principale du pool de noeuds, procédez comme suit :
  
  Dans l'onglet Sécurité, dans la section Attributs de sécurité de la carte d'interface réseau virtuelle principale, sélectionnez Supprimer dans le menu Actions (trois points) en regard de l'attribut de sécurité à supprimer.
  
  Confirmez la suppression de l'attribut de sécurité.
Les attributs de sécurité affichés dans l'onglet Sécurité du pool de noeuds s'appliquent désormais aux cartes d'interface réseau virtuelles principales des nouveaux noeuds de processus actif qui démarrent dans le pool de noeuds.
Utilisez la commande oci ce node-pool create et les paramètres requis pour ajouter un pool de noeuds gérés :
oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name <node-pool-name> --node-shape <shape>
Utilisez la commande oci ce node-pool update et les paramètres requis pour mettre à jour un pool de noeuds gérés :
oci ce node-pool update --node-pool-id <node-pool-ocid> [OPTIONS]
Afin d'obtenir la liste complète des indicateurs et d'options de variable pour les commandes d'interface de connexion OCI, reportez-vous à Référence de ligne de commandes.
Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à la documentation relative à l'API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

Utilisez les opérations d'API suivantes pour ajouter ou enlever des attributs de sécurité de la carte d'interface réseau virtuelle principale d'un pool de noeuds gérés :
- CreateNodePool
- UpdateNodePool

Ajout d'attributs de sécurité aux cartes d'interface réseau virtuelles secondaires des noeuds gérés

Vous pouvez indiquer des attributs de sécurité ZPR pour les cartes d'interface réseau virtuelles secondaires des instances de calcul qui soutiennent les noeuds gérés dans un pool de noeuds gérés. Vous indiquez ces attributs de sécurité lors de la création d'un pool de noeuds gérés ou en mettant à jour un pool de noeuds gérés existant. Dans les clusters qui utilisent le module d'extension CNI de mise en réseau de pod natif OCI VCN, les cartes d'interface réseau virtuelles secondaires sont utilisées pour le trafic de pod. Ces attributs de sécurité ne s'appliquent pas aux cartes d'interface réseau virtuelles principales utilisées pour le trafic au niveau du noeud ni aux autres ressources liées au cluster.

Si vous définissez plusieurs cartes d'interface réseau virtuelles secondaires pour un pool de noeuds gérés, vous devez indiquer les mêmes attributs de sécurité pour toutes les cartes d'interface réseau virtuelles secondaires du pool de noeuds.

Nous vous recommandons de planifier le placement de la charge globale avant d'affecter des attributs de sécurité aux cartes d'interface réseau virtuelles secondaires. Kubernetes Engine applique des attributs de sécurité de pod au niveau du pool de noeuds, de sorte que les charges globales qui nécessitent des profils de sécurité différents doivent être exécutées dans des pools de noeuds différents.

Pour ajouter des attributs de sécurité aux cartes d'interface réseau virtuelles secondaires des noeuds gérés lors de la création d'un cluster à l'aide de la console, reportez-vous à Utilisation de la console pour créer un cluster avec des paramètres définis de manière explicite dans le workflow Création personnalisée.

Pour ajouter des attributs de sécurité aux cartes d'interface réseau virtuelles secondaires des noeuds gérés lors de la création d'un pool de noeuds gérés à l'aide de la console, reportez-vous à Création d'un pool de noeuds gérés.

Pour ajouter ou enlever des attributs de sécurité pour les cartes d'interface réseau virtuelles secondaires des noeuds gérés dans un pool de noeuds gérés existant à l'aide de la console, procédez comme suit :
1. Sur la page de liste Clusters, sélectionnez le nom du cluster à modifier. Si vous avez besoin d'aide pour trouver la page de liste ou le cluster, reportez-vous à Liste des clusters.
2. Sélectionnez l'onglet Pools de noeuds, puis le nom du pool de noeuds à modifier.
  L'onglet Sécurité affiche les attributs de sécurité qui ont été configurés pour les cartes d'interface réseau virtuelles secondaires des noeuds gérés dans le pool de noeuds, le cas échéant.
3. Pour ajouter un attribut de sécurité pour les cartes d'interface réseau virtuelles secondaires des noeuds gérés, procédez comme suit :
  
  Dans l'onglet Sécurité, dans la section Attributs de sécurité de la carte d'interface réseau virtuelle secondaire, sélectionnez Ajouter, puis dans la boîte de dialogue Ajouter des attributs de sécurité :
  
  Sélectionnez l'espace de noms d'attribut de sécurité qui contient l'attribut de sécurité.
  
  Sélectionnez l'attribut de sécurité.
  
  Entrez la valeur de l'attribut de sécurité.
  
  Pour ajouter plusieurs attributs de sécurité à la carte d'interface réseau virtuelle secondaire du pool de noeuds, sélectionnez Ajouter et sélectionnez des attributs de sécurité supplémentaires (jusqu'à cinq au maximum).
  
  Sélectionnez Ajout d'attributs de sécurité.
4. Pour enlever un attribut de sécurité de la carte d'interface réseau virtuelle secondaire du pool de noeuds, procédez comme suit :
  
  Dans l'onglet Sécurité, dans la section Attributs de sécurité de carte d'interface réseau virtuelle secondaire, sélectionnez Supprimer dans le menu Actions (trois points) en regard de l'attribut de sécurité à supprimer.
  
  Confirmez la suppression de l'attribut de sécurité.
Les attributs de sécurité affichés dans l'onglet Sécurité du pool de noeuds s'appliquent désormais aux cartes d'interface réseau virtuelles secondaires des nouveaux noeuds de processus actif qui démarrent dans le pool de noeuds.
Utilisez la commande oci ce node-pool create et les paramètres requis pour ajouter un pool de noeuds gérés :
oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name <node-pool-name> --node-shape <shape>
Utilisez la commande oci ce node-pool update et les paramètres requis pour mettre à jour un pool de noeuds gérés :
oci ce node-pool update --node-pool-id <node-pool-ocid> [OPTIONS]
Afin d'obtenir la liste complète des indicateurs et d'options de variable pour les commandes d'interface de connexion OCI, reportez-vous à Référence de ligne de commandes.
Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à la documentation relative à l'API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

Utilisez les opérations d'API suivantes pour ajouter ou enlever des attributs de sécurité sur ou à partir des cartes d'interface réseau virtuelles secondaires d'un pool de noeuds gérés :
- CreateNodePool
- UpdateNodePool

Ajout d'attributs de sécurité aux équilibreurs de charge et aux équilibreurs de charge réseau provisionnés pour les services Kubernetes de type LoadBalancer

Vous pouvez utiliser l'annotation oci.oraclecloud.com/security-attributes pour indiquer les attributs de sécurité ZPR que Kubernetes Engine ajoute aux équilibreurs de charge et aux équilibreurs de charge réseau qu'il provisionne pour les services de type LoadBalancer. Pour plus d'informations, reportez-vous à Spécification des attributs de sécurité ZPR pour les équilibreurs de charge et les équilibreurs de charge réseau.

Ajout d'attributs de sécurité aux équilibreurs de charge provisionnés par le contrôleur d'entrée natif OCI

Vous pouvez utiliser l'annotation oci-native-ingress.oraclecloud.com/security-attributes dans le manifeste IngressClass pour indiquer les attributs de sécurité ZPR que le contrôleur d'entrée natif OCI ajoute aux équilibreurs de charge qu'il provisionne. Pour plus d'informations, voir Spécification des attributs de sécurité ZPR.

Ajout d'attributs de sécurité aux cibles de montage du service File Storage créées par le module d'extension de volume CSI

Vous pouvez utiliser le paramètre securityAttributes dans le manifeste StorageClass pour spécifier les attributs de sécurité ZPR que le module d'extension de volume CSI ajoute aux cibles de montage du service File Storage qu'il crée. Pour plus d'informations, reportez-vous à Provisionnement des demandes de volume persistant sur le service File Storage.

Documentation Oracle Cloud Infrastructure