Helm-Sicherheit

Die Essenz der Geschichte über den beliebtesten Paketmanager für Kubernetes könnte man mit Emojis darstellen:

• Schachtel — das ist Helm (das passendste Emoji in der letzten Version);
• Schloss — Sicherheit;
• Männchen — die Lösung des Problems.

In Wirklichkeit wird alles jedoch etwas komplizierter, und die Geschichte ist reich an technischen Details darüber, wie man Helm sicher macht..

• Kurz gesagt, was ist Helm, falls Sie es nicht wussten oder vergessen haben? Welche Probleme löst es und wo steht es im Ökosystem?
• Lassen Sie uns die Architektur von Helm betrachten. Kein Gespräch über Sicherheit und darüber, wie man ein Werkzeug oder eine Lösung sicherer macht, kann ohne Verständnis der Architektur des Komponenten erfolgen.
• Lassen Sie uns die Komponenten von Helm besprechen.
• Die drängendste Frage - die Zukunft - die neue Version von Helm 3. 

Alles in diesem Artikel bezieht sich auf Helm 2. Diese Version ist derzeit in Produktion und höchstwahrscheinlich nutzen Sie именно diese, und genau darin gibt es Sicherheitsbedenken.

Über den Sprecher: Alexander Khayev (allexx) ist seit 10 Jahren in der Entwicklung tätig und hilft, Inhalte zu verbessern. Moscow Python Conf++ und ist dem Komitee beigetreten Helm Summit. Derzeit arbeitet er als Development Lead bei Chainstack – eine hybride Rolle zwischen der Leitung der Entwicklung und der Verantwortung für die Lieferung von Endversionen. Das bedeutet, er befindet sich dort, wo alles geschieht, von der Produktentwicklung bis zum Betrieb.

Chainstack ist ein kleines, dynamisch wachsendes Start-up, dessen Ziel es ist, Kunden die Probleme mit der Infrastruktur und dem Betrieb von dezentralen Anwendungen abzunehmen. Das Entwicklungsteam hat seinen Sitz in Singapur. Bitten Sie Chainstack nicht, Kryptowährungen zu kaufen oder zu verkaufen, aber schlagen Sie ein Gespräch über Enterprise-Blockchain-Frameworks vor, und Sie werden mit Freude empfangen.

Helm

Das ist ein Paketmanager (Charts) für Kubernetes. Der klarste und vielseitigste Weg, um Anwendungen in einen Kubernetes-Cluster zu bringen.

Es geht hierbei eindeutig um einen strukturierten und industriellen Ansatz, im Gegensatz zur Erstellung eigener YAML-Manifeste und der Entwicklung kleinerer Tools.

Helm ist das Beste, was derzeit verfügbar und populär ist.

Warum Helm? Zunächst einmal, weil es von der CNCF unterstützt wird. Cloud Native ist eine große Organisation, die die Muttergesellschaft für Projekte wie Kubernetes, etcd, Fluentd und andere ist.

Ein weiterer wichtiger Fakt ist, dass Helm ein sehr beliebtes Projekt ist. Als ich im Januar 2019 begann, darüber nachzudenken, wie man Helm sicher macht, hatte das Projekt auf GitHub etwa tausend Sterne. Bis Mai waren es bereits 12.000.

Viele interessieren sich für Helm, daher werden Ihnen auch dann Kenntnisse über seine Sicherheit nützlich sein, wenn Sie es bisher noch nicht verwenden. Sicherheit ist wichtig.

Das Hauptteam von Helm wird von Microsoft Azure unterstützt, weshalb es ein recht stabiles Projekt ist, im Gegensatz zu vielen anderen. Die Veröffentlichung von Helm 3 Alpha 2 Mitte Juli zeigt, dass viele Menschen an dem Projekt arbeiten und bereit sind, Helm weiterzuentwickeln und zu verbessern.

Helm löst mehrere grundlegende Probleme bei der Verwaltung von Anwendungen in Kubernetes.

• Das Packen von Anwendungen. Selbst eine Anwendung wie "Hello, World" auf WordPress besteht bereits aus mehreren Diensten, die zusammen verpackt werden wollen.
• Die Verwaltung der Komplexität, die bei der Verwaltung dieser Anwendungen entsteht.
• Der Lebenszyklus endet nicht nach der Installation oder Bereitstellung der Anwendung. Sie bleibt aktiv, erfordert regelmäßige Updates, und Helm unterstützt dabei, indem es die richtigen Maßnahmen und Richtlinien bereitstellt.

