Sicherheitskonzepte
Kubernetes Distribution
Jeder NKE-Cluster basiert auf einem Rancher Kubernetes Engine 2 (RKE2) Cluster. RKE2 ist eine CNCF-zertifizierte Kubernetes-Distribution, welche die Installation und Aktualisierung des gesamten Kubernetes-Clusters vereinfacht.
Betriebssystem
Nine nutzt Flatcar OS als zugrunde liegendes Linux-Betriebssystem auf jedem Cluster-Node.
Aus den FAQ von Flatcar OS:
Das OS Image, das von Flatcar Container Linux bereitgestellt wird, enthält nur die minimale Menge an Tools, um Container Workloads zu betreiben. Das bedeutet, dass die Angriffsfläche wesentlich reduziert ist. Dazu kommt, dass die Wahrscheinlichkeit einer versehentlichen oder mutwilligen Störung geringer ist, da das OS Image unveränderlich ist (/usr ist read-only und es gibt keinen Package-Manager, mit dem Packages installiert werden).
Upgrades
Nine bietet regelmässige Upgrades zu neuen Betriebssystem-Images auf NKE-Cluster-Nodes an. Diese Upgrades werden im wöchentlichen Wartungsfenster automatisch und in mehreren Phasen auf allen NKE-Clustern ausgerollt.
Netzwerk
Nine nutzt Cilium als Netzwerk-Provider in NKE-Clustern. Cilium unterstützt Kubernetes NetworkPolicy Ressourcen, mit denen eingehender und ausgehender Netzwerkverkehr gesichert werden kann.
Firewall
NKE-Cluster-Nodes wird standardmässig eine öffentlich erreichbare IP-Adresse zugewiesen. Nine schränkt den Zugriff auf bestimmte Dienste ein, welche auf den Nodes eines NKE-Clusters laufen. Dazu gehört der SSH-Zugriff, der nur über spezielle, von Nine verwaltete VPN-Server möglich ist.
Authentifizierung
Nine bietet eine zentrale Authentifizierung für gemanagte Applikationen an. Dienste wie Grafana, Argo CD oder der Kubernetes API-Server selbst werden über OIDC gesichert.
Neben dem zentralen Management der Nutzerzugänge lässt sich darüber auch die Zwei-Faktor-Authentifizierung (2FA) einrichten.
Zugriffskontrolle
Nine bietet standardmässig clusterweite RBAC-Rollen (Role-Based Access Control) an, die Benutzern oder Service-Accounts zugewiesen werden können:
| Name | Beschreibung |
|---|---|
| admin | Definiert Admin-Rechte für einen Cluster, d.h. das Subjekt kann alle Namespaces und alle darin enthaltenen Ressourcen erstellen, aktualisieren und löschen. Der Zugriff auf bestimmte Namespaces kann nicht entzogen werden. |
| viewer | Definiert Viewer-Rechte für einen Cluster, d.h. der Benutzer kann alle Ressourcen des Clusters ausser Secrets einsehen. Weitere Berechtigungen für bestimmte Namespaces können über RBAC erteilt werden. |
| user | Definiert User-Rechte für einen Cluster, d.h. der Benutzer kann Namespaces erstellen, die eigenen Namespaces löschen und die Secrets in den eigenen Namespaces einsehen. |
Cluster Admin
Administratoren in NKE haben eingeschränkte Berechtigungen im Vergleich zu einem vollen cluster-admin. Sie können alle Namespaces sowie die darin enthaltenen Ressourcen erstellen, aktualisieren und löschen, haben jedoch keinen uneingeschränkten cluster-admin Zugriff.
Custom Resource Definitions (CRDs)
Das Installieren von CRDs ist auf NKE-Clustern aktuell aus folgenden Gründen nicht möglich:
- Konflikte: CRDs sind clusterweit gültig, weshalb es zu Konflikten mit vorinstallierten CRDs oder CRDs von gewissen Add-ons kommen kann.
- Sicherheitsberechtigungen: CRDs werden oft zusammen mit Controllern oder Operatoren installiert, welche häufig clusterweite Berechtigungen benötigen (z. B. alle Secrets auslesen). Da wir gewisse Komponenten für das Management auf den Clustern installiert haben, können wir diese Berechtigungen aus Sicherheitsgründen nicht pauschal erteilen.
- Managed-Ansatz: Die meisten Dienste, die CRDs benötigen, möchten wir als Managed-Add-ons anbieten, damit sich der Benutzer nicht um Updates kümmern muss.
Wir sind uns bewusst, dass die Verbreitung von CRDs zunimmt und Benutzer eigene CRDs und Controller nutzen möchten. Falls Ihr Anwendungsfall spezifische CRDs erfordert, kontaktieren Sie uns bitte unter , damit wir Ihre Anforderungen besser verstehen können.
Managed Applications
Nine bietet bestimmte gemanagte Applikationen an, welche die Sicherheit bei der Nutzung von NKE erhöhen. Beispiele sind:
- Container (OCI) Registry zum Speichern privater Container-Images und Helm Charts.
- Sealed Secrets zum sicheren Speichern von Secrets in einem Git-Repository.
- Automatische TLS-Zertifikate bereitgestellt durch cert-manager.
- Audit Logging ermöglicht Kubernetes-Auditing für NKE.