Kryptograficzne podpisywanie kontenerów: Sigstore, Cosign i weryfikacja pochodzenia obrazów

Obrazy kontenerów przechodzą przez repozytoria kodu źródłowego, usługi kompilacji, rejestry oraz środowiska wdrożeniowe, zanim aplikacja zostanie uruchomiona. Każdy taki etap stwarza ryzyko przypadkowej podmiany, nieautoryzowanej modyfikacji lub pomyłki dotyczącej tego, której kompilacji można zaufać. Podpis kryptograficzny ogranicza to ryzyko, ponieważ łączy konkretny skrót obrazu ze zweryfikowanym podpisującym, natomiast dane o pochodzeniu wyjaśniają, gdzie i w jaki sposób obraz został utworzony. Sigstore oraz narzędzie wiersza poleceń Cosign stały się powszechnie wykorzystywanymi elementami tego procesu, ponieważ obsługują podpisywanie oparte na tożsamości, publiczne rejestry przejrzystości i integrację ze zautomatyzowanymi procesami dostarczania oprogramowania. W 2026 roku rozwiązania te nie są już przeznaczone wyłącznie dla wyspecjalizowanych zespołów ds. bezpieczeństwa. Można je stopniowo wdrażać w standardowych procesach kontenerowych bez konieczności szczegółowego poznawania całej infrastruktury klucza publicznego.

Dlaczego obrazy kontenerów wymagają podpisu kryptograficznego

Rejestr kontenerów może potwierdzić, że obraz został poprawnie przesłany, jednak samo przechowywanie nie dowodzi, że pochodzi on od oczekiwanego zespołu programistycznego. Dane dostępowe mogą zostać skradzione, konta automatyzacji mogą być nieprawidłowo skonfigurowane, a napastnik może spróbować opublikować zmodyfikowany obraz pod znaną nazwą. Podpis stanowi dodatkowy sygnał zaufania, ponieważ łączy kryptograficzny skrót obrazu z rozpoznaną osobą, kontem usługi lub procesem ciągłej integracji. Weryfikacja pozwala następnie odpowiedzieć na praktyczne pytanie przed wdrożeniem: czy dokładnie ten obraz został podpisany przez tożsamość, którą organizacja wyraźnie zatwierdziła?

Skrót odgrywa w tym procesie kluczową rolę. Znacznik taki jak latest, stable lub 1.4 jest wygodnym odwołaniem, jednak znaczniki w rejestrze można zazwyczaj przypisać do innego obrazu. Skrót SHA-256 identyfikuje zawartość jednego konkretnego manifestu obrazu. Gdy zmienia się dowolny istotny element zawartości, zmienia się również skrót. Podpisywanie i weryfikowanie skrótu zapobiega więc niezauważonemu wykorzystaniu prawidłowego podpisu dla innej kompilacji. Dokumentacja produkcyjna powinna zachowywać odwołania oparte na skrótach, nawet jeśli czytelne dla człowieka znaczniki nadal są używane do nawigacji i zarządzania wydaniami.

Podpis nie potwierdza, że aplikacja jest pozbawiona luk bezpieczeństwa lub złośliwego kodu. Dowodzi jedynie, że podpisana zawartość nie została zmieniona oraz że podpis spełnia określone wymagania dotyczące tożsamości. To rozróżnienie jest istotne, ponieważ przejęty proces kompilacji nadal może utworzyć i podpisać szkodliwy obraz. Podpisywanie kontenerów powinno więc działać razem z przeglądem kodu, ochroną gałęzi, skanowaniem zależności, zarządzaniem sekretami oraz kontrolą uprawnień do kompilacji. Jego główną wartością jest zapewnienie wiarygodnego łańcucha kontroli pomiędzy zatwierdzonym procesem kompilacji a środowiskiem, w którym obraz zostaje wykorzystany.

Jak Sigstore łączy podpis z tożsamością

