Automatisch genereren van geheimen in Helm

Opdracht Kubernetes aaS van Mail.ru Ik heb een korte notitie vertaald over hoe je automatisch Helm-secrets kunt genereren bij een update. Hieronder volgt de tekst van de auteur van het artikel — de technisch directeur van Intoware, een SaaS-oplossingenontwikkelaar.

Containers zijn geweldig. In het begin was ik een tegenstander van containers (dat geef ik eerlijk toe), maar nu ben ik volledig voor het gebruik van deze technologie. Als je dit leest, hoop ik dat je succesvol de zeeën van Docker hebt bevaren, de voordelen van Kubernetes hebt ontdekt en je leven veel eenvoudiger hebt gemaakt met Helm.

Er zijn echter sommige dingen die duidelijk moeilijker zijn dan ze zouden moeten zijn.

Hoe genereer je automatisch secrets bij een update?

Een Kubernetes-secret is een resource die sleutel/waarde-paren bevat die je in je code wilt gebruiken. Dit kunnen verbindingsstrengen voor databases, e-mailwachtwoorden, enzovoort zijn. Door secrets te gebruiken, creëer je een duidelijke scheiding tussen code en instellingen, waardoor je eenvoudig verschillende implementaties kunt configureren zonder de codebasis te wijzigen.

Een veelvoorkomende situatie is wanneer twee modules moeten communiceren via een gemeenschappelijke sleutel. Niemand buiten het cluster zou deze sleutel moeten kennen, aangezien deze bedoeld is voor communicatie 'van de ene naar de andere' binnen het cluster.

Secrets aanmaken

Om een secret in Helm aan te maken, moet je doorgaans:

• de secret beschrijven in een waardenbestand;
• deze overschrijven tijdens het deployen;
• er binnen de deployment/pod naar verwijzen;
• … winst!

Dit ziet er meestal ongeveer zo uit:

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

Een eenvoudige Kubernetes-secret die waarden uit values.yml gebruikt.

Maar stel dat je je secret niet in het waardenbestand wilt opgeven.

Er zijn veel scenario's waarbij een gemeenschappelijke sleutel nodig is voor de implementatie, die gegenereerd moet worden tijdens de installatie.

In het bovenstaande voorbeeld van interactie tussen modules is het ongewenst om het secret buiten de implementatie te delen. Daarom is het zeer wenselijk dat Helm mechanismen heeft voor het automatisch aanmaken van een secret zonder dat het specifiek opgegeven hoeft te worden.

Hooks

Haken stellen die Möglichkeit bereit, Code an bestimmten Stellen im Installationsprozess auszuführen. Möglicherweise gibt es eine Konfiguration, die nach der ersten Installation ausgeführt werden muss, oder es muss eine Bereinigung durchgeführt werden, bevor ein Update vorgenommen wird.

Um unser Problem der Schlüsselgenerierung bei der Installation zu lösen, sind vorinstallierte Haken ideal. Aber es gibt einen Haken: Sie können ein Geheimnis nicht automatisch einmal bei einem Update generieren. Die Haken werden bei jedem Update ausgeführt.

Wenn Sie Ihr Geheimnis generiert haben und Ihre erste Installation noch nicht erfolgt ist, hören Sie auf zu lesen, der vorinstallierte Haken ist perfekt für Sie.

Aber wenn das Geheimnis Teil des Updates ist (vielleicht eine neue Funktion, die während der Installation nicht vorhanden war), so ist es bedauerlich, dass es nicht möglich ist, einen vorinstallierten Haken zu erstellen, der nur einmal ausgeführt wird.

Functies

Die Funktionen von Helm ermöglichen das Hinzufügen verschiedener Skripte in die Bereitstellungsskripte.

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ uuidv4 | quote }} #Generiere eine neue UUID und zitiere sie

In diesem Beispiel ist der Wert des Secrets apiKey eine neue UUID, die während der Installation generiert wurde.

Helm enthält eine wirklich umfangreiche Bibliothek von Funktionen, die erstaunliche GO-Template-Funktionen und die Sprig-Funktionsbibliothek verwenden, um anpassbare Bereitstellungen zu erstellen.

Die Lookup-Funktion

wurde in Helm 3.1 hinzugefügt. Die Lookup-Funktion, die es ermöglicht, eine vorhandene Bereitstellung abzufragen und:

• die Existenz von Ressourcen zu überprüfen;
• den Wert einer bestehenden Ressource zur weiteren Verwendung zurückzugeben.

Indem wir beide Möglichkeiten nutzen, können wir ein einmalig 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 }}

Jedes Mal, wenn ein neues Update auf den Server angewendet wird, wird Helm entweder einen neuen Wert für das Geheimnis generieren (wenn das Geheimnis noch nicht existiert) oder den bestehenden Wert wiederverwenden.

Veel succes!

Wat verder te lezen over dit onderwerp:

1. Drie niveaus van autoscaling in Kubernetes en hoe deze effectief te gebruiken.
2. Kubernetes in de geest van piraterij met een implementatiesjabloon.
3. Onze kanaal Rondom Kubernetes op Telegram.

Bron: habr.com