{"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\/pl\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Przyp. t\u0142um.<\/b>: Autor artyku\u0142u \u2014 Reuven Harrison \u2014 ma ponad 20-letnie do\u015bwiadczenie w tworzeniu oprogramowania, a obecnie jest dyrektorem technicznym i wsp\u00f3\u0142za\u0142o\u017cycielem firmy Tufin, kt\u00f3ra tworzy rozwi\u0105zania do zarz\u0105dzania politykami bezpiecze\u0144stwa. Rozwa\u017caj\u0105c polityki sieciowe Kubernetes jako wystarczaj\u0105co pot\u0119\u017cne narz\u0119dzie do segmentacji sieci w klastrze, jednocze\u015bnie uwa\u017ca, \u017ce nie s\u0105 one tak \u0142atwe w zastosowaniu w praktyce. Ten materia\u0142 (do\u015b\u0107 obszerny) ma na celu zwi\u0119kszenie \u015bwiadomo\u015bci specjalist\u00f3w w tej kwestii i pomoc im w tworzeniu niezb\u0119dnych konfiguracji.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Dzi\u015b wiele firm coraz cz\u0119\u015bciej wybiera Kubernetes do uruchamiania swoich aplikacji. Zainteresowanie tym oprogramowaniem jest na tyle wysokie, \u017ce niekt\u00f3rzy nazywaj\u0105 Kubernetes \u201enowym systemem operacyjnym dla centr\u00f3w danych\u201d. Stopniowo Kubernetes (lub k8s) zaczyna by\u0107 postrzegany jako krytyczna cz\u0119\u015b\u0107 biznesu, kt\u00f3ra wymaga organizacji dojrza\u0142ych proces\u00f3w biznesowych, w tym zapewnienia bezpiecze\u0144stwa sieciowego.<\/p>\n<p>Dla specjalist\u00f3w ds. bezpiecze\u0144stwa, kt\u00f3rzy zmagaj\u0105 si\u0119 z prac\u0105 z Kubernetes, prawdziwym odkryciem mo\u017ce by\u0107 domy\u015blna polityka tej platformy: zezwalaj na wszystko.<\/p>\n<p>Ten przewodnik pomo\u017ce zrozumie\u0107 wewn\u0119trzn\u0105 struktur\u0119 polityk sieciowych; wyja\u015bni, czym r\u00f3\u017cni\u0105 si\u0119 od zasad dla zwyk\u0142ych zap\u00f3r ogniowych. Opisane b\u0119d\u0105 r\u00f3wnie\u017c niekt\u00f3re pu\u0142apki oraz udzielone zalecenia, kt\u00f3re pomog\u0105 zabezpieczy\u0107 aplikacje w Kubernetes.<\/p>\n<h2>Polityki sieciowe Kubernetes<\/h2>\n<p>\nMechanizm polityk sieciowych Kubernetes pozwala zarz\u0105dza\u0107 interakcjami wdro\u017conych na platformie aplikacji na poziomie sieciowym (trzecim w modelu OSI). Polityki sieciowe nie maj\u0105 niekt\u00f3rych zaawansowanych funkcji nowoczesnych zap\u00f3r ogniowych, takich jak kontrola na 7 poziomie OSI i wykrywanie zagro\u017ce\u0144, jednak zapewniaj\u0105 podstawowy poziom bezpiecze\u0144stwa sieci, kt\u00f3ry stanowi dobry punkt wyj\u015bcia.<\/p>\n<h2>Polityki sieciowe kontroluj\u0105 komunikacj\u0119 mi\u0119dzy podami<\/h2>\n<p>\nObci\u0105\u017cenia w Kubernetes s\u0105 rozdzielane na pody, kt\u00f3re sk\u0142adaj\u0105 si\u0119 z jednego lub kilku kontener\u00f3w uruchamianych razem. Kubernetes przypisuje ka\u017cdemu podowi adres IP, dost\u0119pny z innych pod\u00f3w. Polityki sieciowe Kubernetes okre\u015blaj\u0105 uprawnienia dost\u0119pu dla grup pod\u00f3w w taki sam spos\u00f3b, jak grupy zabezpiecze\u0144 w chmurze s\u0142u\u017c\u0105 do zarz\u0105dzania dost\u0119pem do instancji maszyn wirtualnych.<\/p>\n<h2>Okre\u015blenie polityk sieciowych<\/h2>\n<p>\nPodobnie jak inne zasoby Kubernetes, polityki sieciowe s\u0105 definiowane w j\u0119zyku YAML. W poni\u017cszym przyk\u0142adzie aplikacja <code>balance<\/code> uzyskuje dost\u0119p do <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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Przyp. t\u0142um.<\/b>: ten zrzut ekranu, podobnie jak wszystkie nast\u0119pne podobne, zosta\u0142 utworzony nie za pomoc\u0105 natywnych narz\u0119dzi Kubernetes, lecz przy u\u017cyciu narz\u0119dzia Tufin Orca, za rozwojem kt\u00f3rego stoi firma autora oryginalnego artyku\u0142u i kt\u00f3re jest wspomniane na ko\u0144cu materia\u0142u.<\/i><\/p>\n<p>Aby okre\u015bli\u0107 w\u0142asn\u0105 polityk\u0119 sieciow\u0105, potrzebna b\u0119dzie podstawowa znajomo\u015b\u0107 YAML. Ten j\u0119zyk opiera si\u0119 na wci\u0119ciach (ustawianych spacjami, a nie tabulacjami). Element z wci\u0119ciem nale\u017cy do najbli\u017cszego elementu z wci\u0119ciem powy\u017cej. Nowy element listy rozpoczyna si\u0119 od my\u015blnika, pozosta\u0142e elementy maj\u0105 posta\u0107 <i>klucz-warto\u015b\u0107<\/i>.<\/p>\n<p>Opisuj\u0105c polityk\u0119 w YAML, u\u017cyj <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, aby utworzy\u0107 j\u0105 w klastrze:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Specyfikacja polityki sieciowej<\/h2>\n<p>\nSpecyfikacja polityki sieciowej Kubernetes zawiera cztery elementy:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: definiuje pody, kt\u00f3rych dotyczy ta polityka (cele) \u2013 obowi\u0105zkowe;<\/li>\n<li> <code>policyTypes<\/code>: wskazuje, jakie typy polityk s\u0105 zawarte: ingress i\/lub egress \u2014 opcjonalny, jednak zalecam jego wyra\u017ane okre\u015blenie we wszystkich przypadkach;<\/li>\n<li> <code>ingress<\/code>: definiuje dozwolony <b>przychodz\u0105cy<\/b> ruch do celowych pod\u00f3w \u2013 opcjonalny;<\/li>\n<li> <code>egress<\/code>: definiuje dozwolony <b>ruch wychodz\u0105cy<\/b> ruch z celowych pod\u00f3w \u2013 opcjonalny.<\/li>\n<\/ol>\n<p>\nPrzyk\u0142ad pochodzi ze strony Kubernetes (zmieni\u0142em <code>role<\/code> na <code>app<\/code>), pokazuje, jak u\u017cywane s\u0105 wszystkie cztery elementy:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZauwa\u017c, \u017ce wszystkie cztery elementy nie s\u0105 obowi\u0105zkowe. Obowi\u0105zkowy jest tylko <code>podSelector<\/code>, pozosta\u0142e parametry mog\u0105 by\u0107 u\u017cywane wed\u0142ug uznania.<\/p>\n<p>Je\u015bli pominiesz <code>policyTypes<\/code>, polityka b\u0119dzie interpretowana w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n<ul>\n<li> Domy\u015blnie zak\u0142ada si\u0119, \u017ce definiuje stron\u0119 ingress. Je\u015bli w polityce nie ma wyra\u017anych wskaz\u00f3wek w tej sprawie, system uzna, \u017ce ca\u0142y ruch jest zabroniony.<\/li>\n<li> Zachowanie na stronie egress b\u0119dzie okre\u015blane przez obecno\u015b\u0107 lub brak odpowiedniego parametru egress.<\/li>\n<\/ul>\n<p>\nAby unikn\u0105\u0107 b\u0142\u0119d\u00f3w, zalecam <b>zawsze wyra\u017anie wskazywa\u0107 <code>policyTypes<\/code><\/b>.<\/p>\n<p>Zgodnie z powy\u017csz\u0105 logik\u0105, je\u015bli parametry <code>ingress<\/code> i\/lub <code>egress<\/code> s\u0105 pomini\u0119te, polityka b\u0119dzie zabrania\u0107 ca\u0142ego ruchu (patrz 'Regu\u0142a czyszczenia' poni\u017cej).<\/p>\n<h2>Polityka domy\u015blna \u2014 zezw\u00f3l<\/h2>\n<p>\nJe\u017celi polityki nie s\u0105 zdefiniowane, Kubernetes domy\u015blnie zezwala na ca\u0142y ruch. Wszystkie pody mog\u0105 swobodnie wymienia\u0107 si\u0119 informacjami. Z punktu widzenia bezpiecze\u0144stwa mo\u017ce to wydawa\u0107 si\u0119 nielogiczne, ale pami\u0119taj, \u017ce Kubernetes zosta\u0142 pierwotnie zaprojektowany przez programist\u00f3w w celu zapewnienia interakcji aplikacji. Polityki sieciowe zosta\u0142y dodane p\u00f3\u017aniej.<\/p>\n<h2>Przestrzenie nazw<\/h2>\n<p>\nPrzestrzenie nazw (Namespaces) to mechanizm wsp\u00f3lnej pracy Kubernetes. S\u0142u\u017c\u0105 do izolowania logicznych \u015brodowisk od siebie, przy czym wymiana danych mi\u0119dzy przestrzeniami jest domy\u015blnie dozwolona.<\/p>\n<p>Podobnie jak wi\u0119kszo\u015b\u0107 komponent\u00f3w Kubernetes, polityki sieciowe znajduj\u0105 si\u0119 w okre\u015blonym przestrzeni nazw. W bloku <code>metadata<\/code> mo\u017cna okre\u015bli\u0107, do kt\u00f3regokolwiek przestrzeni nale\u017cy polityka:<\/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>\nJe\u015bli przestrze\u0144 nazw w metadanych nie jest wyra\u017anie okre\u015blona, system u\u017cyje namespace podanego w kubectl (domy\u015blnie <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nZalecam <b>wyra\u017anie okre\u015bla\u0107 namespace<\/b>, chyba \u017ce piszesz polityk\u0119 przeznaczon\u0105 od razu dla wielu przestrzeni nazw.<\/p>\n<p><b>Podstawowy<\/b> element <code>podSelector<\/code> w polityce b\u0119d\u0105 wybierane pody z przestrzeni nazw, do kt\u00f3rej nale\u017cy polityka (nie ma dost\u0119pu do pod\u00f3w z innej przestrzeni nazw).<\/p>\n<p>Podobnie jak podSelectory <b>w blokach ingress i egress<\/b> mog\u0105 wybiera\u0107 pod\u2019y tylko ze swojej przestrzeni nazw, chyba \u017ce po\u0142\u0105czysz je z pomoc\u0105 <code>namespaceSelector<\/code> (o tym b\u0119dzie mowa w sekcji \u201eFiltruj wed\u0142ug przestrzeni nazw i pod\u00f3w\u201d).<\/p>\n<h2>Zasady nazewnictwa polityk<\/h2>\n<p>\nNazwy polityk s\u0105 unikalne w ramach jednej przestrzeni nazw. Nie mog\u0105 wyst\u0119powa\u0107 dwie polityki o tej samej nazwie w jednej przestrzeni, ale mog\u0105 istnie\u0107 polityki o identycznych nazwach w r\u00f3\u017cnych przestrzeniach. Jest to wygodne, gdy chcesz ponownie zastosowa\u0107 t\u0119 sam\u0105 polityk\u0119 w kilku przestrzeniach.<\/p>\n<p>Szczeg\u00f3lnie podoba mi si\u0119 jeden ze sposob\u00f3w nazewnictwa. Polega on na \u0142\u0105czeniu nazwy przestrzeni nazw z docelowymi pod\u2019ami. Na przyk\u0142ad:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Etykiety<\/h2>\n<p>\nMo\u017cna przypina\u0107 niestandardowe etykiety do obiekt\u00f3w Kubernetes, takich jak pod\u2019y i przestrzenie nazw. Etykiety (<i>labels<\/i> \u2014 oznaczenia) s\u0105 ekwiwalentem tag\u00f3w w chmurze. Polityki sieciowe Kubernetes u\u017cywaj\u0105 etykiet do wybierania <b>pod\u00f3w<\/b>, do kt\u00f3rych s\u0105 stosowane:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 lub <b>przestrzeni nazw<\/b>, kt\u00f3re dotycz\u0105. W tym przyk\u0142adzie wybierane s\u0105 wszystkie pody w przestrzeniach nazw z odpowiednimi etykietami:<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\nJedno ostrze\u017cenie: przy u\u017cyciu <code>namespaceSelector<\/code> <b>upewnij si\u0119, \u017ce wybierane przestrzenie nazw zawieraj\u0105 wymagane etykiety<\/b>. Pami\u0119taj, \u017ce wbudowane przestrzenie nazw, takie jak <code>default<\/code> i <code>kube-system<\/code>, domy\u015blnie nie zawieraj\u0105 etykiet.<\/p>\n<p>Etykiet\u0119 do przestrzeni mo\u017cna doda\u0107 w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nPrzy czym namespace w sekcji <code>metadata<\/code> powinien odnosi\u0107 si\u0119 do faktywnego nazwy przestrzeni, a nie do etykiety:<\/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>\u0179r\u00f3d\u0142o i adresat<\/h2>\n<p>\nPolityki dla zap\u00f3r ogniowych sk\u0142adaj\u0105 si\u0119 z zasad z \u017ar\u00f3d\u0142ami i adresatami. Polityki sieciowe Kubernetes definiowane s\u0105 dla celu \u2013 zestawu pod\u00f3w, do kt\u00f3rych si\u0119 stosuj\u0105, a nast\u0119pnie ustalaj\u0105 zasady dla ruchu przychodz\u0105cego (ingress) i\/lub wychodz\u0105cego (egress). W naszym przyk\u0142adzie celem polityki b\u0119d\u0105 wszystkie pody w przestrzeni nazw <code>default<\/code> z etykiet\u0105 z kluczem <code>app<\/code> i warto\u015bci\u0105 <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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPodsekcja <code>ingress<\/code> w tej polityce otwiera ruch przychodz\u0105cy do docelowych pod\u00f3w. Innymi s\u0142owy, ingress dzia\u0142a jako \u017ar\u00f3d\u0142o, a cel \u2014 odpowiedni adresat. Podobnie egress jest adresatem, a cel \u2014 jego \u017ar\u00f3d\u0142em.<\/p>\n<p><img decoding=\"async\" alt=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>To odpowiada dw\u00f3m regu\u0142om dla zapory: Ingress \u2192 Cel; Cel \u2192 Egress.<\/i><\/p>\n<h2>Egress i DNS (wa\u017cne!)<\/h2>\n<p>\nOgraniczaj\u0105c ruch wychodz\u0105cy, <b>szczeg\u00f3ln\u0105 uwag\u0119 zwr\u00f3\u0107 na DNS<\/b> \u2014 Kubernetes u\u017cywa tej us\u0142ugi do mapowania us\u0142ug na adresy IP. Na przyk\u0142ad, nast\u0119puj\u0105ca polityka nie zadzia\u0142a, poniewa\u017c nie zezwoli\u0142e\u015b aplikacji <code>balance<\/code> na dost\u0119p do 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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMo\u017cesz to poprawi\u0107, otwieraj\u0105c dost\u0119p do us\u0142ugi 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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOstatni element <code>to<\/code> \u2014 pusty, wi\u0119c po\u015brednio wybiera <b>wszystkie pody we wszystkich przestrzeniach nazw<\/b>, pozwalaj\u0105c <code>balance<\/code> wysy\u0142a\u0107 zapytania DNS do odpowiedniej us\u0142ugi Kubernetes (zwykle dzia\u0142a w przestrzeni <code>kube-system<\/code>).<\/p>\n<p>To podej\u015bcie dzia\u0142a, jednak jest <b>nadmiernie zezwalaj\u0105ce i niebezpieczne<\/b>, poniewa\u017c pozwala kierowa\u0107 zapytania DNS poza klaster.<\/p>\n<p>Mo\u017cna je poprawi\u0107 w trzech kolejnych krokach.<\/p>\n<p>1. Zezwoli\u0107 na zapytania DNS tylko <b>wci\u0105\u017c<\/b> do klastra, dodaj\u0105c <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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Zezw\u00f3l na zapytania DNS tylko w okre\u015blonej przestrzeni nazw <code>kube-system<\/code>.<\/p>\n<p>Aby to zrobi\u0107, musisz doda\u0107 etykiet\u0119 do przestrzeni nazw <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 i umie\u015bci\u0107 j\u0105 w polityce za pomoc\u0105 <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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Paranoicy mog\u0105 p\u00f3j\u015b\u0107 jeszcze dalej i ograniczy\u0107 zapytania DNS do okre\u015blonej us\u0142ugi DNS w <code>kube-system<\/code>. W sekcji \u201eFiltruj wed\u0142ug przestrzeni nazw i pod\u00f3w\u201d zostanie opisane, jak to osi\u0105gn\u0105\u0107.<\/p>\n<p>Inn\u0105 opcj\u0105 jest zezwolenie na DNS na poziomie przestrzeni nazw. W takim przypadku nie trzeba go otwiera\u0107 dla ka\u017cdej us\u0142ugi:<\/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>\nPusty <code>podSelector<\/code> wybiera wszystkie pody w przestrzeni nazw.<\/p>\n<p><img decoding=\"async\" alt=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Pierwsze dopasowanie i kolejno\u015b\u0107 regu\u0142<\/h2>\n<p>\nW zwyk\u0142ych zaporach ogniowych dzia\u0142anie (\u201eZezw\u00f3l\u201d lub \u201eZabro\u0144\u201d) w odniesieniu do pakietu jest okre\u015blane przez pierwsz\u0105 regu\u0142\u0119, kt\u00f3ra jest spe\u0142niona. <b>W Kubernetes kolejno\u015b\u0107 polityk nie ma znaczenia.<\/b><\/p>\n<p>Domy\u015blnie, gdy polityki nie s\u0105 okre\u015blone, komunikacja mi\u0119dzy podami jest dozwolona i mog\u0105 one swobodnie wymienia\u0107 si\u0119 informacjami. Gdy zaczynasz formu\u0142owa\u0107 polityki, ka\u017cdy pod, kt\u00f3ry jest dotkni\u0119ty przynajmniej jedn\u0105 z nich, staje si\u0119 izolowany zgodnie z dysjunkcj\u0105 (logiczne LUB) wszystkich polityk, kt\u00f3re go wybra\u0142y. Pody, kt\u00f3re nie s\u0105 obj\u0119te \u017cadn\u0105 polityk\u0105, pozostaj\u0105 otwarte.<\/p>\n<p>Mo\u017cna zmieni\u0107 to zachowanie za pomoc\u0105 regu\u0142y oczyszczania.<\/p>\n<h2>Regu\u0142a oczyszczania (\u201eZabro\u0144\u201d)<\/h2>\n<p>\nPolityki zap\u00f3r ogniowych zazwyczaj zabraniaj\u0105 dowolnego ruchu, kt\u00f3ry nie jest wyra\u017anie dozwolony.<\/p>\n<p><b>W Kubernetes nie ma akcji \u201ezabro\u0144\u201d (deny),<\/b>, jednak podobny efekt mo\u017cna osi\u0105gn\u0105\u0107 za pomoc\u0105 zwyk\u0142ej (zezwalaj\u0105cej) polityki, wybieraj\u0105c pust\u0105 grup\u0119 pod\u00f3w-\u017ar\u00f3de\u0142 (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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTa polityka wybiera wszystkie pod'y w przestrzeni nazw i pozostawia ingress nieokre\u015blonym, zakazuj\u0105c ca\u0142y ruch przychodz\u0105cy.<\/p>\n<p>Podobnie mo\u017cna ograniczy\u0107 ca\u0142y ruch wychodz\u0105cy z przestrzeni nazw:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUwaga, \u017ce <b>wszystkie dodatkowe polityki, kt\u00f3re zezwalaj\u0105 na ruch do pod'\u00f3w w przestrzeni nazw, b\u0119d\u0105 mia\u0142y priorytet nad t\u0105 regu\u0142\u0105<\/b> (analogicznie do dodawania regu\u0142y zezwalaj\u0105cej przed zabraniaj\u0105c\u0105 w konfiguracji zapory).<\/p>\n<h2>Zezw\u00f3l na wszystko (Any-Any-Any-Allow)<\/h2>\n<p>\nAby stworzy\u0107 polityk\u0119 'Zezw\u00f3l na wszystko', nale\u017cy uzupe\u0142ni\u0107 powy\u017csz\u0105 polityk\u0119 zabraniaj\u0105c\u0105 pustym elementem <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;&lt;\n  - {}     # &lt;&lt;&lt;&lt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOtwiera dost\u0119p z <b>wszystkie pod'y we wszystkich przestrzeniach nazw (i wszystkich IP) do dowolnego pod'a w przestrzeni nazw <code>default<\/code><\/b>. Takie zachowanie jest domy\u015blne, wi\u0119c zazwyczaj nie trzeba go definiowa\u0107 dodatkowo. Jednak czasami mo\u017ce by\u0107 konieczne tymczasowe wy\u0142\u0105czenie niekt\u00f3rych specyficznych zezwole\u0144 w celu diagnostyki problemu.<\/p>\n<p>Regu\u0142\u0119 mo\u017cna zaw\u0119zi\u0107 i zezwoli\u0107 na dost\u0119p tylko do <b>okre\u015blonego zestawu pod'\u00f3w<\/b> (<code>app:balance<\/code>) w przestrzeni nazw <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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNast\u0119puj\u0105ca polityka zezwala na ca\u0142y ruch przychodz\u0105cy (ingress) i wychodz\u0105cy (egress), w tym dost\u0119p do dowolnego adresu IP poza klastrem:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>\u0141\u0105czenie wielu polityk<\/h2>\n<p>\nPolityki s\u0105 \u0142\u0105czone przy u\u017cyciu logicznego LUB na trzech poziomach; zezwolenia ka\u017cdego pod'a s\u0105 ustalane na podstawie dysjunkcji wszystkich polityk, kt\u00f3re go dotycz\u0105:<\/p>\n<p>1. W polach <code>od<\/code> i <code>to<\/code> mo\u017cna okre\u015bli\u0107 trzy typy element\u00f3w (wszystkie s\u0105 kombiowane za pomoc\u0105 LUB):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 wybiera ca\u0142\u0105 przestrze\u0144 nazw;<\/li>\n<li> <code>podSelector<\/code> \u2014 wybiera pod'y;<\/li>\n<li> <code>ipBlock<\/code> \u2014 wybiera podsie\u0107.<\/li>\n<\/ul>\n<p>\nPrzy tym liczba element\u00f3w (nawet tych samych) w sekcjach <code>od<\/code>\/<code>to<\/code> nie jest ograniczona. Wszystkie b\u0119d\u0105 po\u0142\u0105czone logicznym LUB.<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. W obr\u0119bie polityki sekcja <code>ingress<\/code> mo\u017ce mie\u0107 wiele element\u00f3w <code>od<\/code> (\u0142\u0105cz\u0105 si\u0119 za pomoc\u0105 logicznego LUB). Podobnie sekcja <code>egress<\/code> mo\u017ce zawiera\u0107 wiele element\u00f3w <code>to<\/code> (r\u00f3wnie\u017c \u0142\u0105cz\u0105 si\u0119 za pomoc\u0105 dysjunkcji):<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. R\u00f3\u017cne polityki s\u0105 r\u00f3wnie\u017c \u0142\u0105czone za pomoc\u0105 logicznego LUB<\/p>\n<p>Ale podczas ich \u0142\u0105czenia istnieje jedno ograniczenie, na kt\u00f3re <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">zaznaczy\u0142<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes mo\u017ce \u0142\u0105czy\u0107 polityki tylko z r\u00f3\u017cnymi <code>policyTypes<\/code> (<code>Ingress<\/code> lub <code>Egress<\/code>). Polityki okre\u015blaj\u0105ce ingress (lub egress) nadpisz\u0105 si\u0119 nawzajem.<\/p>\n<h2>Relacja mi\u0119dzy przestrzeniami nazw<\/h2>\n<p>\nDomy\u015blnie wymiana informacji mi\u0119dzy przestrzeniami nazw jest dozwolona. Mo\u017cna to zmieni\u0107 za pomoc\u0105 polityki blokuj\u0105cej, kt\u00f3ra ograniczy wychodz\u0105cy i\/lub przychodz\u0105cy ruch do przestrzeni nazw (zob. \"Regu\u0142a czyszcz\u0105ca\" powy\u017cej).<\/p>\n<p>Blokuj\u0105c dost\u0119p do przestrzeni nazw (zob. \"Regu\u0142a czyszcz\u0105ca\" powy\u017cej), mo\u017cesz wprowadzi\u0107 wyj\u0105tki w polityce blokuj\u0105cej, zezwalaj\u0105c na po\u0142\u0105czenia z okre\u015blonej przestrzeni nazw za pomoc\u0105 <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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nW rezultacie wszystkie pod\u2019y w przestrzeni nazw <code>default<\/code> uzyskaj\u0105 dost\u0119p do pod'\u00f3w <code>postgres<\/code> w przestrzeni nazw <code>database<\/code>. Ale co, je\u015bli chcesz otworzy\u0107 dost\u0119p do <code>postgres<\/code> tylko okre\u015blonych pod'\u00f3w w przestrzeni nazw <code>default<\/code>?<\/p>\n<h2>Filtr wed\u0142ug przestrzeni nazw i pod'\u00f3w<\/h2>\n<p>\nKubernetes w wersji 1.11 i wy\u017cszej pozwala na \u0142\u0105czenie operator\u00f3w <code>namespaceSelector<\/code> i <code>podSelector<\/code> za pomoc\u0105 logicznego I. Wygl\u0105da to nast\u0119puj\u0105co:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDlaczego to jest interpretowane jako I zamiast zwyk\u0142ego LUB?<\/p>\n<p>Zauwa\u017c, \u017ce <code>podSelector<\/code> nie zaczyna si\u0119 od my\u015blnika. W YAML oznacza to, \u017ce <code>podSelector<\/code> i stoj\u0105cy przed nim <code>namespaceSelector<\/code> nale\u017c\u0105 do tego samego elementu listy. Dlatego \u0142\u0105cz\u0105 si\u0119 za pomoc\u0105 logicznego I.<\/p>\n<p>Dodanie my\u015blnika przed <code>podSelector<\/code> spowoduje powstanie nowego elementu listy, kt\u00f3ry b\u0119dzie \u0142\u0105czony z poprzednim <code>namespaceSelector<\/code> przy u\u017cyciu logicznego LUB.<\/p>\n<p>Aby wybra\u0107 pod'y z okre\u015blon\u0105 etykiet\u0105 <b>we wszystkich przestrzeniach nazw<\/b>, wpisz pusty <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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Wielokrotne etykiety s\u0105 \u0142\u0105czone z AND<\/h2>\n<p>\nRegu\u0142y dla zapory ogniowej z wieloma obiektami (hostami, sieciami, grupami) s\u0105 \u0142\u0105czone przy u\u017cyciu logicznego LUB. Nast\u0119puj\u0105ca regu\u0142a zadzia\u0142a, je\u015bli \u017ar\u00f3d\u0142o pakietu odpowiada <code>Host_1<\/code> LUB <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| \u0179r\u00f3d\u0142o | Cel | Us\u0142uga | Dzia\u0142anie |\n| ----------------------------------------|\n| Host_1 | Subnet_A    | HTTPS   | Zezw\u00f3l  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nPrzeciwnie, w Kubernetes r\u00f3\u017cne etykiety w <code>podSelector<\/code> lub <code>namespaceSelector<\/code> s\u0105 \u0142\u0105czone logicznym AND. Na przyk\u0142ad, nast\u0119puj\u0105ca regu\u0142a wybierze pod\u2019y, kt\u00f3re maj\u0105 obie etykiety, <code>role=db<\/code> I <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nTa sama logika dotyczy wszystkich typ\u00f3w operator\u00f3w: selektor\u00f3w cel\u00f3w polityki, selektor\u00f3w pod'\u00f3w i selektor\u00f3w przestrzeni nazw.<\/p>\n<h2>Podsieci i adresy IP (IPBlocks)<\/h2>\n<p>\nDo segmentacji sieci zapory ogniowe u\u017cywaj\u0105 VLAN, adres\u00f3w IP i podsieci.<\/p>\n<p>W Kubernetes adresy IP s\u0105 przypisywane pod'om automatycznie i mog\u0105 cz\u0119sto si\u0119 zmienia\u0107, dlatego w celu wyboru pod'\u00f3w i przestrzeni nazw w politykach sieciowych u\u017cywane s\u0105 etykiety.<\/p>\n<p>Podsieci (<code>ipBlocks<\/code>) s\u0105 u\u017cywane do zarz\u0105dzania po\u0142\u0105czeniami przychodz\u0105cymi (ingress) lub wychodz\u0105cymi (egress) zewn\u0119trznymi (North-South). Na przyk\u0142ad ta polityka otwiera wszystkim pod'om z przestrzeni nazw <code>default<\/code> dost\u0119p do serwisu 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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPusty selektor pod'\u00f3w w tym przyk\u0142adzie oznacza \u201ewybierz wszystkie pod'y w przestrzeni nazw\u201d.<\/p>\n<p>Ta polityka otwiera dost\u0119p tylko do 8.8.8.8; dost\u0119p do jakiegokolwiek innego IP jest zablokowany. Tak wi\u0119c, zasadniczo zablokowa\u0142e\u015b dost\u0119p do wewn\u0119trznej us\u0142ugi DNS Kubernetes. Je\u015bli chcesz to jednak otworzy\u0107, zr\u00f3b to wyra\u017anie.<\/p>\n<p>Zazwyczaj <code>ipBlocks<\/code> i <code>podSelectors<\/code> s\u0105 wzajemnie wykluczaj\u0105ce, poniewa\u017c wewn\u0119trzne adresy IP pod'\u00f3w nie s\u0105 wykorzystywane w <code>ipBlocks<\/code>. Okre\u015blaj\u0105c <b>wewn\u0119trzne IP pod'\u00f3w<\/b>, faktycznie zezwolisz na po\u0142\u0105czenia do\/od pod'\u00f3w z tymi adresami. W praktyce nie b\u0119dziesz wiedzia\u0142, kt\u00f3ry adres IP u\u017cy\u0107, dlatego nie powinno si\u0119 ich stosowa\u0107 do wyboru pod'\u00f3w.<\/p>\n<p>Jako kontrprzyk\u0142ad, poni\u017csza polityka obejmuje wszystkie IP i w zwi\u0105zku z tym zezwala na dost\u0119p do wszystkich innych pod'\u00f3w:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMo\u017cna otworzy\u0107 dost\u0119p tylko do zewn\u0119trznych IP, wykluczaj\u0105c wewn\u0119trzne adresy IP pod'\u00f3w. Na przyk\u0142ad, je\u015bli podsie\u0107 twojego pod'a to 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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Porty i protoko\u0142y<\/h2>\n<p>\nZazwyczaj pod'y nas\u0142uchuj\u0105 na jednym porcie. Oznacza to, \u017ce mo\u017cna po prostu nie podawa\u0107 numer\u00f3w port\u00f3w w politykach i zostawi\u0107 wszystko domy\u015blnie. Niemniej jednak, polityki powinny by\u0107 jak najbardziej restrykcyjne, dlatego w niekt\u00f3rych przypadkach mo\u017cna r\u00f3wnie\u017c okre\u015bla\u0107 porty:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZauwa\u017c, \u017ce selektor <code>porty<\/code> jest stosowany do wszystkich element\u00f3w w bloku <code>to<\/code> lub <code>od<\/code>, w kt\u00f3rym si\u0119 znajduje. Aby wskaza\u0107 r\u00f3\u017cne porty dla r\u00f3\u017cnych zestaw\u00f3w element\u00f3w, podziel je <code>ingress<\/code> lub <code>egress<\/code> na kilka podsekcji z <code>to<\/code> lub <code>od<\/code> i w ka\u017cdej podaj swoje porty:<\/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=\"Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w ds. bezpiecze\u0144stwa.\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDzia\u0142anie port\u00f3w domy\u015blnie:<\/p>\n<ul>\n<li> Je\u015bli ca\u0142kowicie pomijasz definicj\u0119 port\u00f3w (<code>porty<\/code>), oznacza to wszystkie protoko\u0142y i wszystkie porty;<\/li>\n<li> Je\u015bli pomijasz definicj\u0119 protoko\u0142u (<code>protocol<\/code>), oznacza to TCP;<\/li>\n<li> Je\u015bli pomijasz definicj\u0119 portu (<code>port<\/code>), oznacza to wszystkie porty.<\/li>\n<\/ul>\n<p>\nNajlepsza praktyka: nie polegaj na warto\u015bciach domy\u015blnych, podawaj to, czego potrzebujesz, wyra\u017anie.<\/p>\n<p>Prosz\u0119 zwr\u00f3ci\u0107 uwag\u0119, \u017ce nale\u017cy u\u017cywa\u0107 port\u00f3w pod\u00f3w, a nie us\u0142ug (wi\u0119cej na ten temat w nast\u0119pnym akapicie).<\/p>\n<h2>Czy polityki s\u0105 okre\u015blone dla pod\u00f3w czy us\u0142ug?<\/h2>\n<p>\nZazwyczaj pod\u2019y w Kubernetes komunikuj\u0105 si\u0119 mi\u0119dzy sob\u0105 za po\u015brednictwem us\u0142ugi \u2014 wirtualnego load balancera, kt\u00f3ry kieruje ruch do pod\u00f3w realizuj\u0105cych us\u0142ug\u0119. Mo\u017ce si\u0119 wydawa\u0107, \u017ce polityki sieciowe kontroluj\u0105 dost\u0119p do us\u0142ug, ale to nieprawda. <b>Polityki sieciowe Kubernetes dzia\u0142aj\u0105 z portami pod\u00f3w, a nie us\u0142ug.<\/b><\/p>\n<p>Na przyk\u0142ad, je\u015bli us\u0142uga nas\u0142uchuje na porcie 80, ale kieruje ruch na port 8080 swoich pod\u00f3w, to w polityce sieciowej trzeba okre\u015bli\u0107 w\u0142a\u015bnie 8080.<\/p>\n<p>Taki mechanizm nale\u017cy uzna\u0107 za nieoptymalny: przy zmianach wewn\u0119trznej struktury us\u0142ugi (porty, na kt\u00f3rych nas\u0142uchuj\u0105 pody) b\u0119dzie konieczne aktualizowanie polityk sieciowych.<\/p>\n<p>Nowe podej\u015bcie architektoniczne z wykorzystaniem Service Mesh <i>(na przyk\u0142ad, zobacz Istio poni\u017cej \u2014 przyp. t\u0142um.)<\/i> pozwala poradzi\u0107 sobie z tym problemem.<\/p>\n<h2>Czy konieczne jest zdefiniowanie zar\u00f3wno Ingress, jak i Egress?<\/h2>\n<p>\nKr\u00f3tk\u0105 odpowiedzi\u0105 jest \u2014 tak, aby pod A m\u00f3g\u0142 skontaktowa\u0107 si\u0119 z pod B, nale\u017cy zezwoli\u0107 mu na nawi\u0105zanie po\u0142\u0105czenia wychodz\u0105cego (w tym celu nale\u017cy skonfigurowa\u0107 polityk\u0119 egress), a pod B musi mie\u0107 mo\u017cliwo\u015b\u0107 przyj\u0119cia po\u0142\u0105czenia przychodz\u0105cego (w tym celu, odpowiednio, potrzebna jest polityka ingress).<\/p>\n<p>Jednak w praktyce mo\u017cna polega\u0107 na domy\u015blnej polityce, kt\u00f3ra zezwala na po\u0142\u0105czenia w jednym lub obu kierunkach.<\/p>\n<p>Je\u015bli jaki\u015b pod-<b>ClickHouse-Ninja\/Proton<\/b> zostanie wybrany przez jedn\u0105 lub kilka <b>egress<\/b>-polityk, na\u0142o\u017cone na niego ograniczenia b\u0119d\u0105 okre\u015blane ich dysjunkcj\u0105. W takim przypadku trzeba b\u0119dzie jawnie zezwoli\u0107 na po\u0142\u0105czenie z podem-<b>adresatem<\/b>. Je\u015bli pod nie zostanie wybrany przez \u017cadn\u0105 polityk\u0119, jego wychodz\u0105cy (egress) ruch jest domy\u015blnie dozwolony.<\/p>\n<p>Podobnie, los pod\u2019a-<b>adresata<\/b>, kt\u00f3ry zosta\u0142 wybrany przez jedn\u0105 lub kilka <b>ingress<\/b>-polityki b\u0119d\u0105 okre\u015blane przez ich dysjunkcj\u0119. W takim przypadku trzeba wyra\u017anie zezwoli\u0107 mu na odbieranie ruchu od pod\u2019a-\u017ar\u00f3d\u0142a. Je\u015bli pod nie jest obj\u0119ty \u017cadn\u0105 polityk\u0105, ca\u0142y ruch przychodz\u0105cy (ingress) dla niego jest domy\u015blnie dozwolony.<\/p>\n<p>Zob. punkt \u201eStateful czy Stateless\u201d poni\u017cej.<\/p>\n<h2>Logi<\/h2>\n<p>\nPolityki sieciowe Kubernetes nie potrafi\u0105 rejestrowa\u0107 ruchu. Utrudnia to okre\u015blenie, czy polityka dzia\u0142a poprawnie, i znacznie utrudnia analiz\u0119 w zakresie bezpiecze\u0144stwa.<\/p>\n<h2>Kontrola ruchu do zewn\u0119trznych us\u0142ug<\/h2>\n<p>\nPolityki sieciowe Kubernetes nie pozwalaj\u0105 na wskazywanie pe\u0142nej nazwy domeny (DNS) w sekcjach egress. To powoduje znaczne niedogodno\u015bci przy pr\u00f3bie ograniczenia ruchu do zewn\u0119trznych adresat\u00f3w, kt\u00f3re nie maj\u0105 sta\u0142ego adresu IP (takich jak aws.com).<\/p>\n<h2>Weryfikacja polityki<\/h2>\n<p>\nZapory sieciowe powiadomi\u0105 Ci\u0119 lub nawet odm\u00f3wi\u0105 przyj\u0119cia b\u0142\u0119dnej polityki. Kubernetes r\u00f3wnie\u017c dokonuje pewnej weryfikacji. Przy okre\u015blaniu polityki sieciowej za pomoc\u0105 kubectl, Kubernetes mo\u017ce zadeklarowa\u0107, \u017ce jest ona nieprawid\u0142owa i odm\u00f3wi jej przyj\u0119cia. W innych przypadkach Kubernetes przyjmie polityk\u0119 i uzupe\u0142ni j\u0105 brakuj\u0105cymi szczeg\u00f3\u0142ami. Mo\u017cna je zobaczy\u0107 za pomoc\u0105 polecenia:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nPami\u0119taj, \u017ce system weryfikacji Kubernetes nie jest nieomylny i mo\u017ce przeoczy\u0107 niekt\u00f3re typy b\u0142\u0119d\u00f3w.<\/p>\n<h2>Wykonanie<\/h2>\n<p>\nKubernetes nie zajmuje si\u0119 wdra\u017caniem polityk sieciowych samodzielnie, a jedynie jest bramk\u0105 API, kt\u00f3ra nak\u0142ada obowi\u0105zek kontroli na podleg\u0142y system, zwany Container Networking Interface (CNI). Ustalanie polityk w klastrze Kubernetes bez odpowiedniego przypisania CNI jest podobne do tworzenia polityk na serwerze zarz\u0105dzania zapor\u0105 bez ich p\u00f3\u017aniejszego zainstalowania w zaporach. Musisz sam upewni\u0107 si\u0119, \u017ce masz odpowiednie CNI lub, w przypadku platform Kubernetes osadzonych w chmurze, <i>(mo\u017cna zapozna\u0107 si\u0119 z list\u0105 dostawc\u00f3w <noindex>tutaj<\/noindex> \u2014 przyp. red.)<\/i>, aktywowa\u0107 polityki sieciowe, kt\u00f3re zainstaluj\u0105 CNI za Ciebie.<\/p>\n<p>Zwr\u00f3\u0107 uwag\u0119, \u017ce Kubernetes nie powiadomi Ci\u0119, je\u015bli ustalisz polityk\u0119 sieciow\u0105 bez odpowiedniego wspomagaj\u0105cego CNI.<\/p>\n<h3>Stanowy czy bezstanowy?<\/h3>\n<p>\nWszystkie CNI Kubernetes, z kt\u00f3rymi mia\u0142em do czynienia, przechowuj\u0105 stan (na przyk\u0142ad Calico u\u017cywa Linux conntrack). Umo\u017cliwia to podowi odbieranie odpowiedzi dla nawi\u0105zanych przez niego po\u0142\u0105cze\u0144 TCP bez konieczno\u015bci ponownego ich ustanawiania. Nie znam jednak standardu Kubernetes, kt\u00f3ry gwarantowa\u0142by utrzymanie stanu (statefulness).<\/p>\n<h2>Zaawansowane zarz\u0105dzanie polityk\u0105 bezpiecze\u0144stwa<\/h2>\n<p>\nOto kilka sposob\u00f3w na zwi\u0119kszenie efektywno\u015bci wykonania polityki bezpiecze\u0144stwa w Kubernetes:<\/p>\n<ol>\n<li> Wzorzec architektoniczny Service Mesh wykorzystuje kontenery sidecar do zapewnienia szczeg\u00f3\u0142owej telemetrii i kontroli ruchu na poziomie serwis\u00f3w. Jako przyk\u0142ad mo\u017cna poda\u0107 <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Niekt\u00f3rzy dostawcy CNI rozszerzyli swoje narz\u0119dzia, aby wykracza\u0107 poza polityki sieciowe Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> zapewnia przezroczysto\u015b\u0107 i automatyzacj\u0119 polityk sieciowych Kubernetes.<\/li>\n<\/ol>\n<p>\nPakiet Tufin Orca zarz\u0105dza politykami sieciowymi Kubernetes (i s\u0142u\u017cy jako \u017ar\u00f3d\u0142o zrzut\u00f3w ekranowych podanych powy\u017cej).<\/p>\n<h2>Dodatkowe informacje<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Przyk\u0142ady polityk sieciowych, przygotowane przez Ahmeta Alpa Balkana z GKE<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Dokumentacja z oficjalnej strony Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Przewodnik po modelu sieciowym Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Skrypt do sprawdzania polityk sieciowych<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Podsumowanie<\/h2>\n<p>\nPolityki sieciowe Kubernetes oferuj\u0105 dobr\u0105 gam\u0119 narz\u0119dzi do segmentacji klastr\u00f3w, jednak s\u0105 intuicyjnie nieczytelne i maj\u0105 wiele niuans\u00f3w. Uwa\u017cam, \u017ce z powodu tej z\u0142o\u017cono\u015bci polityki wielu istniej\u0105cych klastr\u00f3w zawieraj\u0105 b\u0142\u0119dy. Mo\u017cliwymi rozwi\u0105zaniami tego problemu s\u0105 automatyzacja definicji polityk lub zastosowanie innych narz\u0119dzi do segmentacji.<\/p>\n<p>Mam nadziej\u0119, \u017ce ten przewodnik pomo\u017ce wyja\u015bni\u0107 pewne kwestie i rozwi\u0105za\u0107 problemy, z kt\u00f3rymi mo\u017cesz si\u0119 spotka\u0107.<\/p>\n<h2>P.S. od t\u0142umacza<\/h2>\n<p>\nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n<ul>\n<li> \u201ePowr\u00f3t do mikroserwis\u00f3w z Istio\u201d: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">cz\u0119\u015b\u0107 1 (wprowadzenie do podstawowych mo\u017cliwo\u015bci)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">cz\u0119\u015b\u0107 2 (routing, zarz\u0105dzanie ruchem)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">cz\u0119\u015b\u0107 3 (bezpiecze\u0144stwo)<\/a><\/noindex>;<\/li>\n<li> \u201eIlustrowany przewodnik po urz\u0105dzeniu sieci w Kubernetes\u201d: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">cz\u0119\u015bci 1 i 2 (model sieci, sieci nak\u0142adkowe)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">cz\u0119\u015b\u0107 3 (us\u0142ugi i przetwarzanie ruchu)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker i Kubernetes w wymagaj\u0105cych \u015brodowiskach bezpiecze\u0144stwa<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 najlepszych praktyk zapewnienia bezpiecze\u0144stwa w Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 sposob\u00f3w (nie) na bycie ofiar\u0105 w\u0142amania w Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>\u0179r\u00f3d\u0142o: <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.1.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\/pl\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\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\/pl\/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\udd47Wprowadzenie do polityk sieciowych Kubernetes dla specjalist\u00f3w w dziedzinie bezpiecze\u0144stwa | ProHoster","description":"Przyk\u0142.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}