Kubernetes HSM Integration: Hardware Security Module fuer kryptographische Operationen

TL;DR

• Hardware Security Modules (HSM) schuetzen kryptographische Schluessel in manipulationssicherer Hardware -- der private Key verlaesst das HSM nie.
• Die Integration mit Kubernetes erfolgt ueber PKCS#11-Interfaces, KMS-Provider fuer etcd-Verschluesselung und cert-manager mit HSM-Backend.
• HashiCorp Vault nutzt HSM fuer Auto-Unseal, sodass der Master Key nie im Klartext auf einer Festplatte liegt.
• FIPS 140-2 Level 3 ist fuer regulierte Branchen (Finanzwesen, Gesundheitswesen, Behoerden) oft Pflicht und nur mit HSM erreichbar.
• HSM-Clustering mit mindestens zwei Modulen ist fuer Produktionsumgebungen Pflicht -- ein einzelnes HSM ist ein Single Point of Failure.

Was ist ein HSM und warum braucht Kubernetes eines?

Ein Hardware Security Module ist ein dediziertes Geraet, das kryptographische Schluessel generiert, speichert und fuer Operationen bereitstellt, ohne dass der Schluessel jemals die geschuetzte Hardware verlaesst. Im Gegensatz zu Software-basierten Loesungen bieten HSMs:

• Physischen Manipulationsschutz: Das Geraet zerstoert Schluessel bei physischem Angriff (Tamper Response)
• Zertifizierte Zufallszahlengenerierung: Hardware-basierte Entropiequelle statt /dev/urandom
• Nachweisbare Compliance: FIPS 140-2 oder Common Criteria Zertifizierung fuer Audits
• Schluesselisolation: Private Keys sind nicht extrahierbar, nur nutzbar

Kubernetes speichert Secrets standardmaessig Base64-kodiert in etcd. Selbst mit Encryption-at-Rest liegt der Encryption Key auf der Festplatte des API Servers. Fuer regulierte Umgebungen ist das nicht ausreichend. HSMs schliessen diese Luecke.

HSM-Anbieter im Vergleich

Fuer On-Premise-Kubernetes-Cluster in der DACH-Region sind Thales Luna und Utimaco die gaengigsten Optionen. Beide bieten PKCS#11-Interfaces und lassen sich ueber KMS-Provider in Kubernetes integrieren.

PKCS#11: Das Standard-Interface

PKCS#11 (Public Key Cryptography Standards #11) ist die Standardschnittstelle fuer die Kommunikation mit HSMs. Kubernetes-Komponenten delegieren kryptographische Operationen ueber dieses Interface an das HSM.

etcd-Verschluesselung mit HSM-backed KMS

Der Kubernetes KMS Provider Plugin v2 ermoeglicht die Anbindung eines HSM als Key Encryption Key (KEK) Quelle:

# EncryptionConfiguration fuer HSM-backed KMS
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - kms:
          apiVersion: v2
          name: hsm-kms-provider
          endpoint: unix:///var/run/hsm-kms/hsm-kms.sock
          timeout: 5s
      - identity: {}

Der KMS-Provider laeuft als DaemonSet auf den Control-Plane-Nodes und kommuniziert ueber PKCS#11 mit dem HSM:

# KMS Provider DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: hsm-kms-provider
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: hsm-kms-provider
  template:
    metadata:
      labels:
        app: hsm-kms-provider
    spec:
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          effect: NoSchedule
      containers:
        - name: kms-provider
          image: registry.internal/hsm-kms-provider:v2.1.0
          volumeMounts:
            - name: hsm-socket
              mountPath: /var/run/hsm-kms
            - name: pkcs11-lib
              mountPath: /usr/lib/pkcs11
              readOnly: true
          env:
            - name: PKCS11_MODULE
              value: /usr/lib/pkcs11/libCryptoki2_64.so
            - name: HSM_SLOT
              value: "0"
            - name: HSM_KEY_LABEL
              value: k8s-kms-kek-2026
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
      volumes:
        - name: hsm-socket
          hostPath:
            path: /var/run/hsm-kms
            type: DirectoryOrCreate
        - name: pkcs11-lib
          hostPath:
            path: /usr/lib/pkcs11
            type: Directory

Weitergehende Strategien zur Verschluesselung in Kubernetes behandelt unser Artikel zu Encryption Strategies.

cert-manager mit HSM-Backend

