Del hemmeligheder på tværs af services med projekt- og clustervariabler

Du har en API-nøgle eller en database-adgangskode, som flere services skal bruge. At indsætte den i hver services env er en hemmelighed der venter på at lække, og en plage at rotere — skift den et sted, og du jagter den i alle de andre. Suble har nu delte variabler: definer en værdi en gang, og referer så til den eksplicit der hvor du faktisk skal bruge den.

To niveauer: projekt og cluster

Projektvariabler ligger på projektet og kan bruges af enhver cluster og instans i det — referer til dem som %{project.NAME}%. Clustervariabler er bundet til en enkelt cluster, og kun dens services kan bruge dem — referer til dem som %{cluster.NAME}%. Namespacene er eksplicitte, så der er ingen skjult rangorden at forholde sig til: du refererer præcis til den, du mener.

De er opt-in — intet lækker

En variabel når kun frem til en container der eksplicit refererer til den. Der er ingen auto-indsprøjtning: en service der ikke skriver %{project.dbPassword}%, ser aldrig den værdi. Det er hele pointen — et delt lager, ikke en delt klump der spreder alle hemmeligheder ud i alle containere i et helt cluster.

Referer til dem overalt hvor du sætter env

Læg en reference inde i en env-værdi — i en cluster-service, en enkelt-instans Docker-app eller din suble.yaml. Fordi det er almindelig streng-interpolation, kan du omdøbe variablen til det din app forventer, og endda indlejre den i en større streng:

# en cluster-service
env:
  API_KEY: "%{project.stripeKey}%"
  DATABASE_URL: "postgres://app:%{cluster.dbPassword}%@db:5432/app"

Nøglen til venstre er hvad din app læser; referencen til højre henter den delte værdi. At indlejre den midt i en connection-URL virker præcis som du håber.

Opløst ved deploy — roter en gang, opdater overalt

Referencer udvides ved deploy-tidspunktet, på maskinen, lige før containeren starter. Din service-konfiguration gemmer referencen, aldrig en kopi af hemmeligheden. Så når du roterer en variabel og redeployer, henter enhver forbruger den nye værdi automatisk — ingen manuel genredigering af hver service.

Hemmeligheder er skriv-en-gang

Marker en variabel som hemmelighed, og dens værdi krypteres i hvile og vises aldrig igen — dashboardet maskerer den, og API'et returnerer den aldrig. Du kan rotere den (angive en ny værdi) men ikke læse den tilbage. Lad hemmeligheds-kontakten være slået fra for ikke-følsom konfiguration, så forbliver den værdi læsbar og kan kopieres.

Opret og administrer dem

Projektvariabler ligger under Projekt → Indstillinger → Delte variabler; clustervariabler er på cluster-siden. Giv hver et navn og en værdi, vælg hemmelighed eller almindelig, og kopier den færdige %{…}%-reference med et klik. Forsøg på at slette en variabel som en service stadig refererer til, blokeres, så du ikke ved et uheld ødelægger et kørende deploy.

I CI, med suble.yaml

De samme referencer virker i suble.yaml, så din committede konfiguration bærer ingen hemmeligheder — kun referencen. suble update sender den til Suble, som opløser den server-side ved deploy. (Lokal ${VAR}-udvidelse virker også stadig, for værdier du injicerer fra dit eget CI-miljø — de to er uafhængige.)

name: web
image: registry.suble.io/acme/web:1
env:
  STRIPE_KEY: "%{project.stripeKey}%"

Definer en gang, referer eksplicit, roter et sted. Dine hemmeligheder ligger i et bevogtet lager i stedet for spredt ud over hver services konfiguration — og de lander kun nogensinde i de containere der faktisk bad om dem.