Skip to content

IP Whitelisting met Ingress-Nginx

IP whitelisting wordt gebruikt om de toegang tot applicaties te beperken tot een gespecificeerde set IP-adressen. Dit is een belangrijke beveiligingsmaatregel, met name voor applicaties die niet publiekelijk toegankelijk hoeven te zijn. In Kubernetes-omgevingen die gebruikmaken van de ingress-nginx controller, kan dit worden geconfigureerd via annotaties op de Ingress-resource.

De primaire annotatie die hiervoor wordt gebruikt is: nginx.ingress.kubernetes.io/whitelist-source-range

Deze annotatie accepteert een door komma's gescheiden lijst van CIDR-blokken (bijvoorbeeld 192.168.1.0/24, 10.0.0.5/32).

Configuratiemethoden

Afhankelijk van de projectstructuur en de gehanteerde deployment-strategie, kan IP whitelisting op verschillende manieren worden geconfigureerd:

1. Via templateValues.yml (Helm-gebaseerde deployments)

In projecten waar deployments worden beheerd met Helm en waarden worden getemplated via een templateValues.yml (of vergelijkbaar bestand), kan de whitelist-annotatie direct in de Ingress-definitie binnen de Helm-template worden opgenomen en aangestuurd door waarden uit templateValues.yml.

Voorbeeld templateValues.yml:

# templateValues.yml
ingress:
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/4, 192.168.1.56" # 10.0.0.0/4 is voor intern verkeer en vpn, 192.168.1.56 is een voorbeeld van een IP-adres dat toegang heeft tot de ingress (dit is een klasse C netwerk, let er op dat je in het echt geen klasse C netwerk maar een publiekelijk IP-adres gebruikt)
    # Andere annotaties...
  # Andere ingress configuratie...

De Helm-template voor de Ingress zou dan deze waarden gebruiken.

2. Via Kustomize Patches

In projecten die Kustomize gebruiken voor het beheren van Kubernetes-configuraties, wordt IP whitelisting vaak toegevoegd of aangepast via patches. Dit stelt teams in staat om basisconfiguraties te overschrijven voor specifieke omgevingen (bijv. acceptatie, productie) zonder de basismanifesten te wijzigen.

Voorbeeld Kustomize patch (kustomization.yaml en patch-bestand):

Stel, je hebt een basis Ingress-manifest. Om whitelisting toe te voegen voor een specifieke overlay (bijv. overlays/production):

development/projectnaam/ingress-whitelist-patch.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-application-ingress # Zorg dat dit overeenkomt met de naam van je Ingress resource
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/4, 192.168.1.56" # 10.0.0.0/4 is voor intern verkeer en vpn, 192.168.1.56 is een voorbeeld van een IP-adres dat toegang heeft tot de ingress (dit is een klasse C netwerk, let er op dat je in het echt geen klasse C netwerk maar een publiekelijk IP-adres gebruikt)

development/projectnaam/kustomization.yaml:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

# basis resources of helm charts

patches:
  - ingress-whitelist-patch.yaml

Belangrijke Overwegingen

  • Specificiteit: Wees zo specifiek mogelijk met je CIDR-blokken om onbedoelde toegang te voorkomen.
  • Onderhoud: Houd de lijst met gewhiteliste IP-adressen up-to-date. Verwijder IP's die niet langer toegang nodig hebben.
  • Testen: Test de whitelisting-configuratie grondig na implementatie om er zeker van te zijn dat deze correct functioneert en de toegang zoals verwacht beperkt.
  • Meerdere Lagen: Overweeg IP whitelisting als één laag in een verdedigingsstrategie, niet als de enige beveiligingsmaatregel.