{"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\/nl\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Opmerking vertaler.<\/b>: De auteur van het artikel - Reuven Harrison - heeft meer dan 20 jaar ervaring in softwareontwikkeling en is momenteel technisch directeur en medeoprichter van Tufin, een bedrijf dat oplossingen voor het beheer van beveiligingsbeleid ontwikkelt. Hij beschouwt netwerkgroepen in Kubernetes als een krachtig middel voor netwerksegmentatie in clusters, maar gelooft tegelijkertijd dat ze in de praktijk niet zo eenvoudig toe te passen zijn. Dit vrij omvangrijke materiaal is bedoeld om de kennis van specialisten op dit gebied te verbeteren en hen te helpen bij het cre\u00ebren van de noodzakelijke configuraties.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Vandaag de dag kiezen steeds meer bedrijven voor Kubernetes om hun applicaties te draaien. De belangstelling voor deze software is zo groot dat sommigen Kubernetes de 'nieuwe besturingssysteem voor datacenters' noemen. Geleidelijk begint Kubernetes (of k8s) te worden gezien als een cruciaal onderdeel van de business dat volwassen bedrijfsprocessen vereist, inclusief netwerkbeveiliging.<\/p>\n<p>Voor beveiligingsspecialisten die worstelen met Kubernetes kan het standaardbeleid van dit platform een openbaring zijn: alles toestaan.<\/p>\n<p>Deze gids helpt om inzicht te krijgen in de interne werking van netwerkbeleid; het zal duidelijk maken hoe ze verschillen van regels voor traditionele firewalls. Er zullen ook enkele valkuilen worden besproken en aanbevelingen worden gegeven die kunnen helpen bij het beveiligen van applicaties in Kubernetes.<\/p>\n<h2>Kubernetes netwerkbeleid<\/h2>\n<p>\nHet mechanisme van Kubernetes netwerkbeleid maakt het mogelijk om de interactie tussen applicaties die op het platform zijn uitgerold op netwerkniveau (laag drie in het OSI-model) te beheren. Netwerkbeleid mist bepaalde geavanceerde functies van moderne firewalls, zoals controle op laag 7 van het OSI-model en dreigingsdetectie, maar biedt een basisniveau van netwerkbeveiliging dat een goede startpunt vormt.<\/p>\n<h2>Netwerkbeleid controleert de communicatie tussen pods<\/h2>\n<p>\nLaden in Kubernetes worden verdeeld over pods, die uit \u00e9\u00e9n of meer gezamenlijk uitgerolde containers bestaan. Kubernetes kent aan elke pod een IP-adres toe dat toegankelijk is vanuit andere pods. Kubernetes netwerkbeleid stelt toegangsrechten in voor groepen pods op dezelfde manier als beveiligingsgroepen in de cloud worden gebruikt om toegang tot virtuele machine-instanties te beheren.<\/p>\n<h2>Definitie van netwerkbeleid<\/h2>\n<p>\nNet als andere Kubernetes-resources worden netwerkbeleidsregels gedefinieerd in YAML. In het onderstaande voorbeeld krijgt de applicatie <code>balance<\/code> toegang tot <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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Opmerking vertaler.<\/b>: deze screenshot, evenals alle volgende soortgelijke, is gemaakt met behulp van een hulpmiddel van Tufin Orca, dat door het bedrijf van de auteur van het originele artikel is ontwikkeld en aan het einde van het materiaal wordt genoemd.<\/i><\/p>\n<p>Voor het defini\u00ebren van uw eigen netwerkbeleid zijn basiskennis van YAML vereist. Deze taal is gebaseerd op inspringingen (gegeven door spaties en niet door tabs). Een element met inspringing behoort tot het dichtstbijzijnde element met inspringing boven hem. Een nieuw listelement begint met een koppelteken; alle andere elementen hebben de vorm <i>van sleutel-waarde<\/i>.<\/p>\n<p>Nadat u het beleid in YAML heeft beschreven, gebruikt u <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, om het in het cluster aan te maken:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Specificatie van netwerkbeleid<\/h2>\n<p>\nDe specificatie van netwerkbeleid in Kubernetes omvat vier elementen:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: definieert de pods die door dit beleid worden getroffen (doelen) \u2014 verplicht;<\/li>\n<li> <code>policyTypes<\/code>: geeft aan welke soorten beleid in dit zijn opgenomen: ingress en\/of egress - optioneel, maar ik raad aan het in alle gevallen expliciet op te nemen;<\/li>\n<li> <code>ingress<\/code>: definieert het toegestaan <b>inkomend<\/b> verkeer naar de doel-pods \u2014 optioneel;<\/li>\n<li> <code>egress<\/code>: definieert het toegestaan <b>uitgaand<\/b> verkeer uit de doel-pods \u2014 optioneel.<\/li>\n<\/ol>\n<p>\nEen voorbeeld, ontleend aan de Kubernetes-website (ik heb <code>role<\/code> en een werkende opdracht krijgen. <code>app<\/code>), toont aan hoe alle vier elementen worden gebruikt:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLet op dat het niet noodzakelijk is om alle vier de elementen op te nemen. Alleen <code>podSelector<\/code>, de andere parameters kunnen optioneel worden gebruikt.<\/p>\n<p>Als je <code>policyTypes<\/code>weglaten, zal het beleid als volgt worden ge\u00efnterpreteerd:<\/p>\n<ul>\n<li> Standaard gaat men ervan uit dat het de ingress-zijde definieert. Als er geen expliciete aanwijzingen in het beleid zijn, beschouwt het systeem al het verkeer als verboden.<\/li>\n<li> Het gedrag aan de egress-zijde zal worden bepaald door de aanwezigheid of afwezigheid van de bijbehorende egress-parameter.<\/li>\n<\/ul>\n<p>\nOm fouten te voorkomen, raad ik aan <b>altijd expliciet aan te geven <code>policyTypes<\/code><\/b>.<\/p>\n<p>Volgens de bovenstaande logica, als de parameters <code>ingress<\/code> and\/or <code>egress<\/code> worden weggelaten, zal het beleid al het verkeer verbieden (zie de \"Cleanup-regel\" hieronder).<\/p>\n<h2>Het standaardbeleid is toestaan<\/h2>\n<p>\nAls er geen beleid gedefinieerd is, staat Kubernetes standaard al het verkeer toe. Alle pods kunnen vrij informatie met elkaar uitwisselen. Vanuit beveiligingsperspectief lijkt dit misschien onlogisch, maar onthoud dat Kubernetes oorspronkelijk is ontworpen door ontwikkelaars om de interactie tussen toepassingen te waarborgen. Netwerkbeleid is later toegevoegd.<\/p>\n<h2>Namespaces<\/h2>\n<p>\nNamespaces zijn een mechanisme voor samenwerking binnen Kubernetes. Ze zijn bedoeld om logische omgevingen van elkaar te isoleren, terwijl gegevensuitwisseling tussen namespaces standaard is toegestaan.<\/p>\n<p>Net als de meeste componenten van Kubernetes leven netwerkbeleid in een specifieke namespace. In het blok <code>metadata<\/code> kan worden vastgelegd aan welke namespace het beleid toebehoort:<\/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>\nAls de namespace in de metadata niet expliciet is opgegeven, zal het systeem de namespace gebruiken die is opgegeven in kubectl (standaard <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nIk raad aan <b>de namespace expliciet aan te geven<\/b>, tenzij u een beleid schrijft dat bedoeld is voor meerdere namespaces.<\/p>\n<p><b>Hoofd<\/b> element <code>podSelector<\/code> het beleid zal pods selecteren uit de namespace waartoe het beleid behoort (het heeft geen toegang tot pods in een andere namespace).<\/p>\n<p>Op dezelfde manier podSelectors <b>in de ingress- en egress-blokken<\/b> alleen pods selecteren uit hun eigen namespace, tenzij u ze combineert met <code>namespaceSelector<\/code> (hierover wordt gesproken in het gedeelte 'Filteren op namespaces en pods').<\/p>\n<h2>Naamgevingsregels voor beleid<\/h2>\n<p>\nBeleidsnamen zijn uniek binnen \u00e9\u00e9n namespace. Er kunnen geen twee beleidsdocumenten met dezelfde naam in \u00e9\u00e9n namespace zijn, maar het is mogelijk om beleidsdocumenten met dezelfde namen in verschillende namespaces te hebben. Dit is handig wanneer u hetzelfde beleid wilt hergebruiken in meerdere namespaces.<\/p>\n<p>Een van de naamgevingswijzen die ik bijzonder leuk vind, bestaat uit het combineren van de naam van de namespace met de doel-pods. Bijvoorbeeld:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Labels<\/h2>\n<p>\nAan Kubernetes-objecten, zoals pods en namespaces, kunnen aangepaste labels worden gehecht. Labels (<i>labels<\/i> \u2014 tags) zijn het equivalent van tags in de cloud. Netwerkbeleidsdocumenten van Kubernetes gebruiken labels om te selecteren <b>pods<\/b>, waaraan zij worden toegepast:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 of <b>namespaces<\/b>, waarop ze van toepassing zijn. In dit voorbeeld worden alle pods in namespaces met overeenkomende labels geselecteerd:<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\nEen waarschuwing: wanneer u <code>namespaceSelector<\/code> <b>zorg ervoor dat de geselecteerde namespaces de juiste label bevatten.<\/b>Houd er rekening mee dat ingebouwde namespaces, zoals <code>default<\/code> en <code>kube-system<\/code>, standaard geen labels bevatten.<\/p>\n<p>U kunt een label aan een namespace toevoegen op de volgende manier:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nHierbij moet de namespace in het gedeelte <code>metadata<\/code> verwijzen naar de feitelijke naam van de namespace en niet naar het label:<\/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>Bron en ontvanger<\/h2>\n<p>\nBeleid voor firewalls bestaat uit regels met bronnen en bestemmingen. Kubernetes netwerkbeleid wordt gedefinieerd voor een doel \u2013 een set van pods waar het op van toepassing is, en stelt vervolgens regels in voor inkomend (ingress) en\/of uitgaand (egress) verkeer. In ons voorbeeld is het doel van het beleid alle pods in de namespace <code>default<\/code> 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>app<\/code> en waarde. <code>. Service-meshen lossen dergelijke problemen meestal op met behulp van mTLS: certificaten fungeren in dit geval als de noodzakelijke identificatie.<\/code>:<\/p>\n<pre><code class=\"plaintext\">Sectie<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nin dit beleid opent het inkomende verkeer naar de doelpods. Met andere woorden, ingress is de bron, en het doel is de overeenkomstige bestemming. Evenzo is egress de bestemming, en het doel is de bron. <code>ingress<\/code> Dit komt overeen met twee regels voor de firewall: Ingress \u2192 Doel; Doel \u2192 Egress.<\/p>\n<p><img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Egress en DNS (belangrijk!)<\/i><\/p>\n<h2>Bij het beperken van uitgaand verkeer,<\/h2>\n<p>\nlet vooral op DNS <b>\u2014 Kubernetes gebruikt deze service om services met IP-adressen te koppelen. Bijvoorbeeld, het volgende beleid zal niet werken omdat je de applicatie niet hebt toegestaan<\/b> om verbinding te maken met DNS: <code>balance<\/code> 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<\/p>\n<pre><code class=\"plaintext\">Dit kan worden opgelost door toegang tot de DNS-service te verlenen:<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\napiVersion: 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<\/p>\n<pre><code class=\"plaintext\">Het laatste element<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nto <code>\u2014 is leeg, en kiest daardoor indirect<\/code> alle pods in alle namespaces <b>alle pods in alle namespaces<\/b>om DNS-verzoeken naar de overeenkomstige Kubernetes-service te sturen (die meestal draait in de namespace <code>balance<\/code> Deze aanpak werkt, maar is <code>kube-system<\/code>).<\/p>\n<p>overmatig permissief en onveilig <b>, omdat het DNS-verzoeken buiten de cluster mogelijk maakt.<\/b>Het kan worden verbeterd in drie opeenvolgende stappen.<\/p>\n<p>1. Sta DNS-verzoeken alleen toe<\/p>\n<p>voor de cluster door toe te voegen <b>binnenin<\/b> clusters, toegevoegen <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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Sta DNS-verzoeken alleen toe in de namespace <code>kube-system<\/code>.<\/p>\n<p>Hiervoor moet je een label aan de namespace toevoegen <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 en dit opnemen in het beleid met behulp van <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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Parano\u00efden kunnen nog verder gaan en DNS-verzoeken beperken tot een specifieke DNS-service in <code>kube-system<\/code>. In het onderdeel 'Filteren op namespaces en pods' wordt uitgelegd hoe dit te bereiken.<\/p>\n<p>Een andere optie is om DNS op namespace-niveau toe te staan. In dit geval hoeft het niet voor elke service te worden geopend:<\/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>\nLeeg <code>podSelector<\/code> selecteert alle pods in de namespace.<\/p>\n<p><img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Eerste overeenkomst en volgorde van regels<\/h2>\n<p>\nIn reguliere firewalls wordt de actie ('Toestaan' of 'Blokkeren') met betrekking tot een pakket bepaald door de eerste regel die van toepassing is. <b>In Kubernetes is de volgorde van beleidsregels niet van belang.<\/b><\/p>\n<p>Standaard is, wanneer er geen beleid is ingesteld, de communicatie tussen pods toegestaan en kunnen ze vrij informatie uitwisselen. Zodra je begint met het formuleren van beleid, wordt elke pod die door een van hen wordt be\u00efnvloed, ge\u00efsoleerd op basis van de disjunctie (logisch OF) van alle beleidsregels die op hen van toepassing zijn. Pods die door geen enkel beleid zijn be\u00efnvloed, blijven open.<\/p>\n<p>Dit gedrag kan worden gewijzigd met behulp van een opruimregel.<\/p>\n<h2>Opruimregel ('Blokkeren')<\/h2>\n<p>\nBeleidsregels van firewalls blokkeren doorgaans al het verkeer dat niet expliciet is toegestaan.<\/p>\n<p><b>In Kubernetes is er geen actie 'blokkeren' (deny)<\/b>, maar een vergelijkbaar effect kan worden bereikt met een gewone (toelatende) policy, door een lege groep pod&#8217;en-bronnen (ingress) te kiezen:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDeze policy kiest alle pod&#8217;en in de naamruimte en laat ingress onbepaald, waardoor al het inkomende verkeer wordt verboden.<\/p>\n<p>Op dezelfde manier kan al het uitgaande verkeer uit de naamruimte worden beperkt:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHoud er rekening mee dat <b>elke extra policy die verkeer naar pod&#8217;en in de naamruimte toestaat, heeft prioriteit boven deze regel<\/b> (vergelijkbaar met het toevoegen van een toestemmingsregel v\u00f3\u00f3r een verbod in de firewallconfiguratie).<\/p>\n<h2>Sta alles toe (Any-Any-Any-Allow)<\/h2>\n<p>\nOm een \"Sta alles toe\" beleid te maken, moet de bovenstaande verbodspolitiek worden aangevuld met een leeg element <code>ingress<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\n  namespace: default\nspec:\n  podSelector: {}\n  ingress: # &lt;&lt;&lt;\n  - {}     # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet opent toegang van <b>alle pod&#8217;en in alle naamruimten (en alle IP-adressen) naar elke pod in de naamruimte <code>default<\/code><\/b>. Dit gedrag is standaard ingeschakeld, dus meestal hoeft dit niet verder gedefinieerd te worden. Soms kan het echter nodig zijn om specifieke toegangen tijdelijk uit te schakelen om een probleem te diagnosticeren.<\/p>\n<p>De regel kan worden ingeperkt en toegang alleen toestaan tot <b>een specifieke set pod&#8217;en<\/b> (<code>app:balance<\/code>) in de naamruimte <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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet volgende beleid staat al het binnenkomende (ingress) en uitgaande (egress) verkeer toe, inclusief toegang tot elk IP buiten de cluster:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\nspec:\n  podSelector: {}\n  ingress:\n  - {}\n  egress:\n  - {}\n  policyTypes:\n  - Ingress\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Combineren van meerdere beleidsregels<\/h2>\n<p>\nPolicies worden samengevoegd met een logische OF op drie niveaus; de toegangen van elke pod worden vastgesteld op basis van de disjunctie van alle policies die erop van toepassing zijn:<\/p>\n<p>1. In de velden <code>van<\/code> en <code>\u2014 is leeg, en kiest daardoor indirect<\/code> kunnen drie soorten elementen worden gedefinieerd (allemaal worden ze gecombineerd met behulp van OF):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 selecteert de hele naamruimte;<\/li>\n<li> <code>podSelector<\/code> \u2014 selecteert pods;<\/li>\n<li> <code>ipBlock<\/code> \u2014 selecteert een subnet.<\/li>\n<\/ul>\n<p>\nIn dit geval is het aantal elementen (zelfs dezelfde) in subsecties <code>van<\/code>\/<code>\u2014 is leeg, en kiest daardoor indirect<\/code> niet beperkt. Ze worden allemaal samengevoegd met een logische OF.<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Binnen een beleidsectie <code>ingress<\/code> kan het meerdere elementen bevatten <code>van<\/code> (samengevoegd met een logische OF). Op soortgelijke wijze kan een sectie <code>egress<\/code> meerdere elementen bevatten <code>\u2014 is leeg, en kiest daardoor indirect<\/code> (ook samengevoegd met een disjunctie):<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Verschillende beleidsregels worden ook samengevoegd met een logische OF<\/p>\n<p>Maar bij het combineren zijn er beperkingen waaraan <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">vermeldde<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes kan alleen beleidsregels combineren die verschillend zijn <code>policyTypes<\/code> (<code>Ingress<\/code> of <code>Egress<\/code>). Beleidsregels die ingress (of egress) defini\u00ebren, zullen elkaar overschrijven.<\/p>\n<h2>De relatie tussen namespaces<\/h2>\n<p>\nStandaard is informatie-uitwisseling tussen namespaces toegestaan. Dit kan worden gewijzigd met een beperkend beleid dat de uitgaande en\/of inkomende verkeer naar een namespace beperkt (zie 'Clearance regel' hierboven).<\/p>\n<p>Door de toegang tot een namespace te blokkeren (zie 'Clearance regel' hierboven), kunt u uitzonderingen maken in het beperkende beleid door verbindingen vanuit een bepaalde namespace toe te staan met <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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAls gevolg hiervan krijgen alle pods in de namespace <code>default<\/code> toegang krijgen tot pod&#8217;en <code>postgres<\/code> in de namespace <code>database<\/code>. Maar wat als u toegang wilt geven aan <code>postgres<\/code> alleen specifieke pod&#8217;en in de naamruimte <code>default<\/code>?<\/p>\n<h2>Filteren op naamruimten EN pod&#8217;en<\/h2>\n<p>\nKubernetes versie 1.11 en hoger staat toe dat operatoren worden gecombineerd <code>namespaceSelector<\/code> en <code>podSelector<\/code> met een logische EN. Dit ziet er als volgt uit:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWaarom wordt dit ge\u00efnterpreteerd als EN in plaats van de gebruikelijke OF?<\/p>\n<p>Let op dat <code>podSelector<\/code> begint niet met een streepje. In YAML betekent dit dat <code>podSelector<\/code> en het voorafgaande element <code>namespaceSelector<\/code> tot hetzelfde lijstitem behoren. Daarom worden ze samengevoegd met een logische EN.<\/p>\n<p>Een dash toevoegen voor <code>podSelector<\/code> leidt tot het ontstaan van een nieuw lijstitem, dat zal worden gecombineerd met het voorgaande <code>namespaceSelector<\/code> met behulp van logische OF.<\/p>\n<p>Om pod&#8217;en met een specifieke label te selecteren <b>in alle namespaces<\/b>, typ leeg <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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Meerdere labels worden gecombineerd met EN<\/h2>\n<p>\nRegels voor de firewall met meerdere objecten (hosts, netwerken, groepen) worden gecombineerd met logische OF. De volgende regel wordt geactiveerd als de pakketbron overeenkomt met <code>Host_1<\/code> OF <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Bron | Bestemming | Dienst | Actie |\n| ----------------------------------------|\n| Host_1 | Subnet_A    | HTTPS   | Toestaan  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nDaarentegen worden in Kubernetes verschillende labels <code>podSelector<\/code> of <code>namespaceSelector<\/code> samengevoegd met logische EN. Bijvoorbeeld, de volgende regel zal pods selecteren die beide labels hebben, <code>role=db<\/code> En <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nDezelfde logica is van toepassing op alle soorten operatoren: doelpolicy-selectors, pod-selectors en naamruimte-selectors.<\/p>\n<h2>Subnetten en IP-adressen (IPBlocks)<\/h2>\n<p>\nVoor netwerksegmentatie gebruiken firewalls VLAN's, IP-adressen en subnetten.<\/p>\n<p>In Kubernetes worden IP-adressen automatisch aan pod&#8217;en toegewezen en kunnen ze vaak veranderen, daarom worden labels gebruikt om pod&#8217;en en naamruimten in netwerkinstellingen te selecteren.<\/p>\n<p>Subnetten (<code>ipBlocks<\/code>) worden gebruikt voor het beheren van inkomende (ingress) of uitgaande (egress) externe (North-South) verbindingen. Bijvoorbeeld, deze policy staat alle pod&#8217;en uit de naamruimte toe <code>default<\/code> toegang tot de DNS-service van 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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEen lege pod-selector in dit voorbeeld betekent 'selecteer alle pod&#8217;en in de naamruimte'.<\/p>\n<p>Dit beleid staat alleen toegang toe tot 8.8.8.8; toegang tot elk ander IP is verboden. Hierdoor heeft u in wezen de toegang tot de interne DNS-service van Kubernetes geblokkeerd. Als u deze toch wilt toestaan, geef dat dan expliciet aan.<\/p>\n<p>Normaal <code>ipBlocks<\/code> en <code>podSelectors<\/code> zijn wederzijds exclusief, aangezien interne IP-adressen van pod&#8217;en niet gebruikt worden in <code>ipBlocks<\/code>. Door <b>interne IP van pod&#8217;en<\/b>, verleen je feitelijk toegang tot\/van pod&#8217;en met deze adressen. In de praktijk weet je niet welk IP-adres je moet gebruiken, daarom moet je ze vermijden bij het selecteren van pod&#8217;en.<\/p>\n<p>Als tegenvoorbeeld, de volgende policy omvat alle IP en staat daardoor toegang toe tot alle andere pod&#8217;en:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJe kunt alleen toegang verlenen tot externe IP's, terwijl interne IP-adressen van pod&#8217;en worden uitgesloten. Bijvoorbeeld, als het subnet van je pod 10.16.0.0\/14 is:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Poorten en protocollen<\/h2>\n<p>\nGewoonlijk luistert een pod naar \u00e9\u00e9n poort. Dit betekent dat je eenvoudigweg de poortnummers in de policies kunt weglaten en alles op standaard kunt laten. Toch is het aan te raden om policies zo restrictief mogelijk te maken, daarom kan het in sommige gevallen nuttig zijn om toch poorten op te geven:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLet op dat de selector <code>poorten<\/code> toegepast wordt op alle elementen in het blok <code>\u2014 is leeg, en kiest daardoor indirect<\/code> of <code>van<\/code>, waarin het zich bevindt. Om verschillende poorten voor verschillende sets elementen op te geven, splitst u <code>ingress<\/code> of <code>egress<\/code> in verschillende subsecties met <code>\u2014 is leeg, en kiest daardoor indirect<\/code> of <code>van<\/code> en schrijft u in elke sectie uw eigen poorten op:<\/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=\"Inleiding tot netwerkkaders van Kubernetes voor beveiligingsspecialisten.\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nStandaardpoortwerking:<\/p>\n<ul>\n<li> Als u de poortdefinities volledig weglaat (<code>poorten<\/code>), betekent dit alle protocollen en alle poorten;<\/li>\n<li> Als u de protocoldefinitie weglaat (<code>protocol<\/code>), betekent dit TCP;<\/li>\n<li> Als u de poortdefinitie weglaat (<code>port<\/code>), betekent dit alle poorten.<\/li>\n<\/ul>\n<p>\nBest practice: vertrouw niet op standaardwaarden, geef expliciet de waarden op die u nodig heeft.<\/p>\n<p>Houd er rekening mee dat je de poorten van pods moet gebruiken en niet die van services (meer hierover in de volgende paragraaf).<\/p>\n<h2>Zijn de beleidsregels gedefinieerd voor pods of voor services?<\/h2>\n<p>\nGewoonlijk communiceren pods in Kubernetes met elkaar via een service - een virtuele load balancer die verkeer naar de pods leidt die de service uitvoeren. Je zou kunnen denken dat netwerkbeleid de toegang tot services beheert, maar dat is niet het geval. <b>Netwerkbeleid in Kubernetes werkt met de poorten van pods, niet die van services.<\/b><\/p>\n<p>Bijvoorbeeld, als een service luistert op poort 80 maar het verkeer doorstuurt naar poort 8080 van zijn pods, dan moet in het netwerkbeleid specifiek poort 8080 worden vermeld.<\/p>\n<p>Dit mechanisme moet als suboptimaal worden beschouwd: bij het wijzigen van de interne structuur van de service (wiens poorten door pods worden beluisterd), moeten de netwerkbeleid worden bijgewerkt.<\/p>\n<p>Een nieuwe architecturale aanpak met behulp van Service Mesh <i>(bijvoorbeeld, zie Istio hieronder \u2014 opmerking van de vertaler)<\/i> maakt het mogelijk om met dit probleem om te gaan.<\/p>\n<h2>Moet zowel Ingress als Egress worden gespecificeerd?<\/h2>\n<p>\nHet korte antwoord is ja, zodat pod A verbinding kan maken met pod B, moet het toestemming krijgen om een uitgaande verbinding te maken (hiervoor moet een egress-beleid worden ingesteld), en pod B moet in staat zijn om een inkomende verbinding te accepteren (hiervoor is een ingress-beleid nodig).<\/p>\n<p>Echter, in de praktijk kan men vertrouwen op het standaardbeleid dat verbindingen in een of beide richtingen toestaat.<\/p>\n<p>Als een bepaalde pod<b>bron<\/b> wordt geselecteerd door een of meerdere <b>egress<\/b>-beleidsregels, worden de aan hem opgelegde beperkingen bepaald door hun disjunctie. In dit geval moet expliciet toestemming worden gegeven voor verbinding met pod-<b>de ontvanger.<\/b>. Als de pod niet door een beleid is geselecteerd, is zijn uitgaande (egress) verkeer standaard toegestaan.<\/p>\n<p>Evenzo zal het lot van de pod-<b>de ontvanger, geselecteerd door een of meerdere<\/b>-beleidsregels, worden bepaald door hun disjunctie. In dit geval moet expliciet worden toegestaan dat hij verkeer ontvangt van de pod-bron. Als de pod niet door een beleid is geselecteerd, is al het inkomende (ingress) verkeer voor hem standaard toegestaan. <b>ingress<\/b>-beleid worden bepaald door hun disjunctie. In dat geval moet expliciet worden toegestaan dat het verkeer ontvangt van de bronpod. Als geen enkel beleid de pod selecteert, is al het binnenkomende (ingress) verkeer voor hem standaard toegestaan.<\/p>\n<p>Netwerkbeleidsregels in Kubernetes kunnen het verkeer niet loggen. Dit bemoeilijkt het vaststellen of het beleid correct functioneert en bemoeilijkt de veiligheidsanalyse aanzienlijk.<\/p>\n<h2>Logs<\/h2>\n<p>\nControle over verkeer naar externe services.<\/p>\n<h2>Monitoring van verkeer naar externe diensten<\/h2>\n<p>\nKubernetes-netwerkbeleid staat niet toe om een volledig domeinnaam (DNS) op te geven in egress-secties. Dit resulteert in aanzienlijke ongemakken bij het proberen te beperken van het verkeer naar externe bestemmingen zonder vast IP-adres (zoals aws.com).<\/p>\n<h2>Beleid controle<\/h2>\n<p>\nFirewalls zullen je waarschuwen of zelfs een fout beleid weigeren. Kubernetes voert ook enige validatie uit. Wanneer je een netwerkbeleid via kubectl instelt, kan Kubernetes aangeven dat het onjuist is en het weigeren te accepteren. In andere gevallen accepteert Kubernetes het beleid en vult het ontbrekende details aan. Deze zijn te zien met het commando:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nHoud er rekening mee dat de verificatiesysteem van Kubernetes niet onfeilbaar is en sommige soorten fouten kan missen.<\/p>\n<h2>Uitvoering<\/h2>\n<p>\nKubernetes implementeert het netwerkbeleid niet zelf, maar fungeert alleen als een API-gateway die de lastige taak van controle overlaat aan een onderliggend systeem dat de Container Networking Interface (CNI) wordt genoemd. Het instellen van beleid in een Kubernetes-cluster zonder de juiste CNI is vergelijkbaar met het maken van beleid op een firewall-beheerder zonder deze vervolgens in de firewalls te installeren. Je moet zelf zorgen voor een geschikte CNI of, in het geval van Kubernetes-platforms in de cloud, <i>(met een lijst van providers beschikbaar <noindex>hier<\/noindex> \u2014 vert. opm.)<\/i>, activeer netwerkbeleid dat CNI voor je instelt.<\/p>\n<p>Let op, Kubernetes waarschuwt je niet als je een netwerkbeleid instelt zonder de juiste ondersteunende CNI.<\/p>\n<h3>Stateful of Stateless?<\/h3>\n<p>\nAlle Kubernetes CNI's waarmee ik te maken heb gehad, zijn stateful (bijvoorbeeld Calico gebruikt Linux conntrack). Dit stelt een pod in staat om antwoorden te ontvangen op de door hem ge\u00efnitieerde TCP-verbinding zonder deze opnieuw te hoeven opzetten. Voor zover ik weet, is er geen Kubernetes-standaard die de opslag van staat (statefulness) garandeert.<\/p>\n<h2>Geavanceerd beheer van beveiligingsbeleid<\/h2>\n<p>\nHier zijn enkele manieren om de effectiviteit van het beveiligingsbeleid in Kubernetes te verbeteren:<\/p>\n<ol>\n<li> Het architecturale patroon Service Mesh maakt gebruik van sidecar-containers voor gedetailleerde telemetrie en verkeerscontrole op serviceniveau. Als voorbeeld kan worden genomen <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Sommige CNI-leveranciers hebben hun tools uitgebreid om verder te gaan dan de netwerkbeleidsregels van Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> biedt transparantie en automatisering van de netwerkbeleidsregels van Kubernetes.<\/li>\n<\/ol>\n<p>\nHet Tufin Orca-pakket beheert de netwerkbeleidsregels van Kubernetes (en dient als bron voor de hierboven weergegeven screenshots).<\/p>\n<h2>Aanvullende informatie<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Voorbeelden van netwerkbeleid, voorbereid door Ahmet Alp Balkan uit GKE<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Documentatie van de offici\u00eble Kubernetes-website<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Handleiding voor het netwerkmodel van Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Script voor het controleren van netwerkbeleidsregels<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclusie<\/h2>\n<p>\nNetwerkbeleidsregels van Kubernetes bieden een behoorlijke set tools voor het segmenteren van clusters, maar zijn intu\u00eftief moeilijk te begrijpen en hebben veel nuances. Ik denk dat door deze complexiteit veel bestaande clusters fouten bevatten. Mogelijke oplossingen voor dit probleem zijn het automatiseren van beleidsdefinities of het toepassen van andere segmentatietools.<\/p>\n<p>Ik hoop dat deze handleiding helpt om enkele vragen te verhelderen en problemen op te lossen waarmee je kunt worden geconfronteerd.<\/p>\n<h2>P.S. van de vertaler<\/h2>\n<p>\nLees ook op onze blog:<\/p>\n<ul>\n<li> \u00abTerug naar microservices met Istio\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">deel 1 (kennis maken met de belangrijkste mogelijkheden)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">deel 2 (routering, verkeersbeheer)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">deel 3 (beveiliging)<\/a><\/noindex>;<\/li>\n<li> \u00abGe\u00efllustreerde handleiding voor netwerkconfiguratie in Kubernetes\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">delen 1 en 2 (netwerkmodel, overlay-netwerken)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">deel 3 (diensten en verkeersverwerking)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">9 beste praktijken voor het beveiligen van Kubernetes.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">OPA en SPIFFE \u2014 twee nieuwe projecten in CNCF voor de beveiliging van cloudapplicaties.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 manieren om (niet) het slachtoffer te worden van een hack in Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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\udd47Introductie tot netwerkbeleidsregels van Kubernetes voor beveiligingsprofessionals | ProHoster","description":"Opmerking.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}