Erstklassige IT-Teams haben produktive Container-Installationen einschließlich Orchestrierung eingerichtet. Nun stellt sich die Frage, wie man sie innerhalb großer mandantenfähiger Infrastrukturen vollständig sicher machen kann.
Für den Anfang müssen Anwender Änderungen in den Standardeinstellungen von Docker und von Kubernetes vornehmen, um mögliche Sicherheitslöcher zu schließen. Zum Beispiel ist eine Standardkomponente eines Container-Images mit Namen „docker.sock“ anfällig für eine Attacke, wenn sie ohne besondere Sicherheitsmaßnahmen für ihren Einsatz eingerichtet wurde: Bei einem Angriff könnte sie als Zugang zum Host-Betriebssystem und zu Backend-Datenbanken genutzt werden, um Daten aus ihnen herauszuziehen. In ähnlicher Weise könnte die API-Standardeinstellung von Kubernetes dazu verwendet werden, dass Container über einen bösartigen oder beschädigten Pod Zugang zum Host-Betriebssystem bekommen.
„Container haben das gleiche Problem wie jede andere virtuelle Maschine (VM): Sie können über ein internes Netzwerk miteinander sprechen“, sagte Jason Patterson, Application Security Architect bei NCR in Atlanta (USA), einem Hersteller von Financial Transaction Systems für Online Banking und Retailer (früher vor allem als Hersteller von Geldautomaten bekannt). „Dies bedeutet, dass eine falsche Konfiguration so ziemlich alle anderen Container in der Umgebung in Mitleidenschaft ziehen kann.“
Konfigurationseinstellungen für Container Security sind problematisch
NCR nutzt OpenShift von Red Hat, das die API-Einstellungen von Kubernetes standardmäßig begrenzt, aber OpenShift-User müssen Security-Beschränkungen in Kauf nehmen, berichtet Patterson.
Im Allgemeinen sei es besser, die Wahlfreiheiten eines Users und die Fähigkeiten eines Containers so weit wie es geht einzuschränken und idealerweise die Container so zu konfigurieren, dass explizit festgelegt ist, zu was die Anwender an Arbeitsschritten und Aktionen autorisiert sind – aber das sei noch nicht üblich, fügt Patterson hinzu.
Es ist möglich einzugrenzen, was ein Container Root User außerhalb des Containers oder seinem Host tun kann, berichtete Etienne Stalmans, Senior Security Engineer bei Heroku in San Francisco. Um dies zu erreichen, können Container-Administratoren entsprechende Einstellungen in „seccomp“ vornehmen, einem Sandbox-Anwendungsmechanismus im Linux-Kernel, und so Erlaubnisse oder Fähigkeiten der Applikation konfigurieren.
Die meisten erprobten Techniken bei Container-Sicherheit schränken den Zugriff auf Hosts und andere Backend-Systeme ein, wenn ein Angreifer einen beschädigten Container verwendet.
„Das macht sie immer noch zu einem privilegierten User, aber nicht außerhalb des Containers“, sagt Stalmans. „Insgesamt ist es am besten, alle Fähigkeiten für alle Container-Benutzer zu reduzieren oder ganz zu löschen, und sie ihnen erst dann wieder zu erlauben, wenn sie wirklich gebraucht werden.“
Einige besonders sicherheitskritische Anwendungen erfordern die Isolierung durch einen Hypervisor, um jede Möglichkeit zu verhindern, dass ein Angreifer Zugang auf den Host erhält. Hersteller wie Intel, Google und Microsoft bieten modifizierte Hypervisoren an, die extra für die Isolierung von Containern geeignet sind.
Experten verweisen auch auf Tools, mit denen die Angriffsoberfläche von Containern und Betriebssystemen auf dem Host verkleinert werden kann.
Der amerikanische Dienstleister Beeline aus Florida, spezialisiert auf Software für Workforce Management und Vendor Management, berichtete auf der Konferenz, dass man ein Tool von Oracle mit Namen „Smith“ benutze, das nicht gebrauchte Funktionen des Betriebssystems abschaltet. Jason Looney, Enterprise Architect bei Beeline, erzählte: „Das führte dazu, dass unsere Docker-Bildgrößen von 65 MByte auf 800 KByte bis 2 MByte abnahmen.“
Sicherheitslücken beim Host und bei APIs
Die meisten erprobten Techniken bei Container-Sicherheit schränken den Zugriff auf Hosts und andere Backend-Systeme ein, wenn ein Angreifer einen beschädigten Container verwendet. Aber der Schutz vor unautorisiertem API-Zugang bleibt ebenfalls problematisch. Dies berichtete Sam Bisbee, Chief Security Officer bei dem Softwareanbieter Threat Stack aus Boston. So hätten sich jüngst ausgefeilte Angriffe auf ein AWS-basiertes System gegen APIs und nicht gegen die Hosts gerichtet.
Bisbee fügte hinzu, dass Angreifer nicht unbedingt nach großen Summen an Daten Ausschau halten: „Eine Security-Policy sollte die ganze Infrastruktur abdecken und nicht nur wichtige Daten.“
Die Version 1.8 von Kubernetes verbesserte die API-Security mit einem Schwenk von attributbasierter zu rollenbasierter Zugangskontrolle (RBAC, Role-Based Access Control). Die meisten Anbieter und Provider von Kubernetes einschließlich Cloud Container Services verfügen nun standardmäßig über RBAC Kubernetes API-Zugang. Stalmans weist darauf hin, dass die Anwender jedoch die Konfigurationseinstellungen verbessern sollten, die unsicheren Pods den Kontakt mit der Kubernetes-API untersagen.
Und Stalmans ergänzt: „Es gibt in der Kubernetes-Community Diskussionen darüber, diese Einstellungen zum Standard zu erheben.“ Es sei auch möglich, dies prinzipiell mit Networking-Tools wie Calico, Istio und Weave zu tun. Stalman: „Aber das würde bedeuten, dass wir zurück bei Firewall-Regeln landen würden, bis ein neuer Standard verabschiedet ist.“
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
