🥇Autogenerering av hemligheter i Helm

Team Kubernetes aaS från Mail.ru översatte en kort notering om hur man automatiskt genererar Helm-hemligheter vid uppdatering. Här är texten från författaren till artikeln - teknisk direktör på Intoware, ett företag som utvecklar SaaS-lösningar.

Containrar är fantastiska. Först var jag emot containrar (skäms att erkänna), men nu stödjer jag helt användningen av denna teknik. Om du läser detta, hoppas jag att du framgångsrikt har navigerat i Dockerhaven, insett fördelarna med Kubernetes och gjort ditt liv mycket enklare med Helm.

Det finns dock saker som är uppenbart svårare än de borde vara.

Hur automatiskt generera hemligheter vid uppdatering?

En Kubernetes-hemlighet är en resurs som innehåller nyckel/värde-par som du vill använda i din kod. Det kan vara anslutningssträngar till databaser, e-postlösenord och så vidare. Genom att använda hemligheter skapar du en tydlig åtskillnad mellan kod och konfigurationer, vilket gör det enkelt att anpassa olika distributioner utan att ändra kodbasen.

Det är en vanlig situation när två moduler måste interagera med hjälp av en gemensam nyckel. Ingen utanför klustret bör känna till denna nyckel, eftersom den är avsedd för kommunikation "från en till en annan" inom klustret.

Skapa hemligheter

Vanligtvis, för att skapa en hemlighet i Helm, behöver du:

beskriva hemligheten i en värdefil;
återdefiniera den under distributionsprocessen;
referera till den inom distributionen/poden;
… vinsten!

Det ser vanligtvis ut ungefär så här:

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

En enkel Kubernetes-hemlighet som använder värden från values.yml

Men låt oss säga att du inte vill ange din hemlighet i värdefilen.

Det finns många scenarier där en gemensam nyckel som behöver genereras under installationen krävs för distributionen.

I exemplet ovan med interaktion mellan moduler är det oönskat att dela hemligheten utanför distributionen. Därför är det mycket önskvärt att Helm har mekanismer för att automatiskt skapa hemligheten utan att behöva ange den direkt.

Hooks

Hooks tillåter körning av kod på specifika ställen under installationsprocessen. Det kan finnas en konfigurationsuppgift som behöver köras efter den första installationen, eller så kanske en rensning behöver göras innan några uppdateringar genomförs.

För att lösa vårt problem med att lägga till en nyckel som genereras vid installationen är förinstallerade hooks perfekta. Men det finns en hake: du kan inte automatiskt generera en hemlighet en gång vid uppdatering. Hooks kommer att fungera vid varje uppdatering.

Men om du har genererat din hemlighet och din första installation inte har ägt rum än, då kan du sluta läsa, för en förinstallerad hook är perfekt för dig.

Men om hemligheten är en del av uppdateringen (kanske en ny funktion som inte fanns under installationen), så är det frustrerande att det inte går att skapa en förinstallerad hook som bara fungerar en gång.

Funktioner

Helm-funktioner gör det möjligt att lägga till olika skriptelement i distributionsscenarier.

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ uuidv4 | quote }} #Generera en ny UUID och quotera den

I det här exemplet visas det att värdet av hemligheten apiKey kommer att vara en ny UUID som genereras vid installationen.

Helm inkluderar ett verkligt omfattande bibliotek av funktioner som använder fantastiska GO-mallfunktioner och Sprig-funktionbiblioteket för att skapa anpassade distributioner.

Lookup-funktion

I Helm 3.1 tillades Lookup-funktionen, som låter dig förfråga en befintlig deployment och:

kontrollera existensen av resurser;
returnera värdet av en existerande resurs för senare användning.

Genom att använda båda dessa möjligheter kan vi skapa en engångs, dynamiskt genererad hemlighet!

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

Varje gång en ny uppdatering tillämpas på servern kommer Helm antingen att generera ett nytt värde för hemligheten (om hemligheten inte redan finns) eller återanvända det befintliga värdet.

Lycka till!

Vad mer att läsa om ämnet:

Källa: habr.com