Hardware-, API-Server- und Container-Risiken bei Kubernetes in den Griff bekommen

Kubernetes ist äußerst populär, aber ohne entsprechende Sicherheitsmaßnahmen auch mit Risiken verbunden. CyberArk nennt drei konkrete Risiken und zeigt, welche Abwehrmaßnahmen erforderlich sind.

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.

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.

1. 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.

2. 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.

3. 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.

www.cyberark.de