Hardware-, API-Server- und Container-Risiken bei Kubernetes

Hardware-, API-Server- und Container-Risiken bei Kubernetes

Beitrag teilen

Kubernetes ist äußerst populär, aber ohne entsprechende Sicherheitsmaßnahmen auch mit Risiken verbunden. Sicherheitsexperte CyberArk nennt drei konkrete Risiken und zeigt, welche Abwehrmaßnahmen erforderlich sind, um Hardware-, API-Server- und Container-Risiken bei Kubernetes in den Griff bekommen.

In der Softwareentwicklung kommt es heute auf Geschwindigkeit und Agilität an. In immer stärkerem Maße wird dabei die Containertechnologie genutzt. Für die Verwaltung der containerisierten Workloads und Services hat sich Kubernetes als der De-facto-Standard herauskristallisiert.

Anzeige

Sicherheitsaspekte bei Kubernetes

Unter Sicherheitsaspekten bringt die Kubernetes-Orchestrierungsplattform spezifische identitätsbezogene Herausforderungen mit sich, die frühzeitig im Entwicklungsprozess adressiert werden müssen. Anderenfalls können containerisierte Umgebungen ein Risiko für die IT-Sicherheit darstellen. Es existieren vor allem drei potenziell gefährdete Bereiche innerhalb von Kubernetes, auf die sich Unternehmen im Rahmen eines echten DevSecOps-Ansatzes konzentrieren sollten.

Kubernetes-Risiko: Hardware

Unabhängig davon, ob Kubernetes im eigenen Rechenzentrum oder in einer von einem Drittanbieter verwalteten Cloud ausgeführt wird, ist immer noch eine Hardware-Plattform erforderlich. Sobald ein Angreifer Zugriff auf die virtuelle Maschine hat, auf der Kubernetes läuft, und sich Zugang zu Root-Rechten verschafft, kann er auch Kubernetes-Cluster attackieren.

Um dies zu verhindern, gibt es folgende Security Best Practices:

  • Die Durchsetzung des Least-Privilege-Prinzips leistet einen entscheidenden Beitrag zum Schutz der Hardware, die sowohl Kubernetes als auch den Containern selbst zugrunde liegt. Virtuelle Maschinen sollten mit dem geringsten Umfang von Privilegien bereitgestellt werden (also nur mit denen, die aus funktionalen Gründen zwingend erforderlich sind), um es Angreifern zu erschweren, einen Root-Zugriff zu erhalten.
  • Credentials müssen regelmäßig rotiert werden, wobei auch die Nutzung einer automatisierten Vault-Lösung sinnvoll ist, um den Schutz weiter zu erhöhen, ohne den Aufwand zu vergrößern.

Kubernetes-Risiko: Kubernetes API Server

Abgesehen von den physischen Maschinen muss auch die Kubernetes Control Plane gesichert werden. Über sie ist ein Zugang zu allen Containern möglich, die in einem Cluster laufen – einschließlich des Kubernetes-API-Servers, der als Frontend fungiert und die Benutzerinteraktion innerhalb des Clusters erleichtert.

Ein Angriff auf den API-Server kann große Auswirkungen haben. Selbst einzelne gestohlene Secrets oder Credentials können verwendet werden, um die Zugriffsrechte und Privilegien eines Angreifers zu erweitern. Eine zunächst kleine Schwachstelle kann sich damit schnell zu einem netzwerkweiten Problem entwickeln.

Zu den Security Best Practices gehören:

  • Zur Risikominimierung sollten Unternehmen zunächst Endpunkte gegen den Diebstahl von Anmeldeinformationen und Malware-Bedrohungen absichern. Besonders relevant sind dabei lokale Rechner, die von Benutzern mit administrativen Rechten in Kubernetes verwendet werden.
  • Eine Multi-Faktor-Authentifizierung (MFA) für den Zugriff auf Kubernetes-API-Server ist unverzichtbar. So kann ein gestohlenes Credential nicht für den Kubernetes-Zugang verwendet werden.
  • Sobald User in Kubernetes authentifiziert sind, können sie auf alle Ressourcen innerhalb des Clusters zugreifen. Die Verwaltung von Berechtigungen ist deshalb von entscheidender Bedeutung. Mit einer rollenbasierten Zugriffskontrolle kann ein Unternehmen sicherstellen, dass die Benutzer nur die wirklich benötigten Zugriffsrechte erhalten.
  • Das Least-Privilege-Prinzip sollte auch über Kubernetes-Service-Accounts hinweg durchgesetzt werden, die bei der Einrichtung eines Clusters automatisch erstellt werden, um die Authentifizierung von Pods zu unterstützen. Ebenso wichtig ist ein regelmäßiges Rotieren der Secrets, um die Zugriffsmöglichkeiten für diejenigen zu unterbinden, die sie nicht mehr benötigen.

