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

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

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.

Anzeige

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

Studie: Cloud-Automatisierung als Schlüssel für Cybersecurity

Trotz angespannter Sicherheitslage überschätzen Unternehmen die Wirksamkeit ihrer Security-Maßnahmen. Eine Studie zeigt, dass Cloud-Automatisierung der Schlüssel für zukunftsfähige Cybersecurity sein ➡ Weiterlesen

ThycoticCentrify verbessert die Benutzerfreundlichkeit des Secret Server

Verbesserte Benutzerfreundlichkeit des Secret Server durch eine automatisierte und vereinfachte Verwaltung von Secrets: Mit neuen Sicherheitskontrollen, Automatisierungsfunktionen und Design-Updates bietet die ➡ Weiterlesen

Account Lifecycle Governance auf Multi-Cloud-Umgebungen

Mit dem Account Lifecycle Manager ist es jetzt möglich, Servicekonten für alle wichtigen Cloud-Anbieter – Microsoft Azure, Amazon Web Services ➡ Weiterlesen

Über 50 Prozent: Sicherheitsvorfälle in DevOps-Umgebungen 

Eine Umfrage von Forrester zeigt, dass die Zentralisierung von Secrets und die Verwendung einheitlicher Tools der Schlüssel zur Sicherung von ➡ Weiterlesen

Diebstahl von Zugangsdaten: jedes 2. Unternehmen betrofffen

Über die Hälfte der Unternehmen von Diebstahl privilegierter Zugangsdaten und Insider Threats betroffen. ThycoticCentrify-Studie: 77 Prozent nutzen Zero-Trust-Ansatz als Reaktion auf ➡ Weiterlesen

Unternehmen setzen auf IAM und PAM in der Wolke

Identity Security in der Cloud: 89 Prozent der Unternehmen setzen auf IAM und PAM in der Wolke. ThycoticCentrify-Studie: Schutz digitaler Identitäten ➡ Weiterlesen

IoT-Sicherheitsreport 2022: Industrielle Steuerungen in Gefahr

IT-Experten fordern im IoT-Sicherheitsreport 2022 eine Bill of Materials (SBOM) für Gerätesoftware: Industrielle Steuerungen, Produktion und das Smart Home sind ➡ Weiterlesen

86 Prozent wollen ihr IT-Sicherheitsbudget bis 2024 erhöhen

Vielen Unternehmen sind die betrieblichen Gefahren durch IT-Vorfälle bewusst. Sie planen Investitionen in Technik und Know-how und nähern sich auch ➡ Weiterlesen