Der cert-manager kann so konfiguriert werden, dass private Schluessel im HSM generiert und gespeichert werden. Das ist besonders relevant fuer TLS-Zertifikate, bei denen der private Key nie auf einer Festplatte landen soll.

HSM als CA-Backend

Die Certificate Authority verwendet einen HSM-gespeicherten Key. Alle ausgestellten Zertifikate werden mit diesem Key signiert:

# cert-manager ClusterIssuer mit HSM-backed CA
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: hsm-ca-issuer
spec:
  ca:
    secretName: hsm-ca-keypair

Der private Key im Secret hsm-ca-keypair wird ueber einen External Secrets Operator mit HSM-Backend bereitgestellt. Der Key selbst ist dabei ein HSM-Handle, nicht der tatsaechliche Schluessel.

PKCS#11-Signer fuer cert-manager

# cert-manager mit PKCS#11 Signer installieren
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true \
  --set extraArgs='{--controllers=*\,pkcs11}' \
  --set volumes[0].name=pkcs11-lib \
  --set volumes[0].hostPath.path=/usr/lib/pkcs11 \
  --set volumeMounts[0].name=pkcs11-lib \
  --set volumeMounts[0].mountPath=/usr/lib/pkcs11 \
  --set volumeMounts[0].readOnly=true

Fuer ein umfassendes Verstaendnis der Zertifikatsverwaltung in Kubernetes lesen Sie unseren PKI- und Certificate-Management-Artikel.

HashiCorp Vault HSM Auto-Unseal

