Configuration and Secret Management with Consul Template on Kubernetes

Onur Yilmaz

Follow

Mar 23, 2020 – 6 min read

Jako zespół platformy w Trendyol Tech, jednym z naszych celów było sprawienie, aby konfiguracja aplikacji i zarządzanie sekretami były dynamiczne, niezawodne, bezpieczne i abstrahowały od aplikacji. Używamy Kubernetes ConfigMaps i Secrets od dłuższego czasu i nie spełniają one w pełni naszych wymagań. Na przykład, gdy zmieniamy konfigurację w ConfigMap, musimy zrestartować nasze aplikacje, aby ta zmiana weszła w życie. Czasami potrzeba kilku minut, aby zmiana została odzwierciedlona na wszystkich instancjach aplikacji. Innym problemem jest to, że sekrety Kubernetes nie są wystarczająco bezpieczne. Potrzebujemy, aby nasze sekrety były bezpieczne i możliwe do skontrolowania.

Naszymi głównymi wymaganiami były;

  • Powinniśmy być w stanie dynamicznie zmieniać konfiguracje aplikacji bez restartowania procesów aplikacji. Kiedy zmieniamy konfigurację, powinno to mieć natychmiastowy wpływ na wszystkie instancje aplikacji.
  • Tajemnice naszych aplikacji muszą być bezpieczne i możliwe do skontrolowania. Chcemy również zapewnić kontrolę dostępu do sekretów opartą na rolach.
  • Musimy odizolować zarządzanie konfiguracją od aplikacji. Innymi słowy, aplikacje nie powinny wiedzieć, gdzie i jak sekrety i konfiguracje są przechowywane i dostarczane dla nich.
  • Nasz system zarządzania konfiguracją i sekretami musi być wysoko dostępny i skalowalny.

Po pewnych badaniach wymyśliliśmy 2 aplikacje; envconsul i consul-template.

Wiedzieliśmy już, że Vault jest standardowym narzędziem branżowym do przechowywania sekretów. Spełnia on wszystkie nasze wymagania i posiada funkcje takie jak dynamiczne sekrety, które mogą być dla nas przydatne w przyszłości. Możesz również użyć Consul jako zaplecza magazynowego dla Vault.

Consul jest rozproszonym, wysoce dostępnym i skalowalnym narzędziem do odkrywania i konfigurowania usług. W naszym przypadku będziemy korzystać tylko z funkcji magazynu wartości kluczowych Consul do przechowywania konfiguracji innych niż tajne.

Możemy użyć envconsul lub consul-template głównie dla trzeciego wymagania: abstrahowania od zarządzania konfiguracją z poziomu aplikacji.

Envconsul zapewnia sposób na uruchomienie podprocesu ze zmiennymi środowiskowymi wypełnionymi z Consul i Vault.

Consul-template wypełnia wartości z Consul i Vault do systemu plików i utrzymuje wartości zsynchronizowane podczas pracy w trybie demona.

Zasada Dwunastu Czynników Aplikacji to, przechowuj konfiguracje w środowisku. Ale problem z Envconsul (lub zmiennych środowiskowych) jest to, że nie można zmienić zmiennych środowiskowych procesu bez ponownego uruchomienia go. Jest to sprzeczne z naszym pierwszym wymaganiem. Chcemy mieć możliwość zmiany konfiguracji bez restartowania procesów aplikacji. Dlatego zdecydowaliśmy się na consul-template.

Podstawowa architektura procesu aplikacji i demona consul-template działających razem

W consul-template, możesz użyć pliku szablonu do renderowania plików konfiguracyjnych. Daje nam to dużą elastyczność. Oto przykładowy plik szablonu;

Consul-template czyta ten szablon, zastępuje pola wyboru wartościami z Consula, jeśli używasz słowa kluczowego „key” i z Vault, jeśli używasz słowa kluczowego „with secret”. Możesz dowiedzieć się więcej o języku szablonów tutaj. Wyrenderowany plik wyjściowy wyglądałby następująco;

server:
port: "8080"
toggles:
fooEnabled: true
database:
username: "username"
password: "password"

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.