Tradycyjne podpisywanie kodu zwykle opiera się na kluczu prywatnym, który należy wygenerować, przechowywać, zabezpieczać, tworzyć jego kopie zapasowe i regularnie zmieniać. Sigstore oferuje alternatywę opartą na tożsamości, określaną często jako podpisywanie bezkluczowe. Nie oznacza to, że żaden klucz kryptograficzny nie jest używany. Cosign tworzy tymczasową parę kluczy na potrzeby operacji podpisywania, jednak klucz prywatny pozostaje krótko w pamięci zamiast funkcjonować jako długoterminowy sekret. Podpisujący uwierzytelnia się przez dostawcę OpenID Connect, dzięki czemu podpis można powiązać z istniejącą tożsamością, na przykład kontem programisty lub zautomatyzowanym procesem.

Urząd certyfikacji Fulcio należący do Sigstore sprawdza token OpenID Connect i wystawia krótkoterminowy certyfikat podpisujący, który łączy tymczasowy klucz publiczny z uwierzytelnioną tożsamością. Publiczne certyfikaty Fulcio są projektowane tak, aby pozostawały ważne jedynie przez kilka minut. Po zakończeniu podpisywania tymczasowy klucz prywatny zostaje usunięty. Takie podejście zmniejsza obciążenie operacyjne oraz ryzyko związane z długoterminowymi kluczami podpisującymi, choć jednocześnie zwiększa znaczenie bezpieczeństwa dostawcy tożsamości i uprawnień przypisanych do procesu kompilacji.

Zdarzenie podpisania jest również rejestrowane przez Rekor, czyli dziennik przejrzystości Sigstore. Dziennik przechowuje możliwe do zweryfikowania metadane dotyczące podpisów i poświadczeń w strukturze, do której można dopisywać kolejne wpisy, ale nie można ich swobodnie zmieniać. Weryfikator może sprawdzić, czy podpis powstał w okresie ważności certyfikatu oraz czy zdarzenie zostało zapisane w oczekiwanym dzienniku. Przejrzystość nie zapobiega każdemu rodzajowi nadużycia, ale sprawia, że aktywność związana z podpisywaniem jest widoczna i trudniejsza do zmodyfikowania bez wykrycia. Organizacje korzystające z podpisywania bezkluczowego powinny monitorować wpisy powiązane ze swoimi repozytoriami i tożsamościami procesów, zamiast traktować dziennik jako zapis, którego nikt nie musi przeglądać.

Podpisywanie i weryfikowanie obrazów kontenerów za pomocą Cosign

Cosign jest głównym narzędziem wiersza poleceń używanym do podpisywania i weryfikowania obrazów kontenerów z wykorzystaniem Sigstore. Proste polecenie podpisywania bezkluczowego ma postać cosign sign registry.example.com/team/application@sha256:DIGEST. W sesji interaktywnej Cosign może zażądać uwierzytelnienia przez obsługiwanego dostawcę tożsamości. W środowisku ciągłej integracji może wykorzystać token OpenID Connect wydany uruchomionemu procesowi. Obraz zazwyczaj musi zostać przesłany do zgodnego rejestru przed podpisaniem, ponieważ podpisy i powiązane rekordy są przechowywane obok obrazu jako artefakty OCI.

Cosign obsługuje również samodzielnie zarządzane klucze oraz klucze przechowywane w chmurowych usługach zarządzania kluczami lub urządzeniach sprzętowych. Takie rozwiązania nadal są przydatne, gdy organizacja wymaga prywatnej infrastruktury zaufania, podpisywania w trybie offline, formalnej kontroli nad kluczami lub zgodności z obowiązującą polityką klucza publicznego. Najważniejsza jest spójność: zespół musi wiedzieć, jaki model podpisywania obowiązuje, kto kontroluje zaufany klucz lub tożsamość oraz w jaki sposób weryfikatorzy uzyskują odpowiednie informacje o zaufaniu. Łączenie kilku nieudokumentowanych metod podpisywania utrudnia analizę incydentów i egzekwowanie zasad.

