Separați automatizarea și administrarea personală
Un pipeline API de raportare trebuie să selecteze un artefact aprobat și să invoce o acțiune de versiune controlată. Aceasta nu necesită automat crearea de utilizatori, modificarea facturării sau citirea fiecărui secret al aplicației. Începeți cu un inventar al permisiunilor și un mediu de test protejat; păstrați acreditările în afara documentelor, depozitelor și jurnalelor exemplu.
Accesul uman pentru recuperare ar trebui să rămână separat, astfel încât revocarea unei acreditări de implementare să nu elimine singura cale de investigare. Identificați un maintainer autorizat și verificarea independentă a hostului. O a doua cheie nerestricționată este o altă acreditare, nu un rol mai îngust.
Descrieți cu precizie operația permisă
| Capabilitate | Necesar? | Graniță |
|---|---|---|
| Citiți artefactul aprobat | Da | Depozit/versiune specifică |
| Invocați acțiunea de versiune | Da | Aplicație și mediu fixate |
| Citiți fiecare secret de rulare | Evitați | Identitate de rulare controlată |
| Modificați utilizatori sau politica SSH | Nu | Administrare separată |
| Modificați configurația fluxului de lucru | Nu pentru identitatea de rulare | Revizuire în depozit protejat |
| Ștergeți backup-urile | Nu | Permisiuni de recuperare separate |
Validați intrările acțiunii de versiune. O comandă restricționată care concatenează text arbitrar într-un shell privilegiat permite totuși muncă neintenționată. Revizuiți împreună comportamentul wrapper-ului, căile inscriptibile și încrederea în artefacte. Privilegiile sudo largi sau accesul la socket-ul Docker pot înfrânge granița dorită.
Tratați modificările fluxului de lucru ca acces la acreditări
Cineva capabil să modifice pași de flux de lucru de încredere poate folosi sau expune acreditările acestora. Revizuiți permisiunile depozitului, mediile de implementare protejate și ce evenimente rulează joburi privilegiate. Țineți acreditările de producție departe de codul pull-request neîncrezut. Acordați unui token de flux de lucru doar permisiunile de care are nevoie jobul său.
GitHub recomandă fixarea la SHA complet al commit-ului pentru selectarea acțiunilor imuabile. Revizuiți acțiunea selectată și actualizările ulterioare; un tag de versiune se poate muta. Evitați inserarea datelor de eveniment neîncrezute direct în codul shell inline. Mascarea valorilor de secret cunoscute nu este o garanție împotriva divulgării prin transformări, jurnale sau artefacte.
Referință tehnică: Utilizare securizată GitHub Actions.
Utilizați durată scurtă de viață când destinația o permite
OpenID Connect poate permite unei destinații acceptate să schimbe identitatea fluxului de lucru cu o acreditare de scurtă durată. Configurați verificări de încredere pentru depozitul, branch-ul sau mediul și audiența intenționate. Aceasta nu este nici o înlocuire universală a SSH, nici o caracteristică oferită de frontend-ul PrivacyNodes actual.
Dacă implementarea dumneavoastră folosește SSH, revizuiți opțiunile de chei autorizate ale pachetului instalat. O comandă forțată singură nu interzice forwarding-ul; restricțiile trebuie să acopere căile de acces intenționate și să invoce totuși o operație de versiune sigură. Testați într-un mediu separat. Păstrați accesul de administrare și recuperare funcțional în timp ce schimbați autentificarea și verificați o conexiune independentă nouă înainte de a elimina metoda veche.
Referință tehnică: GitHub Actions OpenID Connect · format OpenSSH authorized_keys.
Testați munca permisă și interzisă
Verificați că identitatea poate selecta artefactul intenționat, invoca versiunea și obține un rezultat util. Apoi testați-i limitele: secretele altei aplicații, modificările de fișiere nelegate și administrarea arbitrară ar trebui să fie indisponibile. Includeți căile de artefacte și argumentele pe care wrapper-ul trebuie să le respingă.
Înregistrați identitatea, scopul, expirarea unde este cazul, maintainerul care aprobă și locația dovezilor de audit. Păstrați referințe de stocare în loc de valori ale acreditărilor. Dacă un test funcționează doar după acordarea de administrare largă, revizuiți sarcina de versiune în loc să o faceți în mod tacit rolul permanent.
Repetați revocarea și o versiune cu pipeline defect
Pregătiți un înlocuitor cu scopul revizuit, verificați o implementare de test, comutați pipeline-ul și revocați identitatea veche. Confirmați că acreditarea înlocuită eșuează și nu rămâne niciun duplicat în alt flux de lucru. Adăugarea doar a unei chei noi nu elimină accesul anterior.
Documentați cum un maintainer autorizat oprește implementarea și recuperează când CI este indisponibil. Legați această procedură de înregistrarea lansării și inventarul de recuperare. O acreditare îngustă limitează autoritatea intenționată; nu face un artefact răuvoitor inofensiv.
Referințe oficiale
Documentația a fost revizuită pentru acest articol. Exemplele sunt exerciții de planificare, nu comenzi testate pe un server PrivacyNodes. Verificați documentația pentru versiunea instalată.