OpenShift-Implementierungen erfordern eine umfassende Sicherheitsstrategie, die bereits in der Planungsphase entwickelt und während der gesamten Lebensdauer des Clusters aufrechterhalten werden muss. Die Sicherheitsarchitektur umfasst multiple Ebenen von der Host-Sicherheit über Container-Isolation bis hin zu Anwendungsschutz und Compliance-Anforderungen.
Die integrierte Sicherheitsarchitektur von OpenShift bietet zahlreiche eingebaute Schutzmechanismen, erfordert jedoch bewusste Konfigurationsentscheidungen und organisatorische Richtlinien für optimale Wirksamkeit. Sicherheitsüberlegungen müssen sowohl technische Implementierungen als auch operative Verfahren umfassen.
OpenShift unterstützt verschiedene Authentifizierungsmechanismen, die es ermöglichen, bestehende Unternehmens-Identity-Systeme zu integrieren und gleichzeitig granulare Zugriffskontrolle zu implementieren. Die Auswahl und Konfiguration geeigneter Identity Provider bildet die Grundlage für alle weiteren Sicherheitsmaßnahmen.
Der built-in OAuth-Server fungiert als zentrale Authentifizierungskomponente und kann mit verschiedenen externen Identity Providern integriert werden. Der OAuth-Server stellt Tokens für authentifizierte Benutzer aus und verwaltet Session-Management für Web-Console und CLI-Zugriffe. Token haben standardmäßig eine Lebensdauer von 24 Stunden und können bei Bedarf widerrufen werden.
| Provider-Typ | Anwendungsbereich | Vorteile | Überlegungen |
|---|---|---|---|
| LDAP/Active Directory | Unternehmensumgebungen | Zentrale Benutzerverwaltung | Bind-Credentials sicher konfigurieren |
| OpenID Connect | Cloud-native Umgebungen | Standard-Protokolle, MFA-Support | Client-IDs und -Secrets schützen |
| X.509 Client Certificates | Automatisierte Systeme | Starke Authentifizierung | PKI-Infrastruktur erforderlich |
| HTPasswd | Entwicklung/Test | Einfach einzurichten | Nicht für Produktion empfohlen |
LDAP-Integration ermöglicht die Nutzung bestehender Active Directory- oder OpenLDAP-Systeme für Benutzerauthentifizierung. LDAP-Konfigurationen müssen Benutzer-DN-Pfade, Gruppen-Mappings und Verbindungssicherheit berücksichtigen. Bind-Credentials sollten mit minimalen Berechtigungen konfiguriert werden und regelmäßig rotiert werden.
OpenID Connect (OIDC) Provider wie Azure AD, Google Cloud Identity oder Keycloak können für moderne Authentifizierungsflows integriert werden. OIDC bietet standardisierte Protokolle für Single Sign-On und Multi-Factor Authentication, erfordert jedoch korrekte Konfiguration von Client-IDs und -Secrets.
Service Account-Management ist kritisch für automatisierte Prozesse und Anwendungen, die Cluster-APIs verwenden. Service Accounts sollten mit minimalen erforderlichen Berechtigungen konfiguriert werden und regelmäßig auf nicht mehr benötigte Accounts überprüft werden. Automatische Token-Mounting sollte deaktiviert werden, wenn Services keine Cluster-API-Zugriffe benötigen.
OpenShift implementiert granulare rollenbasierte Zugriffskontrolle, die es ermöglicht, Berechtigungen präzise nach dem Principle of Least Privilege zu vergeben. RBAC-Konfigurationen müssen sowohl funktionale Anforderungen erfüllen als auch Sicherheitsrichtlinien durchsetzen.
Cluster-Roles definieren clusterweite Berechtigungen für Operationen wie Node-Management, Namespace-Erstellung oder Security Policy-Administration. Cluster-Admin-Berechtigungen sollten nur an vertrauenswürdige Systemadministratoren vergeben werden und regelmäßig überprüft werden.
Standard-Cluster-Roles: -
cluster-admin: Vollzugriff auf alle Cluster-Ressourcen -
admin: Administrative Rechte innerhalb von Projekten -
edit: Lese-/Schreibzugriff auf die meisten
Projektressourcen - view: Nur-Lese-Zugriff auf
Projektressourcen - system:*: System-Rollen für interne
Komponenten
Project-Roles beschränken Berechtigungen auf spezifische Namespaces und ermöglichen delegierte Administration. Entwicklerteams können Admin-Berechtigungen für ihre Projekte erhalten, ohne clusterweite Zugriffe zu benötigen. Role-Vererbung und -Delegation müssen sorgfältig geplant werden.
Custom Roles ermöglichen die Definition anwendungsspezifischer Berechtigungssets, die genau auf organisatorische Anforderungen zugeschnitten sind. Group-basierte Rechtevergabe vereinfacht das Management von Berechtigungen für Teams und Organisationseinheiten. LDAP- oder OIDC-Gruppen können direkt in OpenShift-Roles gemappt werden, wodurch zentrale Benutzerverwaltung ermöglicht wird.
OpenShift bietet umfangreiche Mechanismen zur Kontrolle der Container-Ausführung und zur Durchsetzung von Sicherheitsrichtlinien auf Container-Ebene. Security Context Constraints (SCCs) definieren, unter welchen Bedingungen Container ausgeführt werden dürfen.
OpenShift liefert verschiedene vordefinierte SCCs für unterschiedliche Sicherheitsanforderungen:
| SCC-Name | Sicherheitslevel | Anwendungsbereich | Einschränkungen |
|---|---|---|---|
restricted |
Sehr hoch | Standard-Anwendungen | Keine privilegierten Container, feste User IDs |
anyuid |
Mittel | Legacy-Anwendungen | Beliebige User IDs, keine Host-Zugriffe |
nonroot |
Hoch | Spezielle Anwendungen | Keine Root-User, sonst wie restricted |
hostmount-anyuid |
Niedrig | System-Tools | Host-Volume-Mounts erlaubt |
privileged |
Sehr niedrig | Infrastruktur-Pods | Vollzugriff auf Host-System |
Default Security Context Constraints beschränken Container-Ausführung auf nicht-privilegierte Modi und verhindern den Zugriff auf Host-Ressourcen. Die “restricted” SCC stellt die sicherste Standard-Konfiguration dar und sollte für die meisten Anwendungen ausreichen.
Privilegierte Container erfordern spezielle SCCs und sollten nur in begründeten Ausnahmefällen verwendet werden. Privilegierte Container haben vollständigen Zugriff auf Host-Systeme und können Sicherheitsmaßnahmen umgehen. Jede privilegierte Container-Ausführung sollte dokumentiert und gerechtfertigt werden.
User ID-Ranges werden automatisch von OpenShift zugewiesen, um Container-Isolation zu gewährleisten. Random User IDs verhindern Privilege Escalation und Inter-Container-Zugriffe. Custom User IDs können für Legacy-Anwendungen erforderlich sein, schwächen jedoch die Sicherheitsposition.
Volume-Mounts unterliegen SCC-Beschränkungen, die bestimmen, welche Host-Pfade von Containern gemountet werden dürfen. Host-Pfad-Mounts sollten minimiert und auf spezifische erforderliche Verzeichnisse beschränkt werden.
SELinux-Labels werden automatisch zugewiesen und sorgen für zusätzliche Container-Isolation auf Kernel-Ebene. SELinux-Policies sollten nicht deaktiviert werden, da sie wichtige Defense-in-Depth-Mechanismen bereitstellen. In manchen Fällen können custom SELinux-Policies für spezielle Anwendungsanforderungen erforderlich sein.
Capabilities-Management ermöglicht die granulare Kontrolle über
Container-Berechtigungen. Gefährliche Capabilities wie
CAP_SYS_ADMIN, CAP_NET_ADMIN oder
CAP_SYS_PTRACE sollten nur nach sorgfältiger Prüfung
gewährt werden.
OpenShift bietet umfangreiche Netzwerk-Sicherheitsfunktionen, die über grundlegende Firewall-Regeln hinausgehen und mikro-segmentierte Container-Netzwerke ermöglichen. Network Policies definieren, welche Pods miteinander kommunizieren dürfen.
Default Network Policies sollten nach dem Deny-All-Prinzip konfiguriert werden, wobei nur explizit benötigte Kommunikationspfade zugelassen werden. Diese Strategie implementiert ein Zero-Trust-Netzwerk-Modell innerhalb des Clusters.
# Beispiel: Default-Deny Network Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
spec:
podSelector: {}
policyTypes:
- Ingress
- EgressNamespace-Isolation verhindert Inter-Namespace-Kommunikation und stellt eine wichtige Sicherheitsgrenze dar. Projekte verschiedener Teams oder Anwendungen sollten in separaten Namespaces betrieben werden, um laterale Bewegungen zu verhindern.
Ingress- und Egress-Regeln kontrollieren eingehenden und ausgehenden Netzwerkverkehr für Pods. Egress-Beschränkungen sind besonders wichtig, um Data Exfiltration und Command-and-Control-Kommunikation zu verhindern.
Port-basierte Filterung ermöglicht granulare Kontrolle über erlaubte Netzwerkprotokolle und -ports. Anwendungen sollten nur auf den minimalen erforderlichen Ports kommunizieren dürfen. Label-basierte Selektion macht Network Policies flexibel und wartbar, da Regeln automatisch auf Pods mit entsprechenden Labels angewendet werden.
OpenShift implementiert umfassende Verschlüsselung für Data-in-Transit und bietet Mechanismen für Data-at-Rest-Verschlüsselung. Zertifikatsverwaltung erfolgt weitgehend automatisch, erfordert jedoch Planung für custom Zertifikate und Certificate Authorities.
TLS-Verschlüsselung ist für alle interne Cluster-Kommunikation aktiviert und nutzt automatisch generierte Zertifikate. Diese Zertifikate werden regelmäßig rotiert und erfordern keine manuellen Eingriffe. Custom Certificate Authorities können für Integration in bestehende PKI-Infrastrukturen konfiguriert werden.
Interne Zertifikate: - API-Server-Kommunikation - etcd-Cluster-Kommunikation - Kubelet-zu-API-Server-Verbindungen - Service-zu-Service-Kommunikation
Route-Verschlüsselung schützt Application-Traffic zwischen externen Clients und Container-Services. OpenShift unterstützt verschiedene TLS-Terminierungsmodelle:
| Terminierungstyp | Verschlüsselung | Anwendungsbereich | Performance |
|---|---|---|---|
| Edge | Client → Router | Öffentliche Services | Hoch |
| Passthrough | Client → Pod | End-to-End-Verschlüsselung | Mittel |
| Re-encrypt | Client → Router → Pod | Sichere interne Kommunikation | Niedrig |
Etcd-Verschlüsselung schützt alle Cluster-Konfigurationsdaten und Secrets at Rest. Encryption-at-Rest sollte für produktive Cluster aktiviert werden und verwendet AES-256-Verschlüsselung. Encryption Keys müssen sicher gespeichert und regelmäßig rotiert werden.
Secret-Management in OpenShift verwendet Kubernetes Secrets für sensitive Daten wie Passwörter, API-Keys und Zertifikate. Secrets sind Base64-codiert, aber nicht verschlüsselt, weshalb RBAC-Kontrollen und etcd-Verschlüsselung kritisch sind.
External Secret Management-Systeme wie HashiCorp Vault oder Azure Key Vault können über Operatoren integriert werden. External Secret Stores bieten erweiterte Features wie automatische Secret-Rotation und detaillierte Audit-Trails.
OpenShift bietet integrierte Tools und Integration für Compliance-Monitoring und automatische Sicherheitsscans. Diese Funktionen ermöglichen kontinuierliche Sicherheitsüberwachung und Compliance-Nachweise.
Der Compliance Operator implementiert automatisierte Compliance-Checks für verschiedene Standards:
Compliance-Reports können für Audit-Zwecke exportiert und in externe Governance-Systeme integriert werden.
Image Security Scanning analysiert Container-Images auf bekannte Vulnerabilities und Policy-Violations. Red Hat Quay.io bietet automatische Scans für Images in Red Hat-Registries. Third-party Scanner wie Twistlock, Aqua oder Sysdig können über APIs integriert werden.
Scanning-Bereiche: - Betriebssystem-Packages und -Vulnerabilities - Anwendungsabhängigkeiten und -Sicherheitslücken - Konfigurationsfehler und Best-Practice-Violations - License-Compliance und Software-Lizenzen
File Integrity Monitoring überwacht kritische Systemdateien auf unauthorized Changes und kann als zusätzliche Intrusion Detection-Maßnahme dienen. Runtime-Security-Tools können Anomalien im Container-Verhalten erkennen und automatische Response-Aktionen auslösen.
Umfassende Backup-Strategien sind essentiell für die Wiederherstellung nach Sicherheitsvorfällen oder Systemausfällen. OpenShift-Backups müssen sowohl Cluster-Konfigurationen als auch Anwendungsdaten umfassen.
Etcd-Backups enthalten alle Cluster-Konfigurationsdaten und sind kritisch für Cluster-Recovery. Etcd-Snapshots sollten regelmäßig und automatisiert erstellt und sicher außerhalb des Clusters gespeichert werden.
# Automatisiertes etcd-Backup-Script
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db \
--endpoints=https://localhost:2379 \
--cacert=/etc/ssl/etcd/ca.crt \
--cert=/etc/ssl/etcd/server.crt \
--key=/etc/ssl/etcd/server.keyConfiguration Backups sollten alle Custom Resources, Secrets und Security Policies umfassen. GitOps-Ansätze können Configuration-as-Code implementieren und Backup- und Recovery-Prozesse vereinfachen.
Application Data Backups erfordern koordinierte Snapshots von Persistent Volumes und Anwendungsstate. Backup-Strategien müssen Konsistenz-Anforderungen verschiedener Anwendungstypen berücksichtigen.
Recovery-Metriken: - Recovery Time Objective (RTO): Maximal akzeptable Ausfallzeit - Recovery Point Objective (RPO): Maximal akzeptabler Datenverlust - Recovery Test-Zyklen: Regelmäßige Validierung der Recovery-Verfahren
Disaster Recovery-Tests müssen regelmäßig durchgeführt werden, um die Funktionsfähigkeit von Backup- und Recovery-Verfahren zu validieren. Recovery-Szenarien sollten verschiedene Ausfallarten abdecken, von einzelnen Node-Ausfällen bis hin zu kompletten Datacenter-Ausfällen.