Współczesne procesy wykorzystujące Cosign mogą powiązać z obrazem nie tylko podstawowy podpis. Poświadczenia mogą zawierać ustrukturyzowane deklaracje, takie jak dane o pochodzeniu kompilacji lub zestawienie składników oprogramowania. Rekordy te są przechowywane niezależnie od warstw obrazu, dlatego dodanie poświadczenia nie zmienia skrótu obrazu aplikacji. Cosign może wyświetlać rekordy łańcucha dostaw powiązane z obrazem, w tym podpisy, poświadczenia i artefakty związane z SBOM. Zachowanie rejestrów nadal bywa różne, szczególnie w zakresie usuwania danych i zarządzania cyklem życia, dlatego zespoły powinny przetestować podpisywanie, pobieranie, replikację i czyszczenie danych w rzeczywiście używanych rozwiązaniach rejestrowych.

Sprawdzanie tożsamości, integralności i pochodzenia obrazu

Przydatna polityka weryfikacji musi określać tożsamość, która powinna podpisywać obraz. Uruchomienie Cosign bez jasno wskazanej oczekiwanej tożsamości może potwierdzić, że ktoś utworzył prawidłowy podpis Sigstore, ale nie dowodzi, że podpisujący należy do właściwego projektu. Weryfikacja bezkluczowa obejmuje więc zarówno tożsamość zapisaną w certyfikacie, jak i wystawcę OpenID Connect. W przypadku zautomatyzowanego procesu oczekiwana tożsamość może zawierać repozytorium, plik procesu i odniesienie do gałęzi. Reguła weryfikacyjna powinna być na tyle precyzyjna, aby odrzucać podpisy pochodzące z niepowiązanych repozytoriów lub niezatwierdzonych procesów.

Cosign sprawdza również, czy skrót zapisany w danych podpisu odpowiada weryfikowanemu obrazowi. Typowe polecenie wykorzystuje cosign verify wraz z pełnym odwołaniem do obrazu, oczekiwaną tożsamością certyfikatu i oczekiwanym wystawcą OIDC. Pomyślny wynik należy traktować jako ustrukturyzowany dowód, a nie jedynie prosty sygnał powodzenia. Warto sprawdzić, który skrót obrazu został zweryfikowany, jaka tożsamość go podpisała, który wystawca ją uwierzytelnił oraz czy dane z dziennika przejrzystości zostały potwierdzone. Nieudana weryfikacja powinna zatrzymywać promocję lub wdrożenie zamiast być zamieniana w ostrzeżenie, które zespoły z czasem zaczynają ignorować.

Dane o pochodzeniu odpowiadają na pytania, których sam podpis nie rozstrzyga. W modelu SLSA pochodzenie oznacza możliwe do zweryfikowania informacje opisujące, gdzie, kiedy i w jaki sposób utworzono dany artefakt. W przypadku obrazu kontenera mogą one wskazywać repozytorium źródłowe, rewizję kodu, proces kompilacji, tożsamość narzędzia budującego oraz inne szczegóły wykonania kompilacji. Podczas weryfikacji należy porównać te deklaracje z wymaganiami organizacji. Obraz może zawierać prawidłowe dane o pochodzeniu, a mimo to nie nadawać się do użycia, jeśli został zbudowany z niezatwierdzonej gałęzi, nieoczekiwanego repozytorium lub niezaufanego procesu. Autentyczne metadane trzeba więc sprawdzać względem zasad, a nie jedynie potwierdzać ich obecność.

Integracja weryfikacji obrazów z procesami dostarczania oprogramowania

Najbardziej niezawodny model polega na jednokrotnym zbudowaniu obrazu, przesłaniu go do rejestru i zapisaniu uzyskanego skrótu. Proces powinien podpisywać właśnie ten skrót, zamiast osobno przebudowywać obraz dla każdego środowiska. Poświadczenia dotyczące pochodzenia oraz SBOM można następnie wygenerować dla tego samego skrótu obiektu. Etapy programistyczne, testowe i produkcyjne promują to niezmienne odwołanie bez modyfikowania jego zawartości. Eliminuje to niepewność dotyczącą tego, czy różne środowiska korzystają z równoważnych kompilacji, i zapewnia jeden możliwy do prześledzenia obiekt na potrzeby przeglądu, zatwierdzania, wycofywania zmian i reagowania na incydenty.

