Kubernetes Bastion Hosts: Sichere Zugriffskontrolle fuer isolierte Cluster

TL;DR

• Bastion Hosts reduzieren die Angriffsflaeche auf einen einzigen, gehaerteten Einstiegspunkt fuer private Kubernetes-Cluster.
• SSH-Tunneling und kubectl-Proxy ermoeglichten sicheren API-Server-Zugriff ohne oeffentliche Endpunkte.
• RBAC am Bastion Host und im Cluster zusammen bilden eine zweistufige Zugriffskontrolle.
• Audit-Logging auf Bastion- und Cluster-Ebene macht jeden Zugriff lueckenlos nachvollziehbar.
• Teleport und HashiCorp Boundary ersetzen klassische Bastion Hosts durch Identity-aware Proxies mit Session-Recording.

Warum isolierte Cluster einen Bastion Host brauchen

Ein Kubernetes-API-Server mit oeffentlicher IP ist ein Dauerziel fuer automatisierte Angriffe. Credential-Stuffing, Brute-Force und die Ausnutzung von API-Server-CVEs treffen jeden exponierten Endpunkt. Die Loesung: Der API-Server bekommt ausschliesslich eine private IP. Zugriff laeuft ueber einen Bastion Host -- einen gehaerteten Jump-Server, der als einziger Einstiegspunkt dient.

Dieses Modell ist seit Jahrzehnten Standard in der Netzwerksicherheit. Fuer Kubernetes-Cluster bringt es spezifische Vorteile:

• Minimale Angriffsflaeche: Nur ein Port (SSH) auf einer Maschine ist exponiert.
• Zentrales Logging: Alle Zugriffe laufen ueber einen Punkt und sind auditierbar.
• Netzwerk-Segmentierung: Control Plane und Worker Nodes bleiben vollstaendig isoliert.
• Compliance: Regulatorische Anforderungen (BSI, ISO 27001) fordern kontrollierte Zugangspunkte.

Fuer eine umfassende Haertung des Clusters selbst empfiehlt sich ergaenzend der Guide zu Kubernetes Security Hardening.

Referenzarchitektur: Drei Netzwerkzonen

Die Architektur teilt die Infrastruktur in drei Zonen:

Der Datenfluss: Admin verbindet sich per SSH zum Bastion Host, baut einen Tunnel zu Port 6443 auf und nutzt kubectl lokal gegen localhost:6443. Alternativ laeuft kubectl direkt auf dem Bastion Host.

SSH-Tunneling: kubectl ueber den Bastion Host

Der SSH-Tunnel ist die einfachste Methode, um kubectl lokal zu nutzen, waehrend der API-Server privat bleibt.

# SSH-Tunnel im Hintergrund aufbauen
ssh -f -N -L 6443:10.0.1.100:6443 admin@bastion.example.com

# kubectl nutzt den Tunnel
export KUBECONFIG=~/.kube/config-production
kubectl get nodes

Die Kubeconfig muss den Server-Eintrag auf https://localhost:6443 setzen. Das Cluster-CA-Zertifikat bleibt unveraendert.

Fuer Teams mit mehreren Clustern bietet sich eine SSH-Config pro Cluster an:

# ~/.ssh/config
Host bastion-prod
    HostName bastion.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519
    LocalForward 6443 10.0.1.100:6443
    ServerAliveInterval 60

Host bastion-staging
    HostName bastion-staging.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519
    LocalForward 16443 10.0.2.100:6443
    ServerAliveInterval 60

Ein ssh bastion-prod genuegt und der Tunnel steht.

kubectl-Proxy als Alternative zum SSH-Tunnel

Statt eines SSH-Tunnels kann kubectl selbst als Proxy fungieren. Das ist nuetzlich, wenn der Bastion Host kubectl installiert hat und ein Reverse-Proxy die Verbindung zum Admin weiterleitet.

# Auf dem Bastion Host
kubectl proxy --port=8080 --accept-hosts='.*' --address='0.0.0.0'

Der Admin greift dann ueber den Bastion Host auf den Proxy zu. Allerdings hat kubectl proxy Einschraenkungen: Es unterstuetzt nur HTTP, kein WebSocket (kein kubectl exec). Fuer interaktive Befehle bleibt der SSH-Tunnel die bessere Wahl.

Eine sicherere Variante ist kubectl proxy mit eingeschraenktem Zugriff:

