Red Hat SummitChapitre 6. La sécurité du réseau
6.1. Comprendre les API de stratégie réseau
Kubernetes offre deux fonctionnalités que les utilisateurs peuvent utiliser pour renforcer la sécurité du réseau. L’API NetworkPolicy est conçue principalement pour les développeurs d’applications et les locataires de l’espace de noms afin de protéger leurs espaces de noms en créant des stratégies basées sur l’espace de noms.
La deuxième fonctionnalité est AdminNetworkPolicy qui se compose de deux API: l’API AdminNetworkPolicy (ANP) et l’API BaselineAdminNetworkPolicy (BANP). ANP et BANP sont conçus pour les administrateurs de cluster et de réseau afin de protéger l’ensemble de leur cluster en créant des stratégies axées sur les clusters. Les administrateurs de clusters peuvent utiliser des ANP pour appliquer des stratégies non-surpassables qui ont préséance sur les objets NetworkPolicy. Les administrateurs peuvent utiliser BANP pour configurer et appliquer des règles optionnelles de stratégie réseau à portée de cluster qui sont subdivisées par les utilisateurs en utilisant des objets NetworkPolicy lorsque cela est nécessaire. Lorsqu’ils sont utilisés ensemble, ANP, BANP et la politique de réseau peuvent atteindre l’isolement multi-locataires complet que les administrateurs peuvent utiliser pour sécuriser leur cluster.
Le CNI d’OVN-Kubernetes dans Red Hat OpenShift Service sur AWS implémente ces stratégies réseau à l’aide des Tiers Access Control List (ACL) pour les évaluer et les appliquer. Les ACL sont évaluées dans l’ordre décroissant du niveau 1 au niveau 3.
Le niveau 1 évalue les objets AdminNetworkPolicy (ANP). Le niveau 2 évalue les objets de NetworkPolicy. Le niveau 3 évalue les objets BaselineAdminNetworkPolicy (BANP).
Les PAN sont évalués en premier. Lorsque la correspondance est une règle d’autorisation ou de refus de l’ANP, tous les objets existants de NetworkPolicy et BaselineAdminNetworkPolicy (BANP) dans le cluster sont ignorés de l’évaluation. Lorsque la correspondance est une règle de passage ANP, l’évaluation passe du niveau 1 de l’ACL au niveau 2 où la politique de NetworkPolicy est évaluée. En l’absence de NetworkPolicy, l’évaluation passe du niveau 2 aux ACL de niveau 3 où le BANP est évalué.
6.1.1. Différences clés entre AdminNetworkPolicy et NetworkPolicy ressources personnalisées
Le tableau suivant explique les principales différences entre l’API AdminNetworkPolicy et l’API NetworkPolicy.
| Éléments de politique générale | AdminNetworkPlicy | La politique de réseau |
|---|---|---|
| L’utilisateur applicable | Administrateur de cluster ou équivalent | Les propriétaires d’espace de noms |
| Champ d’application | Groupe de travail | Espace de nom |
| Laisser tomber le trafic | Il est pris en charge avec une action de Deny explicite définie en règle générale. | Prise en charge par l’isolement implicite de Deny au moment de la création de la politique. |
| Déléguer le trafic | En règle générale, pris en charge avec une action Pass. | Inapplicable |
| Autoriser le trafic | Compatible avec une action explicite Autoriser en règle générale. | L’action par défaut pour toutes les règles est d’autoriser. |
| La préséance de la règle dans le cadre de la politique | Dépend de l’ordre dans lequel ils apparaissent dans un ANP. La position de la règle est élevée, plus la préséance est élevée. | Les règles sont additives |
| A) Priorité des politiques | Au sein des PAN, le champ prioritaire fixe l’ordre d’évaluation. Le nombre de priorité est inférieur à celui de la politique. | Il n’y a pas d’ordre politique entre les politiques. |
| La préséance des caractéristiques | Évalué en premier par l’ACL de niveau 1 et le BANP est évalué en dernier via l’ACL de niveau 3. | Appliquées après l’ANP et avant le BANP, elles sont évaluées au niveau 2 de l’ACL. |
| Assortiment de la sélection de pod | Il peut appliquer différentes règles dans les espaces de noms. | Il peut appliquer différentes règles entre les pods dans un espace de noms unique. |
| Le trafic d’égressivité de cluster | Supporté via des nœuds et des réseaux pairs | Compatible avec le champ ipBlock ainsi que la syntaxe CIDR acceptée. |
| Le trafic d’entrée de cluster | Ce n’est pas pris en charge | Ce n’est pas pris en charge |
| Le support par les pairs de noms de domaine entièrement qualifiés (FQDN) | Ce n’est pas pris en charge | Ce n’est pas pris en charge |
| Les sélecteurs d’espace de noms | Compatible avec la sélection avancée de Namespaces avec l’utilisation du champ namespaces.matchLabels | Prend en charge la sélection de l’espace de noms basé sur l’étiquette avec l’utilisation du champ namespaceSelector |
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}