Vault speichert seinen Master Key verschluesselt. Beim Start muss dieser Key entschluesselt werden (Unseal). Ohne HSM erfordert das manuelle Eingabe von Unseal-Keys durch mehrere Personen (Shamir's Secret Sharing). Mit HSM Auto-Unseal uebernimmt das HSM diesen Schritt automatisch.

Vault-Konfiguration fuer HSM Auto-Unseal

# Vault Helm Values fuer HSM Auto-Unseal
server:
  extraEnvironmentVars:
    VAULT_HSM_LIB: /usr/lib/pkcs11/libCryptoki2_64.so
    VAULT_HSM_SLOT: "0"
    VAULT_HSM_KEY_LABEL: vault-auto-unseal
    VAULT_HSM_GENERATE_KEY: "true"
  ha:
    enabled: true
    replicas: 3
    raft:
      enabled: true
  extraVolumes:
    - type: hostPath
      name: pkcs11-lib
      path: /usr/lib/pkcs11
      readOnly: true

# vault.hcl Konfiguration (Auszug)
# seal "pkcs11" {
#   lib            = "/usr/lib/pkcs11/libCryptoki2_64.so"
#   slot           = "0"
#   key_label      = "vault-auto-unseal"
#   mechanism      = "0x1085"
#   hmac_mechanism = "0x0251"
#   generate_key   = "true"
# }

Der Vorteil: Vault startet automatisch in den unsealed State, ohne dass Operatoren Unseal-Keys eingeben muessen. Die Sicherheit bleibt gewaehrleistet, weil der Master Key nur im HSM entschluesselt werden kann.

Fuer eine ausfuehrliche Vault-Integration lesen Sie unseren Secrets Management mit Vault Artikel.

FIPS 140-2 Level 3 Compliance

FIPS 140-2 definiert vier Sicherheitslevel fuer kryptographische Module:

Fuer die meisten regulierten Umgebungen ist Level 3 die Mindestanforderung. Das bedeutet:

• Alle kryptographischen Schluessel muessen in einem FIPS 140-2 Level 3 zertifizierten Modul generiert und gespeichert werden
• Die kryptographischen Bibliotheken auf den Nodes muessen FIPS-validiert sein (z.B. OpenSSL FIPS Provider)
• etcd-Verschluesselung muss FIPS-konforme Algorithmen verwenden (AES-256, SHA-256)

# FIPS-Modus auf RHEL-basierten Nodes aktivieren
fips-mode-setup --enable

# Neustart erforderlich
reboot

# Pruefen ob FIPS aktiv ist
fips-mode-setup --check
# Erwartet: FIPS mode is enabled.

# OpenSSL FIPS-Provider verifizieren
openssl list -providers

Secure Boot und TPM-Attestation

HSMs schuetzen Schluessel, aber die Integritaet der Nodes selbst muss ebenfalls gewaehrleistet sein. TPM-basierte Attestation stellt sicher, dass nur vertrauenswuerdige Nodes auf das HSM zugreifen koennen. Unser Artikel zu TPM Attestation behandelt dieses Thema im Detail.

# Node-Attestation vor HSM-Zugriff
apiVersion: v1
kind: ConfigMap
metadata:
  name: hsm-access-policy
  namespace: kube-system
data:
  policy.yaml: |
    attestation:
      required: true
      pcr_policy:
        - pcr: 0
          description: "UEFI Firmware"
        - pcr: 7
          description: "Secure Boot State"
        - pcr: 14
          description: "shim/MOK"
    allowed_nodes:
      - fingerprint: "sha256:abc123..."
        name: "control-plane-01"
      - fingerprint: "sha256:def456..."
        name: "control-plane-02"

Performance und Latenz

HSM-Operationen sind langsamer als Software-Kryptographie. Die Latenz haengt von der Operation, dem HSM-Modell und der Netzwerkanbindung ab:

Performance-Optimierung

# HSM Connection Pool Konfiguration
apiVersion: v1
kind: ConfigMap
metadata:
  name: hsm-pool-config
  namespace: kube-system
data:
  pool.yaml: |
    connection_pool:
      min_idle: 5
      max_active: 20
      max_idle: 10
      max_wait_ms: 3000
    caching:
      dek_cache_enabled: true
      dek_cache_ttl_seconds: 300
      dek_cache_max_size: 1000
    retry:
      max_attempts: 3
      backoff_ms: 100

Wichtige Optimierungen:

• DEK-Caching: Data Encryption Keys im Arbeitsspeicher cachen; nur die KEK-Operation geht ans HSM
• Connection Pooling: PKCS#11-Sessions wiederverwenden statt fuer jede Operation neu zu oeffnen
• Lokales HSM bevorzugen: Ein HSM im selben Rack reduziert die Latenz gegenueber Network-HSMs erheblich
• Batch-Operationen: Mehrere kryptographische Operationen in einer Session buendeln

HSM-Clustering fuer Hochverfuegbarkeit

Ein einzelnes HSM ist ein Single Point of Failure. Fuer Produktions-Cluster muessen mindestens zwei HSMs im HA-Modus betrieben werden:

# Thales Luna HSM HA-Group einrichten
lunacm> hagroup createGroup -label k8s-ha-group

# Erstes HSM hinzufuegen
lunacm> hagroup addMember -group k8s-ha-group \
  -serial 123456 -password "partition-password"

# Zweites HSM hinzufuegen
lunacm> hagroup addMember -group k8s-ha-group \
  -serial 789012 -password "partition-password"

# HA-Status pruefen
lunacm> hagroup listGroups

Das HSM-Cluster synchronisiert Schluessel automatisch. Bei Ausfall eines Moduls uebernimmt das verbleibende HSM transparent. Der PKCS#11-Client verbindet sich mit dem HA-Group-Slot.

Haeufige Fehler bei der HSM-Integration

PKCS#11 Library-Pfad falsch. Jeder HSM-Anbieter liefert seine eigene Library. Der Pfad muss exakt stimmen und die Library muss fuer die richtige Plattform (x86_64, aarch64) kompiliert sein.

HSM-Partition nicht initialisiert. Vor der ersten Nutzung muss eine Partition erstellt und mit einem Crypto Officer Password initialisiert werden. Ohne diesen Schritt schlagen alle Aufrufe fehl.

Firewall blockiert HSM-Traffic. Network-HSMs kommunizieren ueber spezifische Ports (Thales Luna: TCP 1792). Diese muessen in Network Policies und Host-Firewalls freigeschaltet sein.

Session-Limits erreicht. HSMs haben begrenzte gleichzeitige Sessions. Ohne Connection Pooling koennen Kubernetes-Cluster mit vielen Nodes diese Limits schnell ausschoepfen.

Kein HSM-Monitoring. HSM-Ausfaelle bemerkt man erst, wenn kryptographische Operationen fehlschlagen. Proaktives Monitoring per SNMP oder REST-API ist Pflicht.

Sie planen die Integration eines Hardware Security Modules in Ihre Kubernetes-Infrastruktur und benoetigen Beratung zu Architektur, HSM-Auswahl oder FIPS-Compliance? Kontaktieren Sie uns fuer ein unverbindliches Gespraech.