Configuratie en Secret Management met Consul Template op Kubernetes

Onur Yilmaz

Follow

23 mrt, 2020 – 6 min read

Als platformteam bij Trendyol Tech was een van onze doelen om applicatieconfiguratie en geheimbeheer dynamisch, betrouwbaar en veilig te maken en weg te abstraheren van applicaties. We gebruiken Kubernetes ConfigMaps en Secrets al een lange tijd en ze voldoen niet volledig aan onze eisen. Bijvoorbeeld; wanneer we een configuratie wijzigen op een ConfigMap, moeten we onze applicatie pods herstarten om deze wijziging van kracht te laten worden. Soms duurt het enkele minuten voordat de wijziging is doorgevoerd in alle applicatie instances. Een ander probleem is dat Kubernetes secrets niet veilig genoeg zijn. Onze geheimen moeten veilig en controleerbaar zijn.

Onze belangrijkste eisen waren;

  • We moeten in staat zijn om applicatieconfiguraties dynamisch te veranderen zonder applicatieprocessen opnieuw te starten. Wanneer we een configuratie wijzigen, moet dit onmiddellijk effect hebben op alle applicatie-instanties.
  • Onze applicatiegeheimen moeten veilig en controleerbaar zijn. We willen ook rolgebaseerde toegangscontrole tot geheimen bieden.
  • We moeten configuratiebeheer wegleiden van applicaties. Met andere woorden, applicaties mogen niet weten waar en hoe geheimen en configuraties worden bewaard en voor hen beschikbaar worden gesteld.
  • Onze configuratie en geheimen management systeem moet hoog beschikbaar en schaalbaar zijn.

Na wat onderzoek, kwamen we uit op 2 applicaties; envconsul en consul-template.

We wisten al dat Vault de industrie standaard tool is voor het opslaan van geheimen. Het voldoet aan al onze eisen en heeft functies zoals dynamische geheimen, wat in de toekomst nuttig voor ons kan zijn. Je kunt ook Consul gebruiken als opslag backend voor Vault.

Consul is een gedistribueerd, hoog beschikbaar en schaalbaar gereedschap voor service discovery en configuratie. In ons geval zullen we alleen de key-value store functie van Consul gebruiken om niet-geheime configuraties te bewaren.

We zouden envconsul of consul-template vooral kunnen gebruiken voor de 3e eis: het weg abstraheren van configuratie management van applicaties.

Envconsul biedt een manier om een sub-proces te starten met omgevingsvariabelen uit Consul en Vault.

Consul-template vult waarden uit Consul en Vault in het bestandssysteem en houdt de waarden synchroon tijdens het werken in daemon-modus.

Een Twaalf-Factor App-regel is, configuraties in de omgeving op te slaan. Maar het probleem met Envconsul (of omgevingsvariabelen) is dat je de omgevingsvariabelen van een proces niet kunt veranderen zonder het opnieuw te starten. Dit gaat in tegen onze eerste eis. We willen in staat zijn om configuraties te veranderen zonder toepassingsprocessen te herstarten. Daarom hebben we gekozen voor consul-template.

Basisarchitectuur van applicatieproces en consul-template daemon die samen draaien

In consul-template kun je een sjabloonbestand gebruiken voor het renderen van configuratiebestanden. Dit geeft ons een grote flexibiliteit. Hier is een voorbeeld van een sjabloonbestand;

Consul-template leest dit sjabloon en vervangt de plaatshouders door waarden uit Consul als u het sleutelwoord “key” gebruikt en uit Vault als u het sleutelwoord “with secret” gebruikt. Meer informatie over de templating taal vindt u hier. Het gerenderde uitvoerbestand zou er als volgt uitzien;

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

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.