Paketierung ist klar strukturiert: Es gibt Metadaten, die vollständig mit der Funktionsweise eines typischen Paketmanagers für Linux, Windows oder MacOS übereinstimmen. Das bedeutet Repository, Abhängigkeiten verschiedener Pakete, Metainformationen für Anwendungen, Konfigurationseinstellungen, Besonderheiten der Einrichtung, Informationsindizierung usw. All das ermöglicht Helm, um es für Anwendungen zu nutzen.

Komplexitätsmanagement. Wenn Sie viele gleichartige Anwendungen haben, ist eine Parametrisierung notwendig. Daraus ergeben sich Templates, aber um nicht selbst einen Weg zur Erstellung von Templates zu entwickeln, kann man das nutzen, was Helm standardmäßig anbietet.

Management des Lebenszyklus von Anwendungen — das ist meiner Meinung nach die interessanteste und noch ungelöste Frage. Genau aus diesem Grund habe ich mich damals für Helm entschieden. Wir mussten den Lebenszyklus der Anwendung im Blick behalten und wollten unsere CI/CD- und Anwendungszyklen in dieses Paradigma überführen.

Helm ermöglicht:

• Verwalten von Deployments, Einführung von Konfiguration und Revision;
• Rollback erfolgreich durchführen;
• Hooks für verschiedene Ereignisse verwenden;
• Zusätzliche Prüfungen von Anwendungen hinzufügen und auf deren Ergebnisse reagieren.

Darüber hinaus verfügt Helm über „Batterien“ – eine enorme Anzahl nützlicher Dinge, die man als Plugins einfügen kann, um das Leben zu erleichtern. Plugins können selbst geschrieben werden, sie sind recht isoliert und erfordern keine strenge Architektur. Wenn Sie etwas umsetzen möchten, empfehle ich, dies als Plugin zu entwickeln und dann möglicherweise in das Upstream zu integrieren.

Helm basiert auf drei grundlegenden Konzepten:

• Chart-Repo – eine Beschreibung und eine Reihe von Parametrierungen, die für Ihr Manifest möglich sind. 
• Konfiguration – also die Werte, die angewendet werden, (Text, numerische Werte usw.).
• Release vereint die beiden oberen Komponenten, und zusammen ergeben sie ein Release. Releases können versioniert werden, wodurch der Lebenszyklus organisiert wird: klein zum Zeitpunkt der Installation und groß zum Zeitpunkt des Upgrades, Downgrades oder Rollbacks.

Architektur von Helm

Das Diagramm spiegelt konzeptionell die hochrangige Architektur von Helm wider.

Ich erinnere daran, dass Helm etwas ist, das mit Kubernetes zu tun hat. Daher benötigen wir einen Kubernetes-Cluster (Rechteck). Die Komponente kube-apiserver befindet sich auf dem Master. Ohne Helm haben wir Kubeconfig. Helm bringt ein kleines binäres Tool mit, das man Helm CLI nennt und auf jedem Gerät installiert werden kann — auf Computern, Laptops, Mainframes – auf alles.

Aber das ist nicht genug. Helm hat eine serverseitige Komponente namens Tiller. Diese repräsentiert Helm innerhalb des Clusters; es ist eine Anwendung innerhalb des Kubernetes-Clusters, wie jede andere auch.

Die nächste Komponente ist das Chart Repo — ein Repository mit Charts. Es gibt ein offizielles Repository, und möglicherweise auch ein privates Repository des Unternehmens oder Projekts.

Interaktion

Lassen Sie uns betrachten, wie die Komponenten der Architektur interagieren, wenn wir eine Anwendung mit Helm installieren möchten.

• Wir geben Helm install, kontaktieren das Repository (Chart Repo) und erhalten das Helm-Chart.

• Das Helm-Tool (Helm CLI) interagiert mit Kubeconfig, um herauszufinden, mit welchem Cluster es kommunizieren soll. 
• Sobald diese Informationen vorliegen, wendet sich das Tool an Tiller, das sich bereits als Anwendung in unserem Cluster befindet. 
• Tiller kommuniziert mit dem Kube-apiserver, um Aktionen in Kubernetes durchzuführen, bestimmte Objekte (Dienste, Pods, Replikate, Secrets usw.) zu erstellen.

