Un workflow de deployment poate construi aplicația, publica pachete și modifica producția. Identitatea sa și datele de intrare merită aceeași atenție ca aplicația. O modernizare utilă combină accesul temporar la cloud cu o legătură verificabilă între codul sursă, build și artefactul instalat.
Există și un detaliu concret pentru 2026: GitHub documentează un nou format implicit al subiectului OIDC pentru repository-urile create după 15 iulie 2026, care include identificatori imuabili ai proprietarului și repository-ului. Acesta nu este disponibil în GitHub Enterprise Server. Nu copia un subiect dintr-o politică veche fără să verifici formatul folosit de repository-ul tău. Consultă documentația OIDC.
Înlocuiește cheile stocate cu o relație de încredere limitată
Prin OIDC, un job obține un token de identitate GitHub și îl schimbă la furnizorul cloud pentru credențiale temporare. Politica de încredere stabilește ce identități pot prelua un rol; permisiunile rolului stabilesc ce pot face.
Restricționează emitentul, audiența și atributele de identitate acceptate la repository-ul și contextul de deployment dorite. Dacă subiectul folosește un environment, configurează și restricțiile de branch și regulile de protecție ale acestuia. OIDC elimină o credențială stocată, dar nu face sigur un rol cu permisiuni excesive.
Păstrează permisiunile cloud în jobul de deployment
Folosește implicit acces numai pentru citire la repository și permite emiterea tokenului doar în jobul care are nevoie de el. Fragmentul următor arată separarea permisiunilor, nu un workflow complet de deployment:
permissions:
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
permissions:
contents: read
id-token: write
steps:
- name: Verificarea cerintelor pentru deployment
run: echo "Configureaza autentificarea cloud si verificarea artefactului"
Adaugă acțiunea de autentificare documentată de furnizorul cloud, fixată la un SHA complet verificat, și configurează politica de încredere înainte de a activa deployment-ul. id-token: write permite solicitarea unui token de identitate; nu acordă direct acces la resurse cloud.
Ține build-urile pentru pull request-uri neverificate în afara acestui job privilegiat. Nu executa codul unui pull request într-un workflow privilegiat doar pentru că triggerul sau fișierul workflow provine din branch-ul implicit.
Identifică exact rezultatul build-ului
Construiește o singură dată și înregistrează digestul artefactului. Generează proveniența pentru acel rezultat în workflow-ul de build de încredere, apoi promovează același digest prin staging și producție. Un build nou după aprobare creează un alt rezultat și rupe legătura dintre ce a trecut testele și ce instalezi.
Atestările GitHub pot asocia un artefact cu originea build-ului. Disponibilitatea depinde de vizibilitatea repository-ului și de plan; verifică ghidul atestărilor înainte să le transformi într-o condiție obligatorie pentru deployment.
Pentru un binar descărcat care are o atestare, verificarea poate arăta astfel:
gh attestation verify ./dist/service --repo YOUR_ORG/YOUR_REPO
Înlocuiește repository-ul și calea. Rulează verificarea într-un job de încredere și oprește deployment-ul la eroare. Definește ce repository și workflow sunt acceptate și asigură-te că instalezi exact octeții verificați. Proveniența stabilește originea; nu dovedește absența vulnerabilităților.
Protejează și celelalte intrări ale workflow-ului
Fixează acțiunile terțe la SHA-uri complete și folosește actualizări automate ale dependențelor cu revizuire. Tratează numele branch-urilor și titlurile PR-urilor ca date neverificate: transmite-le prin variabile de mediu, în loc să interpolezi expresii direct în cod shell executabil. Aceste măsuri sunt descrise în referința de utilizare sigură GitHub.
Pentru runner-ele proprii, preferă instanțe izolate și temporare pentru joburile sensibile. Un runner persistent care a executat cod neverificat nu este un loc potrivit pentru credențiale de producție, chiar dacă sunt temporare.
Demonstrează că restricțiile funcționează
Testează atât succesul, cât și refuzul. Un release permis trebuie să obțină rolul limitat. Un branch neaprobat, un repository fără legătură sau un job din afara environment-ului așteptat trebuie să eșueze. Un artefact modificat trebuie să nu treacă verificarea.
Înregistrează digestul artefactului, commitul sursă, execuția workflow-ului, mediul țintă și persoana care a aprobat fiecare deployment. Pentru revenire, păstrează un artefact verificat anterior și instalează exact acea versiune prin același proces controlat. Astfel, configurația de securitate devine un proces de release auditabil.