Zarządzanie sekretami w pipeline CI/CD to kontrola nad hasłami, tokenami i kluczami, których potoki używają do budowania i wdrażania oprogramowania: gdzie leżą, kto ma do nich dostęp, jak długo są ważne i jak szybko można je wymienić. Ten artykuł opisuje to na jawnie przykładowym scenariuszu wdrożenia.
Na skróty
Czego dowiesz się z artykułu:
- Jakie błędy w obchodzeniu się z poświadczeniami opisuje OWASP dla środowisk CI/CD
- Jak zastąpić statyczne klucze krótkotrwałymi tokenami przez OIDC
- Jak ułożyć menedżer sekretów, rotację i skanowanie repozytoriów
- Kto w zespole odpowiada za poszczególne elementy
Dla kogo jest ten artykuł:
- Inżynierowie DevOps i zespoły platformowe
- Specjaliści bezpieczeństwa aplikacji i DevSecOps
- Liderzy zespołów programistycznych
Czas czytania: 8 minut
Zastrzeżenie: to scenariusz przykładowy
Opisana niżej firma jest fikcyjna. To złożony z typowych sytuacji przykład organizacji średniej wielkości, a nie relacja z konkretnego wdrożenia. Nie podajemy nazw, liczb ani wyników, bo nie pochodzą z pomiaru. Każdy krok opiera się na wytycznych i dokumentacji wskazanych w źródłach.
Dlaczego sekrety w potokach to osobne ryzyko
OWASP opisuje ten problem jako ryzyko CICD-SEC-6 „Insufficient Credential Hygiene” na liście ryzyk bezpieczeństwa CI/CD (owasp.org). Atakujący szuka sekretów i tokenów rozsianych po potokach, a ułatwiają mu to słaba kontrola dostępu do poświadczeń, niebezpieczne przechowywanie i zbyt szerokie uprawnienia. OWASP wymienia typowe błędy:
- poświadczenia wypchnięte do repozytorium — nawet po usunięciu z gałęzi zostają w historii commitów;
- poświadczenia używane w kompilacji i wdrożeniu bez kontroli, który potok i który krok ma do nich dostęp;
- sekrety w warstwach obrazów kontenerowych, potrzebne tylko przy budowaniu obrazu;
- sekrety wypisane w logach kompilacji;
- poświadczenia, których nikt nie rotuje, bo „działa, więc nie ruszamy”.
Punkt wyjścia w scenariuszu
Firma ma kilka zespołów programistycznych. Większość korzysta z GitHub Actions, dział analityki danych z GitLab CI, a aplikacje trafiają do chmury publicznej. Potoki logują się do chmury statycznymi kluczami zapisanymi jako sekrety repozytoriów. Ten sam klucz z szerokimi uprawnieniami krąży między wieloma potokami, a jego właściciel dawno zmienił zespół. Nikt nie wie dokładnie, ile takich kluczy istnieje. To odpowiada niemal każdemu punktowi z listy OWASP.
Inwentaryzacja i najmniejsze uprawnienia
Pierwsze zalecenia OWASP są organizacyjne: stale mapować poświadczenia w całym ekosystemie, od kodu po wdrożenie, przyznawać każdemu dokładnie te uprawnienia, których potrzebuje, i nie współdzielić tego samego zestawu poświadczeń w różnych kontekstach. W scenariuszu zespół platformowy sporządza rejestr: jaki sekret, w którym repozytorium i środowisku, do czego daje dostęp i kto jest jego właścicielem.
Dokumentacja GitHub na docs.github.com pozwala od razu ograniczyć zasięg. Sekrety organizacji można udostępnić tylko wybranym repozytoriom, a dostęp do sekretów środowiska może wymagać zatwierdzenia przez wyznaczonych recenzentów. W GitLab zmienną CI/CD można oznaczyć jako chronioną (dostępna tylko w potokach na chronionych gałęziach i tagach) oraz maskowaną w logach (docs.gitlab.com).
Krótkotrwałe poświadczenia zamiast statycznych kluczy
OWASP zaleca poświadczenia tymczasowe zamiast statycznych. W potokach realizuje się to przez OpenID Connect (OIDC). Według dokumentacji GitHub po skonfigurowaniu zaufania u dostawcy chmury potok prosi o krótkotrwały token dostępu, ważny dla jednego zadania i wygasający automatycznie. Nie trzeba już kopiować kluczy chmurowych do GitHub jako długotrwałych sekretów. GitLab daje ten sam mechanizm przez tokeny ID (JWT) deklarowane w zadaniu słowem kluczowym id_tokens. Po stronie Azure odpowiada temu federacja tożsamości obciążeń (workload identity federation) w Microsoft Entra ID, która ufa tokenom zewnętrznego dostawcy tożsamości, na przykład GitHub (learn.microsoft.com).
W scenariuszu zespół zaczyna od potoków wdrożeniowych do produkcji, bo ich klucze dają najszersze uprawnienia. Zaufanie ogranicza się do konkretnego repozytorium i gałęzi, zgodnie z zaleceniem OWASP, by użycie poświadczeń zawęzić do określonych warunków.
Menedżer sekretów i rotacja
Nie każdy sekret da się zastąpić tokenem federacyjnym. Hasła do baz danych czy klucze API usług zewnętrznych trafiają do menedżera sekretów. GitLab obsługuje zewnętrznych dostawców sekretów, m.in. HashiCorp Vault, Google Cloud Secret Manager, Azure Key Vault i AWS Secrets Manager. W odróżnieniu od zmiennych CI/CD, dostępnych w zadaniach zawsze, sekret z zewnętrznego dostawcy zadanie musi jawnie zamówić. Google Secret Manager przechowuje kolejne wersje sekretu, co pozwala wrócić do poprzedniej po błędnej zmianie (cloud.google.com). AWS Secrets Manager rotuje sekrety automatycznie, na żądanie albo według harmonogramu (aws.amazon.com).
Skanowanie repozytoriów i logów
OWASP (owasp.org) zaleca wykrywanie sekretów w trzech miejscach: wtyczką w IDE przy zmianach lokalnych, automatycznym skanowaniem przy każdym wypchnięciu kodu i okresowym skanowaniem repozytorium razem z historią commitów. Logi wymagają osobnej uwagi. GitHub Actions automatycznie maskuje w logach wartości sekretów, ale dokumentacja zastrzega, że maskowanie nie jest gwarantowane, bo sekret można przekształcić, a runner maskuje tylko sekrety użyte w bieżącym zadaniu. Do tego dochodzi kontrola artefaktów: warstw obrazów, plików binarnych i paczek Helm.
Role i szerszy kontekst
- Zespół platformowy / DevOps — konfiguruje OIDC, menedżer sekretów i szablony potoków.
- Administrator chmury — definiuje relacje zaufania i role z najmniejszymi uprawnieniami.
- Bezpieczeństwo aplikacji (DevSecOps) — ustala zasady, prowadzi skanowanie i procedurę reakcji na wyciek, w tym unieważnienie i wymianę sekretu.
- Właściciele repozytoriów — utrzymują rejestr sekretów swoich projektów.
Szerszą ramę daje publikacja NIST SP 800-204D z lutego 2024 r. na csrc.nist.gov, poświęcona strategiom włączania zabezpieczeń łańcucha dostaw oprogramowania do potoków CI/CD w modelu DevSecOps. Sekrety to tylko jedna z warstw — obok poświadczeń pochodzenia artefaktów (provenance), atestacji i SBOM.
Czytaj także
- Budowa pipeline CI/CD od podstaw — co się zmienia — struktura potoku od pierwszego commita
- GitHub Actions dla automatyzacji wdrożeń — wdrożenia z GitHub Actions krok po kroku
- Bezpieczeństwo tożsamości w chmurze (IAM) — role i uprawnienia, z których korzystają potoki
Rozwijaj kompetencje
Temat rozwijają szkolenia GitHub Actions i GitHub Advanced Security oraz Wdrożenie CI/CD z GitLab CI. Pierwsze obejmuje workflow CI/CD i skanowanie sekretów (secret scanning), drugie konfigurację potoków GitLab, w tym zmienne i sekrety. Skontaktuj się z nami, żeby dopasować zakres do swojego zespołu.
Najczęściej zadawane pytania (FAQ)
Od czego zacząć bezpieczne wdrożenie CI/CD?
Od inwentaryzacji poświadczeń i zasady najmniejszych uprawnień. Potem warto zastąpić statyczne klucze do chmury krótkotrwałymi tokenami OIDC, przenieść pozostałe sekrety do menedżera sekretów i włączyć skanowanie repozytoriów. Taka kolejność ogranicza najpierw sekrety o najszerszym zasięgu.
Czym jest DevSecOps?
DevSecOps to sposób wytwarzania oprogramowania, w którym bezpieczeństwo jest częścią pracy zespołów programistycznych i operacyjnych od początku, a nie osobnym etapem na końcu. Publikacja NIST SP 800-204D opisuje go jako elastyczny, zwinny model pracy, którego cechą są potoki CI/CD, i pokazuje, jak włączyć do nich zabezpieczenia łańcucha dostaw oprogramowania.
Jak przechowywać sekrety w GitHub Actions i GitLab CI?
W GitHub Actions sekrety zapisuje się na poziomie organizacji, repozytorium albo środowiska, z ograniczeniem dostępu do wybranych repozytoriów i zatwierdzaniem dostępu do sekretów środowiska. W GitLab CI zmienne można chronić i maskować, a wrażliwe dane pobierać z zewnętrznego menedżera sekretów. Tam, gdzie to możliwe, lepszy jest token OIDC niż przechowywany klucz.
Jak monitorować procesy CI/CD pod kątem bezpieczeństwa?
Sprawdzaj, które potoki mają dostęp do których sekretów, skanuj repozytoria i historię commitów, przeglądaj logi kompilacji pod kątem wycieków i kontroluj artefakty, w tym warstwy obrazów kontenerowych. OWASP zaleca też okresowe wykrywanie nieużywanych poświadczeń i rotację wszystkich statycznych.