Externe IP's van service weigeren configureren in Kubernetes

U kunt een probleem tegenkomen bij het opzetten van een Kubernetes-cluster als u alleen weet hoe u NodePort moet gebruiken om uw Kubernetes-service via internet toegankelijk te maken. Wanneer u het NodePort-servicetype gebruikt, wordt een hoog poortnummer toegewezen en moet u verbindingen met die poorten toestaan ​​in uw firewallregel. Vooral als de server via het open internet toegankelijk is, is dit schadelijk voor uw infrastructuur. U kunt als clusterbeheerder een blok IP-adressen buiten het cluster toewijzen die verkeer naar services daar kan verzenden. Dit is precies waar we het in dit artikel over gaan hebben: om alle kritieke informatie te vinden over het configureren van externe IP-adressen voor het weigeren van service in Kubernetes.

Wat is Externe IP-service?

Een van de service-eindpunten ontvangt verkeer dat het cluster binnenkomt met behulp van het externe IP-adres (als het bestemmings-IP-adres) en de servicepoort. Kubernetes is niet verantwoordelijk voor het beheer van externe IP.

In deze situatie is het cruciaal om ervoor te zorgen welk IP-adres wordt gebruikt om toegang te krijgen tot het Kubernetes-cluster. Met behulp van het externe IP-servicetype kunnen we de service binden aan het IP-adres dat wordt gebruikt om toegang te krijgen tot het cluster.

Het feit dat het Kubernetes-netwerk samenwerkt met het Overlay-netwerk is belangrijk om deze situatie te begrijpen. Dit houdt in dat u vrijwel elk knooppunt in het cluster kunt benaderen zodra u een van de knooppunten bereikt (hoofd- of werkknooppunt).

Het netwerk wordt op deze manier weergegeven:

Zowel knooppunt 1 als 2 in het diagram delen een enkel IP-adres. De echte pod bevindt zich op knooppunt 1, maar het IP-adres 1.2.3.6 is gebonden aan de Nginx-service op knooppunt 1. Het IP-adres van knooppunt 1, 1.2.3.4, is gebonden aan de httpd-service en de eigenlijke pod van knooppunt 2 bevindt zich daar.

Dit wordt mogelijk gemaakt door de onderbouwing van het Overlay-netwerk. Wanneer we IP-adres 1.2.3.4 krullen, zou de httpd-service moeten reageren; wanneer we 1.2.3.5 krullen, zou de Nginx-service moeten reageren.

Voor- en nadelen van externe IP

Dit zijn de voor- en nadelen van externe IP:

Het is voordelig om externe IP te gebruiken omdat:

• • Uw IP is volledig binnen uw controle. In plaats van het ASN van de cloudprovider te gebruiken, kunt u IP gebruiken dat bij uw eigen ASN hoort.

De nadelen van externe IP omvatten het volgende:

• • De eenvoudige installatie die we nu zullen doornemen, is NIET erg gemakkelijk beschikbaar. Dit houdt in dat als het knooppunt uitvalt, de service niet langer toegankelijk is en u het probleem handmatig moet oplossen.
  • Om de IP's te verwerken, is veel menselijke arbeid vereist. Aangezien de IP's niet dynamisch voor u worden toegewezen, moet u dit handmatig doen.

Wat is standaard weigeren/toestaan-gedrag?

De ' Standaard toestaan ” geeft aan dat al het verkeer standaard is toegestaan. Tenzij specifiek toegestaan, wordt al het verkeer standaard geweigerd bij gebruik van de term ' standaard weigeren .” behalve wanneer er een netwerkbeleid is opgegeven.

• • Al het verkeer van en naar een pod is toegestaan ​​als er geen netwerkbeleid van kracht is voor die pod.
  • Als een of meer netwerkbeleidsregels van kracht zijn voor een pod van het type inkomend verkeer, is alleen dat inkomend verkeer toegestaan ​​dat expliciet is toegestaan ​​door dat beleid.
  • Wanneer een of meer netwerkbeleidsregels van toepassing zijn op een pod van het type uitgaand verkeer, is alleen het uitgaand verkeer dat door dat beleid is toegestaan, toegestaan.