# Nur bestimmte API-Pfade freigeben
kubectl proxy --port=8080 \
  --accept-paths='^/api/v1/namespaces/production' \
  --reject-methods='DELETE,PUT'

RBAC: Zweistufige Zugriffskontrolle

Ein Bastion Host allein reicht nicht. Die Zugriffsrechte muessen auf zwei Ebenen kontrolliert werden:

Ebene 1 -- Bastion Host: Wer darf sich ueberhaupt verbinden? SSH-Keys, MFA und IP-Whitelisting steuern den Zugang.

Ebene 2 -- Kubernetes RBAC: Was darf der Benutzer im Cluster tun? ClusterRoles und RoleBindings steuern die Berechtigungen.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: bastion-readonly
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "nodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bastion-readonly-binding
subjects:
  - kind: User
    name: bastion-admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: bastion-readonly
  apiGroup: rbac.authorization.k8s.io

Fuer eine detaillierte RBAC-Konfiguration mit Namespace-Isolation und Least-Privilege-Prinzip: RBAC fuer Enterprise-Umgebungen.

Bastion Host haerten: SSH und MFA

Die SSH-Konfiguration ist das Fundament der Bastion-Host-Sicherheit:

# /etc/ssh/sshd_config.d/hardening.conf
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowAgentForwarding yes
X11Forwarding no
AllowTcpForwarding yes
PermitTunnel yes

Dazu kommt MFA per TOTP (Google Authenticator) oder FIDO2:

# TOTP einrichten
apt install libpam-google-authenticator
google-authenticator

# PAM-Konfiguration
# /etc/pam.d/sshd -- Zeile hinzufuegen:
auth required pam_google_authenticator.so

Weitere Security-Massnahmen:

• fail2ban: Automatisches Sperren nach fehlgeschlagenen Login-Versuchen
• Unattended-Upgrades: Automatische Sicherheits-Patches
• Minimales OS: Keine unnoetige Software installieren
• IMDSv2 erzwingen: Bei AWS verhindert das SSRF-basierte Credential-Diebstaehle

Audit-Logging: Lueckenlose Nachverfolgung

Die Kombination aus Bastion-Host-Logs und Kubernetes-Audit-Logs ergibt eine vollstaendige Zugriffskette.

Bastion-Host-Logging mit auditd

# /etc/audit/rules.d/bastion.rules
- w /usr/local/bin/kubectl -p x -k kubectl_exec
- w /usr/local/bin/helm -p x -k helm_exec
- a always,exit -F arch=b64 -S execve -k command_exec
- w /etc/ssh/sshd_config -p wa -k ssh_config_change

