Automatische generatie van geheimen in Helm

Automatische generatie van geheimen in Helm

Team Kubernetes aaS van Mail.ru vertaalde een korte notitie over hoe u automatisch Helm-geheimen kunt genereren tijdens het updaten. Het volgende is een tekst van de auteur van het artikel - technisch directeur van Intoware, een bedrijf dat SaaS-oplossingen ontwikkelt.

Containers zijn cool. In eerste instantie was ik anti-container (ik schaam me om het toe te geven), maar nu sta ik volledig achter het gebruik van deze technologie. Als je dit leest, heb je hopelijk met succes de zeeën van Docker bevaren, de voordelen van Kubernetes gerealiseerd en je leven een stuk eenvoudiger gemaakt met Helm.

Sommige dingen zijn echter duidelijk moeilijker dan nodig is.

Hoe kan ik automatisch geheimen genereren tijdens het updaten?

Een Kubernetes-geheim is een bron die sleutel/waarde-paren bevat die u in uw code wilt gebruiken. Dit kunnen databaseverbindingsreeksen, e-mailwachtwoorden, enzovoort zijn. Door geheimen te gebruiken, creëert u een duidelijke scheiding tussen code en instellingen, waardoor u eenvoudig verschillende implementaties kunt aanpassen zonder de codebasis te wijzigen.

Een veel voorkomende situatie is wanneer twee modules moeten communiceren via een gemeenschappelijke sleutel. Niemand buiten het cluster mag deze sleutel kennen, aangezien deze bedoeld is voor één-op-één communicatie binnen het cluster.

Geheimen maken

Om een ​​geheim in Helm te maken, moet u doorgaans het volgende doen:

  • beschrijf het geheim in het waardenbestand;
  • herdefinieer het tijdens de implementatie;
  • verwijs ernaar binnen de implementatie/pod;
  • ... winst!

Meestal ziet het er ongeveer zo uit:

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

Een eenvoudig Kubernetes-geheim met behulp van waarden uit waarden.yml

Maar stel dat u uw geheim niet in het waardenbestand wilt specificeren.

Er zijn veel opties wanneer voor de implementatie een gedeelde sleutel vereist is, die tijdens de installatie moet worden gegenereerd.

In het bovenstaande voorbeeld van module-naar-module-communicatie is het niet wenselijk om het geheim buiten de implementatie te delen. Daarom is het zeer wenselijk dat Helm over mechanismen beschikt om automatisch een geheim te genereren zonder dit direct te hoeven specificeren.

Haken

Met Hooks kunt u tijdens het installatieproces code op specifieke locaties uitvoeren. Het kan zijn dat er een configuratietaak moet worden uitgevoerd na de eerste installatie, of dat er misschien een opschoning moet worden uitgevoerd voordat een update wordt uitgevoerd.

Om ons probleem van het toevoegen van een sleutel die tijdens de installatie wordt gegenereerd op te lossen, zijn pre-installatiehaken ideaal. Maar er zit een addertje onder het gras: je kunt het geheim niet automatisch genereren tijdens een update. Hooks werken bij elke update.

Als je je geheim hebt gegenereerd en je eerste installatie is nog niet gebeurd, stop dan met lezen; de pre-installatie hook zal prima voor je werken.

Maar als het geheim deel uitmaakt van een update (misschien een nieuwe functie die er niet was tijdens de installatie), dan is het jammer dat je geen pre-installatie hook kunt maken die maar één keer werkt.

functies

Met Helm-functies kunt u verschillende scriptelementen aan uw implementatiescripts toevoegen.

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

Dit voorbeeld laat zien dat de waarde van het apiKey-geheim de nieuwe UUID is die tijdens de installatie wordt gegenereerd.

Helm bevat een werkelijk uitgebreide functiebibliotheek die gebruik maakt van de geweldige GO-sjabloonfuncties en de functiebibliotheek van Sprig om aangepaste implementaties te creëren.

Opzoekfunctie

Toegevoegd in Helm 3.1 Opzoekfunctie, waarmee u een bestaande implementatie kunt aanvragen en:

  • controleer het bestaan ​​van hulpbronnen;
  • retourneer de waarde van een bestaande bron voor later gebruik.

Met behulp van deze beide mogelijkheden kunnen we een eenmalig, dynamisch gegenereerd geheim creëren!

# 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 }}

Telkens wanneer een nieuwe update op de server wordt toegepast, genereert Helm een ​​nieuwe geheime waarde (als er nog geen geheim is) of hergebruikt hij de bestaande waarde.

Good Luck!

Wat nog meer te lezen over het onderwerp:

  1. Drie niveaus van automatisch schalen in Kubernetes en hoe u deze effectief kunt gebruiken.
  2. Kubernetes in de geest van piraterij met een sjabloon voor implementatie.
  3. Ons kanaal Around Kubernetes in Telegram.

Bron: www.habr.com

Voeg een reactie