De standaardinstelling voor andere eindpunttypen (VM's, hostinterfaces) is het blokkeren van verkeer. Alleen verkeer dat specifiek is toegestaan ​​door het netwerkbeleid is toegestaan, zelfs als er geen netwerkbeleid van toepassing is op het eindpunt.

Best Practice: Beleid voor impliciet standaard weigeren

U moet een impliciet standaardbeleid voor weigeren configureren dat is gemaakt voor uw Kubernetes-pods. Dit zorgt ervoor dat ongewenst verkeer automatisch wordt geblokkeerd. Houd er rekening mee dat impliciete standaardontkenningen altijd als laatste van kracht worden; als enig ander beleid het verkeer toestaat, is de weigering niet van toepassing. De weigering wordt pas doorgevoerd nadat al het andere beleid is overwogen.

Hoe maak je een standaardbeleid voor weigering voor Kubernetes-pods?

We raden aan om het wereldwijde netwerkbeleid te gebruiken, zelfs als een van de volgende regels kan worden gebruikt om een ​​standaardbeleid voor weigeringen voor Kubernetes-pods op te stellen. Er wordt een wereldwijd netwerkbeleid toegepast op alle workloads (VM's en containers) in alle naamruimten en hosts. Een wereldwijd netwerkbeleid moedigt een voorzichtige benadering van beveiliging aan terwijl bronnen worden beschermd.

• • Schakel standaard in om wereldwijd netwerkbeleid te weigeren, zonder naamruimte
  • Schakel standaard in om netwerkbeleid te weigeren, namespaced
  • Schakel standaard in om Kubernetes-beleid te weigeren, naamruimte

Wat is IP-blokkering?

Hiermee worden specifieke IP-CIDR-bereiken gekozen die zijn toegestaan ​​als inkomende bronnen of uitgaande bestemmingen. Gezien het feit dat Pod-IP's van voorbijgaande aard en onvoorspelbaar zijn, zouden dit cluster-externe IP's moeten zijn.

Het bron- of bestemmings-IP van pakketten moet vaak worden herschreven bij gebruik van methoden voor het in- en uitgaan van clusters. Afhankelijk van de specifieke netwerkplug-in (cloudserviceprovider, service-implementatie, enz.) die wordt gebruikt, kan het gedrag veranderen.

Dit geldt voor inkomend verkeer en het betekent dat u in sommige gevallen inkomende pakketten moet filteren die zijn gebaseerd op het daadwerkelijke bron-IP. Aan de andere kant kan het 'bron-IP' waarop de NetworkPolicy werkt, het IP-adres zijn van een LoadBalancer of zelfs het knooppunt van de Pod, enz.

Dit laat zien dat verbindingen tussen pods en service-IP's die worden herschreven naar cluster-externe IP's, kunnen worden onderworpen aan op ipBlock gebaseerde beperkingen in termen van uitgaand verkeer.

Wat zijn de standaardbeleidsregels?

Al het inkomend en uitgaand verkeer van en naar pods in een naamruimte is standaard toegestaan ​​als er geen besturingselementen voor die naamruimte zijn. U kunt het standaardgedrag van de naamruimte wijzigen door de volgende voorbeelden te gebruiken.

Standaard Alle binnenkomend verkeer weigeren

Wanneer u een netwerkbeleid maakt dat alle pods kiest, maar geen binnenkomend verkeer naar die pods opneemt, kunt u een 'standaard' isolatiebeleid voor binnenkomend verkeer maken en dat is voor een naamruimte.

Dit zorgt ervoor dat alle pods, ongeacht of een andere NetworkPolicy ze kiest, geïsoleerd zijn voor binnendringen. Deze regel is niet van toepassing op isolatie voor het verlaten van een pod.

Standaard Alle uitgaand verkeer weigeren

Wanneer u een NetworkPolicy maakt die alle pods kiest maar uitgaand verkeer van die pods verbiedt, kunt u een 'standaard' isolatiebeleid voor uitgaand verkeer maken en dat is ook voor een naamruimte.

Gevolgtrekking

Deze handleiding ging helemaal over het gebruik van DenyServiceExternalIPs. We hebben ook een schematische weergave ontworpen om onze gebruikers te laten begrijpen dat het werkt. We hebben ook voorbeeldconfiguraties geleverd.