Als nächstes werden wir das Schema komplexer gestalten, um die Angriffsvektoren zu erkennen, denen die gesamte Helm-Architektur ausgesetzt sein könnte. Danach werden wir versuchen, sie zu schützen.

Angriffsvektor

Der erste potenziell schwache Punkt ist privilegierte API—Benutzer. Im Schema ist dies ein Hacker, der administrativen Zugriff auf das Helm CLI erhalten hat.

Ein unprivilegierter API-Benutzer kann ebenfalls eine Bedrohung darstellen, wenn er sich in der Nähe befindet. Ein solcher Benutzer hat einen anderen Kontext, zum Beispiel könnte er in einem bestimmten Namespace des Clusters in den Kubeconfig-Einstellungen verankert sein.

Der interessanteste Angriffsvektor könnte ein Prozess sein, der sich innerhalb des Clusters in der Nähe von Tiller befindet und auf ihn zugreifen kann. Das könnte ein Webserver oder ein Mikroservice sein, der die Netzwerkumgebung des Clusters sieht.

Eine exotische, aber zunehmend beliebte Angriffsart ist mit dem Chart Repo verbunden. Ein Chart, das von einem unehrlichen Autor erstellt wurde, kann unsichere Ressourcen enthalten, und Sie könnten es gutgläubig ausführen. Alternativ kann er das Chart, das Sie aus dem offiziellen Repository herunterladen, manipulieren und beispielsweise Ressourcen in Form von Richtlinien erstellen, um sich selbst Zugriff zu verschaffen.

Lassen Sie uns versuchen, uns gegen Angriffe von all diesen vier Seiten zu verteidigen und herauszufinden, wo die Probleme in der Architektur von Helm liegen und wo möglicherweise keine bestehen.

Wir vergrößern das Schema, fügen mehr Elemente hinzu, behalten aber alle grundlegenden Bestandteile bei.

Die Helm-CLI kommuniziert mit dem Chart Repo, interagiert mit Kubeconfig, und die Arbeit wird an den Cluster im Tiller-Komponenten übergeben.

Tiller wird durch zwei Objekte repräsentiert:

• Tiller-deploy svc, das einen Dienst bereitstellt;
• Tiller-deploy pod (in dem Schema in einem Exemplar in einer Replikation), auf dem die gesamte Last ausgeführt wird und der mit dem Cluster kommuniziert.

Für die Interaktion werden verschiedene Protokolle und Schemata verwendet. Aus Sicherheitsgründen sind uns folgende besonders wichtig:

• Der Mechanismus, mit dem die Helm-CLI auf das Chart Repo zugreift: welches Protokoll verwendet wird, ob eine Authentifizierung stattfindet und was damit gemacht werden kann.
• Das Protokoll, über das das Helm CLI mit kubectl mit Tiller kommuniziert. Dies ist ein RPC-Server, der innerhalb des Clusters installiert ist.
• Tiller selbst ist für die Microservices, die sich im Cluster befinden, zugänglich und interagiert mit dem Kube-apiserver.

Lassen Sie uns all diese Themen der Reihe nach besprechen.

RBAC

Es ist sinnlos, über die Sicherheit von Helm oder anderen Diensten innerhalb des Clusters zu sprechen, wenn RBAC nicht aktiviert ist.

Es scheint zwar nicht die aktuellste Empfehlung zu sein, aber ich bin mir sicher, dass viele RBAC selbst in der Produktion noch nicht aktiviert haben, weil es viel Aufwand erfordert und viele Einstellungen notwendig sind. Dennoch möchte ich Sie dazu anregen, dies zu tun.

https://rbac.dev/ — die Website für RBAC. Dort finden Sie eine Vielzahl interessanter Materialien, die Ihnen helfen, RBAC einzurichten, erklären, warum es gut ist und wie man es im Produktionsumfeld nutzen kann.

