ProHoster > Blog > administracja > Automatyczne generowanie sekretów w Helmie

Automatyczne generowanie sekretów w Helmie

Automatyczne generowanie sekretów w Helmie

Zespół Kubernetes aaS z Mail.ru przetłumaczył krótką notatkę o tym, jak automatycznie generować sekrety Helma podczas aktualizacji. Poniżej tekst od autora artykułu – dyrektora technicznego Intware, firmy tworzącej rozwiązania SaaS.

Kontenery są fajne. Na początku byłem przeciwny kontenerom (wstyd się przyznać), ale teraz w pełni popieram wykorzystanie tej technologii. Jeśli to czytasz, mamy nadzieję, że pomyślnie żeglowałeś po morzach Dockera, zdałeś sobie sprawę z zalet Kubernetesa i znacznie ułatwiłeś sobie życie dzięki Helm.

Jednak niektóre rzeczy są wyraźnie trudniejsze, niż powinny.

Jak automatycznie generować sekrety podczas aktualizacji?

Sekret Kubernetes to zasób zawierający pary klucz/wartość, których chcesz użyć w swoim kodzie. Mogą to być parametry połączenia z bazą danych, hasła e-mail i tak dalej. Używając kluczy tajnych, tworzysz wyraźne oddzielenie kodu od ustawień, co pozwala łatwo dostosowywać różne wdrożenia bez zmiany bazy kodu.

Typową sytuacją jest sytuacja, gdy dwa moduły muszą komunikować się przy użyciu wspólnego klucza. Nikt spoza klastra nie powinien znać tego klucza, ponieważ jest on przeznaczony do komunikacji jeden na jednego w ramach klastra.

Dokonywanie sekretów

Zazwyczaj, aby utworzyć sekret w Helmie, musisz:

  • opisz sekret w pliku wartości;
  • zdefiniuj go na nowo podczas wdrażania;
  • odwołaj się do tego wewnątrz wdrożenia/poda;
  • ... zysk!

Zwykle wygląda to mniej więcej tak:

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

Prosty sekret Kubernetesa wykorzystujący wartości z wartości.yml

Ale powiedzmy, że nie chcesz podawać swojego sekretu w pliku wartości.

Istnieje wiele opcji, gdy wdrożenie wymaga klucza współdzielonego, który należy wygenerować podczas instalacji.

W powyższym przykładzie komunikacji między modułami nie jest pożądane udostępnianie sekretu poza wdrożeniem. Dlatego jest wysoce pożądane, aby Helm posiadał mechanizmy automatycznego generowania sekretu bez konieczności bezpośredniego jego podawania.

Haczyki

Hooki umożliwiają uruchamianie kodu w określonych lokalizacjach podczas procesu instalacji. Może zaistnieć potrzeba wykonania zadania konfiguracyjnego po pierwszej instalacji lub oczyszczenia przed wykonaniem jakiejkolwiek aktualizacji.

Aby rozwiązać nasz problem dodania klucza wygenerowanego podczas instalacji, idealnie sprawdzają się haczyki przedinstalacyjne. Ale jest pewien haczyk: nie można automatycznie wygenerować klucza tajnego po aktualizacji. Hooki będą działać przy każdej aktualizacji.

Jeśli wygenerowałeś swój sekret, a Twoja pierwsza instalacja jeszcze się nie odbyła, przestań czytać, hak przed instalacją będzie dla Ciebie świetny.

Ale jeśli sekret tkwi w aktualizacji (być może w nowej funkcji, której nie było podczas instalacji), to szkoda, że ​​nie można stworzyć haka przedinstalacyjnego, który zadziała tylko raz.

funkcje

Funkcje Helm umożliwiają dodawanie różnych elementów skryptowych do skryptów wdrażania.

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

Ten przykład pokazuje, że wartością sekretu apiKey będzie nowy UUID wygenerowany podczas instalacji.

Helm zawiera naprawdę obszerną bibliotekę funkcji, która wykorzystuje niesamowite funkcje szablonów GO i bibliotekę funkcji Sprig do tworzenia niestandardowych wdrożeń.

Funkcja wyszukiwania

Dodano w Helmie 3.1 Funkcja wyszukiwania, co umożliwia zażądanie istniejącego wdrożenia i:

  • sprawdzić istnienie zasobów;
  • zwraca wartość istniejącego zasobu do późniejszego wykorzystania.

Korzystając z obu tych możliwości, możemy stworzyć jednorazowy, dynamicznie generowany sekret!

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

Za każdym razem, gdy na serwerze zostanie zastosowana nowa aktualizacja, Helm albo wygeneruje nową wartość tajną (jeśli jeszcze nie ma tajnej wartości), albo ponownie wykorzysta istniejącą wartość.

Good Luck!

Co jeszcze przeczytać na ten temat:

  1. Trzy poziomy autoskalowania w Kubernetesie i jak je efektywnie wykorzystać.
  2. Kubernetes w duchu piractwa z szablonem do wdrożenia.
  3. Nasz kanał Around Kubernetes w Telegramie.

Źródło: www.habr.com

Dodaj komentarz