{"id":18358,"date":"2021-03-06T11:10:00","date_gmt":"2021-03-06T10:10:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=18358"},"modified":"2021-03-02T10:25:47","modified_gmt":"2021-03-02T09:25:47","slug":"wie-sich-container-sicher-mit-kubernetes-orchestrieren-lassen","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=18358","title":{"rendered":"Wie sich Container sicher mit Kubernetes orchestrieren lassen"},"content":{"rendered":"\n

Autor\/Redakteur: Richard Werner, Business Consultant bei Trend Micro<\/a>\/gg<\/p>\n\n\n\n

Kubernetes ist das in Cloud-Umgebungen am meist eingesetzte Container-Orchestration-System. Diese Verbreitung macht es f\u00fcr Cyberkriminelle attraktiv, weshalb Cloud-Administratoren eine Sicherheitsstrategie ben\u00f6tigen, die vom Master-Knoten bis zum Container-Image reicht. Ein \u00dcberblick zu den relevanten Sicherheitsma\u00dfnahmen.<\/p>\n\n\n\n

\"\"<\/a>
Grafik: Trend Micro<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Container, meist Docker, und Container-Orchestratoren wie Kubernetes erleichtern nicht nur den Betrieb einer Vielfalt von Anwendungen in einer heterogenen Umgebung, sondern auch die kombinierte Nutzung von Apps in vielen Variationen. Betreibt ein Unternehmen seine Cluster als Managed Services wie etwa Azure Kubernetes Service (AKS)<\/a>, Amazon Elastic Kubernetes Service (Amazon EKS)<\/a> oder Google Kubernetes Engine (GKE)<\/a>, so muss der Cloud-Anbieter die Kontrolle \u00fcber die Sicherheit \u00fcbernehmen. Dennoch ist ein besseres Verst\u00e4ndnis der verf\u00fcgbaren Sicherheitsoptionen hilfreich, um sicherzustellen, dass der Cloud-Anbieter die empfohlenen Best Practices befolgt. Richtet sich eine Organisation ihre eigenen Control Planes ein, ist tieferes Wissen noch wichtiger. Cloud-Administratoren m\u00fcssen vor allem die drei Bedrohungsszenarien externe Angriffe, Fehlkonfigurationen und angreifbare Anwendungen im Blick behalten.<\/p>\n\n\n\n

Das Gehirn vor externen Angriffen sch\u00fctzen<\/strong><\/p>\n\n\n\n

Wenden wir uns zun\u00e4chst dem Gehirn zu \u2013 dem Kubernetes Control Plane. Es fungiert als Hauptknoten im Cluster und verwaltet die Worker Nodes. Die gesamte Kommunikation l\u00e4uft \u00fcber kube-api-server, der letztendlich ein REST API ist, das alle Management- und Betriebsfunktionen definiert und kontrolliert. Verschaffen sich Cyberkriminelle Zugang zur REST API, k\u00f6nnen sie den gesamten Cluster kompromittieren, indem sie die Pods (in denen die Container platziert sind) manipulieren, neue aufsetzen, bereits laufende bearbeiten oder sogar ganz entfernen.<\/p>\n\n\n\n

Eine der grundlegenden Ma\u00dfnahmen zur Sicherung des Control Plane ist die Integrit\u00e4ts\u00fcberwachung der kritischen Kubernetes-Dateien. Auf diese Weise kommt sofort \u00fcber jede \u00c4nderung der Konfiguration eine Benachrichtigung. Eine Liste der wichtigsten Dateien und Verzeichnisse, die das Team st\u00e4ndig \u00fcberwachen muss, zusammen mit den empfohlenen Ownership- und Berechtigungsebenen, sind in der neuesten CIS Kubernetes Benchmark v1.5.1<\/a> detailliert aufgef\u00fchrt.<\/p>\n\n\n\n

Entscheidend ist, dass diese API lediglich von den Maschinen in einem Cluster zu erreichen ist, die Administrationsaufgaben erf\u00fcllen m\u00fcssen. Es empfiehlt sich daher eine Firewall-Regel, die durchsetzt, dass nur die Maschinen auf die API zugreifen k\u00f6nnen, die das auch tun m\u00fcssen.<\/p>\n\n\n\n

API-Server abschotten<\/strong><\/p>\n\n\n\n

Viele Angreifer und Bots suchen im Internet st\u00e4ndig nach offen zug\u00e4nglichen Kubernetes-API-Servern, was leider h\u00e4ufig Aussichten auf Erfolg hat. Denn viele Firmen lassen ihre API-Server \u00f6ffentlich zug\u00e4nglich \u2013 ein kritischer Fehler.<\/p>\n\n\n\n

Die Entwickler sollten das Cluster API nur \u00fcber das interne Netzwerk (oder Unternehmens-VPN) erreichen k\u00f6nnen. Dies l\u00e4sst sich leicht bewerkstelligen, indem die entsprechenden Regeln f\u00fcr die Firewall oder Sicherheitsgruppen (im Fall von AWS) festgelegt werden. Hier gilt es an die Notfallsituation zu denken, in welcher der Cluster-Administrator keinen sofortigen Zugriff auf den Firmen-Laptop oder ein VPN hat. In dem Fall sollte der Zugriff auf den Cluster durch eine sichere Auflistung der IP des Cluster-Administrators gew\u00e4hrleistet werden, vorzugsweise auf den spezifischen API-Port. Daneben ist es ratsam, ein Intrusion Prevention System (IPS) mit Secure Sockets Layer (SSL)-Entschl\u00fcsselungsf\u00e4higkeiten wie Trend Micro TippingPoint Threat Protection System einzusetzen, um den Verkehr zu und von der API zu \u00fcberwachen.<\/p>\n\n\n\n

Fehlkonfigurationen vermeiden und Berechtigungen zuweisen<\/strong><\/p>\n\n\n\n

Wie wichtig der Konfigurationsaspekt bei Kubernetes ist, haben Sicherheitsforscher mit dem Scan der IoT-Suchmaschine Shodan gezeigt. Weltweit gibt es nahezu 3.000 Hosts, bei denen „etcd“ \u00f6ffentlich zug\u00e4nglich ist. „etcd“ ist der Hauptspeicherort f\u00fcr Daten im Cluster. Alle Clusterobjekte werden hier vorgehalten. Gelingt es einem Angreifer auf irgendeine Weise, den API-Server zu umgehen und Objekte direkt in „etcd“ zu manipulieren, so w\u00e4re es, als h\u00e4tte er vollen Zugriff auf den gesamten Cluster. Er k\u00f6nnte Pods erstellen, Geheimnisse lesen und sensible Daten wie Anmeldeinformationen einsehen. Um dies zu verhindern, m\u00fcsste nicht nur die Verschl\u00fcsselung w\u00e4hrend der \u00dcbertragung aktiviert sein, sondern auch die Verschl\u00fcsselung im Ruhezustand (At-Rest).<\/p>\n\n\n\n

Schon bei der Authentifizierungskonfiguration k\u00f6nnen viele Fehler passieren, weil sie sehr komplex ist. So gibt es mehrere Arten der Authentifizierung (rollen-, attribut- oder knotenbasiert). Als Hilfe k\u00f6nnen Cloud-Administratoren den Befehl „kubectl auth can-i“ verwenden, um bestimmte Berechtigungen abzufragen. Kubernetes Benutzer- und Service-Konten sollten lediglich die Berechtigungen erhalten, die sie tats\u00e4chlich ben\u00f6tigen. Mit Roll Based Access Control (RBAC) l\u00e4sst sich festlegen, wer worauf in dem Cluster zugreifen kann.<\/p>\n\n\n\n\n\n\n\n

Netzwerkverkehr standardm\u00e4\u00dfig untersagen<\/strong><\/p>\n\n\n\n

Des Weiteren m\u00fcssen Cloud-Administratoren im Hinterkopf behalten, dass es keine Netzwerk-Policy f\u00fcr einen bestimmten Namensraum gibt. Die standardm\u00e4\u00dfige Policy erlaubt den Verkehr hin und von allen Pods in dem Namensraum.<\/p>\n\n\n\n

Jeder Pod kann mit jedem anderen Pod kommunizieren. Wenn ein Angreifer also in einen \u00f6ffentlich zug\u00e4nglichen Pod eindringt, etwa mit einer Webanwendung, dann kann er diesen nutzen, um sich mit anderen Pods zu verbinden. Dies erleichtert Angreifern die laterale Bewegung nach dem Eindringen erheblich.<\/p>\n\n\n\n

Best Practice hier besteht darin, den Zugang standardm\u00e4\u00dfig zu verbieten und Verkehr nur explizit zuzulassen. Daneben hat es sich bew\u00e4hrt, eine Kubernetes-Distribution einzusetzen, die nur wenige Optionen aber eine sichere Out-of-the-Box-Konfiguration mitbringt. RedHat OpenShift erf\u00fcllt beispielsweise diese Kriterien.<\/p>\n\n\n\n

Angreifbare Anwendungen ausschlie\u00dfen<\/strong><\/p>\n\n\n\n

Auch auf Container-Ebene gibt es sicherheitsrelevante Aspekte, die schnell aus dem Blick geraten. So m\u00fcssen Updates \u00fcberall dort angewendet werden, wo sie ben\u00f6tigt werden, da jede Anwendung ihre eigene Kopie jeder Bibliothek hat. Dieselbe Bibliothek kann in mehreren Images aus verschiedenen Basis-Images installiert werden. Und diese m\u00fcssen alle aktualisiert und mit Sicherheits-Patches versehen werden. Die Integration einer L\u00f6sung zum (automatischen) Aktualisieren in den DevOps-Prozess hilft an der Stelle weiter. Zumindest muss die L\u00f6sung sicherstellen, dass alle genutzten Container Images aktualisiert werden und aus vertrauensw\u00fcrdigen Quellen stammen.<\/p>\n\n\n\n

\"\"<\/a>
Grafik: Trend Micro<\/figcaption><\/figure>\n\n\n\n

Es gab bereits Angriffe, die solche Images missbrauchten, so etwa f\u00fcr das Scannen nach angreifbaren Servern und Krypto-Mining. F\u00fcr dieses Sicherheitsproblem liefert Docker eine Funktion namens \u201eContent Trust\u201c. Damit k\u00f6nnen Nutzer Images in einem Cluster oder Swarm zuverl\u00e4ssig bereitstellen und \u00fcberpr\u00fcfen, ob es sich tats\u00e4chlich um die von ihnen gew\u00fcnschten Images handelt. Docker Content Trust (DCT) kann jedoch die Images nicht \u00fcber den Swarm hinweg auf Ver\u00e4nderungen oder \u00c4hnliches \u00fcberwachen.<\/p>\n\n\n\n

Im Kern ist DCT ein sehr einfaches Tool. Es geht um die Logik innerhalb des Docker-Clients, die Images verifizieren kann, welche Anwender von einem Registry-Server beziehen oder bereitstellen und die auf einem Docker Notary Server der Wahl signiert sind.<\/p>\n\n\n\n

Container-spezifische, automatisierten Scanning-Technologien senken dar\u00fcber hinaus die Gefahr, dass Anwendungen zum Angriffspunkt werden. Diese pr\u00fcfen Images f\u00fcr Apps, die Teil des Continuous-Integration- und Continuous-Delivery (CI\/CD)-Prozesses sind.<\/p>\n\n\n\n

Ein Cluster ist nur so stark wie der schw\u00e4chste Service<\/strong><\/p>\n\n\n\n

Releases erfolgen in Container-Umgebungen schnell, Architekturen werden kontinuierlich integriert und Softwareversionen regelm\u00e4\u00dfig aktualisiert. Herk\u00f6mmliche Sicherheitsverfahren versagen. Aber die allgemeine Sicherheitsregel gilt auch hier, wonach ein Kubernetes-Cluster nur so sicher ist, wie der am schw\u00e4chsten gesicherte Service, der darauf l\u00e4uft. Unternehmen m\u00fcssen deshalb ihre Sicherheit in Bezug auf unterschiedliche Komponenten der Containerarchitektur von den Containerlaufzeiten \u00fcber Orchestratoren bis hin zu Entwicklungsumgebungen im Auge behalten und Sicherheitsma\u00dfnahmen ableiten, die Master-Knoten, API-Server, etcd, Netzwerk-Policies und Anwendungen betreffen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Kubernetes ist das in Cloud-Umgebungen am meist eingesetzte Container-Orchestration-System. Diese Verbreitung macht es f\u00fcr Cyberkriminelle attraktiv, weshalb Cloud-Administratoren eine Sicherheitsstrategie ben\u00f6tigen, die vom Master-Knoten bis zum Container-Image reicht. Ein \u00dcberblick zu den relevanten Sicherheitsma\u00dfnahmen.<\/p>\n","protected":false},"author":1,"featured_media":18359,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[8,18],"tags":[2073,11233,6257,3137,5081,3247,7360,4122,86],"class_list":["post-18358","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artikel","category-virtualisierung","tag-amazon","tag-ci-cd","tag-cloud","tag-container","tag-docker","tag-google","tag-kubernetes","tag-orchestrierung","tag-trend-micro"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/18358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=18358"}],"version-history":[{"count":1,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/18358\/revisions"}],"predecessor-version":[{"id":18363,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/18358\/revisions\/18363"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/media\/18359"}],"wp:attachment":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=18358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=18358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=18358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}