Ich möchte erklären, wie Tiller und RBAC funktionieren. Tiller operiert innerhalb des Clusters unter einem bestimmten Dienstkonto. In der Regel, wenn RBAC nicht konfiguriert ist, handelt es sich um einen Superuser. In der Standardkonfiguration wird Tiller als Administrator fungieren. Deshalb sagt man oft, dass Tiller ein SSH-Tunnel zu Ihrem Cluster ist. Tatsächlich ist das der Fall, und daher kann ein separates, spezialisiertes Dienstkonto anstelle des Standarddienstkontos in obiger Abbildung verwendet werden.

Wenn Sie Helm initialisieren und es zum ersten Mal auf dem Server installieren, können Sie ein Dienstkonto mit --service-accountangeben. Dies ermöglicht die Verwendung eines Benutzers mit den minimal notwendigen Rechten. Sie müssen jedoch eine solche 'Kette' erstellen: Role und RoleBinding.

Leider erledigt Helm das nicht für Sie. Sie oder Ihr Kubernetes-Cluster-Administrator müssen im Vorfeld ein Set aus Role und RoleBinding für das Dienstkonto vorbereiten, um es an Helm weiterzugeben.

Die Frage stellt sich, was der Unterschied zwischen Role und ClusterRole ist? Der Unterschied liegt darin, dass ClusterRole für alle Namespaces gilt, im Gegensatz zu den üblichen Role und RoleBinding, die nur für einen bestimmten Namespace funktionieren. Es ist möglich, Richtlinien sowohl für den gesamten Cluster und alle Namespaces als auch individuell für jeden Namespace festzulegen.

Es ist erwähnenswert, dass RBAC ein weiteres großes Problem löst. Viele beschweren sich, dass Helm leider keine Multitenancy unterstützt. Wenn mehrere Teams einen Cluster nutzen und Helm einsetzen, ist es grundsätzlich nicht möglich, Richtlinien einzurichten und deren Zugriff innerhalb dieses Clusters zu differenzieren, da es einen bestimmten Service-Account gibt, unter dem Helm läuft, und dieser erstellt alle Ressourcen im Cluster unter diesem Account, was oft sehr unpraktisch ist. Das ist tatsächlich der Fall – sowohl die Binärdatei als auch der Prozess, Helm Tiller hat kein Konzept für Multitenancy..

Es gibt jedoch einen großartigen Weg, um Tiller in einem Cluster mehrfach zu starten. Damit gibt es keine Probleme, Tiller kann in jedem Namespace gestartet werden. So können Sie RBAC und Kubeconfig als Kontext nutzen und den Zugriff auf einen speziellen Helm einschränken.

So könnte es aussehen.

Zum Beispiel gibt es zwei Kubeconfigs mit Kontexten für verschiedene Teams (zwei Namespaces): Das X-Team für das Entwicklerteam und den Admin-Cluster. Der Admin-Cluster hat sein eigenes erweitertes Tiller im Kube-system Namespace, entsprechend mit einem erweiterten Service-Account. Und einen separaten Namespace für das Entwicklerteam, das seine Dienste im speziellen Namespace bereitstellen kann.

Das ist ein praktikabler Ansatz, Tiller ist nicht so ressourcenintensiv, als dass es Ihr Budget erheblich belasten könnte. Es ist eine der schnellen Lösungen.

Scheuen Sie sich nicht, Tiller separat zu konfigurieren und Kubeconfig mit Kontext für das Team, den spezifischen Entwickler oder für Umgebungen wie: Dev, Staging, Production bereitzustellen (es ist unwahrscheinlich, dass alles in einem Cluster ist, aber es ist möglich).

Lassen Sie uns, um unsere Geschichte fortzusetzen, von RBAC zur ConfigMap wechseln.

ConfigMaps

Helm verwendet ConfigMaps als Datenrepository. Als wir über die Architektur sprachen, gab es keine Datenbank, in der Informationen zu Releases, Konfigurationen, Rollbacks usw. gespeichert waren. Hier kommen ConfigMaps ins Spiel.

Ein zentrales Problem mit ConfigMaps ist bekannt – sie sind grundsätzlich unsicher, da sie keine sensiblen Daten speichern können.Es geht um alles, was nicht über den Dienst hinausgehen sollte, zum Beispiel Passwörter. Der derzeit nativste Ansatz für Helm besteht darin, von der Verwendung von ConfigMaps auf Secrets umzusteigen.

Das ist ganz einfach. Sie überschreiben die Einstellung von Tiller und geben an, dass das Repository Secrets sein sollen. Dann erhalten Sie für jede Bereitstellung kein ConfigMap, sondern ein Secret.

