Automatische Generierung von Geheimnissen in Helm

Automatische Generierung von Geheimnissen in Helm

Team Kubernetes aaS von Mail.ru übersetzte eine kurze Notiz Informationen zum automatischen Generieren von Helm-Geheimnissen beim Aktualisieren. Das Folgende ist ein Text des Autors des Artikels – technischer Direktor von Intoware, einem Unternehmen, das SaaS-Lösungen entwickelt.

Container sind cool. Zuerst war ich ein Gegner von Containern (es ist mir peinlich, das zuzugeben), aber jetzt unterstütze ich den Einsatz dieser Technologie voll und ganz. Wenn Sie dies lesen, haben Sie hoffentlich erfolgreich durch die Meere von Docker navigiert, die Vorteile von Kubernetes erkannt und Ihr Leben mit Helm viel einfacher gemacht.

Allerdings sind einige Dinge eindeutig schwieriger als nötig.

Wie generiert man beim Update automatisch Geheimnisse?

Ein Kubernetes-Geheimnis ist eine Ressource, die Schlüssel/Wert-Paare enthält, die Sie in Ihrem Code verwenden möchten. Dies können Datenbankverbindungszeichenfolgen, E-Mail-Passwörter usw. sein. Durch die Verwendung von Geheimnissen schaffen Sie eine klare Trennung zwischen Code und Einstellungen, sodass Sie verschiedene Bereitstellungen problemlos anpassen können, ohne die Codebasis zu ändern.

Eine häufige Situation besteht darin, dass zwei Module über einen gemeinsamen Schlüssel kommunizieren müssen. Niemand außerhalb des Clusters sollte diesen Schlüssel kennen, da er für die Eins-zu-eins-Kommunikation innerhalb des Clusters gedacht ist.

Geheimnisse machen

Um in Helm ein Geheimnis zu erstellen, müssen Sie normalerweise Folgendes tun:

  • Beschreiben Sie das Geheimnis in der Wertedatei.
  • Definieren Sie es während der Bereitstellung neu.
  • Verweisen Sie im Deployment/Pod darauf;
  • ... Gewinn!

Normalerweise sieht es ungefähr so ​​aus:

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ .Values.MyApiKeySecret | quote }}

Ein einfaches Kubernetes-Geheimnis, das Werte aus Values.yml verwendet

Nehmen wir jedoch an, Sie möchten Ihr Geheimnis nicht in der Wertedatei angeben.

Es gibt viele Optionen, wenn für die Bereitstellung ein gemeinsamer Schlüssel erforderlich ist, der während der Installation generiert werden muss.

Im obigen Beispiel für die Modul-zu-Modul-Kommunikation ist es nicht wünschenswert, das Geheimnis außerhalb der Bereitstellung weiterzugeben. Daher ist es äußerst wünschenswert, dass Helm über Mechanismen verfügt, um automatisch ein Geheimnis zu generieren, ohne es direkt angeben zu müssen.

Haken

Mit Hooks können Sie während des Installationsprozesses Code an bestimmten Stellen ausführen. Möglicherweise muss nach der ersten Installation ein Konfigurationsauftrag ausgeführt werden, oder es muss möglicherweise eine Bereinigung durchgeführt werden, bevor ein Update durchgeführt wird.

Um unser Problem des Hinzufügens eines während der Installation generierten Schlüssels zu lösen, sind Vorinstallations-Hooks ideal. Aber es gibt einen Haken: Sie können das Geheimnis nicht einmal automatisch bei einem Update generieren. Hooks funktionieren bei jedem Update.

Wenn Sie Ihr Geheimnis generiert haben und Ihre erste Installation noch nicht stattgefunden hat, dann hören Sie auf zu lesen, der Pre-Install-Hook wird für Sie großartig funktionieren.

Aber wenn das Geheimnis Teil eines Updates ist (vielleicht eine neue Funktion, die bei der Installation nicht vorhanden war), dann ist es schade, dass man keinen Vorinstallations-Hook erstellen kann, der nur einmal funktioniert.

Funktionen

Mithilfe von Helmfunktionen können Sie Ihren Bereitstellungsskripts verschiedene Skriptelemente hinzufügen.

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ uuidv4 | quote }} #Generate a new UUID and quote it

Dieses Beispiel zeigt, dass der Wert des apiKey-Geheimnisses die neue UUID ist, die während der Installation generiert wird.

Helm umfasst eine wirklich umfangreiche Funktionsbibliothek, die die erstaunlichen GO-Vorlagenfunktionen und die Funktionsbibliothek von Sprig nutzt, um benutzerdefinierte Bereitstellungen zu erstellen.

Nachschlagefunktion

Hinzugefügt in Helm 3.1 Nachschlagefunktion, mit dem Sie eine vorhandene Bereitstellung anfordern können und:

  • Überprüfen Sie die Existenz von Ressourcen.
  • Gibt den Wert einer vorhandenen Ressource zur späteren Verwendung zurück.

Mithilfe dieser beiden Funktionen können wir ein einmaliges, dynamisch generiertes Geheimnis erstellen!

# 1. Запросить существование секрета и вернуть в переменной $secret
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "some-awesome-secret" -}}
apiVersion: v1
kind: Secret
metadata:
  name: some-awesome-secret
type: Opaque

# 2. Если секрет существует, взять его значение как apiKey (секрет использует кодирование Base64, так что используйте ключ "data")
{{ if $secret -}}
data:
  apiKey: {{ $secret.data.apiKey }}

# 3. Если секрет не существует — создать его (в этот раз используйте "stringData", так как будет обычное значение)!
{{ else -}}
stringData:
  apiKey: {{ uuidv4 | quote }}
{{ end }}

Immer wenn ein neues Update auf den Server angewendet wird, generiert Helm entweder einen neuen geheimen Wert (falls noch kein Geheimnis vorhanden ist) oder verwendet den vorhandenen Wert wieder.

Good Luck!

Was gibt es sonst noch zum Thema zu lesen?:

  1. Drei Ebenen der automatischen Skalierung in Kubernetes und wie man sie effektiv nutzt.
  2. Kubernetes im Geiste der Piraterie mit Vorlage zur Umsetzung.
  3. Unser Kanal Rund um Kubernetes in Telegram.

Source: habr.com

Kommentar hinzufügen