Kubernetes Audit Policy

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    users: ["bastion-admin"]
    resources:
      - group: ""
        resources: ["pods", "secrets", "configmaps"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods/exec", "pods/portforward"]

Fuer eine vollstaendige Security-Audit-Strategie: Kubernetes Security Audit.

Teleport als Identity-Aware Alternative

HashiCorp Boundary und Gravitational Teleport ersetzen den klassischen Bastion Host durch Identity-aware Proxies. Teleport ist im Kubernetes-Umfeld besonders verbreitet.

Vorteile gegenueber klassischen Bastion Hosts:

• Session-Recording: Jede kubectl-Session wird aufgezeichnet und kann spaeter abgespielt werden.
• Certificate-based Auth: Kurzlebige Zertifikate statt langlebiger SSH-Keys.
• SSO-Integration: SAML/OIDC-Anbindung an bestehende Identity Provider.
• Audit-Log: Strukturierte Logs mit voller API-Request-Sichtbarkeit.
• RBAC-Integration: Teleport-Rollen mappen auf Kubernetes-RBAC.

# Teleport Agent auf dem Kubernetes-Cluster installieren
helm repo add teleport https://charts.releases.teleport.dev
helm install teleport-agent teleport/teleport-kube-agent \
  --namespace teleport \
  --create-namespace \
  --set proxyAddr=teleport.example.com:443 \
  --set kubeClusterName=production \
  --set authToken=CLUSTER_JOIN_TOKEN

Nach der Installation nutzen Admins tsh statt ssh:

# Login ueber SSO
tsh login --proxy=teleport.example.com

# Kubernetes-Cluster auflisten
tsh kube ls

# kubectl ueber Teleport nutzen
tsh kube login production
kubectl get pods -n production

Vergleich: Bastion Host vs. Teleport vs. Boundary

Hochverfuegbarkeit: Bastion-HA-Setup

Ein einzelner Bastion Host ist ein Single Point of Failure. Fuer Produktionsumgebungen empfehlen sich zwei Bastion Hosts in unterschiedlichen Availability Zones.

resource "aws_lb" "bastion" {
  name               = "bastion-nlb"
  internal           = false
  load_balancer_type = "network"
  subnets            = var.public_subnet_ids

  enable_cross_zone_load_balancing = true
}

resource "aws_lb_target_group" "bastion_ssh" {
  name     = "bastion-ssh"
  port     = 22
  protocol = "TCP"
  vpc_id   = var.vpc_id

  health_check {
    protocol = "TCP"
    port     = 22
  }
}

Beide Bastion Hosts werden identisch per Terraform und cloud-init konfiguriert. Ein Network Load Balancer verteilt den Traffic und nimmt ausgefallene Hosts automatisch aus der Rotation.

Haeufige Fehler vermeiden

Private Keys auf dem Bastion Host speichern. Stattdessen SSH Agent Forwarding nutzen. Der private Key bleibt lokal.

Zu breite Security Groups. Der Bastion Host braucht nur Zugriff auf Port 6443 (API-Server), nicht auf das gesamte private Netzwerk.

Keine automatischen Updates. Der Bastion Host ist die exponierte Komponente. Unattended-Upgrades oder regelmaessiger Rebuild per Terraform sind Pflicht.

Kein zweiter Faktor. SSH-Keys allein reichen nicht, wenn ein Laptop gestohlen wird. MFA per TOTP oder FIDO2 ist Standard.

Kein Monitoring. Ohne Alerting bei fehlgeschlagenen Logins bringt der Bastion Host wenig. Fail2ban und SIEM-Integration gehoeren dazu.

Integration mit Pod Security Standards

Der Bastion Host kontrolliert den Zugang zum Cluster. Innerhalb des Clusters schuetzen Pod Security Standards die Workloads. Beide Massnahmen ergaenzen sich:

• Der Bastion Host stellt sicher, dass nur autorisierte Personen kubectl ausfuehren koennen.
• Pod Security Standards stellen sicher, dass selbst autorisierte Benutzer keine unsicheren Pods deployen koennen.

Details zur Konfiguration: Pod Security Standards im Enterprise-Einsatz.

Disaster Recovery: Zugriff bei Bastion-Ausfall

Was passiert, wenn beide Bastion Hosts ausfallen? Ein Break-Glass-Verfahren ist notwendig:

1. Temporaerer VPN-Zugang: Ein vorkonfigurierter VPN-Endpunkt, der nur im Notfall aktiviert wird.
2. Cloud-Console-Zugriff: Bei AWS SSM Session Manager, bei GCP IAP Tunnel, bei Azure Bastion.
3. Dokumentierter Prozess: Wer darf den Notfall-Zugang aktivieren, unter welchen Bedingungen.

Fuer eine vollstaendige Disaster-Recovery-Strategie: Kubernetes Backup und Disaster Recovery.

Fazit und Empfehlungen

Bastion Hosts sind ein bewaehrtes Muster fuer die Absicherung privater Kubernetes-Cluster. Die Wahl zwischen klassischem SSH-Bastion, Teleport und Boundary haengt von Teamgroesse und Compliance-Anforderungen ab:

• Kleine Teams (bis 10 Admins): SSH Bastion Host mit MFA und auditd.
• Mittlere Teams (10-50 Admins): Teleport Community Edition mit SSO.
• Enterprise (50+ Admins): Teleport Enterprise oder Boundary mit Session-Recording und Compliance-Reporting.

Unabhaengig von der Wahl: RBAC, Audit-Logging und Hochverfuegbarkeit sind Pflicht. Fuer eine vollstaendige Security-Strategie empfiehlt sich die Kombination mit GitOps-basiertem Change Management via Flux, damit Cluster-Aenderungen nicht nur ueber den Bastion Host, sondern ausschliesslich ueber Git erfolgen.

Wenn Sie Unterstuetzung bei der Absicherung Ihrer Kubernetes-Cluster benoetigen -- von der Architekturplanung bis zur Implementierung -- melden Sie sich gerne fuer ein unverbindliches Gespraech unter /kontakt.