Weryfikacja powinna odbywać się w więcej niż jednym miejscu. Proces wydawniczy może sprawdzić obraz przed przeniesieniem go do rejestru produkcyjnego lub oznaczeniem jako zatwierdzony. Narzędzia wdrożeniowe mogą powtórzyć kontrolę przed aktualizacją obciążenia. Środowiska Kubernetes mogą wykorzystywać Sigstore Policy Controller jako warstwę kontroli dopuszczenia, która zezwala na użycie obrazów lub je odrzuca zgodnie z polityką podpisów i poświadczeń. Kontroler może również rozwiązywać zmienne znaczniki, dzięki czemu dopuszczony skrót pozostaje powiązany z obrazem, który został sprawdzony. Ogranicza to ryzyko przekierowania znacznika pomiędzy momentem dopuszczenia a uruchomieniem.

Egzekwowanie zasad należy wprowadzać etapami. Zespoły mogą rozpocząć od zbierania wyników weryfikacji i identyfikowania niepodpisanych obrazów, nieoczekiwanych tożsamości procesów oraz problemów ze zgodnością rejestrów. Etap ostrzeżeń pozwala zinwentaryzować starsze obciążenia bez blokowania pilnych działań. Następnie zasady można egzekwować w ograniczonej liczbie przestrzeni nazw lub usług, zanim zostaną rozszerzone na pozostałe środowiska. Końcowe reguły powinny określać, które rejestry są akceptowane, którym tożsamościom podpisującym można ufać, czy dane o pochodzeniu są obowiązkowe, jakie repozytoria źródłowe i gałęzie są dozwolone oraz w jaki sposób zatwierdza się i dokumentuje wyjątki awaryjne.

Ograniczenia operacyjne i rozsądne praktyki bezpieczeństwa

Prawidłowy podpis nie rekompensuje słabych zabezpieczeń dotyczących tożsamości podpisującej. Jeżeli napastnik może zmodyfikować zatwierdzony proces lub uzyskać uprawnienie do pobrania jego tokenu OpenID Connect, utworzony obraz może wyglądać tak, jakby pochodził z zaufanego źródła. Uprawnienia do repozytorium, chronione gałęzie, przegląd procesów oraz ograniczone dane dostępowe automatyzacji nadal mają podstawowe znaczenie. Kroki podpisujące i zewnętrzne komponenty procesów powinny być również przypięte do określonych wersji i regularnie sprawdzane, aby nieplanowana aktualizacja nie mogła zmienić sposobu kompilacji lub podpisywania bez odpowiedniej kontroli.

Materiały zaufania wymagają zarządzania cyklem życia nawet wtedy, gdy używane są klucze tymczasowe. Weryfikatorzy zależą od zaufanych głównych urzędów certyfikacji, informacji z dziennika przejrzystości i zasad dotyczących tożsamości. Środowiska odizolowane od sieci mogą wymagać pakietów zawierających podpis, certyfikat, znacznik czasu i dowód umieszczenia wpisu w dzienniku, wraz z zatwierdzoną kopią odpowiednich głównych źródeł zaufania. Prywatne wdrożenia Sigstore wymagają dodatkowej ostrożności, ponieważ organizacja samodzielnie odpowiada za obsługę i ochronę usług Fulcio, Rekor oraz dystrybucję informacji o zaufaniu. Prywatne wdrożenie powinno wynikać z konkretnych wymagań prawnych, zgodności lub warunków operacyjnych, a nie jedynie z przekonania, że daje większą kontrolę.

Najlepszą miarą skuteczności nie jest liczba podpisanych obrazów, lecz liczba wdrożeń opartych na zweryfikowanych dowodach. Dojrzały proces pozwala powiązać uruchomiony skrót z podpisem, tożsamością podpisującego, rewizją kodu źródłowego, procesem kompilacji, deklaracją pochodzenia i zapisem zatwierdzenia. Obejmuje również udokumentowany sposób postępowania w przypadku nieudanej weryfikacji, nieoczekiwanych wpisów w dzienniku lub przejętych tożsamości. Sigstore i Cosign dostarczają kryptograficznych oraz operacyjnych elementów takiego procesu, jednak każda organizacja musi samodzielnie określić wymagania, które przekształcą te rekordy w rzeczywiste decyzje dotyczące zaufania.