De fiecare dată când partajezi un fișier Compose, există două artefacte: cel pe care l-ai scris și cel pe care un instrument îl randează după înlocuirea variabilelor. Al doilea este adesea mai sensibil decât primul, și exact pe acesta îl lipesc oamenii într-un raport de problemă fără să-l citească. Dacă verifici doar fișierul sursă, verifici documentul greșit.

Compară ce poate conține fiecare copie înainte de a decide ce trebuie eliminat.

Modelul randat este un alt document

Compose rezolvă variabilele de mediu, îmbină fișierele de suprascriere și produce o configurație efectivă pe care cititorul nu o mai poate distinge de valori scrise de mână. O referință precum numele unei variabile din sursă devine în ieșire chiar tokenul contului. Structura care face fișierul util pentru diagnostic supraviețuiește acelei transformări; la fel supraviețuiește tot ce nu ar fi trebuit să fie vreodată în el.

Randează fișierul singur înainte de a-l atașa și tratează acea ieșire ca artefactul aflat în revizuire. Dacă nu îl poți randa, nu poți ști ce urmează să publici.

Secretele stau în mai multe locuri decât în câmpul cheii

Începe cu evidentul: chei private, chei partajate anterior, tokenuri, parole și adrese URL de conexiune care încorporează credențiale. Apoi uită-te la tot ce indică fișierul, pentru că o referință nu este o eliminare. Un fișier de mediu montat în serviciu, un fișier de configurare legat de pe host, o etichetă care poartă un token și un argument de comandă care include o parolă călătoresc toate cu implementarea chiar și atunci când YAML-ul pare curat. O cheie lipită într-o variabilă cu un nume liniștitor rămâne o cheie.

Căile de pe host și numele serviciilor scurg un al doilea tip de informație. Numele unui director personal, un nume de host intern sau un interval de rețea pot identifica o persoană sau o organizație fără să conțină nicio credențială, iar acel context merită eliminat din același motiv.

Declarația unui secret nu este secretul

Obiectele secret din Compose separă declarația de material: serviciul primește o cale sau o țintă, iar conținutul trăiește altundeva. Păstrarea declarației în timp ce materialul este înlocuit este de obicei schimbul corect, pentru că revizuitorul trebuie să vadă că un secret există și cum este montat. Ceea ce nu trebuie să supraviețuiască este conținutul în sine.

Etichetele și comentariile merită același tratament. Un comentariu care spune ce cale din seif ține cheia de producție îi spune unui atacator unde să se uite chiar dacă nu conține nicio cheie.

Păstrează forma ca fișierul să diagnosticheze în continuare

O eliminare care scoate modul de rețea, versiunea imaginii sau setările de capabilități produce un fișier cu care nimeni nu poate face depanare. Înlocuiește valorile sensibile și păstrează relațiile: ce serviciu montează ce, în ce rețea intră, de ce dispozitiv are nevoie. Aceasta este partea pe care cititorul o folosește pentru a explica o rută lipsă sau un dispozitiv indisponibil. Este și versiunea pe care un coleg o poate compara cu propria implementare funcțională.

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

Nu implementa copia redactată ca și cum ar fi originalul funcțional. Este o descriere, iar o descriere editată ca să pară sigură va eșua în feluri care seamănă cu erori de configurare.

Dacă materialul a fost expus, înlocuiește-l

Eliminarea atașamentului nu elimină copiile pe care alții le-au făcut deja, iar oglinzile și cache-urile le păstrează pe ale lor. Folosește procesul de revocare și înlocuire al emitentului pentru tot ce a scăpat, apoi actualizează implementarea. Ordinea contează, pentru că înlocuirea mai întâi și revocarea după lasă o fereastră cu două credențiale valide.

În firele de suport, începe cu eroarea exactă, versiunea imaginii, modul de rețea și singura setare care nu este secretă și care contează. Acea combinație explică un dispozitiv lipsă sau o rută ruptă mult mai des decât cheia.

Articole similare