Sie könnten einwenden, dass Secrets an sich ein merkwürdiges Konzept sind und nicht besonders sicher sind. Dennoch ist zu beachten, dass dies von den Entwicklern von Kubernetes selbst angegangen wird. Seit Version 1.10, also schon seit einiger Zeit, gibt es die Möglichkeit, zumindest in öffentlichen Clouds den richtigen Speicher für die Verwaltung von Secrets zu integrieren. Derzeit arbeitet das Team daran, den Zugriff auf Secrets für separate Pods oder andere Entitäten weiter zu verbessern.

Storage Helm sollte besser auf Geheimnisse übertragen werden, und die sollten zentral gesichert werden.

Natürlich bleibt eine Speichergrenze von 1 MB. Helm verwendet hier etcd als verteiltes Speicher für ConfigMaps. Dabei wurde festgestellt, dass dies ein geeigneter Datenchunk für Replikationen usw. ist. Dazu gibt es eine interessante Diskussion auf Reddit, ich empfehle, diese am Wochenende zu finden oder eine Zusammenfassung zu lesen. hier.

Chart-Repos

Charts sind besonders anfällig für soziale Angriffe und können eine Quelle für "Man in the Middle"-Angriffe sein, insbesondere wenn Standardlösungen verwendet werden. Dies betrifft vor allem Repositories, die über HTTP zugänglich sind.

Definitiv sollte das Helm-Repo über HTTPS bereitgestellt werden – das ist die beste Option und kostengünstig.

Bitte beachten Sie Mechanismus zum Signieren von Charts. Die Technologie ist so einfach wie möglich. Es funktioniert wie bei GitHub, eine gewöhnliche PGP-Maschine mit öffentlichen und privaten Schlüsseln. Richten Sie es ein, und Sie werden sicher sein, Ihre Schlüssel zu haben und alles zu signieren, damit es sich tatsächlich um Ihr Chart handelt.

Darüber hinaus, Der Helm-Client unterstützt TLS (nicht im Sinne von HTTP vom Server, sondern gegenseitiges TLS). Sie können Server- und Client-Schlüssel verwenden, um zu kommunizieren. Ehrlich gesagt, ich benutze einen solchen Mechanismus nicht, da ich gegenseitige Zertifikate nicht mag. Grundsätzlich, chartmuseum — das Hauptwerkzeug zur Bereitstellung von Helm-Repos für Helm 2 — unterstützt auch Basic Auth. Basic Auth kann verwendet werden, wenn dies bequemer und sicherer ist.

Es gibt auch ein Plugin helm-gcs, das es ermöglicht, Chart-Repos in Google Cloud Storage zu hosten. Das ist ziemlich praktisch, funktioniert hervorragend und ist ausreichend sicher, da alle beschriebenen Mechanismen effizient genutzt werden.

Wenn Sie HTTPS oder TLS aktivieren, mTLS verwenden und Basic Auth hinzufügen, um das Risiko weiter zu minimieren, erhalten Sie einen sicheren Kommunikationskanal zwischen Helm CLI und Chart Repo.

gRPC API

Der nächste Schritt ist sehr verantwortungsvoll — Tiller, der sich im Cluster befindet, abzusichern; er ist einerseits der Server, andererseits spricht er selbst mit anderen Komponenten und versucht, sich als jemand anderes auszugeben.

Wie bereits erwähnt, ist Tiller ein Service, der gRPC bereitstellt, und der Helm-Client kommuniziert über gRPC damit. Standardmäßig ist natürlich TLS deaktiviert. Warum das so ist, bleibt diskutabel; ich denke, es dient der vereinfachten Einrichtung zu Beginn.

Für Produktionsumgebungen und sogar für Staging empfehle ich, TLS für gRPC zu aktivieren.

Meiner Meinung nach ist es im Gegensatz zu mTLS für Charts hier durchaus sinnvoll und sehr einfach zu implementieren – Sie generieren die PQI-Infrastruktur, erstellen ein Zertifikat, starten Tiller und übergeben das Zertifikat während der Initialisierung. Danach können Sie alle Helm-Befehle mit dem generierten Zertifikat und dem privaten Schlüssel ausführen.

