{"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\/de\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Anmerkung des \u00dcbersetzers.<\/b>: Der Autor des Artikels \u2013 Reuven Harrison \u2013 verf\u00fcgt \u00fcber mehr als 20 Jahre Erfahrung in der Softwareentwicklung und ist derzeit technischer Direktor und Mitgr\u00fcnder des Unternehmens Tufin, das L\u00f6sungen f\u00fcr das Sicherheitsrichtlinienmanagement entwickelt. Er betrachtet Kubernetes-Netzwerkrichtlinien als ein leistungsf\u00e4higes Mittel zur Netzsegmentierung in einem Cluster, ist jedoch gleichzeitig der Meinung, dass sie in der praktischen Anwendung nicht so einfach sind. Dieses (ziemlich umfangreiche) Material soll das Bewusstsein der Fachleute f\u00fcr dieses Thema sch\u00e4rfen und ihnen bei der Erstellung der ben\u00f6tigten Konfigurationen helfen.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Heute entscheiden sich viele Unternehmen zunehmend f\u00fcr Kubernetes zur Ausf\u00fchrung ihrer Anwendungen. Das Interesse an dieser Software ist so gro\u00df, dass einige Kubernetes als \u201eneues Betriebssystem f\u00fcr Rechenzentren\u201c bezeichnen. Allm\u00e4hlich wird Kubernetes (oder k8s) als kritischer Bestandteil des Gesch\u00e4fts angesehen, der die Organisation reifer Gesch\u00e4ftsprozesse erfordert, einschlie\u00dflich der Gew\u00e4hrleistung der Netzwerksicherheit.<\/p>\n<p>F\u00fcr Sicherheitsexperten, die Schwierigkeiten mit Kubernetes haben, k\u00f6nnte die Standardrichtlinie dieser Plattform eine wahre Offenbarung sein: Alles erlauben.<\/p>\n<p>Dieses Handbuch hilft dabei, das interne Wesen von Netzwerkrichtlinien zu verstehen; es erkl\u00e4rt, wie sie sich von Regeln f\u00fcr herk\u00f6mmliche Firewalls unterscheiden. Es werden auch einige Stolpersteine angesprochen und Empfehlungen gegeben, die helfen, Anwendungen in Kubernetes zu sch\u00fctzen.<\/p>\n<h2>Kubernetes-Netzwerkrichtlinien<\/h2>\n<p>\nDer Mechanismus der Kubernetes-Netzwerkrichtlinien erm\u00f6glicht die Verwaltung der Interaktionen der auf der Plattform bereitgestellten Anwendungen auf Netzwerkebene (Schicht drei im OSI-Modell). Netzwerkrichtlinien verf\u00fcgen nicht \u00fcber einige der fortschrittlichen Funktionen moderner Firewalls, wie etwa die Kontrolle auf OSI-Schicht 7 und Bedrohungserkennung, bieten jedoch ein grundlegendes Ma\u00df an Netzwerksicherheit, das einen soliden Ausgangspunkt darstellt.<\/p>\n<h2>Netzwerkpolicies steuern die Kommunikation zwischen Pods.<\/h2>\n<p>\nIn Kubernetes werden Arbeitslasten auf Pods verteilt, die aus einem oder mehreren gemeinsam bereitgestellten Containern bestehen. Kubernetes weist jedem Pod eine IP-Adresse zu, die von anderen Pods erreichbar ist. Die Netzwerkpolicies in Kubernetes legen die Zugriffsrechte f\u00fcr Gruppen von Pods auf die gleiche Weise fest, wie Sicherheitsgruppen in der Cloud verwendet werden, um den Zugriff auf virtuelle Maschinen zu steuern.<\/p>\n<h2>Definition von Netzwerk-Richtlinien<\/h2>\n<p>\nWie andere Kubernetes-Ressourcen werden Netzwerk-Richtlinien in YAML definiert. Im folgenden Beispiel wird der Anwendung <code>balance<\/code> Zugriff auf <code>in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Anmerkung des \u00dcbersetzers.<\/b>: Dieses Screenshot, wie alle folgenden \u00e4hnlichen, wurde nicht mit den nativen Mitteln von Kubernetes erstellt, sondern mit dem Tool Tufin Orca, dessen Entwicklung von dem Unternehmen hinter dem urspr\u00fcnglichen Artikel stammt und das am Ende des Materials erw\u00e4hnt wird.<\/i><\/p>\n<p>Um eine eigene Netzwerk-Richtlinie zu definieren, sind grundlegende Kenntnisse in YAML erforderlich. Diese Sprache basiert auf Einr\u00fcckungen (die mit Leerzeichen anstelle von Tabulatoren angegeben werden). Ein Element mit einer Einr\u00fcckung geh\u00f6rt zum n\u00e4chsten \u00fcbergeordneten Element mit einer Einr\u00fcckung. Ein neues Listenelement beginnt mit einem Bindestrich, w\u00e4hrend alle anderen Elemente wie folgt aussehen: <i>von Schl\u00fcssel-Wert-Paaren<\/i>.<\/p>\n<p>Nachdem Sie die Richtlinie in YAML beschrieben haben, verwenden Sie <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, um sie im Cluster zu erstellen:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Spezifikation der Netzwerk-Richtlinie<\/h2>\n<p>\nDie Spezifikation der Netzwerk-Richtlinie von Kubernetes umfasst vier Elemente:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: definiert die Pods, die von dieser Policy betroffen sind (Ziele) \u2014 obligatorisch;<\/li>\n<li> <code>policyTypes<\/code>: gibt an, welche Arten von Richtlinien in dieser enthalten sind: ingress und\/oder egress \u2013 optional, ich empfehle jedoch, dies in allen F\u00e4llen ausdr\u00fccklich anzugeben;<\/li>\n<li> <code>ingress<\/code>: definiert den erlaubten <b>eingehenden<\/b> der Verkehr zu den Ziel-Pods \u2014 optional;<\/li>\n<li> <code>egress<\/code>: definiert den erlaubten <b>ausgehenden<\/b> der Verkehr von den Ziel-Pods \u2014 optional.<\/li>\n<\/ol>\n<p>\nEin Beispiel, das von der Kubernetes-Website entnommen wurde (ich habe <code>role<\/code> auf <code>App<\/code>), zeigt, wie alle vier Elemente verwendet werden:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBitte beachten Sie, dass nicht alle vier Elemente zwingend erforderlich sind. Nur <code>podSelector<\/code>ist notwendig, die anderen Parameter k\u00f6nnen nach Bedarf verwendet werden.<\/p>\n<p>Wenn Sie weglassen <code>policyTypes<\/code>, wird die Richtlinie wie folgt interpretiert:<\/p>\n<ul>\n<li> Standardm\u00e4\u00dfig wird davon ausgegangen, dass sie die Ingress-Seite definiert. Wenn in der Richtlinie keine ausdr\u00fccklichen Hinweise gegeben werden, wird das System annehmen, dass der gesamte Verkehr verboten ist.<\/li>\n<li> Das Verhalten auf der Egress-Seite wird durch das Vorhandensein oder Fehlen des entsprechenden Egress-Parameters bestimmt.<\/li>\n<\/ul>\n<p>\nUm Fehler zu vermeiden, empfehle ich <b>immer ausdr\u00fccklich anzugeben <code>policyTypes<\/code><\/b>.<\/p>\n<p>Gem\u00e4\u00df der obigen Logik wird, falls die Parameter <code>ingress<\/code> und\/oder <code>egress<\/code> weggelassen werden, die Richtlinie den gesamten Verkehr verbieten (siehe \"Aufr\u00e4umregel\" unten).<\/p>\n<h2>Standardrichtlinie \u2014 erlauben<\/h2>\n<p>\nWenn keine Policies definiert sind, erlaubt Kubernetes standardm\u00e4\u00dfig den gesamten Verkehr. Alle Pods k\u00f6nnen Informationen frei untereinander austauschen. Aus sicherheitstechnischer Sicht mag dies unlogisch erscheinen, aber bedenken Sie, dass Kubernetes urspr\u00fcnglich von Entwicklern erschaffen wurde, um die Interaktion von Anwendungen zu erm\u00f6glichen. Netzwerkpolicies wurden sp\u00e4ter hinzugef\u00fcgt.<\/p>\n<h2>Namespaces<\/h2>\n<p>\nNamespaces (Namespaces) sind ein Mechanismus f\u00fcr die Zusammenarbeit in Kubernetes. Sie sind dazu gedacht, logische Umgebungen voneinander zu isolieren, w\u00e4hrend der Datenaustausch zwischen Namespaces standardm\u00e4\u00dfig erlaubt ist.<\/p>\n<p>Wie die meisten Komponenten von Kubernetes befinden sich Netzwerkrichtlinien in einem bestimmten Namespace. Im Block <code>in der Ressourcenspezifikation des Pods. Genauere Informationen finden Sie im<\/code> kann angegeben werden, welchem Namespace die Richtlinie angeh\u00f6rt:<\/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>\nWenn der Namespace in den Metadaten nicht ausdr\u00fccklich angegeben ist, verwendet das System den Namespace, der in kubectl angegeben ist (standardm\u00e4\u00dfig <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nIch empfehle <b>den Namespace ausdr\u00fccklich anzugeben<\/b>, es sei denn, Sie schreiben Richtlinien, die f\u00fcr mehrere Namensr\u00e4ume gleichzeitig vorgesehen sind.<\/p>\n<p><b>Haupt<\/b> Element <code>podSelector<\/code> In der Policy werden Pods aus dem Namespace ausgew\u00e4hlt, dem die Policy angeh\u00f6rt (sie haben keinen Zugriff auf Pods aus einem anderen Namespace).<\/p>\n<p>\u00c4hnlich wie podSelector <b>nur Pods aus ihrem eigenen Namensraum ausw\u00e4hlen, es sei denn, Sie verbinden sie mit<\/b> (dar\u00fcber wird im Abschnitt 'Filter nach Namensr\u00e4umen und Pods' gesprochen). <code>namespaceSelector<\/code> dar\u00fcber wird im Abschnitt \"Filter nach Namespaces und Pods\" gesprochen.<\/p>\n<h2>Die Namen von Richtlinien sind innerhalb eines Namensraums eindeutig. Es k\u00f6nnen keine zwei Richtlinien mit demselben Namen im gleichen Namensraum existieren, aber es k\u00f6nnen Richtlinien mit denselben Namen in verschiedenen Namensr\u00e4umen vorhanden sein. Dies ist praktisch, wenn Sie dieselbe Richtlinie auf mehreren Namensr\u00e4umen anwenden m\u00f6chten.<\/h2>\n<p>\nIch mag besonders eine der Namenskonventionen. Sie besteht darin, den Namen des Namensraums mit den Ziel-Pods zu kombinieren. Zum Beispiel:<\/p>\n<p>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<\/p>\n<pre><code class=\"plaintext\">Labels<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Benutzerdefinierte Labels k\u00f6nnen an Kubernetes-Objekte wie Pods und Namensr\u00e4ume angeh\u00e4ngt werden. Labels (<\/h2>\n<p>\n\u2014 Tags) sind das \u00c4quivalent zu Tags in der Cloud. Kubernetes-Netzwerkrichtlinien verwenden Labels, um auszuw\u00e4hlen<i>labels<\/i> , auf die sie angewendet werden: <b>Pods<\/b>podSelector:\n  matchLabels:\n    role: db<\/p>\n<pre><code class=\"plaintext\">\u2026 oder<\/code><\/pre>\n<p>\nNamensr\u00e4ume <b>, auf die sie angewendet werden. In diesem Beispiel werden alle Pods in den Namensr\u00e4umen mit den entsprechenden Labels ausgew\u00e4hlt:<\/b>, auf die sie angewendet werden. In diesem Beispiel werden alle Pods in Namespaces mit den entsprechenden Labels ausgew\u00e4hlt:<\/p>\n<pre><code class=\"plaintext\">Eine Warnung: Bei der Verwendung von<\/code><\/pre>\n<p>\nstellen Sie sicher, dass die ausgew\u00e4hlten Namensr\u00e4ume das ben\u00f6tigte Label enthalten <code>namespaceSelector<\/code> <b>. Bedenken Sie, dass die eingebauten Namensr\u00e4ume wie<\/b>, standardm\u00e4\u00dfig keine Labels enthalten. <code>default<\/code> und <code>kube-system<\/code>Ein Label zu einem Namensraum kann wie folgt hinzugef\u00fcgt werden:<\/p>\n<p>kubectl label namespace default namespace=default<\/p>\n<pre><code class=\"bash\">Dabei muss der Namensraum im Abschnitt<\/code><\/pre>\n<p>\nauf den tats\u00e4chlichen Namen des Namensraums und nicht auf das Label verweisen: <code>in der Ressourcenspezifikation des Pods. Genauere Informationen finden Sie im<\/code> apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default   # &lt;&lt;&lt;\nspec:\n...<\/p>\n<pre><code class=\"plaintext\">Quelle und Empf\u00e4nger<\/code><\/pre>\n<p><\/p>\n<h2>Quelle und Empf\u00e4nger<\/h2>\n<p>\nPolicies f\u00fcr Firewalls bestehen aus Regeln mit Quellen und Zielen. Die Netzwerkpolicies in Kubernetes werden f\u00fcr das Ziel definiert \u2014 eine Menge von Pods, auf die sie angewendet werden, und legen dann Regeln f\u00fcr den eingehenden (Ingress) und\/oder ausgehenden (Egress) Verkehr fest. In unserem Beispiel wird das Ziel der Policy alle Pods im Namespace sein. <code>default<\/code> mit einem Label mit dem Schl\u00fcssel <code>App<\/code> und mit dem Wert. <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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnterabschnitt <code>ingress<\/code> in dieser Richtlinie \u00f6ffnet den eingehenden Datenverkehr zu den Ziel-Pods. Mit anderen Worten, der Ingress fungiert als Quelle, und das Ziel ist der entsprechende Empf\u00e4nger. Ebenso ist Egress der Empf\u00e4nger, und das Ziel ist seine Quelle.<\/p>\n<p><img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Dies entspricht zwei Regeln f\u00fcr die Firewall: Ingress \u2192 Ziel; Ziel \u2192 Egress.<\/i><\/p>\n<h2>Egress und DNS (wichtig!)<\/h2>\n<p>\nWenn Sie den ausgehenden Datenverkehr einschr\u00e4nken, <b>achten Sie besonders auf DNS<\/b> \u2013 Kubernetes verwendet diesen Dienst, um Dienste mit IP-Adressen zu verkn\u00fcpfen. Zum Beispiel wird die folgende Richtlinie nicht funktionieren, da Sie dem Programm nicht erlaubt haben, <code>balance<\/code> auf DNS zuzugreifen:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSie k\u00f6nnen sie beheben, indem Sie den Zugriff auf den DNS-Dienst \u00f6ffnen:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas letzte Element <code>to<\/code> ist leer und w\u00e4hlt daher indirekt <b>alle Pods in allen Namespaces<\/b>, erlaubt <code>balance<\/code> das Senden von DNS-Anfragen an den entsprechenden Kubernetes-Dienst (normalerweise l\u00e4uft dieser im Namensraum <code>kube-system<\/code>).<\/p>\n<p>Dieser Ansatz funktioniert, jedoch <b>ist \u00fcberm\u00e4\u00dfig gro\u00dfz\u00fcgig und unsicher<\/b>, da er es erlaubt, DNS-Anfragen au\u00dferhalb des Clusters zu senden.<\/p>\n<p>Sie k\u00f6nnen ihn durch drei aufeinanderfolgende Schritte verbessern.<\/p>\n<p>1. Erlauben Sie DNS-Anfragen nur <b>innerhalb<\/b> zum Cluster, indem Sie hinzuf\u00fcgen <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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Erlaube DNS-Anfragen nur im Namensraum <code>kube-system<\/code>.<\/p>\n<p>Daf\u00fcr muss ein Label im Namensraum hinzugef\u00fcgt werden <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 und es in der Richtlinie festgelegt werden durch <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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Paranoide k\u00f6nnen noch weiter gehen und DNS-Anfragen auf einen bestimmten DNS-Dienst in <code>kube-system<\/code>. Im Abschnitt \"Filter nach Namespaces und Pods\" wird beschrieben, wie dies erreicht werden kann.<\/p>\n<p>Eine andere M\u00f6glichkeit besteht darin, DNS auf Namensraum-Ebene zu erlauben. In diesem Fall muss es nicht f\u00fcr jeden Dienst ge\u00f6ffnet werden:<\/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>\nLeer <code>podSelector<\/code> w\u00e4hlt alle Pods im Namensraum aus.<\/p>\n<p><img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Erste \u00dcbereinstimmung und Reihenfolge der Regeln<\/h2>\n<p>\nIn herk\u00f6mmlichen Firewalls wird die Aktion (\"Erlauben\" oder \"Verweigern\") in Bezug auf ein Paket durch die erste Regel bestimmt, die es erf\u00fcllt. <b>In Kubernetes hat die Reihenfolge der Richtlinien keine Bedeutung.<\/b><\/p>\n<p>Standardm\u00e4\u00dfig, wenn keine Policies definiert sind, sind die Kommunikationen zwischen Pods erlaubt und sie k\u00f6nnen Informationen frei austauschen. Sobald Sie beginnen, Policies zu formulieren, wird jeder Pod, der von einer von ihnen betroffen ist, isoliert gem\u00e4\u00df der Disjunktion (logisches ODER) aller Policies, die ihn ausgew\u00e4hlt haben. Pods, die von keiner Policy betroffen sind, bleiben offen.<\/p>\n<p>Sie k\u00f6nnen ein solches Verhalten durch eine Bereinigungsregel \u00e4ndern.<\/p>\n<h2>Die Bereinigungsregel (\"Verweigern\")<\/h2>\n<p>\nFirewalls-Richtlinien verbieten in der Regel jeglichen ausdr\u00fccklich nicht erlaubten Datenverkehr.<\/p>\n<p><b>In Kubernetes gibt es keine Aktion \u201everweigern\u201c (deny),<\/b>, jedoch kann ein \u00e4hnlicher Effekt mit einer normalen (erlaubenden) Richtlinie erzielt werden, indem eine leere Gruppe von Pod-Quellen (Ingress) ausgew\u00e4hlt wird:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDiese Richtlinie w\u00e4hlt alle Pods im Namespace aus und l\u00e4sst den Ingress undefiniert, wodurch aller eingehender Traffic verboten wird.<\/p>\n<p>\u00c4hnlich kann der gesamte ausgehende Verkehr aus dem Namensraum eingeschr\u00e4nkt werden:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBitte beachten Sie, dass <b>jegliche zus\u00e4tzlichen Richtlinien, die Traffic zu Pods im Namespace erlauben, haben Vorrang vor dieser Regel<\/b> (\u00e4hnlich wie das Hinzuf\u00fcgen einer erlaubenden Regel vor einer verbietenden in einer Firewall-Konfiguration).<\/p>\n<h2>Erlaube alles (Any-Any-Any-Allow)<\/h2>\n<p>\nUm eine \u201eErlaube alles\u201c-Richtlinie zu erstellen, muss die oben angegebene verbietende Richtlinie um ein leeres Element erg\u00e4nzt werden. <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: # &gt;&gt;&gt;\n  - {}     # &gt;&gt;&gt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSie \u00f6ffnet den Zugang von <b>alle Pods in allen Namespaces (und allen IPs) zu irgendeinem Pod im Namespace <code>default<\/code><\/b>. Ein solches Verhalten ist standardm\u00e4\u00dfig aktiviert, sodass es normalerweise nicht zus\u00e4tzlich definiert werden muss. In bestimmten F\u00e4llen kann es jedoch erforderlich sein, einige spezifische Berechtigungen vor\u00fcbergehend zu deaktivieren, um ein Problem zu diagnostizieren.<\/p>\n<p>Die Regel kann eingeschr\u00e4nkt werden, um den Zugang nur zu <b>einer bestimmten Gruppe von Pods<\/b> (<code>app:balance<\/code>) im Namensraum <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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie folgende Richtlinie erlaubt gesamten eingehenden (Ingress) und ausgehenden (Egress) Verkehr, einschlie\u00dflich Zugriff auf jede IP au\u00dferhalb des Clusters:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Kombination mehrerer Richtlinien<\/h2>\n<p>\nDie Richtlinien werden auf drei Ebenen mit logisch ODER kombiniert; die Erlaubnisse jedes Pods werden gem\u00e4\u00df der Disjunktion aller Richtlinien, die ihn betreffen, festgelegt:<\/p>\n<p>1. In den Feldern <code>from<\/code> und <code>to<\/code> k\u00f6nnen drei Typen von Elementen definiert werden (alle werden mit ODER kombiniert):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 w\u00e4hlt den Namensraum vollst\u00e4ndig aus;<\/li>\n<li> <code>podSelector<\/code> \u2014 w\u00e4hlt Pods aus;<\/li>\n<li> <code>ipBlock<\/code> \u2014 w\u00e4hlt ein Subnetz aus.<\/li>\n<\/ul>\n<p>\nDabei ist die Anzahl der Elemente (auch wenn sie gleich sind) in den Unterabschnitten <code>from<\/code>\/<code>to<\/code> nicht begrenzt. Alle werden mit logischem ODER kombiniert.<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Innerer Abschnitt der Richtlinie <code>ingress<\/code> kann mehrere Elemente enthalten <code>from<\/code> (die logisch mit ODER kombiniert werden). Entsprechend kann der Abschnitt <code>egress<\/code> mehrere Elemente umfassen <code>to<\/code> (die ebenfalls mit ODER kombiniert werden):<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Verschiedene Richtlinien werden ebenfalls logisch mit ODER kombiniert<\/p>\n<p>Aber bei ihrer Kombination gibt es eine Einschr\u00e4nkung, auf die <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">wies darauf hin<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes kann Richtlinien nur mit verschiedenen <code>policyTypes<\/code> (<code>Ingress<\/code> oder <code>Egress<\/code>). Richtlinien, die ingress (oder egress) definieren, \u00fcberschreiben sich gegenseitig.<\/p>\n<h2>Kommunikation zwischen Namespaces<\/h2>\n<p>\nStandardm\u00e4\u00dfig ist der Informationsaustausch zwischen Namespaces erlaubt. Dies kann durch eine verbietende Richtlinie ge\u00e4ndert werden, die den ausgehenden und\/oder eingehenden Datenverkehr zu einem Namespace einschr\u00e4nkt (siehe oben \"Bereinigungsvorschrift\").<\/p>\n<p>Wenn Sie den Zugriff auf einen Namespace blockieren (siehe oben \"Bereinigungsvorschrift\"), k\u00f6nnen Sie Ausnahmen in der verbietenden Richtlinie vornehmen, indem Sie Verbindungen von einem bestimmten Namespace \u00fcber <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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInfolgedessen haben alle Pods im Namespace <code>default<\/code> haben Zugriff auf Pods <code>in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier<\/code> im Namensraum <code>database<\/code>. Aber was, wenn Sie den Zugriff auf <code>in einer Umgebung, in der die Locale nicht UTF-8 ist, beispielsweise in einer leeren Umgebung (hier<\/code> nur auf bestimmte Pods im Namespace <code>default<\/code>?<\/p>\n<h2>Filter nach Namespaces und Pods<\/h2>\n<p>\nKubernetes Version 1.11 und h\u00f6her erm\u00f6glicht die Kombination von Operatoren <code>namespaceSelector<\/code> und <code>podSelector<\/code> mit logischem UND. So sieht das aus:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWarum wird das als UND statt als gewohnt ODER interpretiert?<\/p>\n<p>Beachten Sie, dass <code>podSelector<\/code> beginnt nicht mit einem Bindestrich. In YAML bedeutet dies, dass <code>podSelector<\/code> und das davor stehende <code>namespaceSelector<\/code> zu demselben Listelement geh\u00f6ren. Daher werden sie logisch mit UND kombiniert.<\/p>\n<p>Das Hinzuf\u00fcgen eines Bindestrichs davor <code>podSelector<\/code> f\u00fchrt zur Entstehung eines neuen Listenelements, das mit dem vorhergehenden kombiniert wird <code>namespaceSelector<\/code> mittels logischem ODER.<\/p>\n<p>Um Pods mit einem bestimmten Label auszuw\u00e4hlen <b>in allen Namensr\u00e4umen<\/b>, geben Sie leer ein <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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Mehrere Labels werden mit UND kombiniert<\/h2>\n<p>\nRegeln f\u00fcr Firewalls mit mehreren Objekten (Hosts, Netzwerken, Gruppen) werden mittels logischem ODER kombiniert. Die folgende Regel tritt in Kraft, wenn die Quelladresse des Pakets \u00fcbereinstimmt mit <code>Host_1<\/code> ODER <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Quelle | Ziel | Dienst | Aktion |\n| ----------------------------------------|\n| Host_1 | Subnetz_A    | HTTPS   | Erlauben  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nIm Gegensatz dazu werden in Kubernetes verschiedene Labels in <code>podSelector<\/code> oder <code>namespaceSelector<\/code> logischem UND kombiniert. Zum Beispiel w\u00e4hlt die folgende Regel Pods aus, die beide Labels besitzen, <code>role=db<\/code> Und <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nDie gleiche Logik gilt f\u00fcr alle Arten von Operatoren: Zielrichtlinienselektoren, Podselektoren und Namespaceselektoren.<\/p>\n<h2>Subnetze und IP-Adressen (IPBlocks)<\/h2>\n<p>\nZur Segmentierung des Netzwerks verwenden Firewalls VLANs, IP-Adressen und Subnetze.<\/p>\n<p>In Kubernetes werden IP-Adressen automatisch Pods zugewiesen und k\u00f6nnen sich h\u00e4ufig \u00e4ndern, weshalb Labels zur Auswahl von Pods und Namespaces in Netzwerkrichtlinien verwendet werden.<\/p>\n<p>Subnetze (<code>ipBlocks<\/code>) werden bei der Verwaltung von eingehenden (Ingress) oder ausgehenden (Egress) externen (North-South) Verbindungen verwendet. Zum Beispiel \u00f6ffnet diese Richtlinie allen Pods aus dem Namespace <code>default<\/code> Zugriff auf den DNS-Dienst von 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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEin leerer Pod-Selektor in diesem Beispiel bedeutet \u201ealle Pods im Namespace ausw\u00e4hlen\u201c.<\/p>\n<p>Diese Politik erlaubt nur den Zugriff auf 8.8.8.8; der Zugriff auf jede andere IP ist verboten. Damit haben Sie effektiv den Zugriff auf den internen Kubernetes-DNS-Service blockiert. Wenn Sie diesen dennoch gew\u00e4hren m\u00f6chten, geben Sie dies ausdr\u00fccklich an.<\/p>\n<p>Normalerweise <code>ipBlocks<\/code> und <code>podSelectors<\/code> sind gegenseitig ausschlie\u00dfend, da interne IP-Adressen von Pods nicht in <code>ipBlocks<\/code>verwendet werden. Indem Sie <b>internen IPs von Pods<\/b>, erlauben Sie tats\u00e4chlich Verbindungen zu\/von Pods mit diesen Adressen. In der Praxis wissen Sie nicht, welche IP-Adresse verwendet werden soll, weshalb sie nicht f\u00fcr die Auswahl von Pods verwendet werden sollten.<\/p>\n<p>Als Gegenbeispiel umfasst die folgende Richtlinie alle IPs und erlaubt somit den Zugriff auf alle anderen Pods:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEs ist m\u00f6glich, den Zugriff nur auf externe IPs zu \u00f6ffnen und interne IP-Adressen von Pods auszuschlie\u00dfen. Zum Beispiel, wenn das Subnetz Ihres Pods 10.16.0.0\/14 betr\u00e4gt:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Ports und Protokolle<\/h2>\n<p>\nNormalerweise h\u00f6ren Pods auf einen Port. Das bedeutet, dass Sie einfach die Portnummern in den Richtlinien nicht angeben und alles auf die Standardeinstellungen belassen k\u00f6nnen. Es wird jedoch empfohlen, die Richtlinien so restriktiv wie m\u00f6glich zu gestalten, weshalb es in einigen F\u00e4llen dennoch sinnvoll sein kann, Ports anzugeben:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeachten Sie, dass der Selektor <code>ports<\/code> auf alle Elemente im Block angewendet wird, <code>to<\/code> oder <code>from<\/code>, in dem er sich befindet. Um verschiedene Ports f\u00fcr unterschiedliche Elementgruppen anzugeben, teilen Sie <code>ingress<\/code> oder <code>egress<\/code> in mehrere Unterabschnitte auf mit <code>to<\/code> oder <code>from<\/code> und geben Sie in jedem Ihre Ports an:<\/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=\"Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsexperten\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nStandardm\u00e4\u00dfige Portverarbeitung:<\/p>\n<ul>\n<li> Wenn Sie die Portdefinitionen vollst\u00e4ndig weglassen (<code>ports<\/code>), bedeutet dies alle Protokolle und alle Ports;<\/li>\n<li> Wenn Sie die Protokolldefinition weglassen (<code>protocol<\/code>), bedeutet dies TCP;<\/li>\n<li> Wenn Sie die Portdefinition weglassen (<code>port<\/code>), bedeutet dies alle Ports.<\/li>\n<\/ul>\n<p>\nBeste Praxis: Verlassen Sie sich nicht auf Standardwerte, geben Sie die ben\u00f6tigten Werte eindeutig an.<\/p>\n<p>Bitte beachten Sie, dass Sie die Ports der Pods und nicht die der Services verwenden m\u00fcssen (mehr dazu im n\u00e4chsten Abschnitt).<\/p>\n<h2>Sind die Richtlinien f\u00fcr Pods oder Services definiert?<\/h2>\n<p>\nTypischerweise kommunizieren Pods in Kubernetes \u00fcber einen Service \u2013 ein virtueller Lastenausgleich, der den Verkehr zu den Pods weiterleitet, die den Service implementieren. Man k\u00f6nnte denken, dass Netzwerkrichtlinien den Zugang zu Services kontrollieren, aber das ist nicht der Fall. <b>Netzwerkrichtlinien in Kubernetes arbeiten mit den Ports der Pods und nicht mit den der Services.<\/b><\/p>\n<p>Wenn ein Service beispielsweise Port 80 abh\u00f6rt, aber den Verkehr an Port 8080 seiner Pods weiterleitet, muss in der Netzwerkrichtlinie genau 8080 angegeben werden.<\/p>\n<p>Ein solches Mechanismus sollte als suboptimal angesehen werden: Wenn sich die interne Konfiguration des Services \u00e4ndert (dessen Ports von den Pods abh\u00f6rt), m\u00fcssen die Netzwerkrichtlinien aktualisiert werden.<\/p>\n<p>Ein neuer architektonischer Ansatz mit Service Mesh <i>(z. B. siehe weiter unten zu Istio \u2014 Anm. d. \u00dcbers.)<\/i> l\u00f6st dieses Problem.<\/p>\n<h2>Muss man sowohl Ingress als auch Egress angeben?<\/h2>\n<p>\nDie kurze Antwort lautet: Ja, damit Pod A mit Pod B kommunizieren kann, muss ihm erlaubt werden, eine ausgehende Verbindung zu erstellen (dazu muss die Egress-Richtlinie konfiguriert werden), und Pod B muss in der Lage sein, eine eingehende Verbindung zu akzeptieren (dazu ist entsprechend eine Ingress-Richtlinie erforderlich).<\/p>\n<p>In der Praxis kann jedoch oft auf die Standardrichtlinie zur\u00fcckgegriffen werden, die Verbindungen in einer oder beiden Richtungen zul\u00e4sst.<\/p>\n<p>Wenn ein Pod-<b>Quelle<\/b> von einer oder mehreren <b>egress<\/b>-Richtlinien ausgew\u00e4hlt wird, werden die ihm auferlegten Beschr\u00e4nkungen durch ihre Disjunktion bestimmt. In diesem Fall muss der Zugriff auf den Pod-<b>Ziel<\/b>ausdr\u00fccklich gew\u00e4hrt werden. Wenn ein Pod von keiner Richtlinie ausgew\u00e4hlt wird, ist der ausgehende (Egress) Datenverkehr standardm\u00e4\u00dfig erlaubt.<\/p>\n<p>\u00c4hnlich wird das Schicksal des Pods durch<b>Ziel<\/b>, der von einer oder mehreren <b>ingress<\/b>die Richtlinien bestimmt, die durch ihre Disjunktion definiert werden. In diesem Fall muss ausdr\u00fccklich erlaubt werden, dass er Verkehr von einem Quell-Pod erh\u00e4lt. Wenn ein Pod von keiner Richtlinie erfasst wird, ist der gesamte eingehende Verkehr f\u00fcr ihn standardm\u00e4\u00dfig erlaubt.<\/p>\n<p>Siehe Punkt \u201eStateful oder Stateless\u201c weiter unten.<\/p>\n<h2>Logs<\/h2>\n<p>\nNetzwerkrichtlinien in Kubernetes k\u00f6nnen den Datenverkehr nicht protokollieren. Dies erschwert die Feststellung, ob eine Richtlinie ordnungsgem\u00e4\u00df funktioniert, und macht die Sicherheitsanalyse deutlich komplizierter.<\/p>\n<h2>Die Kontrolle des Datenverkehrs zu externen Diensten<\/h2>\n<p>\nDie Kubernetes-Netzwerk-Richtlinien erlauben es nicht, einen vollwertigen Domainnamen (DNS) in den Egress-Abschnitten anzugeben. Diese Tatsache f\u00fchrt zu erheblichen Unannehmlichkeiten, wenn man versucht, den Datenverkehr zu externen Adressen, die keine feste IP-Adresse haben (wie aws.com), zu beschr\u00e4nken.<\/p>\n<h2>Richtlinienpr\u00fcfung<\/h2>\n<p>\nFirewalls warnen Sie oder lehnen sogar ab, fehlerhafte Richtlinien zu akzeptieren. Auch Kubernetes f\u00fchrt einige \u00dcberpr\u00fcfungen durch. Wenn eine Netzwerk-Richtlinie \u00fcber kubectl festgelegt wird, kann Kubernetes angeben, dass sie ung\u00fcltig ist und die Annahme verweigern. In anderen F\u00e4llen akzeptiert Kubernetes die Richtlinie und erg\u00e4nzt sie mit fehlenden Details. Diese k\u00f6nnen Sie mit dem Befehl einsehen:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nBitte beachten Sie, dass das Pr\u00fcfssystem von Kubernetes nicht fehlerfrei ist und bestimmte Arten von Fehlern \u00fcbersehen kann.<\/p>\n<h2>Implementierung<\/h2>\n<p>\nKubernetes selbst implementiert keine Netzwerk-Richtlinien, sondern fungiert lediglich als API-Gateway, das die l\u00e4stige Aufgabe der Kontrolle auf das zugrunde liegende System, das als Container Networking Interface (CNI) bezeichnet wird, \u00fcbertr\u00e4gt. Das Festlegen von Richtlinien in einem Kubernetes-Cluster ohne die Zuweisung des entsprechenden CNI ist vergleichbar mit dem Erstellen von Richtlinien auf einem Firewall-Management-Server, ohne diese anschlie\u00dfend in die Firewalls zu implementieren. Sie m\u00fcssen selbst sicherstellen, dass ein ad\u00e4quates CNI vorhanden ist oder, bei in der Cloud gehosteten Kubernetes-Plattformen, die Netzwerk-Richtlinien aktivieren, die das CNI automatisch f\u00fcr Sie festlegt. <i>(die Liste der Anbieter finden Sie hier <noindex>hier<\/noindex> \u2014 Anm. d. \u00dc.)<\/i>, aktivieren Sie die Netzwerk-Richtlinien, die das CNI f\u00fcr Sie festlegen.<\/p>\n<p>Bitte beachten Sie, dass Kubernetes Sie nicht warnt, wenn Sie eine Netzwerk-Richtlinie ohne das entsprechende unterst\u00fctzende CNI festlegen.<\/p>\n<h3>Stateful oder Stateless?<\/h3>\n<p>\nAlle CNI von Kubernetes, mit denen ich bisher zu tun hatte, speichern den Zustand (zum Beispiel verwendet Calico Linux conntrack). Dies erm\u00f6glicht es einem Pod, Antworten auf die von ihm initiierten TCP-Verbindungen zu erhalten, ohne diese neu aufbauen zu m\u00fcssen. Mir ist jedoch kein Kubernetes-Standard bekannt, der die Speicherung des Zustands (Statefulness) garantiert.<\/p>\n<h2>Erweiterte Sicherheitsrichtlinienverwaltung<\/h2>\n<p>\nHier sind einige M\u00f6glichkeiten, die Effektivit\u00e4t der Umsetzung von Sicherheitsrichtlinien in Kubernetes zu verbessern:<\/p>\n<ol>\n<li> Das architektonische Muster Service Mesh verwendet Sidecar-Container, um umfassende Telemetrie und Kontrolle \u00fcber den Datenverkehr auf der Service-Ebene bereitzustellen. Ein Beispiel k\u00f6nnte sein <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Einige der CNI-Anbieter haben ihre Tools erweitert, sodass sie \u00fcber die Netzwerkrichtlinien von Kubernetes hinausgehen.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> bietet Transparenz und Automatisierung der Netzwerkrichtlinien von Kubernetes.<\/li>\n<\/ol>\n<p>\nDas Tufin Orca-Paket verwaltet die Netzwerkrichtlinien von Kubernetes (und dient als Quelle f\u00fcr die oben gezeigten Screenshots).<\/p>\n<h2>Zus\u00e4tzliche Informationen<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Beispiele f\u00fcr Netzwerkrichtlinien, erstellt von Ahmet Alp Balkan aus GKE.<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Dokumentation von der offiziellen Kubernetes-Website<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Leitfaden zum Netzwerkmodell von Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Skript zur \u00dcberpr\u00fcfung von Netzwerkrichtlinien<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Fazit<\/h2>\n<p>\nDie Netzwerkrichtlinien von Kubernetes bieten eine ansprechende Reihe von Werkzeugen zur Segmentierung von Clustern, sind jedoch nicht intuitiv und weisen zahlreiche Feinheiten auf. Ich bin der Meinung, dass aufgrund dieser Komplexit\u00e4t viele bestehende Cluster fehlerhaft konfiguriert sind. M\u00f6gliche L\u00f6sungen f\u00fcr dieses Problem sind die Automatisierung von Richtlinieneinstellungen oder die Anwendung anderer Segmentierungswerkzeuge.<\/p>\n<p>Ich hoffe, dass dieser Leitfaden dazu beitr\u00e4gt, einige Fragen zu kl\u00e4ren und Probleme zu l\u00f6sen, auf die Sie m\u00f6glicherweise sto\u00dfen.<\/p>\n<h2>P.S. vom \u00dcbersetzer<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> Teil 1 (Eintreffen auf die grundlegenden M\u00f6glichkeiten) <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">Teil 3 (Authentifizierung und Autorisierung)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">Teil 2 (Routing, Verkehrsmanagement)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">Teil 3 (Sicherheit)<\/a><\/noindex>;<\/li>\n<li> \u201eIllustriertes Handbuch zum Netzwerkaufbau in Kubernetes\u201c: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">Teil 1 und 2 (Netzwerkmodell, Overlay-Netzwerke)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">Teil 3 (Dienste und Verkehrsmanagement)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker und Kubernetes in sicherheitssensiblen Umgebungen<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 beste Praktiken f\u00fcr die Sicherheit in Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 Wege, wie man (nicht) Opfer eines Hacks in Kubernetes wird<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Quelle: <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\/de\/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=\"de_DE\" \/>\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\/de\/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\udd47Einf\u00fchrung in die Netzwerkrichtlinien von Kubernetes f\u00fcr Sicherheitsspezialisten | ProHoster","description":"z.B.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}