Kubernetes-Risiko: Container

Pods und Container sind die Bausteine eines Kubernetes-Clusters und enthalten die für die Ausführung der Anwendung erforderlichen Informationen. Innerhalb dieses Container-Ökosystems und -Workflows gibt es mehrere potenzielle Schwachstellen. Dazu zählen etwa ein ungesicherter Zugang zur Container API oder zum Container Host sowie nicht geschützte Image Registries.

Für die Container-Sicherheit empfehlen sich folgende Best Practices:

  • Secrets dürfen weder in Code noch in ein Container-Image integriert werden. Ansonsten hat jeder mit Zugriffsmöglichkeit auf den Quellcode zum Beispiel auch Zugang zu Informationen in Code-Repositories.
  • Mit einer rollenbasierten Zugriffskontrolle, einer Beschränkung des Secret-Zugriffs auf die Prozesse innerhalb eines bestimmten Containers und einer Löschung nicht mehr benötigter Secrets werden die Sicherheitsrisiken deutlich minimiert.
  • Die Secret-Nutzung einschließlich Rotation oder Deaktivierung sollte protokolliert werden. Von Vorteil ist überdies eine zentrale Secrets-Management-Lösung, die die automatische Verwaltung und Sicherung von vertraulichen Zugangsdaten ermöglicht.

„Wendet ein Unternehmen diese Best Practices an, kann es die Sicherheit in der gesamten Kubernetes-Umgebung signifikant verbessern“, erklärt Michael Kleist, Area Vice President DACH bei CyberArk. „Darüber hinaus besteht auch die Möglichkeit, Entwickler mit Self-Service-Funktionen in ihrer täglichen Arbeit zu unterstützen, etwa im Hinblick auf das Code-Scanning. Damit können sie komfortabel und schnell einen weiteren Beitrag zur Erhöhung der Kubernetes-Sicherheit leisten.“

Mehr bei CyberArk.com

 


Über CyberArk

CyberArk ist das weltweit führende Unternehmen im Bereich Identity Security. Mit dem Privileged Access Management als Kernkomponente bietet CyberArk eine umfassende Sicherheit für jede – menschliche oder nicht-menschliche – Identität über Business-Applikationen, verteilte Arbeitsumgebungen, Hybrid-Cloud-Workloads und DevOps-Lifecycles hinweg.


 

Passende Artikel zum Thema

Wireshark-Alternative für die Cloud

Ein Anbieter von Echtzeit-Sicherheitslösungen für die Cloud gab die Veröffentlichung von Stratoshark bekannt, einem Open-Source-Tool, das die granulare Netzwerktransparenz von ➡ Weiterlesen

E-Mail-Schutz vor komplexen Cyberangriffen

Ein Cybersicherheitsunternehmen für umfassenden E-Mail-Schutz vor komplexen Bedrohungen stellt Weiterentwicklungen vor. Die Updates umfassen unter anderem flexible Bereitstellungsoptionen und verbesserte ➡ Weiterlesen

Zero Trust für RISE with SAP

Ein SAP-Partner bietet Kunden ab sofort einen Zero Trust Network Access (ZTNA) Service an, der nativ in „RISE with SAP“ ➡ Weiterlesen

Duale Authentifizierung ist eine Herausforderung

Viele Unternehmen betreiben eine hybride Authentifizierung mit Passkeys und Passwörtern, um der dauerhaft hohen Gefahr des Phishings zu begegnen. Der ➡ Weiterlesen

Datenwiederherstellung in hybriden IT-Umgebungen

Acht von zehn Unternehmen wurden schon durch Ransomware attackiert. Deshalb ist eine anpassungsfähige Datenwiederherstellung gerade für hybride IT-Landschaften essentiell notwendig, ➡ Weiterlesen

Compliance Assistant unterstützt bei DORA Umsetzung

Mithilfe des Compliance Assistant lassen sich Risiken leichter minimieren und zeitaufwändige Prüfungen von Konfigurationen im Rahmen von DORA verkürzen. Dazu ➡ Weiterlesen

Report: Angriffe auf kritische Infrastrukturen nehmen zu

Die Zahl der Sicherheitsvorfälle in kritischen Infrastrukturen ist seit 2022 um 668 Prozent gestiegen. Der Threat Roundup-Bericht 2024 wirft ein Schlaglicht ➡ Weiterlesen

Orchestrierung der E-Mail-Verschlüsselung

E-Mails sind ein unverzichtbares Werkzeug in einer Arbeitswelt, die immer dezentraler wird. Aber wie lassen sich Praktikabilität, Resilienz und Vertrauen ➡ Weiterlesen