Hvordan konfigurere nekte tjeneste eksterne IPS i Kubernetes

Du kan få et problem mens du setter opp en Kubernetes -klynge når du bare vet hvordan du bruker NodePort for å gjøre Kubernetes -tjenesten din tilgjengelig over Internett. Når du bruker NodePort -tjenestetypen, vil det bli tildelt et høyt portnummer, og du må tillate tilkoblinger til disse portene i brannmurregelen. Det er skadelig for infrastrukturen din, spesielt hvis serveren er tilgjengelig via det åpne internett. Du kan tilordne en blokk med IP -adresser utenfor klyngen som en klyngeadministrator som kan overføre trafikk til tjenester der. Dette er nøyaktig hva vi skal snakke om i denne artikkelen: å finne all kritisk informasjon om hvordan du konfigurerer nektet tjeneste eksterne IP -er i Kubernetes.

Hva er ekstern IP -tjeneste?

Et av tjeneste -endepunktene vil motta trafikk som kommer inn i klyngen ved å bruke den eksterne IP -en (som destinasjons -IP) og serviceporten. Kubernetes er ikke ansvarlig for å administrere ekstern IP.

Å sørge for hvilken IP som brukes for å få tilgang til Kubernetes -klyngen som er avgjørende i denne situasjonen. Ved hjelp av den eksterne IP -tjenestetypen kan vi binde tjenesten til IP -adressen som brukes til å få tilgang til klyngen.

At Kubernetes -nettverket samhandler med overleggsnettverket er viktig for å forstå denne situasjonen. Dette innebærer at du kan få tilgang til praktisk talt hver node i klyngen når du kommer til noen av nodene (master eller arbeidernode).

Nettverket vises på denne måten:

Begge nodene 1 og 2 i diagrammet deler en enkelt IP -adresse. Den virkelige pod lever på node 1, men IP -adressen 1.2.3.6 er bundet til Nginx -tjenesten på node 1. Node 1s IP -adresse, 1.2.3.4, er bundet til HTTPD -tjenesten, og Node 2s faktiske pod ligger der.

Dette er muliggjort av overleggsnettverkets underbygg. Når vi krøller IP -adresse 1.2.3.4, HTTPD -tjenesten skal svare; Når vi krøller 1.2.3.5, skal Nginx -tjenesten svare.

Fordelaktig og ulemper med ekstern IP

Her er fordelene og ulempene med ekstern IP:

Det er fordelaktig å bruke ekstern IP fordi:

• • IP -en din er helt innenfor din kontroll. I stedet for å bruke skyleverandørens ASN, kan du bruke IP som tilhører din egen ASN.

Ulempene med ekstern IP inkluderer følgende:

• • Det enkle oppsettet vi vil gå gjennom akkurat nå er ikke veldig lett tilgjengelig. Dette innebærer at hvis noden mislykkes, vil tjenesten ikke lenger være tilgjengelig, og du må løse problemet manuelt.
  • For å håndtere IP -ene er det nødvendig med betydelig menneskelig arbeidskraft. Siden IP -ene ikke er dynamisk tildelt for deg, må du gjøre det manuelt.

Hva er standard benekt/tillat atferd?

“Standard tillater”angir at all trafikk er tillatt som standard. Med mindre det er spesifikt tillatt, nektes all trafikk som standard når du bruker begrepet "Standard nekt.”Bortsett fra når en nettverkspolicy er spesifisert.

• • All trafikk til og fra en pod er tillatt hvis ingen nettverkspolicyer er i kraft for den pod.
  • Hvis en eller flere nettverkspolitikker er i kraft for en pod av type inntrengning, er det bare at inntrengningstrafikk eksplisitt er tillatt av disse retningslinjene er tillatt.
  • Når en eller flere nettverkspolicyer gjelder en pod av type egress, er det bare egress -trafikken som er tillatt av disse retningslinjene er tillatt.

Standardinnstillingen for andre sluttpunkttyper (VM -er, vertsgrensesnitt) er å blokkere trafikken. Bare trafikk som er spesifikt tillatt med nettverkspolicy er tillatt, selv om ingen nettverkspolitikker gjelder for endepunktet.

Beste praksis: Implisitt Standard Nekt -policy

Du må konfigurere en implisitt standard avslagspolicy opprettet for dine Kubernetes Pods. Dette sørger for at uønsket trafikk automatisk blokkeres. Husk at implisitte standard benekter retningslinjer alltid trer i kraft sist; Hvis noen andre retningslinjer tillater trafikk, gjelder ikke avslaget. Nektelsen implementeres bare etter at alle andre retningslinjer er vurdert.

Hvordan lage en standard benekter policy for Kubernetes Pods?

Vi anbefaler å bruke den globale nettverkspolitikken, selv om noen av følgende regler kan brukes til å konstruere en standard benekter policy for Kubernetes Pods. En global nettverkspolitikk brukes på alle arbeidsmengder (VMS og containere) på tvers av alle navneområder og verter. En global nettverkspolitikk oppmuntrer til en forsiktig tilnærming til sikkerhet mens de forsvarer ressurser.

• • Aktiver standard for å nekte global nettverkspolitikk, ikke-navnepace
  • Aktiver standard for å nekte nettverkspolicy, navneområdet
  • Aktiver standard for å nekte Kubernetes -policy, navnefelt

Hva er IP -blokk?

Med dette er spesifikke IP CIDR -områder valgt å være tillatt som inntrengningskilder eller Egress -destinasjoner. Gitt at POD IP-er er forbigående og uforutsigbare, bør disse være klynge-ekstern IP-er.

Kilden eller destinasjons -IP -en for pakker må ofte skrives om når du bruker klyngeinngang og egressemetoder. Avhengig av den aktuelle nettverksplugin (Cloud Service Provider, Service Implementation, etc.) som brukes, kan oppførselen endres.

Dette gjelder for inntreden, og det betyr at du i noen tilfeller må filtrere innkommende pakker som er basert på den faktiske kilden IP. På den annen side kan "kilden IP" som NetworkPolicy fungerer på, være IP -en til en LoadBalancer eller til og med podens node, etc.

Dette viser at tilkoblinger mellom POD-er og IP-er som er skrevet om til klynge-ekstern IP-er kan bli utsatt for ipblock-baserte begrensninger i form av egress.

Hva er standardreglene?

All inntrengning og egress trafikk til og fra belg i et navneområde er som standard tillatt hvis det ikke er noen kontroller for det navneområdet. Du kan endre navnefeltets standardatferd ved å bruke følgende eksempler.

Standard benekter all inntrengningstrafikk

Når du oppretter en nettverkspolicy som velger alle pods, men som ikke inkluderer noen innkommende trafikk til disse belgene, kan du bygge en "standard" inntrengningsisolasjonspolitikk, og det er for et navneområde.

Dette sikrer at alle belg, uavhengig av om noe annet nettverkspolicy velger dem, er isolert for inntrenging. Denne regelen gjelder ikke isolasjon for å forlate noen POD.

Standard benekter all egress trafikk

Når du oppretter en nettverkspolicy som velger alle pods, men forbyr egress -trafikk fra disse podene, kan du bygge en "standard" egressisolasjonspolitikk, og det er også for et navneområde.

Konklusjon

Denne guiden handlet om bruk av DenyServiceExternalips. Vi har designet en diagrammatisk representasjon også for å få brukerne våre til å forstå at den fungerer. Vi har også gitt prøvekonfigurasjoner.