Publikation von Christoph Puppe
Kubernetes-Sicherheit: OpenShift und Rancher nach BSI-Anforderungen härten
Im letzten Teil der Serie zur Kubernetes-Absicherung treten zwei Distributionen an. Der OpenShift-Demo-Cluster in Version 4.12.13 stand nach zwei Stunden, per Terraform in der Google-Cloud installiert, mit 35 Operatoren, die den Betrieb übernehmen; wäre der Cluster ein Linux, wären die Operatoren die von systemd verwalteten Basisdienste. Seit Version 4.11 ersetzen elf Security Context Constraints die Pod Security Policies, Standard ist restricted. Die für die Absicherung nötigen Operatoren fehlen aber in der Defaultinstallation: der Compliance Operator mit OpenSCAP, der File Integrity Operator mit AIDE, der Security Profiles Operator für SECCOMP- und SELinux-Profile. Schwerster Mangel bei SYS.1.6.A5: Die Admin-Webkonsole hängt am selben Loadbalancer wie die Anwendungen. In den OpenShift-Images fanden sich etliche Verwundbarkeiten, für immerhin 26 existieren Exploits; dafür muss der Operator Hub mit fast 500 Paketen den Vergleich mit den Hyperscalern nicht fürchten. Rancher, seit 2020 bei SUSE, liefert mit K3s, RKE und RKE2 drei ausgereifte Distributionen; das Update von Kubernetes 1.24 auf 1.25 lief in zwei Minuten durch, ohne die Workloads zu stören. Doch als Node-Betriebssystem wählt Rancher per Default ein betagtes Ubuntu 18.04 LTS, und die NeuVector-Installation scheiterte im Test. Zwei Tabellen bewerten die Anforderungen der Bausteine SYS.1.6 und APP.4.4; weder Constraints noch Sicherheitsoperatoren ersetzen eine ausgereifte Cloud Workload Protection Platform. Wer alles aus einer Hand will, dürfte bei OpenShift landen, wer mehr Freiheit sucht, eher bei Rancher.
heise online · PDF · Permalink