Zum Hauptinhalt springen

Plattform-Härtung

Diese Seite beschreibt, wie die OpenShift-Plattform unter DuoKey gehärtet wird. Diese Kontrollen werden während der Installation konfiguriert und bei der Übergabe validiert.

Workload-Sicherheit: SCC & Pod Security​

  • Security Context Constraints (SCC) — DuoKey-Workloads laufen unter der SCC restricted-v2: nicht-root, keine Rechteausweitung, entfernte Linux-Capabilities und wo möglich ein schreibgeschütztes Root-Dateisystem.
  • Pod Security Admission (PSA) — Namespaces werden gelabelt, um den Pod-Security-Standard restricted durchzusetzen, wodurch privilegierte Pods bereits bei der Zulassung blockiert werden.
# Den restricted Pod Security Standard auf dem Namespace durchsetzen
apiVersion: v1
kind: Namespace
metadata:
  name: duokey
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Keine DuoKey-Komponente benötigt privileged, hostNetwork oder hostPath.

Verschlüsselung im Ruhezustand​

  • etcd-Verschlüsselung — aktivieren Sie die OpenShift-etcd-Verschlüsselung, sodass Kubernetes-Secrets und -Konfigurationen im Ruhezustand mit aescbc/aesgcm verschlüsselt werden.
  • Volume-Verschlüsselung — persistente Volumes werden über die clusterweite Verschlüsselung von ODF oder über LUKS auf der Speicherebene verschlüsselt.
  • Secrets — Anwendungs-Secrets werden niemals langfristig in etcd gespeichert; sie werden im Arbeitsspeicher aus Ihrem Secret-Manager injiziert (siehe Secret-Manager-Integration).
# etcd-Verschlüsselung aktivieren
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  encryption:
    type: aesgcm

Image-Sicherheit & Lieferkette​

  • Vertrauenswürdige Registry — Images werden aus Ihrer internen Registry (Quay / Mirror) gezogen. Für Air-Gapped-Standorte werden alle Images im Voraus gespiegelt.
  • Image-Signierung — Container-Images werden mit Sigstore/cosign signiert und verifiziert; die Admission-Richtlinie lehnt unsignierte Images ab.
  • Schwachstellen-Scanning — integrieren Sie Quay/Clair oder Ihren Scanner in die Pipeline; blockieren Sie die Bereitstellung von Images oberhalb Ihres CVE-Schwellenwerts.
  • Admission Control — nutzen Sie die Signaturverifizierung von OpenShift und optional eine Policy-Engine (Kyverno / OPA Gatekeeper) für organisatorische Leitplanken.

RBAC​

Der DuoKey- und Plattformzugriff folgt dem Prinzip der geringsten Rechte:

  • Workload-ServiceAccounts erhalten nur die Berechtigungen, die sie benötigen.
  • Menschlicher Zugriff wird über Ihren IdP vermittelt (siehe Identität & SSO) und auf zugeschnittene Cluster-Rollen abgebildet.
  • Kein dauerhaftes Cluster-Admin für den Routinebetrieb; privilegierte Aktionen nutzen Just-in-Time-, auditierte Rechteerhöhung.

FIPS-Modus (Verteidigung / reguliert)​

OpenShift kann in einem FIPS-140-2/3-validierten Kryptografiemodus betrieben werden. Wenn dieser zur Installationszeit aktiviert wird, verwendet der Cluster durchgängig FIPS-validierte Krypto-Module. Kombinieren Sie den FIPS-Modus für die Schlüssel-Vertrauensbasis mit DuoKey MPC und/oder einem Securosys-HSM (siehe Secret-Manager-Integration).

Knoten- & OS-Härtung​

  • Unveränderliches OS — Worker-/Control-Plane-Knoten laufen unter Red Hat CoreOS (RHCOS), einem unveränderlichen, containeroptimierten OS, das vom Machine Config Operator verwaltet wird.
  • Kein SSH-Drift — die Knotenkonfiguration ist deklarativ; Ad-hoc-Änderungen werden automatisch zurückgesetzt.
  • Benchmarks — wenden Sie den CIS-Kubernetes/OpenShift-Benchmark und, für den Verteidigungsbereich, DISA-STIG-Profile über den OpenShift Compliance Operator an.
# Einen CIS/STIG-Scan mit dem Compliance Operator ausführen
oc apply -f - <<'EOF'
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: cis-scan
  namespace: openshift-compliance
profiles:
  - name: ocp4-cis
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: default
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1
EOF

Audit-Logging​

  • Das Kubernetes-/OpenShift-API-Audit-Log zeichnet jede privilegierte Aktion auf.
  • Anwendungs- und Zugriffs-Logs werden an Ihr SIEM ausgeliefert.
  • Siehe Compliance & Audit für Aufbewahrung und SIEM-Integration.

Härtungs-Checkliste​

  • Workloads laufen unter restricted-v2-SCC, Namespace erzwingt restricted-PSA
  • etcd-Verschlüsselung aktiviert (aesgcm)
  • Persistente Volumes im Ruhezustand verschlüsselt
  • Images signiert (cosign) und aus einer vertrauenswürdigen/gespiegelten Registry gezogen
  • Default-Deny-NetworkPolicies vorhanden (siehe Netzwerksicherheit)
  • RBAC mit geringsten Rechten; kein dauerhaftes Cluster-Admin
  • FIPS-Modus aktiviert (falls erforderlich) + HSM-Vertrauensbasis
  • CIS/STIG-Scan besteht über den Compliance Operator
  • API-Audit-Logging an SIEM weitergeleitet