{"id":32641,"date":"2019-10-31T21:48:11","date_gmt":"2019-10-31T18:48:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\/"},"modified":"2019-10-31T21:48:11","modified_gmt":"2019-10-31T18:48:11","slug":"vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Note de traduction.<\/b>: L'auteur de l'article \u2014 Reuven Harrison \u2014 poss\u00e8de plus de 20 ans d'exp\u00e9rience dans le d\u00e9veloppement de logiciels et est actuellement directeur technique et cofondateur de Tufin, une entreprise sp\u00e9cialis\u00e9e dans les solutions de gestion des politiques de s\u00e9curit\u00e9. En consid\u00e9rant les politiques r\u00e9seau de Kubernetes comme un excellent moyen de segmentation des r\u00e9seaux au sein des clusters, il souligne n\u00e9anmoins qu'elles ne sont pas si simples \u00e0 appliquer dans la pratique. Ce document (assez volumineux) vise \u00e0 accro\u00eetre la sensibilisation des professionnels \u00e0 ce sujet et \u00e0 les aider dans la cr\u00e9ation des configurations n\u00e9cessaires.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Aujourd'hui, de nombreuses entreprises choisissent de plus en plus Kubernetes pour d\u00e9ployer leurs applications. L'int\u00e9r\u00eat pour ce logiciel est tel que certains le qualifient de \u00ab nouveau syst\u00e8me d'exploitation pour les centres de donn\u00e9es \u00bb. Progressivement, Kubernetes (ou k8s) commence \u00e0 \u00eatre per\u00e7u comme une partie critique de l'entreprise, n\u00e9cessitant l'organisation de processus commerciaux matures, y compris l'assurance de la s\u00e9curit\u00e9 r\u00e9seau.<\/p>\n<p>Pour les professionnels de la s\u00e9curit\u00e9, qui se retrouvent confront\u00e9s \u00e0 la gestion de Kubernetes, la politique par d\u00e9faut de cette plateforme peut repr\u00e9senter une v\u00e9ritable surprise : tout est autoris\u00e9.<\/p>\n<p>Ce guide vous aidera \u00e0 comprendre le fonctionnement interne des politiques r\u00e9seau ; \u00e0 distinguer celles-ci des r\u00e8gles des pare-feu traditionnels. Il traitera \u00e9galement de certaines difficult\u00e9s et fournira des recommandations pour prot\u00e9ger les applications dans Kubernetes.<\/p>\n<h2>Politiques r\u00e9seau Kubernetes<\/h2>\n<p>\nLe m\u00e9canisme des politiques r\u00e9seau de Kubernetes permet de contr\u00f4ler les interactions des applications d\u00e9ploy\u00e9es sur la plateforme \u00e0 un niveau r\u00e9seau (le troisi\u00e8me niveau dans le mod\u00e8le OSI). Les politiques r\u00e9seau ne disposent pas de certaines fonctionnalit\u00e9s avanc\u00e9es des pare-feu modernes, telles que le contr\u00f4le au niveau 7 du mod\u00e8le OSI et la d\u00e9tection des menaces, mais elles offrent un niveau de s\u00e9curit\u00e9 r\u00e9seau de base, qui constitue un bon point de d\u00e9part.<\/p>\n<h2>Les politiques r\u00e9seau contr\u00f4lent les communications entre les pods.<\/h2>\n<p>\nLes charges de travail dans Kubernetes sont r\u00e9parties sur des pods, qui se composent d'un ou plusieurs conteneurs d\u00e9ploy\u00e9s ensemble. Kubernetes attribue \u00e0 chaque pod une adresse IP accessible depuis d'autres pods. Les politiques r\u00e9seau de Kubernetes d\u00e9finissent les droits d'acc\u00e8s pour des groupes de pods de la m\u00eame mani\u00e8re que les groupes de s\u00e9curit\u00e9 dans le cloud sont utilis\u00e9s pour g\u00e9rer l'acc\u00e8s aux instances de machines virtuelles.<\/p>\n<h2>D\u00e9finition des politiques r\u00e9seau<\/h2>\n<p>\nComme les autres ressources Kubernetes, les politiques r\u00e9seau sont d\u00e9finies en YAML. Dans l'exemple ci-dessous, l'application <code>balance<\/code> obtient l'acc\u00e8s \u00e0 <code>postgres<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: balance\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Note de traduction.<\/b>: cette capture d'\u00e9cran, comme toutes les suivantes, a \u00e9t\u00e9 cr\u00e9\u00e9e non pas avec les outils de Kubernetes, mais \u00e0 l'aide de l'outil Tufin Orca, dont le d\u00e9veloppement est soutenu par l'auteur de l'article original, mentionn\u00e9 \u00e0 la fin du document.<\/i><\/p>\n<p>Pour d\u00e9finir votre propre politique r\u00e9seau, des connaissances de base en YAML seront n\u00e9cessaires. Ce langage est bas\u00e9 sur des indentations (utilis\u00e9es par des espaces, et non des tabulations). Un \u00e9l\u00e9ment indente appartient \u00e0 l'\u00e9l\u00e9ment indente le plus proche au-dessus de lui. Un nouvel \u00e9l\u00e9ment de liste commence par un tiret, tous les autres \u00e9l\u00e9ments ressemblent \u00e0 <i>cl\u00e9-valeur<\/i>.<\/p>\n<p>Apr\u00e8s avoir d\u00e9crit la politique en YAML, utilisez <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, pour la cr\u00e9er dans le cluster :<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Sp\u00e9cification de la politique r\u00e9seau<\/h2>\n<p>\nLa sp\u00e9cification de la politique r\u00e9seau Kubernetes comprend quatre \u00e9l\u00e9ments :<\/p>\n<ol>\n<li> <code>podSelector<\/code>: d\u00e9finit les pods affect\u00e9s par cette politique (cibles) \u2014 obligatoire ;<\/li>\n<li> <code>policyTypes<\/code>: indique quels types de politiques sont inclus : ingress et\/ou egress \u2014 facultatif, mais je recommande de l'indiquer explicitement dans tous les cas ;<\/li>\n<li> <code>ingress<\/code>: d\u00e9finit le trafic <b>entrant<\/b> le trafic vers les pods cibles \u2014 facultatif ;<\/li>\n<li> <code>egress<\/code>: d\u00e9finit le trafic <b>trafic<\/b> le trafic des pods cibles \u2014 facultatif.<\/li>\n<\/ol>\n<p>\nL'exemple suivant, tir\u00e9 du site Kubernetes (j'ai remplac\u00e9 <code>role<\/code> sur <code>app<\/code>), montre comment tous les quatre \u00e9l\u00e9ments sont utilis\u00e9s :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:    # &lt;&lt;&lt;\n    matchLabels:\n      app: db\n  policyTypes:    # &lt;&lt;&lt;\n  - Ingress\n  - Egress\n  ingress:        # &lt;&lt;&lt;\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:         # &lt;&lt;&lt;\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVeuillez noter que l'inclusion des quatre \u00e9l\u00e9ments n'est pas obligatoire. Seul <code>podSelector<\/code>est obligatoire, les autres param\u00e8tres peuvent \u00eatre utilis\u00e9s \u00e0 votre convenance.<\/p>\n<p>Si vous omettez <code>policyTypes<\/code>, la politique sera interpr\u00e9t\u00e9e comme suit :<\/p>\n<ul>\n<li> Par d\u00e9faut, il est suppos\u00e9 qu'elle d\u00e9finit le c\u00f4t\u00e9 ingress. Si aucune indication explicite \u00e0 cet \u00e9gard n'est pr\u00e9sente dans la politique, le syst\u00e8me consid\u00e9rera que tout le trafic est interdit.<\/li>\n<li> Comportement sur le c\u00f4t\u00e9 egress sera d\u00e9termin\u00e9 par la pr\u00e9sence ou l'absence du param\u00e8tre egress correspondant.<\/li>\n<\/ul>\n<p>\nPour \u00e9viter des erreurs, je recommande <b>de toujours indiquer explicitement <code>policyTypes<\/code><\/b>.<\/p>\n<p>Conform\u00e9ment \u00e0 la logique ci-dessus, si les param\u00e8tres <code>ingress<\/code> et\/ou <code>egress<\/code> sont omis, la politique interdire tous les trafics (voir \u00ab R\u00e8gle de nettoyage \u00bb ci-dessous).<\/p>\n<h2>Politique par d\u00e9faut \u2014 autoriser<\/h2>\n<p>\nSi aucune politique n'est d\u00e9finie, Kubernetes autorise par d\u00e9faut tout le trafic. Tous les pods peuvent librement \u00e9changer des informations entre eux. D'un point de vue s\u00e9curitaire, cela peut sembler illogique, mais n'oubliez pas que Kubernetes a \u00e9t\u00e9 initialement con\u00e7u par des d\u00e9veloppeurs pour faciliter l'interaction des applications. Les politiques r\u00e9seau ont \u00e9t\u00e9 ajout\u00e9es plus tard.<\/p>\n<h2>Espaces de noms<\/h2>\n<p>\nLes espaces de noms (Namespaces) sont un m\u00e9canisme de collaboration de Kubernetes. Ils sont destin\u00e9s \u00e0 isoler des environnements logiques les uns des autres, tout en permettant par d\u00e9faut l'\u00e9change de donn\u00e9es entre les espaces.<\/p>\n<p>Comme la plupart des composants de Kubernetes, les politiques r\u00e9seau r\u00e9sident dans un espace de noms sp\u00e9cifique. Dans le bloc <code>m\u00e9tadonn\u00e9es<\/code> vous pouvez sp\u00e9cifier \u00e0 quel espace appartient la politique :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: my-namespace  # &lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p>\nSi l'espace de noms dans les m\u00e9tadonn\u00e9es n'est pas explicitement indiqu\u00e9, le syst\u00e8me utilisera le namespace sp\u00e9cifi\u00e9 dans kubectl (par d\u00e9faut <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nJe recommande <b>d'indiquer explicitement le namespace<\/b>, \u00e0 moins que vous ne r\u00e9digiez une politique destin\u00e9e \u00e0 plusieurs espaces de noms.<\/p>\n<p><b>Principal<\/b> \u00e9l\u00e9ment <code>podSelector<\/code> la politique s\u00e9lectionnera des pods de l'espace de noms auquel appartient la politique (il n'a pas acc\u00e8s aux pods d'un autre espace de noms).<\/p>\n<p>De la m\u00eame mani\u00e8re pour les podSelectors, <b>dans les blocs ingress et egress<\/b> peuvent choisir des pods uniquement de leur espace de noms, sauf si vous les combinez \u00e0 l'aide de <code>namespaceSelector<\/code> (nous en parlerons dans la section \u00ab Filtrer par espaces de noms et pods \u00bb).<\/p>\n<h2>R\u00e8gles de nommage des politiques<\/h2>\n<p>\nLes noms des politiques doivent \u00eatre uniques au sein d'un m\u00eame espace de noms. Deux politiques portant le m\u00eame nom ne peuvent exister dans un m\u00eame espace, mais des politiques avec des noms identiques peuvent exister dans des espaces diff\u00e9rents. Cela est pratique lorsque vous souhaitez r\u00e9utiliser la m\u00eame politique dans plusieurs espaces.<\/p>\n<p>J'aime particuli\u00e8rement une des fa\u00e7ons de nommer. Il s'agit d'associer le nom de l'espace de noms aux pods cibles. Par exemple :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres  # &lt;&lt;&lt;\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>\u00c9tiquettes<\/h2>\n<p>\nDes \u00e9tiquettes personnalis\u00e9es peuvent \u00eatre attach\u00e9es aux objets Kubernetes, tels que les pods et les espaces de noms. Les \u00e9tiquettes (<i>labels<\/i> \u2014 labels) sont l'\u00e9quivalent des tags dans le cloud. Les politiques r\u00e9seau Kubernetes utilisent des \u00e9tiquettes pour s\u00e9lectionner <b>pods<\/b>, auxquelles elles s'appliquent :<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 ou <b>espaces de noms<\/b>, auxquels elles s'appliquent. Dans cet exemple, tous les pods dans les espaces de noms avec les \u00e9tiquettes correspondantes sont s\u00e9lectionn\u00e9s :<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\nUne mise en garde : lors de l'utilisation <code>namespaceSelector<\/code> <b>assurez-vous que les espaces de noms s\u00e9lectionn\u00e9s contiennent bien l'\u00e9tiquette souhait\u00e9e<\/b>. Notez que les espaces de noms int\u00e9gr\u00e9s, tels que <code>default<\/code> et <code>kube-system<\/code>, ne contiennent par d\u00e9faut aucune \u00e9tiquette.<\/p>\n<p>Vous pouvez ajouter une \u00e9tiquette \u00e0 un espace de cette mani\u00e8re :<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nDans ce cas, le namespace dans la section <code>m\u00e9tadonn\u00e9es<\/code> doit faire r\u00e9f\u00e9rence au v\u00e9ritable nom de l'espace et non \u00e0 l'\u00e9tiquette :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default   # &lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p><\/p>\n<h2>Source et destinataire<\/h2>\n<p>\nLes politiques pour les pare-feu se composent de r\u00e8gles avec des sources et des destinataires. Les politiques r\u00e9seau de Kubernetes sont d\u00e9finies pour une cible \u2014 un ensemble de pods auxquels elles s'appliquent, puis \u00e9tablissent des r\u00e8gles pour le trafic entrant (ingress) et\/ou sortant (egress). Dans notre exemple, la cible de la politique sera tous les pods dans l'espace de noms <code>default<\/code> avec un label de cl\u00e9 <code>app<\/code> et la valeur <code>db<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: db   # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress\n  - Egress\n  ingress:\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSous-section <code>ingress<\/code> dans cette politique ouvre le trafic entrant vers les pod\u2019 s cibles. En d'autres termes, l'ingress agit comme source, et la cible \u2014 comme destinataire correspondant. De m\u00eame, l'egress est le destinataire, et la cible est sa source.<\/p>\n<p><img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>C'est \u00e9quivalent \u00e0 deux r\u00e8gles pour le pare-feu : Ingress \u2192 Cible ; Cible \u2192 Egress.<\/i><\/p>\n<h2>Egress et DNS (important !)<\/h2>\n<p>\nEn limitant le trafic sortant, <b>faites particuli\u00e8rement attention \u00e0 DNS<\/b> \u2014 Kubernetes utilise ce service pour faire correspondre les services avec les adresses IP. Par exemple, la politique suivante ne fonctionnera pas, car vous n'avez pas autoris\u00e9 l'application <code>balance<\/code> \u00e0 acc\u00e9der \u00e0 DNS :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVous pouvez corriger cela en ouvrant l'acc\u00e8s au service DNS :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:               # &lt;&lt;&lt;\n    ports:            # &lt;&lt;&lt;\n    - protocol: UDP   # &lt;&lt;&lt;\n      port: 53        # &lt;&lt;&lt;\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe dernier \u00e9l\u00e9ment <code>to<\/code> \u2014 est vide, et donc, il choisit indirectement <b>tous les pods dans tous les espaces de noms.<\/b>, permettant <code>balance<\/code> d'envoyer des requ\u00eates DNS au service Kubernetes correspondant (qui fonctionne g\u00e9n\u00e9ralement dans l'espace <code>kube-system<\/code>).<\/p>\n<p>Cette approche fonctionne, cependant, elle est <b>trop permissive et peu s\u00e9curis\u00e9e<\/b>, car elle permet d'envoyer des requ\u00eates DNS en dehors du cluster.<\/p>\n<p>Vous pouvez am\u00e9liorer cela par trois \u00e9tapes successives.<\/p>\n<p>1. Autoriser les requ\u00eates DNS uniquement <b>\u00e0 l'int\u00e9rieur<\/b> au cluster en ajoutant <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector: {} # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Autoriser les requ\u00eates DNS uniquement dans l'espace de noms <code>kube-system<\/code>.<\/p>\n<p>Pour cela, il faut ajouter une \u00e9tiquette dans l'espace de noms <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 et l'inclure dans la politique en utilisant <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector:         # &lt;&lt;&lt;\n        matchLabels:             # &lt;&lt;&lt;\n          namespace: kube-system # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Les paranos peuvent aller encore plus loin et restreindre les requ\u00eates DNS \u00e0 un service DNS sp\u00e9cifique dans <code>kube-system<\/code>Dans la section \u00ab Filtrer par espaces de noms et pods \u00bb, nous expliquerons comment y parvenir.<\/p>\n<p>Une autre option est d'autoriser DNS au niveau de l'espace de noms. Dans ce cas, il ne sera pas n\u00e9cessaire de l'ouvrir pour chaque service :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.dns\n  namespace: default\nspec:\n  podSelector: {} # &lt;&lt;&lt;\n  egress:\n  - to:\n    - namespaceSelector: {}\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\nVide <code>podSelector<\/code> s\u00e9lectionne tous les pods dans l'espace de noms.<\/p>\n<p><img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Premier matching et ordre des r\u00e8gles<\/h2>\n<p>\nDans les pare-feux classiques, l'action (\u00ab Autoriser \u00bb ou \u00ab Interdire \u00bb) concernant un paquet est d\u00e9termin\u00e9e par la premi\u00e8re r\u00e8gle \u00e0 laquelle il correspond. <b>Dans Kubernetes, l'ordre des politiques n'a pas d'importance.<\/b><\/p>\n<p>Par d\u00e9faut, lorsque les politiques ne sont pas d\u00e9finies, les communications entre les pods sont autoris\u00e9es et ils peuvent librement \u00e9changer des informations. D\u00e8s que vous commencez \u00e0 formuler des politiques, chaque pod touch\u00e9 par au moins l'une d'entre elles devient isol\u00e9 selon la disjonction (logique OU) de toutes les politiques qui le s\u00e9lectionnent. Les pods non affect\u00e9s par une politique demeurent ouverts.<\/p>\n<p>Il est possible de modifier ce comportement avec une r\u00e8gle de nettoyage.<\/p>\n<h2>R\u00e8gle de nettoyage (\u00ab Interdire \u00bb)<\/h2>\n<p>\nLes politiques de pare-feu interdisent g\u00e9n\u00e9ralement tout trafic qui n'est pas explicitement autoris\u00e9.<\/p>\n<p><b>Il n'existe pas d'action \u00ab interdire \u00bb (deny) dans Kubernetes<\/b>, cependant, un effet similaire peut \u00eatre obtenu avec une politique standard (permissive), en choisissant un groupe de pods sources (ingress) vide :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCette politique s\u00e9lectionne tous les pods dans l'espace de noms et laisse l'ingress ind\u00e9fini, interdisant tout le trafic entrant.<\/p>\n<p>De mani\u00e8re similaire, il est possible de restreindre tout le trafic sortant de l'espace de noms :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all-egress\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNotez que <b>toutes les politiques suppl\u00e9mentaires permettant le trafic vers les pods dans l'espace de noms auront la priorit\u00e9 sur cette r\u00e8gle<\/b> (similaire \u00e0 l'ajout d'une r\u00e8gle d'autorisation avant une r\u00e8gle d'interdiction dans la configuration du pare-feu).<\/p>\n<h2>Autoriser tout (Any-Any-Any-Allow)<\/h2>\n<p>\nPour cr\u00e9er une politique \u00ab Autoriser tout \u00bb, il est n\u00e9cessaire de compl\u00e9ter la politique restrictive ci-dessus avec un \u00e9l\u00e9ment vide <code>ingress<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\n  namespace: default\nspec:\n  podSelector: {}\n  ingress: # &lt;&lt;&lt;\n  - {}     # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nElle ouvre l'acc\u00e8s depuis <b>tous les pods dans tous les espaces de noms (et toutes les IP) vers n'importe quel pod dans l'espace de noms <code>default<\/code><\/b>. Ce comportement est activ\u00e9 par d\u00e9faut, donc il n'est g\u00e9n\u00e9ralement pas n\u00e9cessaire de le d\u00e9finir \u00e0 nouveau. Cependant, il peut parfois \u00eatre n\u00e9cessaire de d\u00e9sactiver temporairement certaines autorisations sp\u00e9cifiques pour diagnostiquer un probl\u00e8me.<\/p>\n<p>La r\u00e8gle peut \u00eatre affin\u00e9e pour autoriser l'acc\u00e8s uniquement \u00e0 <b>un ensemble sp\u00e9cifique de pods<\/b> (<code>app:balance<\/code>) dans l'espace de noms <code>default<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all-to-balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  ingress: \n  - {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa politique suivante autorise tout le trafic entrant (ingress) et sortant (egress), y compris l'acc\u00e8s \u00e0 n'importe quelle IP en dehors du cluster :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\nspec:\n  podSelector: {}\n  ingress:\n  - {}\n  egress:\n  - {}\n  policyTypes:\n  - Ingress\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Union de plusieurs politiques<\/h2>\n<p>\nLes politiques sont combin\u00e9es \u00e0 l'aide d'un OU logique \u00e0 trois niveaux; les autorisations de chaque pod sont \u00e9tablies en fonction de la disjonction de toutes les politiques qui le concernent :<\/p>\n<p>1. Dans les champs <code>from<\/code> et <code>to<\/code> vous pouvez d\u00e9finir trois types d'\u00e9l\u00e9ments (tous combin\u00e9s par OU) :<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 s\u00e9lectionne l'espace de noms dans son ensemble ;<\/li>\n<li> <code>podSelector<\/code> \u2014 s\u00e9lectionne des pods ;<\/li>\n<li> <code>ipBlock<\/code> \u2014 s\u00e9lectionne une sous-r\u00e9seau.<\/li>\n<\/ul>\n<p>\nDans ce cas, le nombre d'\u00e9l\u00e9ments (m\u00eame identiques) dans les sous-sections <code>from<\/code>\/<code>to<\/code> n'est pas limit\u00e9. Tous seront combin\u00e9s par un OU logique.<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. L'int\u00e9rieur d'une politique section <code>ingress<\/code> peut contenir de nombreux \u00e9l\u00e9ments <code>from<\/code> (qui sont combin\u00e9s avec un OU logique). De m\u00eame, la section <code>egress<\/code> peut inclure de nombreux \u00e9l\u00e9ments <code>to<\/code> (qui sont \u00e9galement combin\u00e9s avec une disjonction) :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Diff\u00e9rentes politiques sont \u00e9galement combin\u00e9es avec un OU logique<\/p>\n<p>Mais lors de leur combinaison, il existe une restriction, \u00e0 laquelle <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">a indiqu\u00e9<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes peut combiner des politiques uniquement avec diff\u00e9rents <code>policyTypes<\/code> (<code>Ingress<\/code> ou <code>Egress<\/code>). Les politiques d\u00e9finissant l'ingress (ou l'egress) se substitueront les unes aux autres.<\/p>\n<h2>Relation entre les espaces de noms<\/h2>\n<p>\nPar d\u00e9faut, l'\u00e9change d'informations entre les espaces de noms est autoris\u00e9. Cela peut \u00eatre modifi\u00e9 par une politique restrictive qui limitera le trafic sortant et\/ou entrant vers l'espace de noms (voir \u00ab R\u00e8gle de nettoyage \u00bb ci-dessus).<\/p>\n<p>En bloquant l'acc\u00e8s \u00e0 l'espace de noms (voir \u00ab R\u00e8gle de nettoyage \u00bb ci-dessus), vous pouvez faire des exceptions \u00e0 la politique restrictive, en autorisant les connexions d'un espace de noms sp\u00e9cifique gr\u00e2ce \u00e0 <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: # &lt;&lt;&lt;\n        matchLabels:\n          namespace: default\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn cons\u00e9quence, tous les pods dans l'espace de noms <code>default<\/code> auront acc\u00e8s aux pods <code>postgres<\/code> dans l'espace de noms <code>database<\/code>. Mais que faire si vous souhaitez ouvrir l'acc\u00e8s \u00e0 <code>postgres<\/code> seulement \u00e0 des pods sp\u00e9cifiques dans l'espace de noms <code>default<\/code>?<\/p>\n<h2>Filtrer par espaces de noms Et pods<\/h2>\n<p>\nKubernetes version 1.11 et plus permet de combiner des op\u00e9rateurs <code>namespaceSelector<\/code> et <code>podSelector<\/code> avec une logique ET. Cela ressemble \u00e0 ceci :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector:\n        matchLabels:\n          namespace: default\n      podSelector: # &lt;&lt;&lt;\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPourquoi cela est-il interpr\u00e9t\u00e9 comme un ET au lieu d'un OU habituel ?<\/p>\n<p>Veuillez noter que <code>podSelector<\/code> ne commence pas par un tiret. En YAML, cela signifie que <code>podSelector<\/code> et celui qui le pr\u00e9c\u00e8de <code>namespaceSelector<\/code> sont li\u00e9s au m\u00eame \u00e9l\u00e9ment de la liste. Par cons\u00e9quent, ils sont combin\u00e9s avec un ET.<\/p>\n<p>Ajouter un tiret devant <code>podSelector<\/code> conduira \u00e0 la cr\u00e9ation d'un nouvel \u00e9l\u00e9ment de liste qui sera combin\u00e9 avec le pr\u00e9c\u00e9dent <code>namespaceSelector<\/code> \u00e0 l'aide de l'op\u00e9rateur logique OU.<\/p>\n<p>Pour s\u00e9lectionner des pods avec un label sp\u00e9cifique <b>dans tous les espaces de noms<\/b>, entrez vide <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: {}\n      podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Des \u00e9tiquettes multiples sont combin\u00e9es avec ET<\/h2>\n<p>\nLes r\u00e8gles du pare-feu avec plusieurs objets (h\u00f4tes, r\u00e9seaux, groupes) sont combin\u00e9es \u00e0 l'aide de l'op\u00e9rateur logique OU. La r\u00e8gle suivante sera appliqu\u00e9e si la source du paquet correspond \u00e0 <code>Host_1<\/code> OU <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Source | Destination | Service | Action |\n| ----------------------------------------|\n| Host_1 | Subnet_A    | HTTPS   | Allow  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nEn revanche, dans Kubernetes, diff\u00e9rentes \u00e9tiquettes sont <code>podSelector<\/code> ou <code>namespaceSelector<\/code> combin\u00e9es par l'op\u00e9rateur logique ET. Par exemple, la r\u00e8gle suivante s\u00e9lectionnera des pods ayant les deux \u00e9tiquettes <code>role=db<\/code> Et <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nLa m\u00eame logique s'applique \u00e0 tous les types d'op\u00e9rateurs : s\u00e9lecteurs d'objectifs politiques, s\u00e9lecteurs de pods et s\u00e9lecteurs d'espaces de noms.<\/p>\n<h2>Sous-r\u00e9seaux et adresses IP (IPBlocks)<\/h2>\n<p>\nPour segmenter le r\u00e9seau, les pare-feu utilisent des VLAN, des adresses IP et des sous-r\u00e9seaux.<\/p>\n<p>Dans Kubernetes, les adresses IP sont attribu\u00e9es aux pods automatiquement et peuvent changer fr\u00e9quemment, c'est pourquoi des labels sont utilis\u00e9s pour s\u00e9lectionner des pods et des espaces de noms dans les politiques r\u00e9seau.<\/p>\n<p>Sous-r\u00e9seaux (<code>ipBlocks<\/code>) sont utilis\u00e9s pour g\u00e9rer les connexions externes (Nord-Sud) entrantes (ingress) ou sortantes (egress). Par exemple, cette politique ouvre \u00e0 tous les pods de l'espace de noms <code>default<\/code> l'acc\u00e8s au service DNS de Google :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-dns\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 8.8.8.8\/32\n    ports:\n    - protocol: UDP\n      port: 53<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn s\u00e9lecteur de pods vide dans cet exemple signifie \u00ab choisir tous les pods dans l'espace de noms \u00bb.<\/p>\n<p>Cette politique ouvre l'acc\u00e8s uniquement \u00e0 8.8.8.8 ; l'acc\u00e8s \u00e0 toute autre IP est interdit. Ainsi, vous avez en fait bloqu\u00e9 l'acc\u00e8s au service DNS interne de Kubernetes. Si vous souhaitez n\u00e9anmoins l'ouvrir, veuillez le pr\u00e9ciser explicitement.<\/p>\n<p>Habituellement <code>ipBlocks<\/code> et <code>les podSelectors<\/code> sont mutuellement exclusifs, car les adresses IP internes des pods ne sont pas utilis\u00e9es dans <code>ipBlocks<\/code>. En sp\u00e9cifiant <b>les IP internes des pods<\/b>, vous autoriserez effectivement les connexions vers\/depuis les pods avec ces adresses. En pratique, vous ne saurez pas quelle adresse IP utiliser, c'est pourquoi il ne faut pas les appliquer pour s\u00e9lectionner des pods.<\/p>\n<p>Comme contre-exemple, la politique suivante inclut toutes les IP et, par cons\u00e9quent, permet l'acc\u00e8s \u00e0 tous les autres pods :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVous pouvez ouvrir l'acc\u00e8s uniquement aux IP externes, en excluant les adresses IP internes des pods. Par exemple, si la sous-r\u00e9seau de votre pod est 10.16.0.0\/14 :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0\n        except:\n        - 10.16.0.0\/14<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Ports et protocoles<\/h2>\n<p>\nEn g\u00e9n\u00e9ral, les pods \u00e9coutent un seul port. Cela signifie qu'il est suffisant de ne pas sp\u00e9cifier les num\u00e9ros de port dans les politiques et de laisser tout par d\u00e9faut. Cependant, il est recommand\u00e9 de rendre les politiques aussi restrictives que possible, donc dans certains cas, il est toujours possible de sp\u00e9cifier des ports :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;\n      - port: 443      # &lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;\n      - port: 80       # &lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNotez que le s\u00e9lecteur <code>ports<\/code> s'applique \u00e0 tous les \u00e9l\u00e9ments dans le bloc <code>to<\/code> ou <code>from<\/code>, dans lequel il est contenu. Pour sp\u00e9cifier des ports diff\u00e9rents pour diff\u00e9rents ensembles d'\u00e9l\u00e9ments, divisez <code>ingress<\/code> ou <code>egress<\/code> en plusieurs sous-sections avec <code>to<\/code> ou <code>from<\/code> et dans chacune sp\u00e9cifiez vos ports :<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    ports:             # &lt;&lt;&lt;\n     - port: 443       # &lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;\n     - port: 80        # &lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduction aux politiques r\u00e9seau Kubernetes pour les professionnels de la s\u00e9curit\u00e9\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFonctionnement des ports par d\u00e9faut :<\/p>\n<ul>\n<li> Si vous omettez compl\u00e8tement la d\u00e9finition des ports (<code>ports<\/code>), cela signifie tous les protocoles et tous les ports ;<\/li>\n<li> Si vous omettez la d\u00e9finition du protocole (<code>protocol<\/code>), cela signifie TCP ;<\/li>\n<li> Si vous omettez la d\u00e9finition du port (<code>port<\/code>), cela signifie tous les ports.<\/li>\n<\/ul>\n<p>\nMeilleure pratique : ne vous fiez pas aux valeurs par d\u00e9faut, sp\u00e9cifiez clairement ce dont vous avez besoin.<\/p>\n<p>Veuillez noter qu'il est n\u00e9cessaire d'utiliser les ports des pods et non ceux des services (plus de d\u00e9tails \u00e0 ce sujet dans le paragraphe suivant).<\/p>\n<h2>Les politiques sont-elles d\u00e9finies pour les pods ou les services ?<\/h2>\n<p>\nEn g\u00e9n\u00e9ral, les pods dans Kubernetes se communiquent entre eux via un service \u2014 un \u00e9quilibreur de charge virtuel qui redirige le trafic vers les pods qui mettent en \u0153uvre le service. On pourrait penser que les politiques r\u00e9seau contr\u00f4lent l'acc\u00e8s aux services, mais ce n'est pas le cas. <b>Les politiques r\u00e9seau Kubernetes fonctionnent avec les ports des pods, et non des services.<\/b><\/p>\n<p>Par exemple, si un service \u00e9coute sur le port 80, mais redirige le trafic vers le port 8080 de ses pods, la politique r\u00e9seau doit sp\u00e9cifier exactement 8080.<\/p>\n<p>Un tel m\u00e9canisme doit \u00eatre reconnu comme sous-optimal : lors de changements dans la structure interne du service (dont les ports sont \u00e9cout\u00e9s par les pods), les politiques r\u00e9seau devront \u00eatre mises \u00e0 jour.<\/p>\n<p>Une nouvelle approche architecturale utilisant le Service Mesh <i>(par exemple, voir Istio ci-dessous \u2014 note du traducteur)<\/i> permet de r\u00e9soudre ce probl\u00e8me.<\/p>\n<h2>Est-il n\u00e9cessaire de d\u00e9finir des r\u00e8gles pour Ingress et Egress ?<\/h2>\n<p>\nLa r\u00e9ponse courte est oui, pour que le pod A puisse communiquer avec le pod B, il faut lui permettre d'\u00e9tablir une connexion sortante (pour cela, il faut configurer la politique d'egress), et le pod B doit pouvoir accepter une connexion entrante (pour cela, il faut une politique d'ingress, respectivement).<\/p>\n<p>Cependant, en pratique, on peut compter sur la politique par d\u00e9faut qui autorise les connexions dans un sens ou dans l'autre.<\/p>\n<p>Si un pod-<b>source<\/b> est s\u00e9lectionn\u00e9 par une ou plusieurs <b>egress<\/b>-politiques, les restrictions qui s'appliquent \u00e0 lui seront d\u00e9finies par leur disjonction. Dans ce cas, il sera n\u00e9cessaire d'autoriser explicitement la connexion au pod-<b>destinataire<\/b>. Si le pod n'est s\u00e9lectionn\u00e9 par aucune politique, son trafic sortant (egress) est par d\u00e9faut autoris\u00e9.<\/p>\n<p>De mani\u00e8re similaire, le devenir du pod-<b>destinataire<\/b>, s\u00e9lectionn\u00e9 par une ou plusieurs <b>ingress<\/b>-politiques sera d\u00e9termin\u00e9 par leur disjonction. Dans ce cas, il est n\u00e9cessaire de lui permettre explicitement de recevoir du trafic du pod source. Si le pod n'est pas s\u00e9lectionn\u00e9 par une politique, tout le trafic entrant (ingress) lui est autoris\u00e9 par d\u00e9faut.<\/p>\n<p>Voir le point \u00ab Stateful ou Stateless \u00bb ci-dessous.<\/p>\n<h2>Journaux<\/h2>\n<p>\nLes politiques r\u00e9seau de Kubernetes ne savent pas journaliser le trafic. Cela complique la d\u00e9termination de l'efficacit\u00e9 de la politique et rend l'analyse en mati\u00e8re de s\u00e9curit\u00e9 tr\u00e8s difficile.<\/p>\n<h2>Contr\u00f4le du trafic vers des services externes<\/h2>\n<p>\nLes politiques r\u00e9seau de Kubernetes ne permettent pas de sp\u00e9cifier un nom de domaine complet (DNS) dans les sections egress. Cela entra\u00eene des d\u00e9sagr\u00e9ments importants lorsqu'il s'agit de limiter le trafic vers des destinataires externes qui n'ont pas d'adresse IP fixe (comme aws.com).<\/p>\n<h2>V\u00e9rification de la politique<\/h2>\n<p>\nLes pare-feu vous avertiront ou m\u00eame refuseront d\u2019accepter une politique erron\u00e9e. Kubernetes effectue \u00e9galement une certaine v\u00e9rification. Lors de la d\u00e9finition d'une politique r\u00e9seau via kubectl, Kubernetes peut affirmer qu'elle est incorrecte et refuser de l'accepter. Dans d'autres cas, Kubernetes acceptera la politique et compl\u00e9tera les d\u00e9tails manquants. Vous pouvez les voir avec la commande :<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nGardez \u00e0 l'esprit que le syst\u00e8me de v\u00e9rification de Kubernetes n'est pas infaillible et peut laisser passer certains types d'erreurs.<\/p>\n<h2>Ex\u00e9cution<\/h2>\n<p>\nKubernetes ne g\u00e8re pas la mise en \u0153uvre des politiques r\u00e9seau lui-m\u00eame, mais agit simplement comme une API de passerelle, d\u00e9l\u00e9guant la lourde t\u00e2che de contr\u00f4le \u00e0 un syst\u00e8me sous-jacent appel\u00e9 Container Networking Interface (CNI). D\u00e9finir des politiques dans un cluster Kubernetes sans assigner le CNI appropri\u00e9 est comparable \u00e0 cr\u00e9er des politiques sur un serveur de gestion de pare-feu sans les appliquer par la suite dans les pare-feu. Vous devez vous assurer de disposer d'un CNI ad\u00e9quat ou, dans le cas des plateformes Kubernetes h\u00e9berg\u00e9es dans le cloud, <i>(vous pouvez consulter la liste des fournisseurs <noindex>ici<\/noindex> \u2014 note de traduction.)<\/i>, d'activer des politiques r\u00e9seau qui \u00e9tabliront le CNI pour vous.<\/p>\n<p>Notez que Kubernetes ne vous avertira pas si vous d\u00e9finissez une politique r\u00e9seau sans CNI auxiliaire appropri\u00e9.<\/p>\n<h3>Stateful ou Stateless ?<\/h3>\n<p>\nTous les CNI Kubernetes auxquels j'ai \u00e9t\u00e9 confront\u00e9 gardent l'\u00e9tat (par exemple, Calico utilise le conntrack de Linux). Cela permet au pod de recevoir des r\u00e9ponses sur la connexion TCP initi\u00e9e sans avoir \u00e0 l'\u00e9tablir \u00e0 nouveau. Cependant, je ne connais aucun standard Kubernetes qui garantirait la conservation de l'\u00e9tat (statefulness).<\/p>\n<h2>Gestion avanc\u00e9e des politiques de s\u00e9curit\u00e9<\/h2>\n<p>\nVoici quelques moyens d'am\u00e9liorer l'efficacit\u00e9 de l'application des politiques de s\u00e9curit\u00e9 dans Kubernetes :<\/p>\n<ol>\n<li> Le mod\u00e8le architectural Service Mesh utilise des conteneurs sidecar pour fournir une t\u00e9l\u00e9m\u00e9trie d\u00e9taill\u00e9e et un contr\u00f4le du trafic au niveau des services. Par exemple, <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Certains fournisseurs de CNI ont enrichi leurs outils pour aller au-del\u00e0 des politiques r\u00e9seau de Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> offre de la transparence et de l'automatisation des politiques r\u00e9seau de Kubernetes.<\/li>\n<\/ol>\n<p>\nLe paquet Tufin Orca g\u00e8re les politiques r\u00e9seau de Kubernetes (et sert de source pour les captures d'\u00e9cran ci-dessus).<\/p>\n<h2>Informations suppl\u00e9mentaires<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Exemples de politiques r\u00e9seau, pr\u00e9par\u00e9s par Ahmet Alp Balkan de GKE.<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Documentation officielle du site Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Guide sur le mod\u00e8le r\u00e9seau de Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Script pour v\u00e9rifier les politiques r\u00e9seau<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclusion<\/h2>\n<p>\nLes politiques r\u00e9seau de Kubernetes offrent un bon ensemble d'outils pour la segmentation des clusters, mais elles sont peu intuitives et pr\u00e9sentent de nombreuses subtilit\u00e9s. Je pense qu'en raison de cette complexit\u00e9, de nombreuses politiques des clusters existants contiennent des erreurs. Des solutions possibles \u00e0 ce probl\u00e8me incluent l'automatisation des d\u00e9finitions de politiques ou l'application d'autres outils de segmentation.<\/p>\n<p>J'esp\u00e8re que ce guide contribuera \u00e0 clarifier certaines questions et \u00e0 r\u00e9soudre les probl\u00e8mes auxquels vous pourriez faire face.<\/p>\n<h2>P.S. de l'auteur<\/h2>\n<p>\nLisez aussi dans notre blog :<\/p>\n<ul>\n<li> \u00ab Retour aux microservices avec Istio \u00bb : <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">partie 1 (introduction aux principales fonctionnalit\u00e9s)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">partie 2 (routage, gestion du trafic)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">partie 3 (s\u00e9curit\u00e9)<\/a><\/noindex>;<\/li>\n<li> \u00ab Guide illustr\u00e9 sur la mise en r\u00e9seau dans Kubernetes \u00bb : <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">parties 1 et 2 (mod\u00e8le r\u00e9seau, r\u00e9seaux superpos\u00e9s)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">partie 3 (services et traitement du trafic)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker et Kubernetes dans des environnements exigeants en mati\u00e8re de s\u00e9curit\u00e9<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 meilleures pratiques en mati\u00e8re de s\u00e9curit\u00e9 dans Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 fa\u00e7ons de (ne pas) devenir une victime de hacking dans Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443190\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0410\u0432\u0442\u043e\u0440 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 Reuven Harrison \u2014 \u0438\u043c\u0435\u0435\u0442 \u0431\u043e\u043b\u0435\u0435 20 \u043b\u0435\u0442 \u043e\u043f\u044b\u0442\u0430 \u0432 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f, \u0430 \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u043e\u043c \u0438 \u0441\u043e\u0443\u0447\u0440\u0435\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Tufin, \u0441\u043e\u0437\u0434\u0430\u044e\u0449\u0435\u0439 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0434\u043b\u044f \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0430\u043c\u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043c\u043e\u0449\u043d\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0434\u043b\u044f \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0441\u0435\u0442\u0438 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435, \u043e\u043d \u0432 \u0442\u043e \u0436\u0435 \u0432\u0440\u0435\u043c\u044f \u0441\u0447\u0438\u0442\u0430\u0435\u0442, \u0447\u0442\u043e \u043e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24432,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32641","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Introduction aux politiques r\u00e9seau de Kubernetes pour les sp\u00e9cialistes de la s\u00e9curit\u00e9 | ProHoster","description":"Ex.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:48:11+00:00","article:modified_time":"2019-10-31T18:48:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32641","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 11:53:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:55:23","updated":"2026-01-21 11:53:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}