Autogenerering av hemmeligheter i Helm

Autogenerering av hemmeligheter i Helm

Lag Kubernetes aaS fra Mail.ru oversatte et kort notat om hvordan du automatisk genererer Helm-hemmeligheter ved oppdatering. Følgende er en tekst fra artikkelforfatteren - teknisk direktør i Intoware, et selskap som utvikler SaaS-løsninger.

Beholdere er kule. Først var jeg anti-container (jeg er flau over å innrømme det), men nå støtter jeg fullt ut bruken av denne teknologien. Hvis du leser dette, har du forhåpentligvis klart å navigere i Dockers hav, innsett fordelene med Kubernetes og gjort livet ditt mye enklere med Helm.

Noen ting er imidlertid klart vanskeligere enn de trenger å være.

Hvordan generere hemmeligheter automatisk når du oppdaterer?

En Kubernetes-hemmelighet er en ressurs som inneholder nøkkel/verdi-par som du vil bruke i koden din. Disse kan være databasetilkoblingsstrenger, e-postpassord og så videre. Ved å bruke hemmeligheter skaper du et tydelig skille mellom kode og innstillinger, slik at du enkelt kan tilpasse forskjellige distribusjoner uten å endre kodebasen.

En vanlig situasjon er når to moduler må kommunisere med en felles nøkkel. Ingen utenfor klyngen bør kjenne til denne nøkkelen, siden den er ment for en-til-en kommunikasjon innenfor klyngen.

Lage hemmeligheter

Vanligvis, for å lage en hemmelighet i Helm, må du:

  • beskriv hemmeligheten i verdifilen;
  • redefiner den under distribusjon;
  • referer til det inne i distribusjonen/poden;
  • ... profitt!

Det ser vanligvis omtrent slik ut:

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

En enkel Kubernetes-hemmelighet som bruker verdier fra values.yml

Men la oss si at du ikke vil spesifisere hemmeligheten din i verdifilen.

Det er mange alternativer når distribusjon krever en delt nøkkel, som må genereres under installasjonen.

I modul-til-modul kommunikasjonseksemplet ovenfor er det ikke ønskelig å dele hemmeligheten utenfor distribusjonen. Derfor er det svært ønskelig at Helm har mekanismer for automatisk å generere en hemmelighet uten å måtte spesifisere den direkte.

Kroker

Hooks lar deg kjøre kode på bestemte steder under installasjonsprosessen. Det kan være en konfigurasjonsjobb som må kjøres etter den første installasjonen, eller kanskje en opprydding må gjøres før du utfører noen oppdatering.

For å løse problemet vårt med å legge til en nøkkel generert under installasjonen, er pre-installasjonskroker ideelle. Men det er en hake: du kan ikke automatisk generere hemmeligheten én gang på en oppdatering. Hooks vil fungere på hver oppdatering.

Hvis du har generert hemmeligheten din og den første installasjonen din ikke har skjedd ennå, slutt å lese, forhåndsinstallasjonskroken vil fungere bra for deg.

Men hvis hemmeligheten er en del av en oppdatering (kanskje en ny funksjon som ikke var der under installasjonen), så er det synd at du ikke kan lage en pre-installasjonskrok som bare fungerer én gang.

funksjoner

Hjelmfunksjoner lar deg legge til ulike skriptelementer i distribusjonsskriptene dine.

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

Dette eksemplet viser at verdien av apiKey-hemmeligheten vil være den nye UUID-en som genereres under installasjonen.

Helm inkluderer et virkelig omfattende funksjonsbibliotek som utnytter de fantastiske GO-malfunksjonene og Sprigs funksjonsbibliotek for å lage tilpassede distribusjoner.

Oppslagsfunksjon

Lagt til i Helm 3.1 Oppslagsfunksjon, som lar deg be om en eksisterende distribusjon og:

  • kontrollere eksistensen av ressurser;
  • returner verdien av en eksisterende ressurs for senere bruk.

Ved å bruke begge disse egenskapene kan vi lage en engangs, dynamisk generert hemmelighet!

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

Hver gang en ny oppdatering brukes på serveren, vil Helm enten generere en ny hemmelig verdi (hvis det ikke er noen hemmelighet ennå) eller gjenbruke den eksisterende verdien.

Lykke til!

Hva annet å lese om emnet:

  1. Tre nivåer av autoskalering i Kubernetes og hvordan du bruker dem effektivt.
  2. Kubernetes i piratkopieringens ånd med en mal for implementering.
  3. Vår kanal Around Kubernetes i Telegram.

Kilde: www.habr.com

Legg til en kommentar