So schützen Sie sich vor allen Anfragen an Tiller von außerhalb des Clusters.

Wir haben also den Verbindungskanal zu Tiller gesichert, bereits RBAC besprochen und die Rechte des Kubernetes apiservers angepasst sowie die Domäne, mit der er interagieren kann, reduziert.

Geschützter Helm

Schauen wir uns das finale Diagramm an. Es ist dieselbe Architektur mit denselben Pfeilen.

Alle Verbindungen können nun mutig grün dargestellt werden:

• für das Chart-Repository verwenden wir TLS oder mTLS und Basic Auth;
• mTLS für Tiller, das als gRPC-Service mit TLS bereitgestellt wird, wobei wir Zertifikate verwenden;
• Im Cluster wird ein spezieller Service-Account mit Rolle und Rollebindung verwendet. 

Wir haben den Cluster deutlich gesichert, aber jemand hat einmal gesagt:

„Es gibt nur eine wirklich sichere Lösung – ein ausgeschalteter Computer, der in einer Betonkiste steht und von Soldaten bewacht wird.“

Es gibt verschiedene Möglichkeiten, Daten zu manipulieren und neue Angriffsvektoren zu finden. Ich bin jedoch zuversichtlich, dass diese Empfehlungen es ermöglichen, einen grundlegenden Industrie-Sicherheitsstandard zu realisieren.

Bonus

Dieser Abschnitt bezieht sich nicht direkt auf die Sicherheit, wird aber trotzdem nützlich sein. Ich zeige einige interessante Dinge, die nur wenigen bekannt sind. Beispielsweise, wie man Charts sucht – offizielle und inoffizielle.

Im Repository github.com/helm/charts gibt es derzeit etwa 300 Charts und zwei Streams: stable und incubator. Wer beiträgt, weiß, wie schwer es ist, von incubator nach stable zu kommen und wie einfach man von stable fallen kann. Allerdings ist es nicht das beste Werkzeug, um Charts für Prometheus und alles andere, was Ihnen gefällt, zu suchen, aus einem einfachen Grund – es ist kein Portal, wo es bequem ist, nach Paketen zu suchen.

Aber es gibt einen Service hub.helm.sh, mit dem das Finden von Charts viel einfacher ist. Das Wichtigste ist, dass es viel mehr externe Repositories gibt und fast 800 Charts verfügbar sind. Außerdem können Sie Ihr eigenes Repository anschließen, wenn Sie aus irgendeinem Grund Ihre Charts nicht in stable senden möchten.

Probieren Sie hub.helm.sh aus und lassen Sie uns gemeinsam daran arbeiten. Dieser Dienst steht unter dem Helm-Projekt und Sie können sogar dessen UI mitgestalten, wenn Sie ein Frontend-Entwickler sind und einfach das Erscheinungsbild verbessern möchten.

Ich möchte auch Ihre Aufmerksamkeit auf die Open Service Broker API-Integration. Das klingt kompliziert und unverständlich, löst aber Probleme, mit denen alle konfrontiert sind. Lassen Sie mich das an einem einfachen Beispiel erklären.

Es gibt ein Kubernetes-Cluster, in dem wir eine klassische Anwendung – WordPress – ausführen möchten. In der Regel wird eine Datenbank für die volle Funktionalität benötigt. Es gibt viele verschiedene Lösungen, zum Beispiel kann man seinen eigenen Stateful-Service starten. Das ist nicht sehr bequem, aber viele machen das so.

Andere, wie wir bei Chainstack, verwenden verwaltete Datenbanken, zum Beispiel MySQL oder PostgreSQL, für Server. Daher befindet sich unsere DB irgendwo in der Cloud.

Es gibt jedoch ein Problem: Wir müssen unseren Service mit der Datenbank verbinden, einen Datenbank-Flavor erstellen, die Zugangsdaten übermitteln und diese verwalten. All dies wird normalerweise manuell von einem Systemadministrator oder einem Entwickler erledigt. Das ist kein Problem, wenn es nur wenige Anwendungen gibt. Bei vielen Anwendungen jedoch benötigt man einen Kombi. Solch ein Kombi ist der Service Broker. Er ermöglicht die Nutzung eines speziellen Plugins für das öffentliche Cloud-Cluster und das Anfordern von Ressourcen beim Anbieter über den Broker, als wäre es eine API. Dafür kann die nativen Kubernetes-Tools verwendet werden.

