Sicherheit
Die Sicherheit eines Kubernetes-Clusters verteilt sich auf zwei Ebenen: die von centron betriebene Infrastruktur und die von Ihnen verantwortete Konfiguration innerhalb des Clusters. Diese Seite beschreibt beide.
Von centron verantwortet
Rechenzentrum
Der Betrieb erfolgt ausschließlich im centron Rechenzentrum in Hallstadt bei Bamberg, Deutschland. Das Rechenzentrum ist nach ISO 27001 zertifiziert und durch Enterprise-Firewalls sowie DDoS-Schutz abgesichert.
Da alle Daten ausschließlich in Deutschland verarbeitet werden, unterliegen sie durchgehend deutschem und europäischem Datenschutzrecht.
Control Plane
Die Control Plane wird von centron betrieben und gepflegt. Ein direkter Zugriff – etwa per SSH – ist weder für Sie noch nach außen möglich; die Kommunikation erfolgt ausschließlich über den authentifizierten API-Endpunkt.
Patches und Updates
Sicherheitskritische Updates für Control Plane und Node-Betriebssysteme installiert centron automatisch. Die Installation erfolgt rollierend im konfigurierten Upgrade-Fenster, Node für Node und ohne Ausfallzeit.
Siehe Unterstützte Versionen.
Netzwerkisolation
Alle Ressourcen eines Rechenzentrums liegen in einem VPC-Netzwerk und kommunizieren über private IP-Adressen. Pod- und Service-Netzwerke sind clusterintern und nach außen nicht erreichbar.
In Ihrer Verantwortung
Zugang zur Konfigurationsdatei
Die Konfigurationsdatei (kubeconfig) enthält ein Authentifizierungstoken mit weitreichenden Rechten an Ihrem Cluster. Behandeln Sie sie wie ein Passwort:
-
Nicht in Versionsverwaltungen einchecken
-
Nicht über unverschlüsselte Kanäle weitergeben
-
Dateirechte restriktiv setzen:
chmod 600 /<pfad>/<cluster-name>-kubeconfig.yaml
Rechtevergabe im Cluster
Vergeben Sie Rechte nach dem Prinzip der geringsten Berechtigung. Anwendungen sollten nicht mit Cluster-Administratorrechten laufen. Über RoleBindings begrenzen Sie Rechte auf einzelne Namespaces.
Siehe RoleBindings einrichten.
Secrets
Zugangsdaten, Tokens und Zertifikate gehören in Secret-Objekte, nicht in Container-Images oder Manifeste:
kubectl create secret generic db-credentials \
--from-literal=username=app \
--from-literal=password=<passwort>
Der Inhalt eines Kubernetes-Secrets ist lediglich Base64-kodiert, nicht verschlüsselt. Jeder mit Leserechten auf Secrets im Namespace kann ihn auslesen. Beschränken Sie diese Rechte entsprechend.
Netzwerk-Policies
Standardmäßig kann in Kubernetes jeder Pod jeden anderen Pod erreichen. Mit NetworkPolicy-Objekten schränken Sie den Datenverkehr gezielt ein:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: nur-aus-frontend
namespace: produktion
spec:
podSelector:
matchLabels:
app: datenbank
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 5432
Container-Sicherheit
-
Verwenden Sie Images aus vertrauenswürdigen Quellen und halten Sie sie aktuell.
-
Setzen Sie feste Image-Tags oder Digests statt
latest, damit nachvollziehbar bleibt, was ausgerollt wurde. -
Betreiben Sie Container nach Möglichkeit ohne Root-Rechte:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
containers:
- name: app
image: registry.example.com/app:1.4.2
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true -
Setzen Sie
limits, damit ein einzelner Container einen Node nicht vollständig auslasten kann.
Zugriff auf den API-Endpunkt
Beschränken Sie den Zugriff auf die Kubernetes API nach Möglichkeit auf bekannte Quelladressen.
Verantwortungsteilung im Überblick
| Bereich | Verantwortung |
|---|---|
| Physische Sicherheit des Rechenzentrums | centron |
| Betrieb und Patching der Control Plane | centron |
| Betriebssystem-Updates der Nodes | centron |
| Netzwerkisolation auf Infrastrukturebene | centron |
| Umgang mit der Konfigurationsdatei | Kunde |
| RBAC-Regeln und Namespaces | Kunde |
| Network Policies innerhalb des Clusters | Kunde |
| Sicherheit der Container-Images | Kunde |
| Verwaltung von Secrets | Kunde |
| Sicherung der Anwendungsdaten | Kunde |
Verwandte Themen
- Verfügbarkeit – Standort und Rechenzentrum
- Scope of Support
- RoleBindings einrichten
- Best Practices