Xylos brands

Hoe garandeer je een veilige toegang met Kubernetes Ingress Controllers?

In eerdere blogposts startten we een toepassing op in Azure Container Instances en Azure Kubernetes service. Maar we stonden niet stil bij de veiligheidsaspecten van de applicatie zoals:

  • Is AKS wel veilig? Zijn er publieke “endpoints” die we moeten beveiligen?
  • Wie heeft welke rechten in AKS (RBAC)?
  • Bevat de container geen zwakheden?
  • Moeten we onze containers scannen op virussen of malware?
  • Moeten we een firewall uitrollen en configureren?
  • Is het verkeer naar de toepassing beveiligd?

De laatste vraag is eenvoudig te beantwoorden: “Neen”. Om het verkeer naar de toepassing te beveiligen, moet je zelf actie ondernemen. Azure of Kubernetes zal dat niet voor jou doen. In deze blogpost zoomen we in op de laatste vraag.

1.Wat is Kubernetes service met Azure Load Balancer?

In eerdere blogposts lanceerden we twee containers met een webtoepassing. Vervolgens maakten we een service en publiceerden we deze service op het internet via een publieke Azure Load Balancer. Je netwerk engineers hoeven hiervoor niets te doen: AKS zal de Azure Load Balancer aanmaken en instellen zoals het hoort. Onderstaand diagram illustreert deze set-up:

We zien hier twee Kubernetes services voor twee applicaties A en B. De pods die je containers bevatten zijn verspreid over de drie nodes van de cluster. Beide services zijn van het LoadBalancer type. AKS maakt automatisch de Azure Load Balancer en één publiek IP-adres per service aan. De routing configuratie die het IP-adres van service A en B koppelt aan de pods van die service, werkt Kubernetes automatisch bij.

Deze configuratie is helemaal niet op de hoogte van je toepassing. Je kan op niveau van de load balancer of de service geen SSL-certificaat configureren. En dat heb je nu net nodig om het verkeer naar je toepassing te beveiligen.

Als je heel wat services hebt, zit je met een hele stapel IP-adressen die je moet beheren. Een systeem dat één IP-adres kan koppelen aan meerdere applicaties maakt het beheer eenvoudiger. In het Kubernetes-ecosysteem spreken we dan over een Ingress Controller.

2. Wat is een Ingress Controller?

Een Ingress Controller is niets meer dan een reverse proxy. Een reverse proxy is op de hoogte van de applicatie laag: laag 7. In dit geval is dat http. Onderstaand diagram maakt het duidelijk:

Het gaat hier om twee toepassingen, te bereiken via https://serviceA en https://serviceB (afgekorte URLs als voorbeeld). De Ingress Controller is op de hoogte van de applicatielaag en kan aanvragen doorverwijzen naar de interne Service A (analoog voor Service B). Service A en Service B hebben nu geen extern IP-adres. De Ingress Controller daarentegen heeft wel een extern IP-adres dat via een aparte service met type LoadBalancer aangemaakt wordt.

Kubernetes bevat geen standaard Ingress Controller. Die installeer je best zelf. De meest gebruikte Ingress Controller is vermoedelijk nginx-ingress. Al zijn er nog meer. Bij Xylos gebruiken we o.a. Voyager en traefik. Microsoft biedt HTTP application routing aan als AKS add-on om snel een Ingress Controller uit te rollen. Het is wel niet aangeraden om die in productie te gebruiken.

3. De configuratie van de Ingress Controller

Stel dat je nginx-ingress hebt uitgerold en je wil die Ingress Controller configureren. Hoe ga je te werk? Het antwoord is vrij eenvoudig: maak een ingress resource aan met een YAML-file:

Dit YAML-bestand configureert een geïnstalleerde nginx-ingress controller om aanvragen voor de webtoepassing op https://demo.xylos.com door te verwijzen naar twee Kubernetes services. De URL https://demo.xylos.com/ gaat naar service demo-app-client, https://demo.xylos.com/api gaat naar service demo-app-api. Uiteraard zal dit enkel werken als je in DNS demo.xylos.com vertaalt naar het IP-adres van de Ingress Controller.

4. Certificaat

Het YAML-bestand bevat een lijn met secretName: tls-secret. Die lijn verwijst naar een geïnstalleerd certificaat voor demo.xylos.com. Het verkeer naar de Ingress Controller wordt beveiligd met SSL en vervolgens getermineerd. Het verkeer van de Ingress Controller is intern en wordt niet beveiligd.

Je kan het certificaat manueel installeren als een Kubernetes secret. Als alternatief kan je Let’s Encrypt gebruikten om een of meerdere certificaten automatisch aan te maken. Je hebt dan wel nog wat extra software nodig die het certificaat kan aanvragen zoals certmanager. De Microsoft documentatie bevat een complete gids om dit te automatiseren met nginx-ingress en certmanager.

5. Conclusie

In deze laatste blogpost van de serie "In 6 stappen naar de cloud" bespraken we transportveiligheid met een Ingress Controller. We bespraken de basis zonder ons te bekommeren over andere veiligheidsaspecten zoals bijvoorbeeld web application firewalls (WAF) in combinatie met Kubernetes. Wil je daar meer over weten? Dan kan je altijd bij onze consultants terecht.

Deel dit blogbericht

Laat een antwoord achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd.

Breng jouw kennis en skills naar een hoger niveau

Schrijf nu in voor onze nieuwsbrief en krijg maandelijks:

  • Uitnodigingen voor Xylos' events & webinars
  • De laatste blogposts en cases
  • Nieuwste IT-trends