{"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 Netzwerkpolitik von Kubernetes f\u00fcr Sicherheitsexperten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Einf\u00fchrung
\n
\nHinweis.<\/b>: Der Autor des Artikels, Reuven Harrison, bringt \u00fcber 20 Jahre Erfahrung in der Softwareentwicklung mit und ist derzeit technischer Direktor und Mitgr\u00fcnder von Tufin, einem Unternehmen, das L\u00f6sungen zur Verwaltung von Sicherheitsrichtlinien entwickelt. W\u00e4hrend er Kubernetes-Netzwerkrichtlinien als ein kraftvolles Mittel zur Netzwerksegmentierung innerhalb von Clustern sieht, ist er gleichzeitig der Meinung, dass deren praktische Anwendung nicht so einfach ist. Dieser umfangreiche Beitrag soll das Bewusstsein der Fachleute zu diesem Thema sch\u00e4rfen und ihnen helfen, die erforderlichen Konfigurationen zu erstellen.<\/i><\/a><\/noindex><\/p>\n

Heute entscheiden sich immer mehr Unternehmen daf\u00fcr, Kubernetes zur Ausf\u00fchrung ihrer Anwendungen zu nutzen. Das Interesse an dieser Software ist so gro\u00df, dass manche Kubernetes als \"das neue Betriebssystem f\u00fcr Rechenzentren\" bezeichnen. Allm\u00e4hlich wird Kubernetes (oder k8s) als eine kritische Komponente f\u00fcr Unternehmen wahrgenommen, die eine reife Organisation der Gesch\u00e4ftsprozesse erfordert, einschlie\u00dflich der Gew\u00e4hrleistung der Netzwerksicherheit.<\/p>\n

F\u00fcr Sicherheitsexperten, die sich mit Kubernetes auseinandersetzen, kann die Standardpolitik dieser Plattform eine echte Offenbarung sein: alles zuzulassen.<\/p>\n

Dieses Handbuch hilft, die inneren Abl\u00e4ufe der Netzwerkpolitiken zu verstehen und die Unterschiede zu den Regeln herk\u00f6mmlicher Firewalls zu erkennen. Au\u00dferdem werden einige Fallstricke beleuchtet und Empfehlungen gegeben, die helfen, Anwendungen in Kubernetes zu sch\u00fctzen.<\/p>\n

Netzwerkpolitiken von Kubernetes<\/h2>\n

\nDer Mechanismus der Netzwerkpolitiken von Kubernetes erm\u00f6glicht die Steuerung der Interaktion von in der Plattform bereitgestellten Anwendungen auf Netzwerkschicht (der dritten Schicht im OSI-Modell). Netzwerkpolitiken bieten nicht die erweiterten Funktionen moderner Firewalls, wie etwa die Kontrolle auf Schicht 7 des OSI-Modells und Bedrohungserkennung, gew\u00e4hrleisten jedoch ein grundlegendes Ma\u00df an Netzwerksicherheit, das einen guten Ausgangspunkt darstellt.<\/p>\n

Netzwerkrichtlinien steuern die Kommunikation zwischen Pods.<\/h2>\n

\nArbeitslasten in Kubernetes werden auf Pods verteilt, die aus einem oder mehreren zusammen bereitgestellten Containern bestehen. Kubernetes weist jedem Pod eine IP-Adresse zu, die von anderen Pods aus erreichbar ist. Die Netzwerkrichtlinien von Kubernetes legen Zugriffsrechte f\u00fcr Gruppen von Pods fest, \u00e4hnlich wie Sicherheitsgruppen in der Cloud verwendet werden, um den Zugriff auf virtuelle Maschinen zu steuern.<\/p>\n

Definition von Netzwerkrichtlinien<\/h2>\n

\nWie andere Ressourcen in Kubernetes werden Netzwerkrichtlinien im YAML-Format definiert. Im folgenden Beispiel wird der Anwendung balance<\/code> Zugriff gew\u00e4hrt auf postgres<\/code>:<\/p>\n

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
\n\"Einf\u00fchrung
\n
\n(Hinweis.<\/b>: Dieser Screenshot, wie alle folgenden \u00e4hnlichen, wurde nicht mit nativen Mitteln von Kubernetes erstellt, sondern mit dem Tool Tufin Orca, das von der Firma des Autors des Originalartikels entwickelt wurde und am Ende des Materials erw\u00e4hnt wird.<\/i><\/p>\n
F\u00fcr die Festlegung der eigenen Netzwerkrichtlinien sind grundlegende Kenntnisse in YAML erforderlich. Diese Sprache basiert auf Einr\u00fcckungen (die durch Leerzeichen und nicht durch Tabulatoren erstellt werden). Ein einger\u00fccktes Element geh\u00f6rt zum n\u00e4chstgelegenen \u00fcbergeordneten Element mit einer Einr\u00fcckung. Ein neues Listenelement beginnt mit einem Bindestrich, alle anderen Elemente erscheinen als Schl\u00fcssel-Wert-Paar<\/i>.<\/p>\n
Nachdem Sie die Richtlinie in YAML beschrieben haben, verwenden Sie kubectl<\/a><\/noindex>, um sie im Cluster zu erstellen:<\/p>\n
kubectl create -f policy.yaml<\/code><\/pre>\n
<\/p>\n
Spezifikation der Netzwerkrichtlinie<\/h2>\n
\nDie Spezifikation der Kubernetes-Netzwerkrichtlinie umfasst vier Elemente:<\/p>\n
    \n
  1.  podSelector<\/code>: definiert die von dieser Richtlinie betroffenen Pods (Ziele) \u2013 obligatorisch;<\/li>\n
  2.  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
  3.  ingress<\/code>: definiert den erlaubten eingehenden<\/b> der Datenverkehr zu den Ziel-Pods \u2013 optional;<\/li>\n
  4.  egress<\/code>: definiert den erlaubten ausgehenden<\/b> der Datenverkehr aus den Ziel-Pods \u2013 optional.<\/li>\n<\/ol>\n
    \nEin Beispiel, das von der Kubernetes-Website entnommen wurde (ich habe role<\/code> findet man app<\/code>), zeigt, wie alle vier Elemente verwendet werden:<\/p>\n
    apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:    # <<<\n    matchLabels:\n      app: db\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
    \n\"Einf\u00fchrung
    \n\"Einf\u00fchrung
    \n
    \nBitte beachten Sie, dass das Einf\u00fcgen aller vier Elemente nicht zwingend erforderlich ist. Nur podSelector<\/code>ist Pflicht; die \u00fcbrigen Parameter k\u00f6nnen nach Bedarf verwendet werden.<\/p>\n
    Wenn Sie weglassen policyTypes<\/code>, wird die Richtlinie folgenderma\u00dfen interpretiert:<\/p>\n