{"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\/da\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Bem. overs.<\/b>: Artiklen er skrevet af Reuven Harrison, som har over 20 \u00e5rs erfaring med softwareudvikling og i dag er teknisk direkt\u00f8r og medstifter af Tufin, der udvikler l\u00f8sninger til h\u00e5ndtering af sikkerhedspolitikker. Selvom han betragter netv\u00e6rkspolitikker i Kubernetes som et kraftfuldt redskab til netv\u00e6rkssegmentering i klynger, mener han samtidig, at de ikke er s\u00e5 nemme at anvende i praksis. Dette materiale (som er ret omfattende) har til form\u00e5l at \u00f8ge bevidstheden hos fagfolk om emnet og hj\u00e6lpe dem med at skabe de n\u00f8dvendige konfigurationer.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>I dag v\u00e6lger mange virksomheder i stigende grad Kubernetes til at k\u00f8re deres applikationer. Interessen for denne software er s\u00e5 stor, at nogle kalder Kubernetes \"det nye operativsystem for datacentre\". Langsomt men sikkert begynder Kubernetes (eller k8s) at blive opfattet som en kritisk vigtig del af forretningen, der kr\u00e6ver etablering af modne forretningsprocesser, herunder sikring af netv\u00e6rkssikkerhed.<\/p>\n<p>For sikkerhedsspecialister, der er foruroliget over arbejdet med Kubernetes, kan standardpolitikken for denne platform v\u00e6re en \u00f8jen\u00e5bner: tillad alt.<\/p>\n<p>Denne vejledning vil hj\u00e6lpe med at forst\u00e5 det indre arbejde af netv\u00e6rkspolitikker; forst\u00e5 forskellene fra regler for almindelige firewall. Der vil ogs\u00e5 blive diskuteret nogle faldgruber, og der gives anbefalinger, som kan hj\u00e6lpe med at beskytte applikationer i Kubernetes.<\/p>\n<h2>Kubernetes-netv\u00e6rkspolitikker<\/h2>\n<p>\nMechanismen for Kubernetes-netv\u00e6rkspolitikker g\u00f8r det muligt at styre interaktionen mellem applikationer implementeret p\u00e5 platformen p\u00e5 netv\u00e6rksniveau (det tredje niveau i OSI-modellen). Netv\u00e6rkspolitikker mangler nogle af de avancerede funktioner fra moderne firewalls, s\u00e5som kontrol p\u00e5 niveau 7 i OSI og trusselsopdagelse, men de leverer et grundl\u00e6ggende niveau af netv\u00e6rkssikkerhed, som er en god start.<\/p>\n<h2>Netv\u00e6rkspolitikker kontrollerer kommunikation mellem pod'er.<\/h2>\n<p>\nArbejdslaster i Kubernetes fordeles p\u00e5 pod'er, som best\u00e5r af en eller flere containere, der er udrykket sammen. Kubernetes tildeler hver pod en IP-adresse, der er tilg\u00e6ngelig fra andre pod'er. Kubernetes netv\u00e6rkspolitikker angiver adgangsrettigheder for grupper af pod'er p\u00e5 samme m\u00e5de, som sikkerhedsgrupper i skyen bruges til at kontrollere adgangen til virtuelle maskiner.<\/p>\n<h2>Definition af netv\u00e6rkspolitikker<\/h2>\n<p>\nSom andre Kubernetes-ressourcer defineres netv\u00e6rkspolitikker i YAML-sprog. I det f\u00f8lgende eksempel f\u00e5r anvendelsen <code>balance<\/code> adgang til <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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Bem. overs.<\/b>: dette screenshot, ligesom alle f\u00f8lgende lignende, er skabt ved hj\u00e6lp af v\u00e6rkt\u00f8jet Tufin Orca, som er udviklet af forfatteren til den oprindelige artikel og n\u00e6vnes i slutningen af materialet.)<\/i><\/p>\n<p>For at definere en egen netv\u00e6rkspolitik kr\u00e6ves grundl\u00e6ggende kendskab til YAML. Dette sprog er baseret p\u00e5 indrykning (som skal angives med mellemrum, ikke tabulatorer). Et element med indrykning tilh\u00f8rer det n\u00e6rmeste overliggende element med indrykning. Et nyt listeelement starter med en bindestreg, og alle andre elementer fremst\u00e5r som <i>n\u00f8gle-v\u00e6rdi<\/i>.<\/p>\n<p>N\u00e5r du har beskrevet politikken i YAML, skal du bruge <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, for at oprette den i klyngen:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Specifikation af netv\u00e6rkspolitik<\/h2>\n<p>\nSpecifikationen af Kubernetes-netv\u00e6rkspolitikken best\u00e5r af fire elementer:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: definerer de pod'er, der ber\u00f8res af denne politik (m\u00e5l) - obligatorisk;<\/li>\n<li> <code>policyTypes<\/code>: angiver, hvilke typer politikker der er inkluderet: ingress og\/eller egress - valgfrit, men jeg anbefaler at skrive det klart i alle tilf\u00e6lde;<\/li>\n<li> <code>ingress<\/code>: definerer den tilladte <b>indg\u00e5ende<\/b> trafik til de m\u00e5lrettede pod'er - valgfrit;<\/li>\n<li> <code>egress<\/code>: definerer den tilladte <b>udg\u00e5ende<\/b> trafik fra de m\u00e5lrettede pod'er - valgfrit.<\/li>\n<\/ol>\n<p>\nEt eksempel hentet fra Kubernetes' hjemmeside (jeg har \u00e6ndret <code>rolle<\/code> og f\u00e5 en fungerende kommando. <code>app<\/code>), viser hvordan alle fire elementer anvendes:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBem\u00e6rk, at det ikke er obligatorisk at inkludere alle fire elementer. Kun <code>podSelector<\/code>er n\u00f8dvendigt, mens de \u00f8vrige parametre kan bruges valgfrit.<\/p>\n<p>Hvis du udelader <code>policyTypes<\/code>, vil politikken blive fortolket som f\u00f8lger:<\/p>\n<ul>\n<li> Som standard antages det, at den definerer ingress-siden. Hvis der ikke er eksplicitte angivelser i politikken, vil systemet betragte al trafik som forbudt.<\/li>\n<li> Adf\u00e6rden p\u00e5 egress-siden bestemmes af tilstedev\u00e6relsen eller frav\u00e6ret af den tilsvarende egress-parameter.<\/li>\n<\/ul>\n<p>\nFor at undg\u00e5 fejl anbefaler jeg <b>altid at angive eksplicit <code>policyTypes<\/code><\/b>.<\/p>\n<p>I overensstemmelse med den ovenst\u00e5ende logik, hvis parametrene <code>ingress<\/code> og\/eller <code>egress<\/code> udelades, vil politikken forbyde al trafik (se \"Rydningsregel\" nedenfor).<\/p>\n<h2>Standardpolitikken er at tillade<\/h2>\n<p>\nHvis der ikke er defineret politikker, tillader Kubernetes som standard al trafik. Alle pod'er kan frit udveksle information med hinanden. Fra et sikkerhedsm\u00e6ssigt perspektiv kan det synes ulogisk, men husk p\u00e5, at Kubernetes oprindeligt blev designet af udviklere med det form\u00e5l at sikre interaktion mellem applikationer. Netv\u00e6rkspolitikker blev tilf\u00f8jet senere.<\/p>\n<h2>Navnerum<\/h2>\n<p>\nNavnerum (Namespaces) er et mekanisme til kollektivt arbejde i Kubernetes. De er beregnet til at isolere logiske milj\u00f8er fra hinanden, mens dataudveksling mellem navnerum som standard er tilladt.<\/p>\n<p>Som med de fleste Kubernetes-komponenter lever netv\u00e6rkspolitikker i et bestemt navnerum. I blokken <code>metadata<\/code> kan du angive, hvilket navnerum politikken tilh\u00f8rer:<\/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>\nHvis navnerummet i metadata ikke er angivet eksplicit, vil systemet bruge det navnerum, der er angivet i kubectl (som standard <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nJeg anbefaler <b>eksplicit at angive navnerummet<\/b>, medmindre du skriver en politik, der er beregnet til flere navnerum p\u00e5 \u00e9n gang.<\/p>\n<p><b>Prim\u00e6r<\/b> element <code>podSelector<\/code> politikken vil v\u00e6lge pod'er fra det navnerum, som politikken tilh\u00f8rer (den har ikke adgang til pod'er fra et andet navnerum).<\/p>\n<p>Ligeledes podSelector'er <b>i ingress- og egress-blokke<\/b> kun v\u00e6lge pods fra deres eget navnerum, medmindre du sammenk\u00e6der dem ved hj\u00e6lp af <code>namespaceSelector<\/code> (dette vil blive dr\u00f8ftet i afsnittet 'Filtrering efter navnerum og pod'er').<\/p>\n<h2>Navngivningsregler for politikker<\/h2>\n<p>\nPolitiknavnene er unikke inden for et enkelt navnerum. Der kan ikke v\u00e6re to politikker med samme navn i \u00e9t navnerum, men der kan v\u00e6re politikker med samme navne i forskellige navnerum. Dette er praktisk, n\u00e5r du vil genbruge den samme politik p\u00e5 flere navnerum.<\/p>\n<p>Jeg kan is\u00e6r godt lide en af m\u00e5derne at navngive p\u00e5. Den g\u00e5r ud p\u00e5 at kombinere navnet p\u00e5 navnerummet med de m\u00e5lrettede pods. For eksempel:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Labels<\/h2>\n<p>\nBrugerdefinerede labels kan knyttes til Kubernetes-objekter s\u00e5som pods og navnerum. Labels (<i>labels<\/i> \u2014 etiketter) svarer til tags i skyen. Kubernetes netv\u00e6rkspolitikker bruger labels til at v\u00e6lge <b>pod'er<\/b>, som de anvendes p\u00e5:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 eller <b>navnerum<\/b>, som de anvendes p\u00e5. I dette eksempel v\u00e6lges alle pod'er i navnerum med de relevante labels:<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\n\u00c9n advarsel: n\u00e5r du bruger <code>namespaceSelector<\/code> <b>skal du sikre dig, at de valgte navnerum indeholder den \u00f8nskede label<\/b>. V\u00e6r opm\u00e6rksom p\u00e5, at indbyggede navnerum, s\u00e5som <code>default<\/code> og <code>kube-system<\/code>, som standard ikke indeholder labels.<\/p>\n<p>For at tilf\u00f8je en label til et navnerum kan du g\u00f8re f\u00f8lgende:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nHer skal namespace i sektionen <code>metadata<\/code> henvise til det faktiske navn p\u00e5 navnerummet og ikke til labelen:<\/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>Kilde og modtager<\/h2>\n<p>\nPolitikker for firewalls best\u00e5r af regler med kilder og modtagere. Kubernetes netv\u00e6rkspolitikker defineres for en m\u00e5lgruppe - et s\u00e6t pod'er, som de anvendes p\u00e5, og derefter fasts\u00e6tter regler for indg\u00e5ende (ingress) og\/eller udg\u00e5ende (egress) trafik. I vores eksempel vil m\u00e5let for politikken v\u00e6re alle pod'er i navnerummet <code>default<\/code> med et label med n\u00f8gle <code>app<\/code> og v\u00e6rdi <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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnderafsnit <code>ingress<\/code> i denne politik \u00e5bner indg\u00e5ende trafik til m\u00e5l-pod'erne. Med andre ord fungerer ingress som kilde, og m\u00e5let er den tilsvarende modtager. Tilsvarende er egress modtageren, og m\u00e5let er dens kilde.<\/p>\n<p><img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Dette svarer til to firewall-regler: Ingress \u2192 M\u00e5l; M\u00e5l \u2192 Egress.<\/i><\/p>\n<h2>Egress og DNS (vigtigt!)<\/h2>\n<p>\nN\u00e5r du begr\u00e6nser udg\u00e5ende trafik, <b>s\u00e6rligt v\u00e6r opm\u00e6rksom p\u00e5 DNS<\/b> \u2014 Kubernetes bruger denne tjeneste til at kortl\u00e6gge tjenester til IP-adresser. For eksempel vil f\u00f8lgende politik ikke fungere, da du ikke har tilladt applikationen <code>balance<\/code> at f\u00e5 adgang til DNS:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDu kan rette det ved at \u00e5bne for adgangen til DNS-tjenesten:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet sidste element <code>til<\/code> \u2014 er tomt, og derfor v\u00e6lger det indirekte <b>alle pod'er i alle navnerum<\/b>, hvilket tillader <code>balance<\/code> at sende DNS-foresp\u00f8rgsler til den relevante Kubernetes-tjeneste (den k\u00f8rer typisk i navnerummet <code>kube-system<\/code>).<\/p>\n<p>Denne tilgang fungerer, men den <b>er alt for tilladende og usikker<\/b>, da den tillader at sende DNS-foresp\u00f8rgsler udenfor klyngen.<\/p>\n<p>Det kan forbedres i tre trin.<\/p>\n<p>1. Tillad DNS-foresp\u00f8rgsler kun <b>indenfor<\/b> klyngen ved at tilf\u00f8je <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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Tillad DNS-foresp\u00f8rgsler kun inden for navnerummet <code>kube-system<\/code>.<\/p>\n<p>For dette skal du tilf\u00f8je et label til navnerummet <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 og angive det i politikken ved hj\u00e6lp af <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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Paranoide kan g\u00e5 endnu l\u00e6ngere og begr\u00e6nse DNS-foresp\u00f8rgsler til en bestemt DNS-tjeneste i <code>kube-system<\/code>. I afsnittet 'Filtrering efter navnerum og pod'er' vil det blive forklaret, hvordan dette opn\u00e5s.<\/p>\n<p>En anden mulighed er at tillade DNS p\u00e5 navnerumsniveau. I s\u00e5 fald beh\u00f8ver det ikke at \u00e5bnes for hver tjeneste:<\/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>\nTom <code>podSelector<\/code> v\u00e6lger alle pods i navnerummet.<\/p>\n<p><img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Den f\u00f8rste overensstemmelse og r\u00e6kkef\u00f8lge for regler<\/h2>\n<p>\nI almindelige firewalls bestemmes handlingen (\"Tillad\" eller \"Forbyd\") for en pakke af den f\u00f8rste regel, den opfylder. <b>I Kubernetes har r\u00e6kkef\u00f8lgen af politikker ingen betydning.<\/b><\/p>\n<p>Som standard, n\u00e5r politikker ikke er defineret, er kommunikationen mellem pod'er tilladt, og de kan frit udveksle information. S\u00e5 snart du begynder at formulere politikker, bliver hver pod ber\u00f8rt af en af dem isoleret i henhold til disjunktion (logisk ELLER) af alle politikker, der v\u00e6lger den. Pod'er, der ikke er ber\u00f8rt af nogen politik, forbliver \u00e5bne.<\/p>\n<p>Denne adf\u00e6rd kan \u00e6ndres med et rydderegulativ.<\/p>\n<h2>Rydde-regulativet (\"Forbyd\")<\/h2>\n<p>\nFirewall-politikker forbyder normalt enhver trafik, der ikke er eksplicit tilladt.<\/p>\n<p><b>I Kubernetes findes der ikke nogen handling \"forbyd\" (deny),<\/b>, men en lignende effekt kan opn\u00e5s med en almindelig (tilladende) politik ved at v\u00e6lge en tom gruppe af pod-kilder (ingress):<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDenne politik v\u00e6lger alle pod'er i navnerummet og lader ingress v\u00e6re udefineret, hvilket forhindrer al indkommende trafik.<\/p>\n<p>P\u00e5 samme m\u00e5de kan man begr\u00e6nse al udg\u00e5ende trafik fra navnerummet:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBem\u00e6rk, at <b>enhver yderligere politik, der tillader trafik til pod'er i navnerummet, vil have forrang over denne regel<\/b> (svarende til at tilf\u00f8je en tilladende regel f\u00f8r en forbudt i firewall-konfigurationen).<\/p>\n<h2>Tillad alt (Any-Any-Any-Allow)<\/h2>\n<p>\nFor at oprette en \"Tillad alt\" politik, skal du supplere ovenst\u00e5ende forbudspolitik med et tomt 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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen \u00e5bner adgang fra <b>alle pod'er i alle navnerum (og alle IP'er) til enhver pod i navnerummet <code>default<\/code><\/b>. Denne adf\u00e6rd er aktiveret som standard, s\u00e5 normalt beh\u00f8ver den ikke at blive defineret yderligere. Dog kan det nogle gange v\u00e6re n\u00f8dvendigt midlertidigt at deaktivere nogle specifikke tilladelser for at diagnosticere et problem.<\/p>\n<p>Reglen kan indsn\u00e6vres og tillade adgang kun til <b>et bestemt s\u00e6t af pod'er<\/b> (<code>app:balance<\/code>) i navnerummet <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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen f\u00f8lgende politik tillader al indg\u00e5ende (ingress) og udg\u00e5ende (egress) trafik, inklusive adgang til enhver IP uden for klyngen:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Kombinering af flere politikker<\/h2>\n<p>\nPolitikker kombineres ved hj\u00e6lp af logisk ELLER p\u00e5 tre niveauer; tilladelserne for hver pod fasts\u00e6ttes i henhold til disjunktionen af alle de politikker, der p\u00e5virker den:<\/p>\n<p>1. I felterne <code>fra<\/code> og <code>til<\/code> kan du definere tre typer elementer (alle kombineres med ELLER):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 v\u00e6lger navnerummet som helhed;<\/li>\n<li> <code>podSelector<\/code> \u2014 v\u00e6lger pods;<\/li>\n<li> <code>ipBlock<\/code> \u2014 v\u00e6lger subnet.<\/li>\n<\/ul>\n<p>\nDer er ingen gr\u00e6nse for antallet af elementer (selv de samme) i underafsnit <code>fra<\/code>\/<code>til<\/code> Alle vil blive kombineret logisk ELLER.<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Inden for politikafsnittet <code>ingress<\/code> kan der v\u00e6re mange elementer <code>fra<\/code> (kombineres med logisk ELLER). Tilsvarende kan afsnittet <code>egress<\/code> omfatte mange elementer <code>til<\/code> (ogs\u00e5 kombineres med disjunktion):<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Forskellige politikker kombineres ogs\u00e5 med logisk ELLER<\/p>\n<p>Men n\u00e5r de kombineres, er der en begr\u00e6nsning, som <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">at<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes kan kun kombinere politikker med forskellige <code>policyTypes<\/code> (<code>Ingress<\/code> eller <code>Egress<\/code>). Politikker, der definerer ingress (eller egress), vil overskrive hinanden.<\/p>\n<h2>Forbindelse mellem navnerum<\/h2>\n<p>\nSom standard er informationsudveksling mellem navnerum tilladt. Dette kan \u00e6ndres med en restriktiv politik, som begr\u00e6nser udg\u00e5ende og\/eller indg\u00e5ende trafik i et navnerum (se \"Cleansing rule\" ovenfor).<\/p>\n<p>Ved at blokere adgangen til et navnerum (se \"Cleansing rule\" ovenfor) kan du lave undtagelser i den restriktive politik ved at tillade forbindelser fra et bestemt navnerum ved hj\u00e6lp af <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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSom et resultat vil alle pod\u2019ene i navnerummet <code>default<\/code> vil have adgang til pod'er <code>postgres<\/code> i navnerummet <code>database<\/code>. Men hvad nu, hvis du vil \u00e5bne adgangen til <code>postgres<\/code> kun bestemte pod'er i navnerummet <code>default<\/code>?<\/p>\n<h2>Filter efter navnerum og pod'er<\/h2>\n<p>\nKubernetes version 1.11 og h\u00f8jere tillader kombination af operatorer <code>namespaceSelector<\/code> og <code>podSelector<\/code> ved hj\u00e6lp af logisk OG. Det ser s\u00e5ledes ud:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvorfor tolkes dette som OG i stedet for det s\u00e6dvanlige ELLER?<\/p>\n<p>Bem\u00e6rk venligst, at <code>podSelector<\/code> starter ikke med et bindestreg. I YAML betyder det, at <code>podSelector<\/code> og det, der st\u00e5r f\u00f8r det <code>namespaceSelector<\/code> tilh\u00f8rer det samme listeelement. Derfor kombineres de med logisk OG.<\/p>\n<p>Tilf\u00f8jelse af et bindestreg foran <code>podSelector<\/code> vil f\u00f8re til oprettelsen af et nyt listeelement, der kombineres med det forrige <code>namespaceSelector<\/code> ved hj\u00e6lp af en logisk ELLER.<\/p>\n<p>For at v\u00e6lge pod'er med en bestemt etiket <b>i alle navnerum<\/b>, indtast et tomt <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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Flere labels kombineres med OG<\/h2>\n<p>\nFirewall-regler med flere objekter (hosts, netv\u00e6rk, grupper) kombineres ved hj\u00e6lp af logisk ELLER. Den f\u00f8lgende regel g\u00e6lder, hvis kildepakken matcher <code>Host_1<\/code> . <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Kilde | Destination | Tjeneste | Handling |\n| ----------------------------------------|\n| Host_1 | Subnet_A    | HTTPS   | Tillad  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nOmvendt i Kubernetes kombineres forskellige labels med <code>podSelector<\/code> eller <code>namespaceSelector<\/code> logisk OG. For eksempel vil den f\u00f8lgende regel v\u00e6lge pods med begge labels, <code>role=db<\/code> Og <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nDen samme logik g\u00e6lder for alle typer operatorer: politikm\u00e5lere, pod-selektorer og navnerums-selektorer.<\/p>\n<h2>Subnet og IP-adresser (IPBlocks)<\/h2>\n<p>\nFor at segmentere netv\u00e6rket bruger firewalls VLAN, IP-adresser og subnets.<\/p>\n<p>I Kubernetes tildeles IP-adresser automatisk til pod'er og kan ofte \u00e6ndre sig, derfor bruges etiketter til at v\u00e6lge pod'er og navnerum i netv\u00e6rkspolitikker.<\/p>\n<p>Subnets (<code>ipBlocks<\/code>) bruges ved h\u00e5ndtering af indkommende (ingress) eller udg\u00e5ende (egress) eksterne (North-South) forbindelser. For eksempel \u00e5bner denne politik for alle pod'er fra navnerummet <code>default<\/code> adgang til Googles DNS-tjeneste:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn tom pod-selektor i dette eksempel betyder 'v\u00e6lg alle pod'er i navnerummet'.<\/p>\n<p>Denne politik \u00e5bner kun adgang til 8.8.8.8; adgang til enhver anden IP er forbudt. Dermed har du i praksis blokeret adgangen til Kubernetes interne DNS-tjeneste. Hvis du alligevel vil \u00e5bne det, skal du angive det eksplicit.<\/p>\n<p>Normalt <code>ipBlocks<\/code> og <code>podSelectors<\/code> er gensidigt udelukkende, da interne IP-adresser for pod'er ikke bruges i <code>ipBlocks<\/code>. Ved at angive <b>indre IP'er for pod'er<\/b>, vil du faktisk tillade forbindelser til\/fra pod'er med disse adresser. I praksis vil du ikke vide, hvilken IP-adresse der skal bruges, derfor b\u00f8r de ikke anvendes til at v\u00e6lge pod'er.<\/p>\n<p>Som kontrast inkluderer f\u00f8lgende politik alle IP'er og tillader derfor adgang til alle andre pod'er:<\/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=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMan kan \u00e5bne adgang kun til eksterne IP'er ved at udelukke de interne IP-adresser for pod'er. For eksempel, hvis din pod's subnet er 10.16.0.0\/14:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0\n        except:\n        - 10.16.0.0\/14<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Porter og protokoller<\/h2>\n<p>\nNormalt lytter pod'er p\u00e5 \u00e9n port. Det betyder, at man ganske enkelt kan undlade at angive portnumre i politikkerne og lade alt v\u00e6re som standard. Dog anbefales det at g\u00f8re politikker s\u00e5 restriktive som muligt, s\u00e5 i nogle tilf\u00e6lde kan man stadig angive porte:<\/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;&lt;\n      - port: 443      # &lt;&lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;&lt;\n      - port: 80       # &lt;&lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBem\u00e6rk, at selektor <code>ports<\/code> anvendes p\u00e5 alle elementer i blokken <code>til<\/code> eller <code>fra<\/code>, hvori den er indeholdt. For at angive forskellige porte for forskellige s\u00e6tbredder, del <code>ingress<\/code> eller <code>egress<\/code> op i flere underafsnit med <code>til<\/code> eller <code>fra<\/code> og angiv de n\u00f8dvendige porte for hver:<\/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;&lt;\n     - port: 443       # &lt;&lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;&lt;\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;&lt;\n     - port: 80        # &lt;&lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduktion til Kubernetes-netv\u00e6rkspolitikker for sikkerhedsspecialister\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nStandard portdrift:<\/p>\n<ul>\n<li> Hvis du helt udelader portdefinitioner (<code>ports<\/code>), betyder det alle protokoller og alle porte;<\/li>\n<li> Hvis du udelader protokoldefinitionen (<code>protocol<\/code>), betyder det TCP;<\/li>\n<li> Hvis du udelader portdefinitionen (<code>port<\/code>), betyder det alle porte.<\/li>\n<\/ul>\n<p>\nBedste praksis: stol ikke p\u00e5 standardv\u00e6rdier, angiv det, du har brug for, eksplicit.<\/p>\n<p>Bem\u00e6rk, at du skal bruge poddenes porte, ikke tjenesters porte (l\u00e6s mere om dette i n\u00e6ste afsnit).<\/p>\n<h2>Er politikkerne defineret for pod'er eller tjenester?<\/h2>\n<p>\nNormalt kommunikerer pod'er i Kubernetes med hinanden gennem tjenester - en virtuel belastningsfordeler, der omdirigerer trafik til de pod'er, der leverer tjenesten. Man kunne tro, at netv\u00e6rkspolitikker kontrollerer adgangen til tjenester, men det er ikke tilf\u00e6ldet. <b>Kubernetes netv\u00e6rkspolitikker arbejder med poddenes porte, ikke tjenesters porte.<\/b><\/p>\n<p>For eksempel, hvis en tjeneste lytter p\u00e5 port 80, men omdirigerer trafik til port 8080 p\u00e5 sine pod'er, skal netv\u00e6rkspolitikken angive netop 8080.<\/p>\n<p>En s\u00e5dan mekanisme b\u00f8r betragtes som suboptimal: N\u00e5r den interne struktur af tjenesten \u00e6ndres (de porte, som pod'erne lytter p\u00e5), skal netv\u00e6rkspolitikkerne opdateres.<\/p>\n<p>En ny arkitektonisk tilgang ved brug af Service Mesh <i>(for eksempel se om Istio nedenfor \u2014 bem. overs.)<\/i> l\u00f8ser dette problem.<\/p>\n<h2>Skal b\u00e5de Ingress og Egress angives?<\/h2>\n<p>\nDet korte svar er ja, for at pod A kan kommunikere med pod B, skal det tillades at oprette en udg\u00e5ende forbindelse (for dette skal der konfigureres en egress-politik), og pod B skal kunne modtage en indg\u00e5ende forbindelse (for dette kr\u00e6ves en ingress-politik).<\/p>\n<p>Men i praksis kan man stole p\u00e5 standardpolitikken, som tillader forbindelser i en eller begge retninger.<\/p>\n<p>Hvis en pod-<b>kilde<\/b> bliver valgt af en eller flere <b>egress<\/b>-politikker, vil de begr\u00e6nsninger, der p\u00e5l\u00e6gges den, blive bestemt af deres disjunktion. I dette tilf\u00e6lde vil det v\u00e6re n\u00f8dvendigt at tillade forbindelse til pod-<b>modtageren<\/b>. Hvis pod'en ikke er valgt af nogen politik, er dens udg\u00e5ende (egress) trafik tilladt som standard.<\/p>\n<p>P\u00e5 samme m\u00e5de vil sk\u00e6bnen for pod'en-<b>modtageren<\/b>, valgt af en eller flere <b>ingress<\/b>-politik v\u00e6re bestemt af deres disjunktion. I dette tilf\u00e6lde skal det eksplicit tillades at modtage trafik fra pod'en-kilde. Hvis pod'en ikke v\u00e6lges af nogen politik, er al indkommende (ingress) trafik for den tilladt som standard.<\/p>\n<p>Se punktet 'Stateful eller Stateless' nedenfor.<\/p>\n<h2>Logs<\/h2>\n<p>\nNetv\u00e6rkspolitikker i Kubernetes har ikke mulighed for at registrere trafik. Det g\u00f8r det sv\u00e6rt at afg\u00f8re, om politikken fungerer korrekt og komplicerer analysen inden for sikkerhed.<\/p>\n<h2>Kontrol over trafikken til eksterne tjenester<\/h2>\n<p>\nKubernetes-netv\u00e6rkspolitikker tillader ikke at angive et fuldt dom\u00e6nenavn (DNS) i egress-sektionerne. Denne situation skaber betydelige udfordringer ved fors\u00f8g p\u00e5 at begr\u00e6nse trafik til eksterne adresser, der ikke har en fast IP-adresse (s\u00e5som aws.com).<\/p>\n<h2>Politik kontrol<\/h2>\n<p>\nFirewalls vil advare dig eller endda n\u00e6gte at acceptere en fejlagtig politik. Kubernetes udf\u00f8rer ogs\u00e5 en vis validering. N\u00e5r du angiver netv\u00e6rkspolitikken via kubectl, kan Kubernetes erkl\u00e6re, at den er ugyldig og n\u00e6gte at acceptere den. I andre tilf\u00e6lde vil Kubernetes acceptere politikken og supplere den med manglende detaljer. Disse kan ses med f\u00f8lgende kommando:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nV\u00e6r opm\u00e6rksom p\u00e5, at Kubernetes' valideringssystem ikke er ufejlbarligt og kan overse nogle typer fejl.<\/p>\n<h2>Udf\u00f8relse<\/h2>\n<p>\nKubernetes implementerer ikke netv\u00e6rkspolitikker selv, men fungerer blot som en API-gateway, der p\u00e5l\u00e6gger kontrollen til et underliggende system kaldet Container Networking Interface (CNI). At angive politikker i et Kubernetes-kluster uden at tildele den relevante CNI svarer til at oprette politikker p\u00e5 en firewall-administrationsserver uden at installere dem i firewalls. Du skal selv sikre, at der er en passende CNI tilg\u00e6ngelig, eller i tilf\u00e6lde af Kubernetes-platforme i skyen <i>(se listen over udbydere <noindex>her<\/noindex> \u2014 red.)<\/i>, aktivere netv\u00e6rkspolitikker, der vil etablere CNI for dig.<\/p>\n<p>Bem\u00e6rk, at Kubernetes ikke vil advare dig, hvis du angiver en netv\u00e6rkspolitik uden den relevante CNI.<\/p>\n<h3>Stateful eller Stateless?<\/h3>\n<p>\nAlle Kubernetes CNI'er, jeg har stiftet bekendtskab med, er stateful (for eksempel bruger Calico Linux conntrack). Dette g\u00f8r det muligt for en pod at modtage svar p\u00e5 en TCP-forbindelse, den har initieret, uden at skulle etablere den igen. Jeg kender dog ikke til nogen Kubernetes-standard, der garanterer statefulness.<\/p>\n<h2>Avanceret sikkerhedspolitikstyring<\/h2>\n<p>\nHer er nogle m\u00e5der at \u00f8ge effektiviteten af sikkerhedspolitikudf\u00f8relse i Kubernetes:<\/p>\n<ol>\n<li> Arkitekturm\u00f8nsteret Service Mesh bruger sidecar-containere til at levere detaljeret telemetri og trafikstyring p\u00e5 serviceniveau. Et eksempel kunne v\u00e6re <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Nogle af CNI-leverand\u00f8rerne har forbedret deres v\u00e6rkt\u00f8jer, s\u00e5 de g\u00e5r udover netv\u00e6rkspolitikkerne i Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> giver gennemsigtighed og automatisering af netv\u00e6rkspolitikkerne i Kubernetes.<\/li>\n<\/ol>\n<p>\nTufin Orca-pakken administrerer netv\u00e6rkspolitikkerne i Kubernetes (og fungerer som kilde til de ovenfor n\u00e6vnte sk\u00e6rmbilleder).<\/p>\n<h2>Yderligere oplysninger<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Eksempler p\u00e5 netv\u00e6rkspolitikker, forberedt af Ahmet Alp Balkan fra GKE<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Dokumentation fra den officielle Kubernetes-hjemmeside<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Guide til Kubernetes-netv\u00e6rksmodellen<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Script til kontrol af netv\u00e6rkspolitikker<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Konklusion<\/h2>\n<p>\nNetv\u00e6rkspolitikkerne i Kubernetes tilbyder et godt s\u00e6t v\u00e6rkt\u00f8jer til segmentering af klynger, men de er ikke intuitive og har mange nuancer. Jeg mener, at p\u00e5 grund af denne kompleksitet indeholder mange eksisterende klynger fejl. Mulige l\u00f8sninger p\u00e5 dette problem er automatisering af politikdefinitioner eller brug af andre segmenteringsv\u00e6rkt\u00f8jer.<\/p>\n<p>Jeg h\u00e5ber, at denne guide vil hj\u00e6lpe med at klarl\u00e6gge nogle sp\u00f8rgsm\u00e5l og l\u00f8se de problemer, du m\u00e5tte st\u00f8de p\u00e5.<\/p>\n<h2>P.S. fra overs\u00e6tteren<\/h2>\n<p>\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n<ul>\n<li> \u00abTilbage til mikrotjenester sammen med Istio\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">del 1 (introduktion til de grundl\u00e6ggende funktioner)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">del 2 (routing, trafikstyring)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">del 3 (sikkerhed)<\/a><\/noindex>;<\/li>\n<li> \u00abIllustreret guide til netv\u00e6rksopbygning i Kubernetes\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">del 1 og 2 (netv\u00e6rksmodel, overlay-netv\u00e6rk)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">del 3 (tjenester og trafikbehandling)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker og Kubernetes i sikkerhedskr\u00e6vende milj\u00f8er<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 bedste praksisser for at sikre sikkerheden i Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 m\u00e5der (ikke) at blive offer for hacking i Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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\udd47Introduktion til netv\u00e6rkspolitikker i Kubernetes for sikkerhedsspecialister | ProHoster","description":"Bem.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}