06.05.2025
IPsec-VPN-Tunnel aus Kubernetes heraus sicher aufbauenStrongswan-VPN in Kubernetes: Externe Dienste sicher einbinden
In manchen Fällen benötigt es eine VPN-Anbindung zu einem externen Service - was mit Kubernetes tricky sein kann. In diesem Beitrag zeigen wir, wie man mit StrongSwan einen IPsec-Tunnel aus Kubernetes heraus zu einem externen Dienst aufbaut und dabei Nginx als Reverse-Proxy nutzt. Das Setup ist klar strukturiert, gut wartbar und unterscheidet dynamisch zwischen Staging und Production.
Inhaltsverzeichnis
1. Problemstellung
Manchmal steht eine wichtige Datenbank nicht im eigenen Cluster, sondern hinter einer Firewall auf einem externen Server. Der Zugriff erfolgt nur über ein VPN – zum Beispiel via IPSec mit einer WatchGuard-Appliance. Die Herausforderung: Wie erreichen Anwendungen im Cluster diesen Service zuverlässig und sicher?
2. Zielbild
Ziel war es, eine schlanke und wartbare Lösung zu schaffen, die:
- von innerhalb des Clusters auf fest definierte externe Services via VPN zugreifen kann,
- klar zwischen Staging- und Produktionszugängen unterscheidet,
- flexibel konfigurierbar bleibt,
- mit Kubernetes-Standards arbeitet (Probes, Services, ConfigMaps etc.).
3. Lösungsidee
Wir haben einen dedizierten Pod mit Strongswan und Nginx aufgesetzt:
- Strongswan übernimmt den Aufbau des IPSec-Tunnels zum externen VPN-Endpunkt.
- Nginx fungiert als TCP-Proxy und leitet Anfragen aus dem Cluster an den externen Service weiter.
- Je nach Umgebung (Staging oder Production) wird der Nginx entsprechend konfiguriert.
Innerhalb des Clusters können andere Services einfach via ClusterIP auf den Nginx zugreifen, der dann die Verbindung über das VPN übernimmt.
4. Umsetzung in Kubernetes
a) Dockerfile
Im Container laufen Nginx und Strongswan nebeneinander. Ein Startscript entscheidet je nach ENVIRONMENT-Variable, welche Konfigurationsdateien verwendet werden.
FROM nginx:1.27.3-alpine
RUN apk add --no-cache strongswan netcat-openbsd
...
CMD ["/scripts/startup.sh"]
b) Nginx-Konfiguration
Für Production gibt es eine einzige TCP-Weiterleitung (z. B. auf Port 8080), im Staging sind es zwei (8080 + 8081 für Prod/Staging).
stream {
upstream ext-db-production {
server NGINX_EXTDB_IP_PRODUCTION:NGINX_EXTDB_PORT_PRODUCTION;
}
server {
listen 8080;
proxy_pass ext-db-production;
}
...
}
Wir können auch Deine Kubernetes Apps per VPN verbinden.
c) VPN-Setup mit Strongswan
Der Tunnel wird über swanctl.conf und Umgebungsvariablen dynamisch konfiguriert. So können IP-Adressen, PSK und Subnetze per Helm Template eingespielt werden.
connections {
k8s-ext-db {
remote_addrs = SWANCTL_CONF_REMOTE_ADDRS
local {
auth = psk
id = SWANCTL_CONF_LOCAL_ID
}
remote {
auth = psk
}
children {
net-net {
local_ts = SWANCTL_CONF_LOCAL_TS
remote_ts = SWANCTL_CONF_REMOTE_TS
esp_proposals = SWANCTL_CONF_ESP_PROPOSALS
...
}
}
version = 2
proposals = SWANCTL_CONF_PROPOSALS
...
}
}
secrets {
ike-k8s-nors {
id-k8s = SWANCTL_CONF_LOCAL_ID
secret = SWANCTL_CONF_SECRET_PSK_TOKEN
}
}
Die großgeschriebenen Variablen in allen Config-Dateien werden vom Startup Script mit Werten aus den Umgebungsvariablen ersetzt. Dadurch kann der Pod für verschiedene Umgebungen dynamisch konfiguriert werden. Die Werte könnten natürlich auch direkt angegeben werden.
Das Startup Script führt dann nur noch folgende Commands aus um die VPN Verbindung aufzubauen:
swanctl --load-all
ipsec up k8s-ext-db
d) Health-Probes
Ein Shell-Skript prüft regelmäßig:
- ob die VPN-Ziel-IP erreichbar ist:
nc -z -w 1 $PROBE_STRONGSWAN_IP $PROBE_STRONGSWAN_PORT - ob der interne Nginx eine
/healthz-Route bedient:curl -f -LI $PROBE_NGINX_IP:$PROBE_NGINX_PORT/healthz
Nur wenn beide Bedingungen erfüllt sind, wird der Exit-Code 0 zurückgeben. Damit lassen sich die Pods gut in Kubernetes überwachen und restarten, falls etwas hängt.
5. Besonderheiten
- Der Pod benötigt die
NET_ADMIN-Capability, damit Strongswan Routing-Tables setzen darf. - Production und Staging unterscheiden sich nicht nur in den Zielsystemen, sondern auch in der Menge der angebundenen externen Dienste.
- Der gesamte Tunnel läuft in einem dedizierten Service – andere Pods im Cluster brauchen davon nichts zu wissen.
6. Pod Manifest
Hier ein Beispiel für das Pod-Manifest:
apiVersion: v1
kind: Pod
metadata:
name: vpn-client
namespace: vpn
spec:
containers:
- name: vpn
image: your-vpn-image:1.0.0
imagePullPolicy: Always
envFrom:
- configMapRef:
name: vpn-client-configmap
ports:
- containerPort: 8080
name: ext-db-prod
protocol: TCP
livenessProbe:
exec:
command:
- /scripts/probe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 2
readinessProbe:
exec:
command:
- /scripts/probe.sh
failureThreshold: 1
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 2
startupProbe:
exec:
command:
- /scripts/probe.sh
failureThreshold: 40
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 2
securityContext:
capabilities:
add:
- NET_ADMIN
7. Fazit
Die Kombination aus Strongswan und Nginx ist eine robuste, leichtgewichtige Möglichkeit, externe Dienste über VPN in Kubernetes anzubinden. Die strikte Trennung nach Umgebungen, flexible Helm-Templates und Kubernetes-Probes machen die Lösung production-ready – ohne Overhead durch zusätzliche Tools.
8. Häufige Fragen
1. Warum brauche ich ein VPN in Kubernetes?
Ein VPN ermöglicht sichere Verbindungen zwischen deinem Cluster und externen Systemen, etwa Datenbanken oder Legacy-Systemen, die nicht öffentlich erreichbar sind. Es ist besonders sinnvoll, wenn sensible Daten übertragen werden oder direkte IP-Kommunikation erforderlich ist.
2. Was ist StrongSwan und warum eignet es sich für Kubernetes?
StrongSwan ist eine etablierte Open-Source-VPN-Lösung für IPsec-basierte Tunnel. Sie ist leichtgewichtig, zuverlässig und lässt sich durch ihre Modularität gut in containerisierte Umgebungen wie Kubernetes integrieren.
3. Wie integriere ich StrongSwan in Kubernetes?
StrongSwan kann als dediziertes Deployment in einem Pod betrieben werden. Über eine angepasste Netzwerkkonfiguration und iptables-Routing wird der Traffic durch das VPN geleitet. NGINX oder andere Proxies übernehmen dabei das Routing zum Zielsystem über das VPN.
4. Gibt es Helm-Charts für StrongSwan in Kubernetes?
Nein, es gibt keine offiziellen Helm-Charts. Die meisten Setups nutzen eigene Deployments mit Docker-Images, Konfigurationsdateien und init-Skripten. Das kann zwar mühselig sein, ermöglicht aber maximale Flexibilität bei der VPN-Einrichtung.
5. Welche Alternativen zu StrongSwan gibt es?
Je nach Anforderungen kannst du auch WireGuard (modern, schnell), OpenVPN (bewährt, aber komplexer) oder VPN-Services von Cloud-Anbietern wie AWS Site-to-Site VPN oder Azure VPN Gateway einsetzen.
Hast du noch Fragen oder eine Meinung? Mit deinem GitHub Account kannst Du es uns wissen lassen...
Hier sind ein paar Artikel, die du auch interessant finden könntest:
Kubernetes Backup in Storage Buckets
Wir nutzen neben Kubernetes auch Cloud Storage, Cloud SQL und GitHub Actions, um unsere Anwendungen effizient zu betreiben – und zu sichern. In diesem Artikel zeigen wir dir, wie du eine zuverlässige Kubernetes Backup Strategie umsetzt, um Datenbanken, Medien und Code vor Verlust zu schützen.
Gefyra Roadmap 2025
Gefyra plant Großes für 2025! Von verbesserten Developer-Tools über neue Integrationen bis hin zu mehr Performance – die Roadmap verspricht spannende Neuerungen. In diesem Blogpost werfen wir einen Blick auf die kommenden Features und zeigen, wie Gefyra die Entwicklung und das Debugging in Kubernetes weiter revolutionieren will. Bleib dran für einen Ausblick auf das nächste Kapitel!
Kostenoptimierung eines Azure Kubernetes Clusters
Cloud-Ressourcen sind mächtig und praktisch, aber teuer – besonders Kubernetes-Cluster. In diesem Blogpost zeigen wir, wie wir in einem Bestandsprojekt die Azure Kubernetes Service Kostenoptimierung erfolgreich umgesetzt haben. Dabei stellen wir Strategien, Tools und Best Practices vor, die geholfen haben, AKS Kosten zu reduzieren, ohne die Performance zu beeinträchtigen.
Elasticsearch: Die leistungsstarke Suchlösung für deine Daten.
Elasticsearch ist eine Open-Source-Such- und Analyse-Engine, die auf Apache Lucene basiert. Sie ermöglicht es, große Mengen an Daten in Echtzeit zu durchsuchen und zu analysieren. In diesem Artikel werfen wir einen genaueren Blick auf Elasticsearch, erkunden seine wichtigsten Funktionen und zeigen dir anhand von Praxisbeispielen, wie du Elasticsearch in dein Projekt integrieren kannst.
Effiziente Betriebszeiten mit KEDA: Dynamisches Autoscaling für Kubernetes-Cluster
Kubernetes ist leistungsstark, doch ohne optimierte Betriebszeiten können unnötige Ressourcen und Kosten entstehen. KEDA (Kubernetes Event - Driven Autoscaling) ermöglicht es, Workloads dynamisch zu skalieren und z.B. außerhalb definierter Betriebszeiten zu pausieren. In diesem Blogpost zeigen wir, wie du mit KEDA deinen Cluster an Arbeitszeiten anpasst – für mehr Effizienz und reduzierte Hosting-Kosten.
Kubernetes Skalierung in der Google Cloud
In diesem Artikel geht es um die Möglichkeit, Kubernetes Workloads in der Google Cloud einfach und nachhaltig zu skalieren.
Was unsere Kunden über uns sagen
- Ofa Bamberg GmbHB2B Online-Shop | B2C Website | Hosting | Betreuung | Security© Ofa Bamberg GmbH
- Ludwig-Maximilians-Universität MünchenPlattformentwicklung | Hosting | Betreuung | APIs | Website
Blueshoe hat unsere Forschungsdatenplattform Munich Media Monitoring (M3) entwickelt und uns hervorragend dabei beraten. Das Team hat unsere Anforderungen genau verstanden und sich aktiv in die Ausgestaltung der Software und der Betriebsumgebung eingebracht. Wir sind froh, dass auch Wartung und weiterführender Support in Blueshoes Händen liegen.
- Deutsches MuseumDigitalisierung | Beratung | Datenbank-Optimierung | GraphQL | CMSFoto: Anne Göttlicher
Im Rahmen eines komplexen Digitalisierungsprojekts für unsere Exponate-Datenbank war Blueshoe ein äußerst verlässlicher Partner. Sie haben uns nicht nur während des gesamten Projekts hervorragend beraten, sondern unsere Anforderungen perfekt umgesetzt. Dank ihrer Arbeit ist unsere Datenbank nun ein bedeutender Mehrwert für die weltweite wissenschaftliche Forschung.
- Fonds Finanz Maklerservice GmbHPlattformentwicklung | Prozess-Systeme | Hosting | Betreuung | Zertifikate | Website© Fonds Finanz Maklerservice GmbH
Blueshoe ist unsere verlängerte Werkbank für Entwicklung, Wartung und Support unserer Weiterbildungs- und Zertifizierungsplattformen. Das Team hat sich gründlich in unsere Abläufe eingearbeitet, und wir freuen uns, Blueshoe als zuverlässigen Partner an unserer Seite zu haben.
- Technische Universität HamburgPlattformentwicklung | Beratung | Prozess-Systeme | Hosting | Website
Seit 2019 unterstützt uns die Blueshoe GmbH tatkräftig bei der Entwicklung und Weiterentwicklung des "Digital Learning Lab" und der "Digital Learning Tools". Dank ihrer Beratung konnten wir von Anfang an auf eine zukunftssichere, moderne technische Struktur setzen. Die Zusammenarbeit ist reibungslos, und wir fühlen uns rundum gut betreut. Und davon profitieren dann auch die Lehrkräfte in Hamburg.
