Auto-generaasje fan geheimen yn Helm

Auto-generaasje fan geheimen yn Helm

team Kubernetes aaS fan Mail.ru in koarte notysje oerset oer hoe't jo automatysk Helm-geheimen kinne generearje by it bywurkjen. It folgjende is in tekst fan 'e skriuwer fan it artikel - technysk direkteur fan Intoware, in bedriuw dat SaaS-oplossingen ûntwikkelet.

Containers binne koel. Earst wie ik anty-container (ik skamje it ta te jaan), mar no stipe ik it gebrûk fan dizze technology folslein. As jo ​​​​dit lêze, hawwe jo hooplik mei súkses de seeën fan Docker navigearre, de foardielen fan Kubernetes realisearre en jo libben in stik makliker makke mei Helm.

Guon dingen binne lykwols dúdlik dreger dan se moatte wêze.

Hoe kinne jo geheimen automatysk generearje by it bywurkjen?

In Kubernetes-geheim is in boarne dy't kaai / wearde-pearen befettet dy't jo wolle brûke yn jo koade. Dit kinne databankferbiningstrings, e-postwachtwurden, ensfh. Troch gebrûk fan geheimen meitsje jo in dúdlike skieding tusken koade en ynstellings, wêrtroch it maklik is om ferskate ynset oan te passen sûnder de koadebase te feroarjen.

In mienskiplike situaasje is as twa modules moatte kommunisearje mei in mienskiplike kaai. Nimmen bûten it kluster moat dizze kaai witte, om't it bedoeld is foar ien-op-ien kommunikaasje binnen it kluster.

It meitsjen fan geheimen

Typysk, om in geheim yn Helm te meitsjen, moatte jo:

  • beskriuw it geheim yn it weardebestân;
  • opnij definiearje it by ynset;
  • ferwize nei it binnen de ynset / pod;
  • ... winst!

It sjocht der normaal sa út:

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

In ienfâldich Kubernetes-geheim mei wearden fan values.yml

Mar litte wy sizze dat jo jo geheim net wolle opjaan yn it weardebestân.

D'r binne in protte opsjes as ynset in dielde kaai fereasket, dy't moatte wurde oanmakke by ynstallaasje.

Yn de module-to-module kommunikaasje foarbyld hjirboppe, is it net winsklik om te dielen it geheim bûten de ynset. Dêrom is it heul winsklik dat Helm meganismen hat om in geheim automatysk te generearjen sûnder it direkt te spesifisearjen.

Hooks

Haken kinne jo koade útfiere op spesifike lokaasjes tidens it ynstallaasjeproses. D'r kin in konfiguraasjetaak wêze dy't nei de earste ynstallaasje útfierd wurde moat, of miskien moat in skjinmeitsjen dien wurde foardat jo in update útfiere.

Om ús probleem op te lossen fan it tafoegjen fan in kaai generearre tidens ynstallaasje, binne pre-ynstallaasjehaken ideaal. Mar d'r is in fangen: jo kinne it geheim net ien kear automatysk generearje by in update. Hooks sille wurkje op elke update.

As jo ​​​​jo geheim hawwe generearre en jo earste ynstallaasje is noch net bard, stop dan mei lêzen, de pre-ynstallaasjehaak sil geweldich foar jo wurkje.

Mar as it geheim diel útmakket fan in fernijing (miskien in nije funksje dy't der net wie op it momint fan ynstallaasje), dan is it spitich dat jo gjin pre-ynstallaasjehaak meitsje kinne dy't mar ien kear wurket.

Funksjes

Helmfunksjes kinne jo ferskate skripteleminten tafoegje oan jo ynsetskripts.

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 foarbyld lit sjen dat de wearde fan it apiKey-geheim de nije UUID sil wêze generearre tidens ynstallaasje.

Helm omfettet in wirklik wiidweidige funksjebibleteek dy't de geweldige GO-sjabloanfunksjes en Sprig's funksjebibleteek brûkt om oanpaste ynset te meitsjen.

Lookup funksje

Tafoege yn Helm 3.1 Lookup funksje, wêrmei jo in besteande ynset oanfreegje kinne en:

  • kontrolearje it bestean fan boarnen;
  • werom de wearde fan in besteande boarne foar letter gebrûk.

Mei help fan beide fan dizze mooglikheden, kinne wy ​​meitsje in ienmalige, dynamysk oanmakke geheim!

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

Wannear't in nije fernijing wurdt tapast op de tsjinner, Helm sil ofwel in nije geheime wearde generearje (as d'r noch gjin geheim is) of opnij brûke de besteande wearde.

Súkses!

Wat oars te lêzen oer it ûnderwerp:

  1. Trije nivo's fan autoscaling yn Kubernetes en hoe't se se effektyf kinne brûke.
  2. Kubernetes yn 'e geast fan piraterij mei in sjabloan foar ymplemintaasje.
  3. Us kanaal Around Kubernetes yn Telegram.

Boarne: www.habr.com

Add a comment