Većina razvojnih timova i dalje čuva API ključeve, lozinke i tokene u istim konfiguracionim fajlovima u kojima se nalaze adrese servera, portovi ili nazivi servisa. Takva praksa je postala toliko uobičajena da se retko dovodi u pitanje. Međutim, sve više developera smatra da problem nije samo bezbednosni, već i arhitektonski.
Osnovna ideja je jednostavna. Konfiguracija opisuje kako se aplikacija ponaša i trebalo bi da bude deo repozitorijuma, code review procesa i dokumentacije. Tajni podaci, sa druge strane, predstavljaju ovlašćenja za pristup sistemima i zbog toga imaju potpuno drugačiji životni ciklus.
Ako promena lozinke zahteva izmenu konfiguracije aplikacije, to je znak da su dve stvari koje bi morale da budu odvojene previše čvrsto povezane.
Četvrtina NixOS modula koristi zaobilazno rešenje
Analiza 445 NixOS modula koji rade sa tajnim podacima pokazala je koliko je ovaj problem rasprostranjen. Čak 110 modula, odnosno gotovo četvrtina analiziranih, bezbedno preuzima tajni podatak, ali ga zatim ubacuje u konfiguracioni fajl zato što aplikacija ne podržava nijedan drugi način prosleđivanja kredencijala.
To znači da svaki modul mora da koristi dodatne skripte i alate poput envsubst, sed, jq ili yq kako bi tokom pokretanja napravio novu verziju konfiguracije koja sadrži i tajne podatke.
Takav pristup može biti bezbedan ako je pravilno implementiran, ali uvodi složenost koja uopšte ne bi trebalo da postoji. Svaka aplikacija zahteva sopstvenu logiku za spajanje konfiguracije i kredencijala, što povećava količinu koda koji treba održavati i otvara prostor za greške.
Ovakav obrazac nije specifičan za NixOS. Isti pristup može se pronaći u Kubernetes Helm šablonima, CI/CD pipelineovima, entrypoint skriptama i drugim alatima koji pokušavaju da spoje konfiguraciju i tajne podatke.
Tajni podaci zaslužuju poseban kanal
Umesto da lozinke i tokeni budu deo konfiguracije, aplikacije bi trebalo da podrže zaseban način njihovog prosleđivanja.
To može biti referenca na fajl sa lozinkom, systemd credential, namenska promenljiva okruženja ili integracija sa servisima poput Vaulta, 1Passworda ili cloud secret managera.
Nijedna od ovih metoda nije savršena. Promenljive okruženja mogu da se nasleđuju između procesa, argumenti komandne linije mogu završiti u listi aktivnih procesa, a fajlovi zahtevaju pažljivo podešene dozvole pristupa.
Međutim, zajednička prednost svih ovih pristupa jeste to što konfiguracija više ne mora da sadrži poverljive podatke. Na taj način razvojni tim može da deli konfiguraciju bez rizika da će zajedno sa njom podeliti i pristup produkcionim servisima.
Greška koju je napravio i Cachix
Dobar primer ovog problema je Cachix. Ovaj alat je godinama čuvao autentikacioni token i ključeve za potpisivanje u istom konfiguracionom fajlu zajedno sa ostalim podešavanjima. To je značilo da deljenje konfiguracije praktično podrazumeva i deljenje kredencijala.
Na prvi pogled to je delovalo praktično. Međutim, svaki put kada bi neko želeo da podeli konfiguraciju između članova tima ili različitih okruženja, morao je da vodi računa da slučajno ne podeli i kredencijale.
Zbog toga je u novijim verzijama uveden SecretSpec, koji odvaja opis potrebnih tajni od njihovih stvarnih vrednosti. Aplikacija zna da joj je, na primer, potreban DATABASE_URL ili STRIPE_API_KEY, ali ne zna gde se oni fizički nalaze. Tu odluku donosi okruženje u kojem se aplikacija izvršava.
Na developerskoj mašini to može biti sistemski keyring, u CI okruženju promenljive okruženja, a u produkciji Vault, 1Password ili neki drugi servis za upravljanje tajnama.
Konfiguracija treba da opisuje potrebe, a ne da čuva lozinke
Upravo je to osnovna ideja koju SecretSpec pokušava da uvede. Umesto da konfiguracioni fajl sadrži konkretne vrednosti, on opisuje samo koje su aplikaciji potrebne tajne.
Na taj način ista konfiguracija može da se koristi u lokalnom razvoju, testnom okruženju i produkciji, dok svako okruženje samostalno odlučuje odakle će preuzeti odgovarajuće kredencijale.
Takav pristup olakšava rotaciju lozinki, smanjuje mogućnost curenja podataka i eliminiše veliki deo pomoćnog koda koji danas postoji samo zato što aplikacije i dalje očekuju da se tajni podaci nalaze u konfiguracionim fajlovima.
Kako infrastruktura postaje složenija, razdvajanje konfiguracije i tajnih podataka više nije samo preporuka za bezbednost. Sve češće postaje pokazatelj kvalitetno projektovane arhitekture aplikacije.