Es ist ganz einfach. Man kann zum Beispiel Managed MySQL in Azure mit dem Basis-Tier anfordern (das ist konfigurierbar). Mit der Azure-API wird die Datenbank erstellt und für die Verwendung vorbereitet. Sie müssen sich dabei nicht einmischen; dafür ist das Plugin zuständig. Zum Beispiel wird OSBA (das Azure-Plugin) die Zugangsdaten an den Service zurückgeben und diese an Helm übermitteln. Sie können WordPress mit cloudbasiertem MySQL verwenden, ohne sich um verwaltete Datenbanken kümmern zu müssen und sich keine Sorgen um Stateful-Services im Inneren zu machen.

Man kann sagen, dass Helm der Kleber ist, der auf der einen Seite das Deployment von Services ermöglicht und auf der anderen Seite Ressourcen von Cloud-Anbietern konsumiert.

Sie können ein eigenes Plugin erstellen und all diese Funktionen lokal nutzen. So haben Sie einfach Ihr eigenes Plugin für einen Unternehmens-Cloud-Anbieter. Ich empfehle, diesen Ansatz auszuprobieren, besonders wenn Sie im großen Maßstab arbeiten und schnell Entwicklungs-, Test- oder gesamte Infrastruktur für eine Funktion einrichten möchten. Das wird Ihren Operations- oder DevOps-Teams das Leben erheblich erleichtern.

Ein weiteres Tool, das ich bereits erwähnt habe, ist das helm-gcs Plugin, das die Verwendung von Google-Buckets (Objektspeicher) ermöglicht, um Helm-Charts zu speichern.

Es sind nur vier Befehle erforderlich, um damit zu beginnen:

1. das Plugin installieren;
2. es initialisieren;
3. den Pfad zu dem Bucket angeben, der sich in GCP befindet;
4. die Charts auf die übliche Weise veröffentlichen.

Das Beste daran ist, dass die native Methode von GCP zur Authentifizierung verwendet wird. Sie können einen Dienst-Account, einen Entwickler-Account oder was auch immer nutzen. Das ist sehr praktisch und verursacht keine Betriebskosten. Wenn Sie wie ich die Philosophie ohne Operations propagieren, wird das besonders von Vorteil sein, insbesondere für kleine Teams.

Alternativen

Helm ist nicht die einzige Lösung für das Management von Services. Es gibt viele Fragen dazu, vielleicht ist das der Grund, warum die dritte Version so schnell erschienen ist. Natürlich gibt es auch Alternativen.

Das können spezialisierte Lösungen wie Ksonnet oder Metaparticle sein. Sie können auch Ihre traditionellen Infrastrukturmanagement-Tools (Ansible, Terraform, Chef usw.) für die gleichen Zwecke einsetzen, über die ich gesprochen habe.

Schließlich gibt es die Lösung Operator Framework, dessen Popularität zunimmt.

Das Operator Framework ist die Hauptalternative zu Helm, auf die man achten sollte.

Es ist nativ für CNCF und Kubernetes konzipiert, aber die Einstiegshürde ist viel höher, man muss mehr programmieren und weniger Manifestdateien beschreiben.

Es gibt verschiedene Add-ons wie Draft und Scaffold. Diese erleichtern das Leben erheblich, zum Beispiel den Entwicklern, indem sie den Zyklus von Helm für die Bereitstellung einer Testumgebung vereinfachen. Ich würde sie als Erweiterungswerkzeuge bezeichnen.

Hier ist ein anschauliches Diagramm, das zeigt, wo sich was befindet.

Auf der x-Achse sehen wir Ihr persönliches Kontrollniveau über das Geschehen, auf der y-Achse – das Maß an Kubernetes-Nativität. Helm Version 2 befindet sich irgendwo dazwischen. In Version 3 sind sowohl Kontrolle als auch Nativität zwar nicht revolutionär verbessert, aber dennoch optimiert. Ksonnet-Lösungen sind letztlich immer noch hinter Helm 2 zurück. Sie sind jedoch einen Blick wert, um zu wissen, was es sonst noch in dieser Welt gibt. Natürlich wird Ihr Konfigurationsmanager unter Ihrer Kontrolle bleiben, ist aber für Kubernetes nicht nativ.

