PProfessNet Academy
Git, GitHub & DevOps/06advanced12 min

Sekrety i bezpieczeństwo w pipeline (gh secret, OIDC)

Pipeline to też powierzchnia ataku

CI/CD ma dostęp do kodu, sekretów i często do środowisk produkcyjnych. Wyciek tokenu z workflow potrafi być groźniejszy niż bug w aplikacji. Ta lekcja porządkuje, jak trzymać sekrety i jak całkiem ich pozbyć się dzięki OIDC.

Sekrety w GitHub Actions

Sekrety są szyfrowane i wstrzykiwane do workflow jako zmienne. Nigdy nie trafiają do logów (GitHub maskuje ich wartości). Definiujesz je na poziomie repo, środowiska lub organizacji.

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}
        run: ./scripts/deploy.sh

Zarządzanie przez gh CLI

gh secret pozwala ustawiać sekrety z terminala — szybciej niż klikanie w panelu i łatwo zautomatyzować.

# Ustaw sekret repozytorium (z pliku lub interaktywnie)
gh secret set API_TOKEN

# Z wartości w zmiennej / pliku
gh secret set API_TOKEN --body "$TOKEN"
gh secret set SERVICE_JSON < service-account.json

# Sekret dla konkretnego środowiska
gh secret set DB_PASSWORD --env production

# Lista i usuwanie
gh secret list
gh secret delete API_TOKEN

Wskazówka: gh secret list pokazuje nazwy i daty, nigdy wartości — sekretu nie da się odczytać po zapisaniu, można go tylko nadpisać. Jeśli zgubisz wartość, wygeneruj nową i zrotuj.

Najlepsza praktyka: OIDC zamiast długowiecznych kluczy

Klasycznie do deployu na chmurę (AWS, Azure, GCP) trzymano w sekretach długowieczne klucze. To ryzyko — taki klucz, jeśli wycieknie, działa miesiącami. OIDC (OpenID Connect) eliminuje problem: GitHub wystawia krótkożyciowy token tożsamości, który chmura wymienia na tymczasowe uprawnienia. Żadnych stałych kluczy w repo.

permissions:
  id-token: write   # pozwala workflow poprosić o token OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Login do chmury przez OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/github-deploy
          aws-region: eu-central-1
      - run: ./deploy.sh

Po stronie chmury konfigurujesz trust policy, która ufa tokenom z konkretnego repo i gałęzi. Token żyje minuty, więc nawet przechwycony szybko wygasa.

Zasady bezpieczeństwa pipeline'u

ZasadaDlaczego
Minimalne permissionsDomyślnie ogranicz GITHUB_TOKEN do read
Przypinaj akcje do wersji/SHA@v4 lub konkretny SHA, nie @main
Sekrety per środowiskoProdukcja oddzielona od preview
OIDC zamiast kluczyBrak długowiecznych poświadczeń
Uważaj na pull_request_targetMoże wystawić sekrety na forki

Ograniczanie uprawnień tokenu

Domyślny GITHUB_TOKEN bywa zbyt potężny. Ustaw minimum na górze workflow:

permissions:
  contents: read

Rozszerzaj tylko tam, gdzie konkretny job naprawdę potrzebuje więcej (np. id-token: write dla OIDC, packages: write dla publikacji).

Podsumowanie

Sekrety trzymaj w GitHub Actions (szyfrowane, maskowane), zarządzaj nimi przez gh secret i rotuj po incydentach. Tam, gdzie się da, zamień długowieczne klucze na OIDC — krótkożyciowe tokeny bez stałych poświadczeń. Ogranicz permissions i przypinaj akcje do wersji. To minimum higieny bezpiecznego CI/CD.