Zero Trust Security, vom Buzzword zur Implementierung

Mehr als ein Buzzword

Zero Trust ist in den letzten Jahren zu einem der meiststrapazierten Begriffe in der IT-Security geworden. Jeder Hersteller behauptet, eine Zero-Trust-Lösung zu verkaufen. Dabei ist Zero Trust kein Produkt, es ist ein Architekturprinzip. Und wie bei den meisten Architekturprinzipien liegt die Herausforderung nicht in der Theorie, sondern in der praktischen Umsetzung.

Das Grundprinzip

“Never trust, always verify”, dieser Satz fasst Zero Trust zusammen. In einer klassischen Netzwerkarchitektur gilt alles innerhalb der Firewall als vertrauenswürdig. Zero Trust verwirft dieses Modell. Jede Anfrage wird authentifiziert und autorisiert, unabhängig davon, woher sie kommt.

Für Microservice-Architekturen in Kubernetes bedeutet das konkret:

• Service-zu-Service-Kommunikation muss authentifiziert sein
• Jeder API-Aufruf muss ein gültiges Token tragen
• Netzwerkzugriff wird auf das Minimum beschränkt
• Secrets dürfen nicht in Konfigurationsdateien stehen
• Jeder Zugriff wird protokolliert und auditiert

mTLS, Mutual TLS zwischen Services

In einer Microservice-Architektur kommunizieren Services untereinander über das Netzwerk. Ohne Absicherung kann jeder Pod im Cluster jeden anderen Pod erreichen. mTLS stellt sicher, dass sich beide Seiten einer Verbindung gegenseitig authentifizieren.

Implementierung mit Istio Service Mesh

Istio injiziert einen Envoy Sidecar-Proxy in jeden Pod. Dieser Proxy übernimmt die mTLS-Terminierung transparent, die Anwendung selbst muss nicht angepasst werden.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: vop-system
spec:
  mtls:
    mode: STRICT

Mit mode: STRICT werden alle unverschlüsselten Verbindungen innerhalb des Namespaces abgelehnt. Das ist die Baseline für Zero Trust auf Netzwerkebene.

Zertifikatsverwaltung

Istio übernimmt die Zertifikatsrotation automatisch. Zertifikate haben eine Lebensdauer von 24 Stunden und werden vor Ablauf erneuert. Kein Service muss Zertifikate manuell verwalten. Das entfernt eine häufige Fehlerquelle, abgelaufene Zertifikate sind eine der Top-Ursachen für Produktionsausfälle.

OIDC/OAuth2 für jeden Request

mTLS sichert die Transportschicht. Aber wer darf welche API aufrufen? Dafür brauchen wir Identity-Token. Wir setzen auf OIDC (OpenID Connect) mit einem zentralen Identity Provider (Keycloak).

Token-Validierung

Jeder Service validiert das JWT-Token im Authorization-Header:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(jwt -> jwt
                    .jwtAuthenticationConverter(customJwtConverter())
                )
            )
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/actuator/health").permitAll()
                .requestMatchers("/api/v1/**").hasAuthority("SCOPE_vop:read")
                .anyRequest().authenticated()
            )
            .build();
    }
}

Kritisch dabei: Die Token-Validierung erfolgt lokal gegen den Public Key des Identity Providers, kein Netzwerk-Roundtrip pro Request. Der JWKS-Endpoint wird gecacht und periodisch aktualisiert.

Service-to-Service Token

Für die interne Kommunikation nutzen Services den OAuth2 Client Credentials Flow. Jeder Service hat eine eigene Client-ID und ein Secret (aus Vault bezogen). Die Tokens enthalten Scopes, die den Zugriff auf spezifische Ressourcen einschränken.

Service	Client-ID	Erlaubte Scopes
VoP Gateway	vop-gateway	vop:read, vop:write
Name Matcher	vop-matcher	vop:read
Audit Service	vop-audit	vop:audit, vop:read

Kubernetes Network Policies

Network Policies sind die Firewall-Regeln auf Pod-Ebene. Ohne Network Policies kann jeder Pod im Cluster jeden anderen Pod erreichen. Das widerspricht dem Zero-Trust-Prinzip fundamental.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vop-matcher-policy
  namespace: vop-system
spec:
  podSelector:
    matchLabels:
      app: vop-matcher
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: vop-gateway
      ports:
        - port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: vop-database
      ports:
        - port: 5432

Diese Policy stellt sicher, dass der Name Matcher nur vom Gateway angesprochen werden kann und nur die Datenbank erreichen darf. Jeder andere Netzwerkverkehr wird blockiert.

Defense in Depth

Network Policies, mTLS und OIDC sind komplementäre Schichten:

Schicht	Schutzmechanismus	Was es absichert
Netzwerk	Network Policies	Welche Pods kommunizieren dürfen
Transport	mTLS	Verschlüsselung und Service-Identität
Anwendung	OIDC/JWT	Berechtigung für spezifische Operationen
Daten	Vault + Encryption	Secrets und sensible Daten

HashiCorp Vault für Secrets

Secrets in Kubernetes ConfigMaps oder Environment-Variablen zu speichern ist ein verbreitetes Anti-Pattern. ConfigMaps sind Base64-kodiert, nicht verschlüsselt. Jeder mit RBAC-Leserechten auf den Namespace sieht die Werte.

Vault löst dieses Problem:

• Dynamic Secrets, Datenbank-Credentials werden on-demand erzeugt und haben eine begrenzte Lebensdauer
• Secret Rotation, Automatische Rotation ohne Service-Restart
• Audit Logging, Jeder Zugriff auf ein Secret wird protokolliert
• Kubernetes Auth, Services authentifizieren sich bei Vault über ihren Kubernetes Service Account

Vault Agent Sidecar

Der Vault Agent läuft als Sidecar im Pod, bezieht Secrets aus Vault und stellt sie der Anwendung als Datei oder Environment-Variable bereit. Die Anwendung selbst kennt Vault nicht, sie liest ihre Konfiguration wie gewohnt.

Kong API Gateway als Enforcement Point

Am Eintrittspunkt des Systems sitzt Kong als API Gateway. Kong übernimmt zentrale Sicherheitsfunktionen:

• Rate Limiting, Schutz vor Brute-Force und DoS
• OIDC Plugin, Token-Validierung am Eingang
• Request Transformation, Sensitive Header entfernen, bevor Requests an Backend-Services weitergeleitet werden
• Logging, Zentralisiertes Access Logging für Audit-Zwecke

Kong ist der einzige öffentlich erreichbare Service. Alle Backend-Services sind ausschließlich über Kong erreichbar, das reduziert die Angriffsfläche erheblich.

Fazit

Zero Trust ist kein einzelnes Produkt, das man kauft und installiert. Es ist eine Architekturentscheidung, die sich durch alle Schichten zieht, vom Netzwerk über den Transport bis zur Anwendungslogik. Die Implementierung erfordert Aufwand, aber in regulierten Umgebungen und bei sicherheitskritischen Systemen gibt es dazu keine Alternative. Die hier beschriebenen Bausteine, mTLS, OIDC, Network Policies, Vault und Kong, bilden zusammen ein konsistentes Sicherheitsmodell, das über reine Perimeter-Sicherheit hinausgeht.