Das Operator Framework ist vollständig nativ für Kubernetes und ermöglicht eine viel elegantere und präzisere Verwaltung (aber denken Sie an das Einstiegsniveau). Es eignet sich eher für spezialisierte Anwendungen und deren Management als für eine Massenlösung zur Verpackung einer Vielzahl von Anwendungen mit Helm.

Erweiterungen verbessern lediglich das Kontrollniveau, ergänzen den Workflow oder beschleunigen CI/CD-Pipelines.

Die Zukunft von Helm

Die gute Nachricht ist, dass Helm 3 erscheint. Die Alpha-Version 3.0.0-alpha.2 ist bereits veröffentlicht und kann ausprobiert werden. Sie ist recht stabil, aber die Funktionalität ist momentan noch begrenzt.

Warum wird Helm 3 benötigt? Zunächst einmal geht es um das Verschwinden von Tiller, als Komponente. Das ist, wie Sie bereits verstehen, ein enormer Fortschritt, da sich die Sicherheitsarchitektur dadurch erheblich vereinfacht.

Als Helm 2 entwickelt wurde, zu einer Zeit als Kubernetes 1.8 oder sogar früher, waren viele Konzepte noch unausgereift. Zum Beispiel wird das Konzept der CRDs jetzt aktiv eingeführt, und Helm wird CRDs verwenden, um Strukturen zu speichern. Es wird möglich sein, nur den Client zu verwenden und keinen Serverteil zu betreiben. Entsprechend können die nativen Kubernetes-Befehle für die Arbeit mit Strukturen und Ressourcen verwendet werden. Das ist ein erheblichen Fortschritt.

Es wird unterstützung für native OCI-Repositorys geben (Open Container Initiative). Dies ist eine große Initiative, die für Helm besonders interessant ist, um seine Charts zu veröffentlichen. Es reicht so weit, dass beispielsweise Docker Hub viele OCI-Standards unterstützt. Ich mache keine Vorhersagen, aber es könnte sein, dass klassische Anbieter von Docker-Repositorys beginnen, Ihnen das Hosting Ihrer Helm-Charts zu ermöglichen.

Eine umstrittene Angelegenheit für mich ist die Unterstützung für Lua, als Templating-Engine für das Schreiben von Skripten. Ich bin kein großer Fan von Lua, aber das wird eine völlig optionale Möglichkeit sein. Ich habe das dreimal überprüft – die Verwendung von Lua wird nicht obligatorisch sein. Daher kann jeder, der möchte, Lua verwenden, während die Go-Anhänger sich uns anschließen und go-tmpl verwenden können.

Endlich das, was mir auf jeden Fall gefehlt hat – das Erscheinen von Schemata und die Validierung von Datentypen. Es wird keine Probleme mehr mit int oder string geben, man muss null nicht in Anführungszeichen setzen. Es wird ein JSON-Schema geben, das es ermöglicht, dies klar für Werte zu beschreiben.

Das ereignisgesteuerte Modellwird stark überarbeitet. Es ist bereits konzeptionell beschrieben. Schaut euch den Helm 3-Thread an, und ihr werdet sehen, wie viele Ereignisse, Hooks und anderes hinzugefügt wurden, was den Deploy-Prozess erheblich vereinfacht und zugleich mehr Kontrolle darüber bietet.

Helm 3 wird einfacher, sicherer und interessanter sein, nicht weil wir Helm 2 nicht mögen, sondern weil Kubernetes fortschrittlicher wird. Entsprechend kann Helm die Entwicklungen in Kubernetes nutzen und hervorragende Manager für Kubernetes schaffen.

Eine weitere gute Nachricht ist, dass auf der DevOpsConf Alexander Khayev wird erläutern, ob Container sicher sein können. Wir erinnern daran, dass die Konferenz zur Integration von Entwicklungs-, Test- und Betriebsprozessen in Moskau stattfinden wird. am 30. September und 1. Oktober.Bis zum 20. August kann man noch einen Vortrag einreichen und von seinen Erfahrungen bei der Lösung einer der vielen Herausforderungen des DevOps-Ansatzes berichten.

Verfolgen Sie die Updates zur Konferenz und Neuigkeiten in der Newsletter und Telegram-Gruppe..

Quelle: habr.com