Container werden heute niemanden überraschen. Sie werden von der Frage zur Containersicherheit überrascht sein. Es ist besonders interessant, Kollegen, die Container und Microservices in der Produktion verwenden, ernsthaft zu befragen: Oft sehe ich überraschte Gesichter und eine verwirrte Frage. Sie sagen: „Was, warum ist das so?“. Es stellt sich heraus, dass wir bereits über Technologie Bescheid wissen (und wie können wir das nicht wissen: Es scheint, dass sogar Schulkinder bald in der Lage sein werden, einen Kubernetes-Cluster als Klasse im Technologieunterricht aufzubauen), aber sie haben noch nicht gelernt, wie man seine Komponenten schützt. Vielleicht gab es einfach niemanden, der unterrichtete.
In diesem Artikel und auf
DevOops werden wir Redner haben, die einen Hund zum Thema containerfreundliche Sicherheitslösungen
gefressen haben. Wir gehen zu ihnen, um Antworten auf die einfachsten Fragen zur Cloud-Sicherheit zu erhalten. Ist es notwendig, mit etwas Selbstbildung zu beginnen?
Die Teilnehmer:
Seth Vargo leitet den Developer Advocate bei Google. Zuvor arbeitete er bei HashiCorp, Chef Software, CustomInk und mehreren anderen Startups in Pittsburgh. Er ist Autor von Learning Chef und setzt sich für den Abbau von technologischen Ungleichheiten ein.
Liz Rice ist technische Evangelistin bei Aqua Security, einer Cloud-basierten Sicherheitslösung für die Anwendungsbereitstellung und Containerunternehmen. Liz ist eine sehr berühmte Person in der Gemeinde, die Vorsitzende von Kubeon-s .
Oleg Chirukhin, Herausgeber der JUG.ru Group
Beginnen wir mit einer Frage, die unsere weitere Diskussion bestimmen wird. Was bedeutet DevOps für Sie? Wie unterscheidet es sich von der weniger bekannten SRE?
Als ich zum Beispiel bei einem früheren Job gebeten wurde, „DevOps zu implementieren“, ging ich einfach durch das Inhaltsverzeichnis des SRE-Buches , griff nach Ideen und wandte sie einzeln an. Na ja, oder zumindest habe ich versucht, sie anderen zu vermitteln. Was sagen Sie - ist das der richtige Ansatz?
Wenn wir über DevOps sprechen, sprechen wir über die Vermeidung des Abgrunds aus der Lücke, die normalerweise zwischen den Codeentwicklungsprozessen (Dev) und ihrer anschließenden Wartung (Ops) bestand. Stellen Sie sich vor, wir haben eine hohe Mauer, auf deren einer Seite Entwickler sitzen. Er erstellt einen Code und wirft ihn über die Mauer. Auf der anderen Seite der Mauer stehen Menschen, die sich für Unterstützung einsetzen. Sie fangen die übertragene Anwendung ab und beginnen mit dem Start und der Wartung. Und diese Leute kennen die Details, die während des Betriebs benötigt werden. Zum Beispiel, welche Ports und wo zugewiesen und geöffnet werden.
Anstatt zwei getrennte Gruppen von Menschen mit unterschiedlichen Interessen zu haben, möchte ich sie miteinander kommunizieren lassen, entscheiden, was als nächstes zu tun ist, und gemeinsam bestimmen, welche Ziele sie während des Arbeitstages gemeinsam erreichen wollen. DevOps ist also eine Veränderung in der Kommunikationskultur, die Kollegen in verschiedenen technischen Teams dabei hilft, für das Gemeinwohl zu arbeiten: Wert für das Unternehmen schaffen, Software bereitstellen und weiterarbeiten. Ich denke, dies sind sehr wichtige Änderungen, die neue verwandte Tools mit sich bringen: Wenn Sie keine Kommunikationskultur haben, ist es nicht sinnvoll, dieselben CI / CD-Prozesse einzuführen.
Es gibt oft Verwechslungen mit den Konzepten von DevOps und SRE. Einige Leute denken, dass SRE mit DevOps konkurriert, andere betrachten sie als völlig andere, überlappende Konzepte. Meiner Meinung nach sind sie keine Konkurrenten, sondern enge Freunde. Denken Sie an die Ansätze, die DevOps zugrunde liegen: Reduzierung der Organisationskosten, Behandlung von Fehlern als normaler Bestandteil des Workflows, schrittweise Einführung von Änderungen, Automatisierung und Implementierung der dafür erforderlichen Tools sowie Verwendung von Metriken zur Bewertung von Prozessen. Wie Sie sehen, ist dies alles sehr abstrakt: DevOps sagt uns nicht, wie wir die Organisationskosten senken oder schrittweise Änderungen einführen können, sondern nur, dass es schön wäre, wenn sie implementiert würden.
Nun schauen wir uns SRE an. Obwohl sich der SRE-Ansatz unabhängig vom DevOps-Ansatz entwickelt hat, ist SRE, könnte man sagen, eine Implementierung der DevOps-Prinzipien: Wenn Sie sich DevOps als abstrakte Klasse oder Schnittstelle in der Programmierung vorstellen, wird SRE eine konkrete Klasse sein, die diese Schnittstelle implementiert. SRE hat klar definierte Ansätze für eine Vielzahl von Dingen und Konzepten: Miteigentum, Risikoteilung, Obduktion, Erfassung und Akkumulation von Metrikwerten und vieles mehr. Daher ist es für Unternehmen bequemer, über die Einführung von SRE zu sprechen, da sehr verständliche Prozesse und Einheiten vorhanden sind.
Denken Sie, dass der Begriff "DevOps-Ingenieur" richtig ist? Kann es irgendwie ersetzt werden?
Ich persönlich glaube nicht, dass das Konzept des "DevOps-Ingenieurs" existiert. In meinem Artikel „10 Mythen von DevOps“ können Sie ausführlicher lesen, dass „DevOps“ tatsächlich eine Ideologie ist: mehr Kommunikation und Zusammenarbeit zwischen verschiedenen, aber im Wesentlichen verbundenen Organisationseinheiten. Obwohl es heute ziemlich robust und vertraut aussieht, erregte ein solcher Ansatz zunächst sowohl Lob als auch scharfe Kritik. Seitdem haben viele Organisationen, darunter Etsy, Facebook und Flick, die Prinzipien von DevOps überraschend erfolgreich umgesetzt.
Daher stellte keine dieser Organisationen „DevOps-Ingenieure“ ein. Der Erfolg der Implementierung ist auf die sich abzeichnende interne Zusammenarbeit der Teams und die Bereitschaft zurückzuführen, ihre bestehenden Prozesse und Verfahren zu ändern, um ein gemeinsames Ziel zu erreichen. Die Rolle des sogenannten „DevOps-Ingenieurs“ bestand darin, die Zusammenarbeit zwischen Gruppen zu fördern und sicherzustellen, dass Organisationseinheiten regelmäßig Ideen und Ziele austauschen. Eigentlich haben wir diese Leute schon heute und wir nennen sie "Manager".
Ich werde noch einen Moment hinzufügen. Wenn wir jemanden für eine bestimmte Position oder Rolle ernennen, erwarten wir von ihm ganz bestimmte Dinge und Handlungen. Daher ist die Auswahl einer Berufsbezeichnung wichtig. Die genauen Namen der Stellen können jedoch aufgrund lokaler Realitäten und Traditionen, die von der Organisation übernommen wurden, abweichen. Daher ist es nicht wichtig, den Namen als solchen zu verwenden, sondern das Gleichgewicht zwischen den Stellen aller Personen, die im Unternehmen arbeiten.
Vor nicht allzu langer Zeit habe ich mit einer Person gesprochen, die in einer ziemlich großen Organisation gearbeitet hat. Deshalb haben sie ein Team von mehreren Mitarbeitern zusammengestellt und es beispielsweise als Infrastruktur-Team bezeichnet. Dann wurde dieses Team in etwas anderes umbenannt und nach einer Weile wurde ein anderes Team gegründet, und jetzt wurde es als Infrastruktur-Team bezeichnet - daher waren alle nur verwirrt: Wer sind die „Infrastruktur-Spezialisten“ und welche Rolle spielen sie?
Meiner Meinung nach ist das Wichtigste nicht die Existenz eines Teams oder einer Position mit einem bestimmten Namen, sondern die Präsenz eines klaren Verständnisses innerhalb der Organisation, wer für was verantwortlich ist. Es spielt keine Rolle, ob sie sie SRE oder DevOps nennen: Die Hauptsache ist zu verstehen, was ein bestimmter Name für diese bestimmte Organisation bedeutet.
Liz, Sie beraten, wie erklären Sie Kundenunternehmen die DevOps-Prinzipien? Sie klingen ziemlich abstrakt und etwas schwer zu erklären. Oder haben Sie einen Ansatz entwickelt, mit dem Sie diese Ideen an Kunden weitergeben können?
Es kommt auf den Zweck an. Viele Personen und Unternehmen, mit denen ich im Rahmen der Konsultationen kommuniziere, kommen zu uns und sagen, dass sie Kubernetes und Container bereitstellen möchten. Bevor Sie jedoch über Technologie sprechen, müssen Sie verstehen, warum sie versuchen, solche Schritte zu unternehmen. Und es stellt sich heraus, dass der erwartete Nutzen von Veränderungen häufig auf dem Wunsch beruht, flexibler zu sein. Daher erklärte die Bewegung in die Richtung, dass technische Teams die Ergebnisse ihrer Arbeit schneller veröffentlichen könnten, so etwas „an den Fingern“. An dieser Stelle ist es nützlich, die Konversation dahingehend zu verschieben, dass das Problem der mangelnden Kultur (Gewohnheiten, wenn Sie möchten) der Kommunikation zwischen Teammitgliedern nicht durch das „Werfen“ neuer Technologien unterstützt wird. Diese Kommunikation ist die wichtigste Ressource.
Da ich häufig an der Verbesserung der Sicherheit von Lösungen beteiligt bin, verlagert sich unser Gespräch außerdem in Richtung „Dev - ** Sec ** - Ops“, und es stellt sich heraus, dass der Aufbau des Systems so erfolgen sollte, dass die meisten In den frühen Phasen der Prozesse und nicht nur auf die altmodische Weise an die Frage herangegangen: Zuerst schreiben wir den Anwendungscode, dann stellen wir ihn bereit, dann übergeben wir ihn an den Wartungsdienst, und erst ganz am Ende beginnt jemand, über die Sicherheit des laufenden Codes nachzudenken.
Tatsächlich sind viele Sicherheitsprobleme zu Beginn des Prozesses billiger und einfacher zu lösen, aber Sie müssen von Anfang an viele Punkte in das Projekt einbringen. Wenn Sie beispielsweise mit Containern arbeiten möchten, müssen Sie sich Sorgen machen, dass die Bilder auf ziemlich sichere Weise erfasst werden. Es kann nützlich sein, sie auf Schwachstellen zu scannen, um zumindest die Bereitstellung von Software mit bereits bekannten Sicherheitsproblemen zu vermeiden. Vielleicht werden Sie versuchen, die Container so zu konfigurieren, dass die darin enthaltene Software nicht standardmäßig als Root gestartet wird (der Einfachheit halber werden sie der Einfachheit halber ohne besondere Notwendigkeit beim Zusammenstellen der Container ausgeführt). Wenn Sie diese Schritte ausführen, erhalten Sie am Ende eine Erhöhung der Sicherheit Ihrer Anwendung, und Sie können im Kontext all dieser DevOps über die SecOps-Kultur sprechen.
Dies bedeutet jedoch, dass Entwickler, die eigentlich keine Experten für Anwendungssicherheit sind, gezwungen sind, nicht nur über den Anwendungscode nachzudenken, sondern auch ihre eigenen Sicherheitssysteme zu erstellen. Was sollte Ihrer Meinung nach das Mindestmaß an Fähigkeiten für einen modernen Softwareentwickler oder Betriebsingenieur sein?
Sie und ich, ob es uns gefällt oder nicht, sehen ständig neue Regeln und Anforderungen, die sich irgendwann als notwendig herausstellen, um Folgendes zu erfüllen und einzuhalten: Nehmen Sie die gleiche DSGVO als Beispiel. Die Entstehung und Existenz dieser Vorschriften bedeutet, dass immer mehr Menschen ein Gefühl der Sicherheit haben müssen. Beispielsweise können Sie heute Benutzernamen und Kennwörter nicht mehr im Klartext in Datenbankfeldern speichern - dies wird nicht mehr als zumindest tolerierbar angesehen. Ich würde sagen, dass in der Branche bereits für jeden ganz klare Anforderungen an "Hygiene" bestehen.
Die Hersteller von Tools und Infrastrukturen selbst haben einen erheblichen Einfluss auf diesen Prozess und versuchen, Systeme so zu entwerfen und zu ändern, dass Benutzer von Anfang an sicherere Anwendungen und Systeme erstellen können. In Kubernetes haben sich beispielsweise im letzten Jahr viele der Standardeinstellungen und Parameterwerte geändert, um die Sicherheit zu erhöhen, und das ist wirklich sehr cool. Bisher war der API-Server standardmäßig für anonymen Zugriff geöffnet - dies ist nicht ganz das, was Sie von "out of the box" erwarten. Jetzt sind Dinge wie die rollenbasierte Zugriffskontrolle aufgetaucht, sodass wir jetzt über Berechtigungen verfügen (ja, "out of the box"). Wenn Sie Kubernetes zum ersten Mal starten, sind Sie nicht für die ganze Welt offen, sondern standardmäßig geschützt. Ich denke, dies ist eine gute Möglichkeit, die Sicherheit im Verlauf vertrauter Prozesse allen zur Verfügung zu stellen, da wir die Standardwerte nicht ständig in sichere ändern müssen (was außerdem berücksichtigt werden musste).
Persönlich glaube ich, dass jeder Softwareentwickler mindestens ein grundlegendes Verständnis von Sicherheit haben sollte. Dinge wie die OWASP-Ansätze (Open Web Application Security Project) helfen, aber letztendlich müssen die Ingenieure Autodidakten sein. Es ist unwahrscheinlich, dass jeder Ingenieur über einen Doktortitel in Kryptographie verfügt. Wenn wir jedoch möchten, dass unsere Kollegen die Sicherheit ernst nehmen, sollten wir es ihnen leichter machen, die richtigen Entscheidungen zu treffen. Hier können Tools wie Vault helfen - und Sicherheitsteams und Fachleute können Entscheidungen treffen und „Sicherheit als API“ bereitstellen.
Wenn ich das richtig verstehe, besteht die Tendenz, alles in Code umzuwandeln. Alles als Code. Infrastruktur als Code, Prozesse als Code, Code als Code. Was sind die Auswirkungen?
Bevor wir über die Konsequenzen sprechen, müssen wir über die Vorteile sprechen. Der Code gibt es schon sehr lange. Anwendungen waren schon immer „Code“, und in dieser Zeit wurde ein umfangreiches Ökosystem von Tools und Prozessen geschaffen, um den Anwendungsentwicklungsprozess zu unterstützen und zu verbessern (CI / CD, Flusen, Tools für die gemeinsame Entwicklung usw.). Nachdem wir die Infrastruktur als Code, Prozesse als Code, Sicherheit als Code beschrieben haben, können wir dasselbe Ökosystem verwenden, ohne dafür etwas extra zu bezahlen. Sie können gemeinsam Infrastrukturänderungen entwickeln, Richtlinienüberprüfungen durchführen usw. Sie können Infrastrukturänderungen testen, bevor Sie sie bereitstellen. Dies sind nur einige der Vorteile, die mit der Übersetzung von etwas in Code verbunden sind.
Ich denke, die größten Konsequenzen sind Zeit und Komplexität. Wenn Sie mit etwas „wie mit Code“ arbeiten (z. B. über Terraform, Vault, CloudFormation, Deployment Manager usw.), müssen Sie manchmal auf Diskrepanzen zwischen dem, was im Code geschrieben ist, und dem, was tatsächlich passiert, stoßen in der Wolke. Die Modellierung komplexer Beziehungen ist manchmal visuell schwierig, insbesondere unter Berücksichtigung der Skalierung. Darüber hinaus kann es zu Ungenauigkeiten bei Abstraktionen kommen. Beispielsweise kann ein Skript, das über die API arbeitet, den aktuellen Status nicht wahrnehmen, wenn er den Benutzern über die Weboberfläche angezeigt wird. Mit der Zeit nimmt jedoch die Komplexität ab und die Flexibilität kehrt zurück.
Code und andere formale Modelle sind ein Bereich, der für maschinelle Analyse und maschinelles Lernen geeignet ist. Wann genau werden uns Roboter ersetzen? Wie sollen wir reagieren?
Können Roboter Kubernetes ohne Menschen konfigurieren? Insbesondere kann es vorkommen, dass einige Berufe (z. B. ein Systemadministrator oder ein Software-Tester mit einem hohen Maß an Interaktivität - ein sozial akzeptables Wort für einen „manuellen Tester“) einfach verschwinden?
Ich glaube nicht, dass die Menschen verschwinden werden, aber ich vermute, dass einige der Arbeitsplätze, die wir heute haben, in Zukunft nicht mehr gerettet werden. Ich lebe in Pittsburgh, der Welthauptstadt autonomer Autokontrollsysteme, und sehe selbstfahrende Autos buchstäblich jeden Tag. In Zukunft werden Taxifahrer natürlich durch Roboter-Fahrtechnologien ersetzt. Vielleicht nicht sofort, aber nach 10 oder mehr Jahren, aber diese Zukunft wird unweigerlich kommen. Ich denke jedoch, dass Taxifahrer nicht verschwinden werden. Die Menschheit erfindet sich ständig neu.
Ich glaube, dass dies auch für maschinelles Lernen im Bereich Management gilt. Ich freue mich auf mehr KI, um unsere Systeme stabiler und belastbarer zu machen, und ich denke, wir können uns entscheiden, diesen Ansatz zu bekämpfen - oder ihn zu akzeptieren. Die Rolle traditioneller Systemadministratoren kann durch jemanden ersetzt werden, der das KI-System kontrolliert. Dies bedeutet jedoch nicht, dass die Personen selbst verschwinden. Wir haben die gleichen Veränderungen in mehreren Branchen erlebt, in denen Technologie und Innovation eine höhere Geschwindigkeit und Genauigkeit als Menschen bieten, aber am Ende muss jemand den Robotern folgen :).
Stellen Sie sich vor, ein reguläres Entwicklungsteam erstellt eine Webanwendung und platziert sie in einem Kubernetes-Cluster. Wie können wir sicherstellen, dass die Anwendung sicher ist? Stellen Sie einen Blackhat-Hacker oder Spezialisten ein, der versucht, Sicherheitslücken zu finden, oder gibt es weniger komplizierte Möglichkeiten?
Wir von Aqua Security haben kürzlich ein Open-Source-Tool namens kube-hunter veröffentlicht . Es ist in der Lage, Kubernetes auf Hacking oder Penetration zu testen - was es zu einem ziemlich einfachen Test macht. Sie können dieses Tool verwenden und Ihren eigenen Cluster testen, und Sie werden mit ziemlicher Sicherheit etwas Interessantes für sich selbst lernen, insbesondere wenn Ihre Installation auf der alten Version von Kubernetes basiert, bei der die Standardeinstellungen weniger sicher waren - möglicherweise haben Sie dies beispielsweise offene Ports.
Wir alle haben Geschichten über Leute gehört, die "vergessen" haben, ihr Cluster-Kontrollfeld für den freien Zugriff auf das gesamte Internet zu schließen. Daher bestand das Ziel der Erstellung von kube-hunter darin, unser eigenes System zu überprüfen und sicherzustellen, dass es geschützt ist. Nach unserer Meinung scannen Hacker Hosts im Internet seit langem nach offenen, bekannten Ressourcen und Ports. Daher ist Ihr Kubernetes-Kontrollfeld, das zufällig nicht geschützt ist (und daher für alle zugänglich ist), möglicherweise nicht so schwer zu finden, insbesondere mit Tools, die sie sind es gewohnt zu benutzen.
Wir möchten, dass Hunter gewöhnlichen Kubernetes-Administratoren hilft, besser zu verstehen, ob Konfigurationsprobleme in ihrer Bereitstellung auftreten. Daher wurde es ausschließlich für Kubernetes entwickelt und meldet, dass es in einer Sprache gefunden wurde, die Kubernetes-Benutzer verstehen. Wir werden Sie also darüber informieren, dass Sie keinen Port 6443 geöffnet haben, sondern beispielsweise auf diese bestimmte Komponente von Kubernetes zugreifen. Auf diese Weise können Benutzer leichter feststellen, ob das, was sie gefunden haben, ein Problem mit einer sicherheitsschwächenden Konfiguration ist und ob es sich lohnt, es sofort zu beheben - ohne ein Kubernetes-Sicherheitsexperte zu sein. Wir möchten versuchen, diese Überprüfungen jederzeit verfügbar zu machen, ohne dass externe Experten erforderlich sind.
Es gibt eine Beobachtung: Viele interessieren sich nicht mehr dafür, was sich in den Containern befindet, die sie starten.
Ja, und sie haben keine Ahnung, welche Abhängigkeiten in diese Container eingebaut wurden. Wenn Sie jedoch planen, den Container-Ansatz für die Bereitstellung des Dienstes zu verwenden, erscheint es sinnvoll, herauszufinden, welche Art von Software sich in diesem oder jenem Image befindet. Dies ist jedoch kein Problem des Container-Ansatzes selbst, sondern nur eine Einstellung derjenigen, die den Ansatz verwenden, zur Sicherheit.
Es ist nicht so schwierig, alles richtig und zuverlässig zu machen. Wenn Sie sich in die Cloud-Welt begeben, müssen Sie zusätzliche Tools verwenden, die mit ziemlicher Sicherheit zusätzliche Sicherheitsstufen bieten.
Wolken haben ihre eigenen Besonderheiten. Zum Beispiel stoße ich oft auf das Missverständnis, dass in der Cloud-Welt ein Tool, an das die Menschen früher gewöhnt waren, automatisch alles tut, was sie brauchen. In gewisser Hinsicht sind sie richtig: Nehmen wir an, Sie können die übliche (und immer funktionierende) Liste von Firewall-Einstellungen verwenden, was die Sicherheit erhöht, aber einige der alten Tools sind heute nicht mehr geeignet. Wenn Sie beispielsweise ein Container-Image bereitstellen und das alte bekannte Tool zum Scannen nach Schwachstellen verwenden, findet der Scanner, wenn er nicht weiß, wie er in das Image schauen soll, einfach nichts und Sie erhalten (möglicherweise falsches) Vertrauen, dass alles in Ordnung ist.
Ich mag es wirklich, wenn Sie sich der Architektur von Microservices zuwenden, erhalten Sie eine ziemlich große Anzahl kleiner Funktionen in Containern (deren Inhalt sich in Ihrer Handfläche befindet) und Sie können den Verkehr zwischen ihnen sehen. Jeder der Container kann als eine Art Black Box wahrgenommen werden, von der streng definierte Aktionen erwartet werden. Und sobald sich dieser oder jener Container unerwartet verhält oder seltsame Ergebnisse liefert, ist es möglich, darauf zu reagieren. Je besser die spezifischen Bilder der Container zusammengestellt und konfiguriert sind, desto verständlicher ist es, ob sie ordnungsgemäß funktionieren.
Und wie kann man Anomalien erkennen? Verwenden Sie so etwas wie Antivirus-Heuristiken, neuronale Netze?
Während des gesamten Software-Lebenszyklus verwenden wir verschiedene Sicherheitstools. runtime enforcer — , , . «», , , nginx, , nginx . , , «» , . , , . : , , .
. Serverless , , . . « »? , ?
, severless , , , . serverless — . severless-, «», . , «- ». severless. serverless- . «» , ( «» ) .
serverless – « ». serverless- pub/sub, , Redis . , , - () .
severless- , . , , , serverless- . - . , , , . serverless, - .
, serverless- . , , . ?
, , — , , , DevOps. , , , , .
, , : YAML. , Kubernetes Kubernetes, YAML. , 30 000 YAML. , , , 30 000 YAML, , , .
, Kubernetes . , , ?
Kubernetes , . , , , , - , . , , YAML- , , Kubernetes . , . , .
, Kubernetes — , . . , Kubernetes CNCF graduated, , , , , CNCF .
, : YAML, , . , YAML Kubernetes.
, YAML, , , , YAML. , , , - YAML .
, Kubernetes, , ?
. , , , , . – Istio ( service mesh), 1.0. , , , «».
, - , .
, ?
C . , , , , !
! , : — .
DevOops 2018 «Modern security with microservices and the cloud» , «Practical steps for securing your container deployment» . .