{"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\/ro\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota traduc\u0103torului.<\/b>: Autorul articolului \u2014 Reuven Harrison \u2014 are peste 20 de ani de experien\u021b\u0103 \u00een dezvoltarea de software \u0219i, \u00een prezent, este director tehnic \u0219i cofondator al companiei Tufin, care creeaz\u0103 solu\u021bii pentru gestionarea politicilor de securitate. Consider\u00e2nd politicile de re\u021bea Kubernetes ca un instrument destul de puternic pentru segmentarea re\u021belei \u00een cluster, el consider\u0103 totodat\u0103 c\u0103 acestea nu sunt at\u00e2t de u\u0219or de aplicat \u00een practic\u0103. Acest material (destul de voluminos) are scopul de a \u00eembun\u0103t\u0103\u021bi con\u0219tientizarea speciali\u0219tilor \u00een acest domeniu \u0219i de a-i ajuta \u00een crearea configura\u021biilor necesare.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Ast\u0103zi, multe companii aleg din ce \u00een ce mai des Kubernetes pentru a-\u0219i rula aplica\u021biile. Interesul pentru acest software este at\u00e2t de mare \u00eenc\u00e2t unii \u00eel numesc \u201enoua sistem de operare pentru centre de date\u201d. Treptat, Kubernetes (sau k8s) \u00eencepe s\u0103 fie perceput ca o parte critic\u0103 a afacerii, care necesit\u0103 organizarea unor procese de afaceri mature, inclusiv asigurarea securit\u0103\u021bii re\u021belei.<\/p>\n<p>Pentru speciali\u0219tii \u00een securitate, care se confrunt\u0103 cu utilizarea Kubernetes, o adev\u0103rat\u0103 descoperire ar putea fi politica de baz\u0103 a acestei platforme: a permite totul.<\/p>\n<p>Aceguid despre re\u021bele va ajuta s\u0103 \u00een\u021belege\u021bi structura intern\u0103 a politicilor de re\u021bea; s\u0103 \u00een\u021belege\u021bi cum se deosebesc acestea de regulile pentru firewall-urile obi\u0219nuite. De asemenea, vor fi discutate c\u00e2teva capcane \u0219i vor fi date recomand\u0103ri care s\u0103 ajute la protejarea aplica\u021biilor \u00een Kubernetes.<\/p>\n<h2>Politicile de re\u021bea Kubernetes<\/h2>\n<p>\nMecanismul politicilor de re\u021bea Kubernetes permite gestionarea interac\u021biunilor aplica\u021biilor desf\u0103\u0219urate pe platform\u0103 la nivel de re\u021bea (al treilea nivel \u00een modelul OSI). Politicile de re\u021bea nu beneficiaz\u0103 de unele func\u021bii avansate ale firewall-urilor moderne, cum ar fi controlul la nivelul 7 OSI \u0219i detectarea amenin\u021b\u0103rilor, totu\u0219i, ele ofer\u0103 un nivel de baz\u0103 de securitate a re\u021belei, care reprezint\u0103 un punct de plecare decent.<\/p>\n<h2>Politicile de re\u021bea controleaz\u0103 comunic\u0103rile \u00eentre pod-uri<\/h2>\n<p>\nSarcinile de lucru \u00een Kubernetes sunt distribuite pe pod-uri, care constau din unul sau mai multe containere desf\u0103\u0219urate \u00eempreun\u0103. Kubernetes asign\u0103 fiec\u0103rui pod o adres\u0103 IP, accesibil\u0103 din alte pod-uri. Politicile de re\u021bea Kubernetes stabilesc drepturile de acces pentru grupuri de pod-uri \u00een acela\u0219i mod \u00een care grupurile de securitate \u00een cloud sunt folosite pentru a gestiona accesul la instan\u021bele virtuale.<\/p>\n<h2>Definirea politicilor de re\u021bea<\/h2>\n<p>\nCa \u0219i celelalte resurse Kubernetes, politicile de re\u021bea sunt definite \u00een YAML. \u00cen exemplul de mai jos, aplica\u021biei <code>balance<\/code> i se ofer\u0103 acces la <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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Nota traduc\u0103torului.<\/b>: aceast\u0103 captur\u0103 de ecran, la fel ca toate cele similare care urmeaz\u0103, a fost creat\u0103 nu cu instrumente native Kubernetes, ci cu ajutorul uneltelor Tufin Orca, dezvoltat de compania autorului articolului original, men\u021bionat\u0103 la finalul materialului.<\/i><\/p>\n<p>Pentru a defini propria politic\u0103 de re\u021bea, sunt necesare cuno\u0219tin\u021be de baz\u0103 \u00een YAML. Acest limbaj se bazeaz\u0103 pe indentare (care se realizeaz\u0103 cu spa\u021bii, nu cu tabulatoare). Un element cu indentare apar\u021bine celui mai apropiat element cu indentare deasupra sa. Un nou element de list\u0103 \u00eencepe cu un cratim\u0103, toate celelalte elemente av\u00e2nd forma <i>cheie-valoare<\/i>.<\/p>\n<p>Dup\u0103 ce a\u021bi descris politica \u00een YAML, utiliza\u021bi <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, pentru a o crea \u00een cluster:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Specifica\u021bia politicii de re\u021bea<\/h2>\n<p>\nSpecifica\u021bia politicii de re\u021bea Kubernetes include patru elemente:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: define\u0219te pod-urile afectate de aceast\u0103 politic\u0103 (\u021binte) \u2014 obligatorie;<\/li>\n<li> <code>policyTypes<\/code>: indic\u0103 ce tipuri de politici sunt incluse aici: ingress \u0219i\/sau egress \u2014 op\u021bional, dar v\u0103 recomand s\u0103 \u00eel specifica\u021bi clar \u00een toate cazurile;<\/li>\n<li> <code>ingress<\/code>: define\u0219te traficul <b>\u00eentr\u00e2nc<\/b> traficul c\u0103tre pod-urile \u021bint\u0103 \u2014 op\u021bional;<\/li>\n<li> <code>egress<\/code>: define\u0219te traficul <b>traficul<\/b> traficul din pod-urile \u021bint\u0103 \u2014 op\u021bional.<\/li>\n<\/ol>\n<p>\nUn exemplu preluat de pe site-ul Kubernetes (am \u00eenlocuit <code>role<\/code> pe <code>app<\/code>), arat\u0103 cum sunt utilizate toate cele patru elemente:<\/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;&lt;\n    matchLabels:\n      app: db\n  policyTypes:    # &lt;&lt;&lt;&lt;\n  - Ingress\n  - Egress\n  ingress:        # &lt;&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;&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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRe\u021bine\u021bi c\u0103 nu este obligatorie includerea tuturor celor patru elemente. Numai <code>podSelector<\/code>parametru este necesar.<\/p>\n<p>Dac\u0103 omite\u021bi <code>policyTypes<\/code>, politica va fi interpretat\u0103 astfel:<\/p>\n<ul>\n<li> Implicit, se presupune c\u0103 aceasta define\u0219te partea ingress. Dac\u0103 nu exist\u0103 indica\u021bii clare \u00een politic\u0103, sistemul va considera c\u0103 tot traficul este interzis.<\/li>\n<li> Comportamentul pe partea egress va fi determinat de prezen\u021ba sau absen\u021ba corespunz\u0103torului parametru egress.<\/li>\n<\/ul>\n<p>\nPentru a evita erorile, v\u0103 recomand <b>s\u0103 indica\u021bi \u00eentotdeauna \u00een mod explicit <code>policyTypes<\/code><\/b>.<\/p>\n<p>Conform logicii prezentate mai sus, \u00een cazul \u00een care parametrii <code>ingress<\/code> \u0219i \/ sau <code>egress<\/code> sunt omisi, politica va interzice tot traficul (vezi \u201eRegula de cur\u0103\u021bare\u201d mai jos).<\/p>\n<h2>Politica implicit\u0103 este de a permite<\/h2>\n<p>\nDac\u0103 politicile nu sunt definite, Kubernetes permite \u00een mod implicit tot traficul. Toate pod-urile pot comunica liber \u00eentre ele. Din perspectiva securit\u0103\u021bii, acest lucru poate p\u0103rea ilogic, dar aminti\u021bi-v\u0103 c\u0103 Kubernetes a fost creat ini\u021bial de dezvoltatori pentru a asigura interac\u021biunea aplica\u021biilor. Politicile de re\u021bea au fost ad\u0103ugate ulterior.<\/p>\n<h2>Spa\u021biile de nume<\/h2>\n<p>\nSpa\u021biile de nume (Namespaces) sunt un mecanism de colaborare \u00een Kubernetes. Ele sunt destinate izol\u0103rii mediilor logice unul de cel\u0103lalt, \u00een timp ce schimbul de date \u00eentre spa\u021bii este permis \u00een mod implicit.<\/p>\n<p>Ca majoritatea componentelor Kubernetes, politicile de re\u021bea tr\u0103iesc \u00eentr-un anumit spa\u021biu de nume. \u00cen blocul <code>metadata<\/code> pute\u021bi specifica exact cui apar\u021bine politica:<\/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;&lt;\nspec:\n...<\/code><\/pre>\n<p>\nDac\u0103 spa\u021biul de nume din metadate nu este specificat explicit, sistemul va folosi namespace-ul specificat \u00een kubectl (implicit <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nV\u0103 recomand <b>s\u0103 specifica\u021bi explicit namespace-ul<\/b>, dec\u00e2t dac\u0103 elabora\u021bi o politic\u0103 destinat\u0103 mai multor spa\u021bii de nume.<\/p>\n<p><b>Principal<\/b> element <code>podSelector<\/code> \u00een politic\u0103 vor selecta pod-uri din spa\u021biul de nume c\u0103ruia \u00eei apar\u021bine politica (nu are acces la pod-urile din alt spa\u021biu de nume).<\/p>\n<p>\u00cen mod similar, selec\u021biile de pod-uri <b>\u00een blocurile ingress \u0219i egress<\/b> pot alege doar pod-uri din propriul spa\u021biu de nume, cu excep\u021bia cazului \u00een care nu le combina\u021bi folosind <code>namespaceSelector<\/code> (vom discuta despre asta \u00een sec\u021biunea \u201eFiltrare dup\u0103 spa\u021bii de nume \u0219i pod-uri\u201d).<\/p>\n<h2>Reguli de denumire a politicilor<\/h2>\n<p>\nNumele politicilor sunt unice \u00eentr-un singur spa\u021biu de nume. Nu pot exista dou\u0103 politici cu acela\u0219i nume \u00eentr-un singur spa\u021biu, dar pot exista politici cu acelea\u0219i denumiri \u00een spa\u021bii diferite. Acest lucru este convenabil c\u00e2nd dori\u021bi s\u0103 aplica\u021bi aceea\u0219i politic\u0103 pe mai multe spa\u021bii.<\/p>\n<p>\u00cemi place \u00een mod special unul dintre modurile de denumire. Acesta const\u0103 \u00een combinarea numelui spa\u021biului de nume cu pod-urile \u021bint\u0103. De exemplu:<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Etichete<\/h2>\n<p>\nLa obiectele Kubernetes, cum ar fi pod-urile \u0219i spa\u021biile de nume, pot fi ata\u0219ate etichete personalizate. Etichetele (<i>labels<\/i> \u2014 sunt echivalentul etichetelor din cloud. Politicile de re\u021bea Kubernetes folosesc etichetele pentru a selecta <b>pod-uri<\/b>, la care se aplic\u0103:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 sau <b>spa\u021bii de nume<\/b>, la care se aplic\u0103. \u00cen acest exemplu, se selecteaz\u0103 toate pod-urile din spa\u021biile de nume cu etichetele corespunz\u0103toare:<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\nO singur\u0103 avertizare: atunci c\u00e2nd utiliza\u021bi <code>namespaceSelector<\/code> <b>asigura\u021bi-v\u0103 c\u0103 spa\u021biile de nume selectate con\u021bin eticheta necesar\u0103<\/b>. Re\u021bine\u021bi c\u0103 spa\u021biile de nume \u00eencorporate, cum ar fi <code>default<\/code> \u0219i <code>kube-system<\/code>, nu con\u021bin etichete \u00een mod default.<\/p>\n<p>Pentru a ad\u0103uga o etichet\u0103 unui spa\u021biu de nume, face\u021bi urm\u0103toarele:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nAici, namespace-ul din sec\u021biune <code>metadata<\/code> trebuie s\u0103 fac\u0103 referire la numele efectiv al spa\u021biului, nu la etichet\u0103:<\/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>Surs\u0103 \u0219i destinatar<\/h2>\n<p>\nPoliticile pentru firewall-uri constau din reguli cu surse \u0219i destina\u021bii. Politicile de re\u021bea Kubernetes sunt definite pentru o \u021bint\u0103 \u2014 un set de pod-uri la care se aplic\u0103, \u0219i apoi stabilesc reguli pentru traficul intrat (ingress) \u0219i\/sau ie\u0219it (egress). \u00cen exemplul nostru, \u021binta politicii va fi toate pod-urile din spa\u021biul de nume <code>default<\/code> cu eticheta cu cheia <code>app<\/code> \u0219i valoarea <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;&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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSubsec\u021biune <code>ingress<\/code> \u00een aceast\u0103 politic\u0103 deschide traficul de intrare c\u0103tre pod-urile \u021bint\u0103. Cu alte cuvinte, ingress ac\u021bioneaz\u0103 ca surs\u0103, iar \u021binta este destinatarul corespunz\u0103tor. Similar, egress este destinatarul, iar \u021binta este sursa acestuia.<\/p>\n<p><img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Aceasta este echivalent\u0103 cu dou\u0103 reguli pentru firewall: Ingress \u2192 \u021aint\u0103; \u021aint\u0103 \u2192 Egress.<\/i><\/p>\n<h2>Egress \u0219i DNS (important!)<\/h2>\n<p>\nLimit\u00e2nd traficul de ie\u0219ire, <b>presta\u021bi o aten\u021bie special\u0103 asupra DNS-ului<\/b> \u2014 Kubernetes folose\u0219te acest serviciu pentru a maparea serviciilor cu adrese IP. De exemplu, urm\u0103toarea politic\u0103 nu va func\u021biona deoarece nu a\u021bi permis aplica\u021biei <code>balance<\/code> s\u0103 acceseze DNS-ul:<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO pute\u021bi corecta deschiz\u00e2nd accesul la serviciul 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;&lt;\n    ports:            # &lt;&lt;&lt;&lt;\n    - protocol: UDP   # &lt;&lt;&lt;&lt;\n      port: 53        # &lt;&lt;&lt;&lt;\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUltimul element <code>to<\/code> \u2014 gol \u0219i, prin urmare, selecteaz\u0103 indirect <b>toate pod-urile din toate spa\u021biile de nume<\/b>, permi\u021b\u00e2nd <code>balance<\/code> trimiterea cererilor DNS c\u0103tre serviciul corespunz\u0103tor Kubernetes (care func\u021bioneaz\u0103 de obicei \u00een spa\u021biul <code>kube-system<\/code>).<\/p>\n<p>Aceast\u0103 abordare func\u021bioneaz\u0103, totu\u0219i este <b>excesiv permisiv\u0103 \u0219i nesigur\u0103<\/b>, deoarece permite direc\u021bionarea cererilor DNS \u00een afara clusterei.<\/p>\n<p>Pute\u021bi s\u0103 o \u00eembun\u0103t\u0103\u021bi\u021bi prin trei pa\u0219i succesivi.<\/p>\n<p>1. Permite\u021bi cererile DNS doar <b>inside<\/b> clusterei, ad\u0103ug\u00e2nd <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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Permite\u021bi cererile DNS doar \u00een spa\u021biul de nume <code>kube-system<\/code>.<\/p>\n<p>Pentru aceasta, trebuie ad\u0103ugat un eticheta \u00een spa\u021biul de nume <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 \u0219i specifica\u021bi-l \u00een politic\u0103 folosind <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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Paranoicii pot merge \u0219i mai departe \u0219i pot restric\u021biona cererile DNS la un anumit serviciu DNS \u00een <code>kube-system<\/code>. \u00cen sec\u021biunea \u201eFiltrare dup\u0103 spa\u021bii de nume \u0219i pod-uri\u201d vom discuta cum s\u0103 realiz\u0103m acest lucru.<\/p>\n<p>O alt\u0103 variant\u0103 este s\u0103 permite\u021bi DNS la nivel de spa\u021biu de nume. \u00cen acest caz, nu va trebui s\u0103 fie deschis pentru fiecare serviciu:<\/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>\nGol <code>podSelector<\/code> alege toate pod-urile din spa\u021biul de nume.<\/p>\n<p><img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>\u00cent\u00e2lnirea ini\u021bial\u0103 \u0219i ordinea regulilor<\/h2>\n<p>\n\u00cen firewall-urile obi\u0219nuite, ac\u021biunea (\u201ePermite\u201d sau \u201eBlocheaz\u0103\u201d) \u00een leg\u0103tur\u0103 cu un pachet este determinat\u0103 de prima regul\u0103 care i se aplic\u0103. <b>\u00cen Kubernetes, ordinea politicilor nu are nicio importan\u021b\u0103.<\/b><\/p>\n<p>\u00cen mod implicit, atunci c\u00e2nd politicile nu sunt specificate, comunic\u0103rile \u00eentre pod-uri sunt permise \u0219i acestea pot comunica liber. Odat\u0103 ce \u00eencepe\u021bi s\u0103 defini\u021bi politici, fiecare pod afectat de m\u0103car una dintre ele devine izolat conform disjunc\u021biei (logic OR) tuturor politicilor care l-au selectat. Pod-urile care nu sunt afectate de nicio politic\u0103 r\u0103m\u00e2n deschise.<\/p>\n<p>Aceast\u0103 comportare poate fi modificat\u0103 folosind o regul\u0103 de cur\u0103\u021bare.<\/p>\n<h2>Regula de cur\u0103\u021bare (\u201eBlocheaz\u0103\u201d)<\/h2>\n<p>\nPoliticile firewall-urilor blocheaz\u0103 de obicei orice trafic care nu este explicit permis.<\/p>\n<p><b>\u00cen Kubernetes, nu exist\u0103 o ac\u021biune \u201ea bloca\u201d (deny),<\/b>, \u00eens\u0103 un efect similar poate fi ob\u021binut cu o politic\u0103 obi\u0219nuit\u0103 (de permisiune), aleg\u00e2nd un grup gol de pod-uri-surs\u0103 (ingress):<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAceast\u0103 politic\u0103 selecteaz\u0103 toate pod-urile din spa\u021biul de nume \u0219i las\u0103 ingress-ul nedefinit, interzic\u00e2nd tot traficul de intrare.<\/p>\n<p>\u00cen mod similar, se poate restric\u021biona tot traficul de ie\u0219ire din spa\u021biul de nume:<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRe\u021bine\u021bi c\u0103 <b>orice politici suplimentare care permit traficul c\u0103tre pod-urile din spa\u021biul de nume vor avea prioritate fa\u021b\u0103 de aceast\u0103 regul\u0103<\/b> (similar cu ad\u0103ugarea unei reguli de permisiune \u00eenaintea unei reguli de interdic\u021bie \u00een configura\u021bia unui firewall).<\/p>\n<h2>Permite tot (Any-Any-Any-Allow)<\/h2>\n<p>\nPentru a crea o politic\u0103 \"Permite tot\", trebuie s\u0103 completa\u021bi politica de interdic\u021bie de mai sus cu un element gol <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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAceasta deschide accesul de la <b>toate pod-urile din toate spa\u021biile de nume (\u0219i toate IP-urile) c\u0103tre orice pod din spa\u021biul de nume <code>default<\/code><\/b>. Un asemenea comportament este activat implicit, a\u0219a c\u0103, \u00een general, nu este necesar\u0103 definirea sa suplimentar. Cu toate acestea, uneori poate fi necesar s\u0103 dezactiva\u021bi temporar anumite permisiuni specifice pentru diagnosticarea problemei.<\/p>\n<p>Regula poate fi restr\u00e2ns\u0103 \u0219i poate permite accesul doar la <b>unui set specific de pod-uri<\/b> (<code>app:balance<\/code>) din spa\u021biul de nume <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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUrm\u0103toarea politic\u0103 permite tot traficul de intrare (ingress) \u0219i ie\u0219ire (egress), inclusiv accesul c\u0103tre orice IP din afara cluster-ului:<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Combinarea mai multor politici<\/h2>\n<p>\nPoliticile sunt combinatorii folosind logica OR la trei niveluri; permisiunile fiec\u0103rui pod sunt stabilite conform disjunc\u021biei tuturor politicilor care \u00eel afecteaz\u0103:<\/p>\n<p>1. \u00cen c\u00e2mpurile <code>from<\/code> \u0219i <code>to<\/code> se pot defini trei tipuri de elemente (toate acestea sunt combinate prin OR):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 selecteaz\u0103 \u00eentregul spa\u021biu de nume;<\/li>\n<li> <code>podSelector<\/code> \u2014 selecteaz\u0103 pod-urile;<\/li>\n<li> <code>ipBlock<\/code> \u2014 selecteaz\u0103 o subre\u021bea.<\/li>\n<\/ul>\n<p>\n\u00cen aceast\u0103 situa\u021bie, num\u0103rul de elemente (chiar \u0219i identice) \u00een subdiviziuni <code>from<\/code>\/<code>to<\/code> nu este limitat. Toate acestea vor fi combinate printr-o logic\u0103 OR.<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. \u00cen cadrul politicii, sec\u021biunea <code>ingress<\/code> poate avea mai multe elemente <code>from<\/code> (se unesc logic prin OR). \u00cen mod similar, sec\u021biunea <code>egress<\/code> poate include mai multe elemente <code>to<\/code> (de asemenea se unesc prin disjunc\u021bie):<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Politicile diferite sunt, de asemenea, unite logic prin OR<\/p>\n<p>Dar c\u00e2nd sunt unite, exist\u0103 o restric\u021bie, la care <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">am indicat<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes poate combina politicile doar cu diferite <code>policyTypes<\/code> (<code>Ingress<\/code> sau <code>Egress<\/code>). Politicile care definesc ingress (sau egress) vor suprascrie una pe alta.<\/p>\n<h2>Leg\u0103tura \u00eentre spa\u021biile de nume<\/h2>\n<p>\n\u00cen mod implicit, schimbul de informa\u021bii \u00eentre spa\u021biile de nume este permis. Acest lucru poate fi modificat printr-o politic\u0103 restrictiv\u0103, care va limita traficul de ie\u0219ire \u0219i\/sau de intrare \u00een spa\u021biul de nume (vezi \"Regula de cur\u0103\u021bare\" de mai sus).<\/p>\n<p>Bloc\u00e2nd accesul \u00eentr-un spa\u021biu de nume (vezi \"Regula de cur\u0103\u021bare\" de mai sus), po\u021bi face excep\u021bii \u00een politica restrictiv\u0103, permit\u00e2nd conexiuni dintr-un anumit spa\u021biu de nume prin <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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCa rezultat, toate pod-urile din spa\u021biul de nume <code>default<\/code> vor avea acces la pod-uri <code>postgres<\/code> \u00een spa\u021biul de nume <code>database<\/code>. Dar ce se \u00eent\u00e2mpl\u0103 dac\u0103 vrei s\u0103 deschizi accesul doar la anumite pod-uri din spa\u021biul de nume <code>postgres<\/code> numai la pod-urile specifice din spa\u021biul de nume <code>default<\/code>?<\/p>\n<h2>Filtru pe spa\u021biile de nume \u0219i pod-uri<\/h2>\n<p>\nprin intermediul logicii AND. Iat\u0103 cum arat\u0103: <code>namespaceSelector<\/code> \u0219i <code>podSelector<\/code> 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<\/p>\n<pre><code class=\"plaintext\">De ce este interpretat ca AND \u00een loc de obi\u0219nuitul OR?<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nnu \u00eencepe cu o linie de defalcare. \u00cen YAML, aceasta \u00eenseamn\u0103 c\u0103<\/p>\n<p>Re\u021bine\u021bi c\u0103 <code>podSelector<\/code> \u0219i cel care o precede <code>podSelector<\/code> se refer\u0103 la acela\u0219i element din list\u0103. Prin urmare, ele sunt unite logic prin AND. <code>namespaceSelector<\/code> Ad\u0103ugarea unei linii de defalcare \u00een fa\u021ba<\/p>\n<p>Ad\u0103ugarea unei liniu\u021be \u00eenainte de <code>podSelector<\/code> va duce la crearea unui nou element de list\u0103, care se va combina cu cel anterior <code>namespaceSelector<\/code> folosind operatorul logic OR.<\/p>\n<p>Pentru a selecta pod-uri cu o etichet\u0103 specific\u0103 <b>\u00een toate spa\u021biile de nume<\/b>, introduce\u021bi un vid <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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Etichetele multiple sunt combinate cu AND<\/h2>\n<p>\nRegulile pentru firewall-uri cu obiecte multiple (gazde, re\u021bele, grupuri) sunt combinate folosind operatorul logic OR. Urm\u0103toarea regul\u0103 va fi aplicat\u0103 dac\u0103 sursa pachetului se potrive\u0219te cu <code>Host_1<\/code> SAU <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>\n\u00cen schimb, \u00een Kubernetes etichetele diferite din <code>podSelector<\/code> sau <code>namespaceSelector<\/code> sunt combinate cu AND. De exemplu, urm\u0103toarea regul\u0103 va selecta pod-urile care au ambele etichete, <code>role=db<\/code> \u0218i <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nAceea\u0219i logic\u0103 se aplic\u0103 tuturor tipurilor de operatori: selec\u021biilor \u021bint\u0103 ale politicii, selec\u021biilor de pod-uri \u0219i selec\u021biilor spa\u021biilor de nume.<\/p>\n<h2>Subre\u021bele \u0219i adrese IP (IPBlocks)<\/h2>\n<p>\nPentru segmentarea re\u021belei, firewall-urile utilizeaz\u0103 VLAN-uri, adrese IP \u0219i subre\u021bele.<\/p>\n<p>\u00cen Kubernetes, adresele IP sunt atribuite pod-urilor automat \u0219i pot fi schimbate frecvent, de aceea etichetele sunt folosite pentru a selecta pod-uri \u0219i spa\u021bii de nume \u00een politicile de re\u021bea.<\/p>\n<p>Subre\u021bele (<code>ipBlocks<\/code>) sunt folosite \u00een gestionarea conexiunilor externe (North-South) de intrare (ingress) sau de ie\u0219ire (egress). De exemplu, aceast\u0103 politic\u0103 deschide tuturor pod-urilor din spa\u021biul de nume <code>default<\/code> acces la serviciul DNS 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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn selector gol de pod-uri \u00een acest exemplu \u00eenseamn\u0103 \u201ea alege toate pod-urile din spa\u021biul de nume\u201d.<\/p>\n<p>Aceast\u0103 politic\u0103 ofer\u0103 acces doar la 8.8.8.8; accesul la orice alt\u0103 adres\u0103 IP este interzis. A\u0219adar, \u00een esen\u021b\u0103, a\u021bi blocat accesul la serviciul intern DNS Kubernetes. Dac\u0103 dori\u021bi totu\u0219i s\u0103-l deschide\u021bi, specifica\u021bi acest lucru explicit.<\/p>\n<p>De obicei <code>ipBlocks<\/code> \u0219i <code>podSelectors<\/code> sunt excludente, deoarece adresele IP interne ale pod-urilor nu sunt folosite \u00een <code>ipBlocks<\/code>. Specific\u00e2nd <b>adresele IP interne ale pod-urilor<\/b>, de fapt, vei permite conexiuni c\u0103tre\/de la pod-uri cu aceste adrese. \u00cen practic\u0103, nu vei \u0219ti ce adres\u0103 IP s\u0103 folose\u0219ti, de aceea nu ar trebui s\u0103 fie aplicate pentru alegerea pod-urilor.<\/p>\n<p>Ca exemplu contra, urm\u0103toarea politic\u0103 include toate IP-urile \u0219i, prin urmare, permite accesul la toate celelalte pod-uri:<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPo\u021bi deschide accesul doar la IP-uri externe, excluz\u00e2nd adresele IP interne ale pod-urilor. De exemplu, dac\u0103 subnetul pod-ului t\u0103u este 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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Porturi \u0219i protocoale<\/h2>\n<p>\nDe obicei, pod-urile ascult\u0103 un singur port. Aceasta \u00eenseamn\u0103 c\u0103 po\u021bi pur \u0219i simplu s\u0103 nu specifici numerele porturilor \u00een politici \u0219i s\u0103 la\u0219i totul la valoarea implicit\u0103. Totu\u0219i, politicile ar trebui s\u0103 fie c\u00e2t mai restrictive, de aceea, \u00een unele cazuri, este totu\u0219i posibil s\u0103 specifici porturile:<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nObserva\u021bi c\u0103 selectorul <code>porturi<\/code> se aplic\u0103 la toate elementele din blocul <code>to<\/code> sau <code>from<\/code>, care \u00eel con\u021bine. Pentru a specifica porturi diferite pentru diferite seturi de elemente, \u00eemp\u0103r\u021bi\u021bi <code>ingress<\/code> sau <code>egress<\/code> \u00een mai multe subsec\u021biuni cu <code>to<\/code> sau <code>from<\/code> \u0219i \u00een fiecare specifica\u021bi porturile dvs.:<\/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=\"Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFunc\u021bionarea porturilor implicite:<\/p>\n<ul>\n<li> Dac\u0103 omite\u021bi complet defini\u021bia porturilor (<code>porturi<\/code>), aceasta \u00eenseamn\u0103 toate protocoalele \u0219i toate porturile;<\/li>\n<li> Dac\u0103 omite\u021bi defini\u021bia protocolului (<code>protocol<\/code>), aceasta \u00eenseamn\u0103 TCP;<\/li>\n<li> Dac\u0103 omite\u021bi defini\u021bia portului (<code>port<\/code>), aceasta \u00eenseamn\u0103 toate porturile.<\/li>\n<\/ul>\n<p>\nCele mai bune practici: nu v\u0103 baza\u021bi pe valorile implicite, specifica\u021bi clar ce ave\u021bi nevoie.<\/p>\n<p>V\u0103 rug\u0103m s\u0103 re\u021bine\u021bi c\u0103 trebuie s\u0103 utiliza\u021bi porturile pod-urilor, nu ale serviciilor (mai multe detalii \u00een paragraful urm\u0103tor).<\/p>\n<h2>Politicile sunt definite pentru pod-uri sau servicii?<\/h2>\n<p>\nDe obicei, pod-urile din Kubernetes comunic\u0103 \u00eentre ele prin intermediul serviciului \u2014 un echilibrator de \u00eenc\u0103rcare virtual care redirec\u021bioneaz\u0103 traficul c\u0103tre pod-urile care implementeaz\u0103 serviciul. S-ar putea crede c\u0103 politicile de re\u021bea controleaz\u0103 accesul la servicii, dar nu este a\u0219a. <b>Politicile de re\u021bea Kubernetes func\u021bioneaz\u0103 cu porturile pod-urilor, nu cu serviciile.<\/b><\/p>\n<p>De exemplu, dac\u0103 un serviciu ascult\u0103 pe portul 80, dar redirec\u021bioneaz\u0103 traficul c\u0103tre portul 8080 al pod-urilor sale, \u00een politica de re\u021bea trebuie specificat exact 8080.<\/p>\n<p>Un astfel de mecanism ar trebui considerat suboptimal: atunci c\u00e2nd se schimb\u0103 structura intern\u0103 a serviciului (porturile c\u0103ruia sunt ascultate de pod-uri), va fi necesar s\u0103 actualiza\u021bi politicile de re\u021bea.<\/p>\n<p>O nou\u0103 abordare arhitectural\u0103 folosind Service Mesh <i>(de exemplu, consulta\u021bi Istio mai jos \u2014 n. trad.)<\/i> permite abordarea acestei probleme.<\/p>\n<h2>Este necesar s\u0103 se defineasc\u0103 at\u00e2t Ingress, c\u00e2t \u0219i Egress?<\/h2>\n<p>\nR\u0103spunsul scurt este da, pentru ca pod-ul A s\u0103 se poat\u0103 conecta la pod-ul B, este necesar s\u0103 i se permit\u0103 s\u0103 stabileasc\u0103 o conexiune de ie\u0219ire (pentru aceasta, trebuie configurat\u0103 politica egress), iar pod-ul B trebuie s\u0103 fie capabil s\u0103 primeasc\u0103 o conexiune de intrare (prin urmare, este necesar\u0103 o politic\u0103 ingress).<\/p>\n<p>Cu toate acestea, \u00een practic\u0103, se poate conta pe politica implicit\u0103, care permite conexiuni \u00eentr-o direc\u021bie sau \u00een ambele.<\/p>\n<p>Dac\u0103 un pod-<b>sursa<\/b> este selectat de una sau mai multe <b>egress<\/b>-politici, restric\u021biile impuse vor fi definite de disjunc\u021bia acestora. \u00cen acest caz, va fi necesar s\u0103 se permit\u0103 explicit conectarea la pod-ul-<b>destinat<\/b>. Dac\u0103 pod-ul nu este selectat de nicio politic\u0103, traficul s\u0103u de ie\u0219ire (egress) este permis \u00een mod implicit.<\/p>\n<p>\u00cen mod similar, soarta pod-ului-<b>destinat<\/b>, selectat de una sau mai multe <b>ingress<\/b>-politicile vor fi determinate de disjunc\u021bia lor. \u00cen acest caz, trebuie explicit permis\u0103 primirea traficului de la pod-ul-surs\u0103. Dac\u0103 pod-ul nu este selectat de vreo politic\u0103, tot traficul de intrare (ingress) pentru acesta este permis implicit.<\/p>\n<p>Consulta\u021bi sec\u021biunea \u201eStateful sau Stateless\u201d mai jos.<\/p>\n<h2>Jurnale<\/h2>\n<p>\nPoliticile de re\u021bea Kubernetes nu pot \u00eenregistra traficul. Acest lucru \u00eengreuneaz\u0103 determinarea dac\u0103 o politic\u0103 func\u021bioneaz\u0103 corect \u0219i complic\u0103 foarte mult analiza \u00een domeniul securit\u0103\u021bii.<\/p>\n<h2>Controlul traficului c\u0103tre servicii externe<\/h2>\n<p>\nPoliticile de re\u021bea Kubernetes nu permit specificarea unui nume de domeniu complet (DNS) \u00een sec\u021biunile egress. Acest lucru conduce la dificult\u0103\u021bi semnificative atunci c\u00e2nd \u00eencerca\u021bi s\u0103 restric\u021biona\u021bi traficul c\u0103tre destina\u021bii externe care nu au o adres\u0103 IP fix\u0103 (precum aws.com).<\/p>\n<h2>Verificarea politicii<\/h2>\n<p>\nFirewall-urile v\u0103 vor avertiza sau chiar vor refuza s\u0103 accepte o politic\u0103 incorect\u0103. Kubernetes efectueaz\u0103, de asemenea, unele verific\u0103ri. Atunci c\u00e2nd seta\u021bi o politic\u0103 de re\u021bea prin kubectl, Kubernetes poate afirma c\u0103 aceasta este incorect\u0103 \u0219i se va refuza s\u0103 o accepte. \u00cen alte cazuri, Kubernetes va accepta politica \u0219i va completa detaliile lips\u0103. Acestea pot fi vizualizate cu comanda:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nRe\u021bine\u021bi c\u0103 sistemul de verificare Kubernetes nu este infailibil \u0219i poate trece cu vederea anumite tipuri de erori.<\/p>\n<h2>Executare<\/h2>\n<p>\nKubernetes nu implementeaz\u0103 politicile de re\u021bea de unul singur, ci func\u021bioneaz\u0103 doar ca un gateway API, l\u0103s\u00e2nd sarcina de control pe o infrastructur\u0103 subiacenta numit\u0103 Interface de Re\u021bea a Containerelor (CNI). Seta\u021bi politicile \u00een clusterul Kubernetes f\u0103r\u0103 a desemna un CNI corespunz\u0103tor este similar cu a crea politici pe serverul de management al firewall-ului f\u0103r\u0103 a le instala ulterior \u00een firewall-uri. Trebuie s\u0103 v\u0103 asigura\u021bi c\u0103 ave\u021bi un CNI adecvat sau, \u00een cazul platformelor Kubernetes gazduite \u00een cloud, <i>(lista furnizorilor poate fi consultat\u0103 <noindex>aici<\/noindex> \u2014 n.r.)<\/i>, activ\u00e2nd politicile de re\u021bea, care vor seta CNI pentru dumneavoastr\u0103.<\/p>\n<p>Re\u021bine\u021bi c\u0103 Kubernetes nu v\u0103 va avertiza dac\u0103 seta\u021bi o politic\u0103 de re\u021bea f\u0103r\u0103 un CNI auxiliar corespunz\u0103tor.<\/p>\n<h3>Stateful sau Stateless?<\/h3>\n<p>\nToate CNI Kubernetes cu care m-am \u00eent\u00e2lnit p\u0103streaz\u0103 starea (de exemplu, Calico utilizeaz\u0103 conntrack-ul Linux). Aceasta permite pod-ului s\u0103 primeasc\u0103 r\u0103spunsuri pentru conexiunea TCP pe care a ini\u021biat-o, f\u0103r\u0103 a fi nevoie s\u0103 o stabileasc\u0103 din nou. Cu toate acestea, nu cunosc un standard Kubernetes care s\u0103 garanteze p\u0103strarea st\u0103rii (statefulness).<\/p>\n<h2>Gestionarea avansat\u0103 a politicilor de securitate<\/h2>\n<p>\nIat\u0103 c\u00e2teva modalit\u0103\u021bi de a spori eficien\u021ba implement\u0103rii politicii de securitate \u00een Kubernetes:<\/p>\n<ol>\n<li> Modelul arhitectural Service Mesh utilizeaz\u0103 containere sidecar pentru a oferi telemetrie detaliat\u0103 \u0219i control al traficului la nivel de servicii. Un exemplu poate fi luat din <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Unii dintre furnizorii CNI \u0219i-au extins instrumentele astfel \u00eenc\u00e2t acestea s\u0103 dep\u0103\u0219easc\u0103 politicile de re\u021bea Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> asigur\u0103 transparen\u021ba \u0219i automatizarea politicilor de re\u021bea Kubernetes.<\/li>\n<\/ol>\n<p>\nPachetul Tufin Orca gestioneaz\u0103 politicile de re\u021bea Kubernetes (\u0219i serve\u0219te ca surs\u0103 pentru capturile de ecran men\u021bionate mai sus).<\/p>\n<h2>Informa\u021bii suplimentare<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Exemple de politici de re\u021bea, preg\u0103tite de Ahmet Alp Balkan din GKE<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Documenta\u021bia de pe site-ul oficial Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Ghidul modelului de re\u021bea Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Script pentru verificarea politicilor de re\u021bea<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Concluzie<\/h2>\n<p>\nPoliticile de re\u021bea Kubernetes ofer\u0103 un set decent de instrumente pentru segmentarea clustere, totu\u0219i, acestea sunt contraintuitive \u0219i au multe subtilit\u0103\u021bi. Cred c\u0103 din cauza acestei complexit\u0103\u021bi, politicile multor clustere existente con\u021bin erori. Posibile solu\u021bii pentru aceast\u0103 problem\u0103 includ automatizarea defini\u021biilor de politic\u0103 sau utilizarea altor instrumente de segmentare.<\/p>\n<p>Sper c\u0103 acest ghid va ajuta la clarificarea unor \u00eentreb\u0103ri \u0219i la rezolvarea problemelor cu care s-ar putea s\u0103 te confrun\u021bi.<\/p>\n<h2>P.S. de la traduc\u0103tor<\/h2>\n<p>\nCiti\u021bi \u0219i \u00een blogul nostru:<\/p>\n<ul>\n<li> \u201e\u00cenapoi la microservicii \u00eempreun\u0103 cu Istio\u201d: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">partea 1 (introducere \u00een func\u021bionalit\u0103\u021bile de baz\u0103)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">partea 2 (rutare, gestionarea traficului)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">partea 3 (securitate)<\/a><\/noindex>;<\/li>\n<li> \u201eGhidul ilustrat pentru configurarea re\u021belei \u00een Kubernetes\u201d: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">p\u0103r\u021bile 1 \u0219i 2 (modelul de re\u021bea, re\u021belele overlay)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">partea 3 (servicii \u0219i procesarea traficului)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker \u0219i Kubernetes \u00een medii cu cerin\u021be stricte de securitate<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 cele mai bune practici pentru a asigura securitate \u00een Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 moduri (nu) de a deveni victima unui atac cibernetic \u00een Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Sursa: <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.1 - 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\/ro\/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.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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\udd47Introducere \u00een politicile de re\u021bea Kubernetes pentru speciali\u0219tii \u00een securitate | ProHoster","description":"Not\u0103.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}