Podpis obrazu kontenera to za mało — Cosign może sprawdzić też pochodzenie

Aby sprawdzić podpis obrazu kontenera, uruchom cosign verify dla obrazu wskazanego digestem. Podaj zaufany klucz publiczny albo oczekiwaną tożsamość z certyfikatu i wystawcę OIDC. Instrukcja Sigstore pokazuje oba warianty i wyjaśnia, że Cosign domyślnie porównuje digest obrazu z digestem zapisanym w podpisanym ładunku.

Poprawny wynik wiąże wskazaną zawartość obrazu z zaakceptowanym kluczem lub tożsamością podpisującego. Jeżeli przed wdrożeniem musisz także ustalić deklarowane źródło i sposób budowania, sprawdź osobno podpisaną atestację pochodzenia SLSA poleceniem cosign verify-attestation, a następnie oceń jej treść. Sam podpis obrazu nie zawiera takiego dowodu procesu budowania.

Ustal digest obrazu przeznaczonego do wdrożenia

W dalszych poleceniach REGISTRY/OBRAZ@sha256:DIGEST oznacza przykładową referencję; zastąp ją nazwą i rzeczywistym digestem własnego obrazu. Tag pomaga odnaleźć wydanie, ale może zostać ponownie przypisany do innej zawartości. Referencja z digestem wskazuje konkretny manifest, dlatego użyj jej zarówno przy weryfikacji, jak i w konfiguracji wdrożenia.

Digest ustal na podstawie obrazu w rejestrze lub danych wydania. Oddzielnie ustal punkt zaufania: klucz publiczny uprawnionego wydawcy albo dokładną tożsamość podpisującego i jej wystawcę OIDC. Weryfikacja dowolnego poprawnego podpisu byłaby za słabym warunkiem, jeśli obraz miał zostać podpisany przez określony proces publikacji. Wartości oczekiwane muszą więc pochodzić z przyjętej polityki wydania, a nie z podpisu, który właśnie oceniasz.

Podpis kluczem: dopasuj go do zaakceptowanego wydawcy

Jeśli wydawca przekazał zaufany klucz publiczny, użyj cosign verify --key cosign.pub REGISTRY/OBRAZ@sha256:DIGEST. Plik cosign.pub powinien być kluczem wcześniej zaakceptowanym dla tego wydawcy. Pobranie klucza wyłącznie z tego samego niezaufanego miejsca co obraz pozwoliłoby osobie podmieniającej obraz podstawić również własny klucz.

Po powodzeniu polecenia upewnij się, że weryfikowana referencja odpowiada dokładnie temu, co trafi do środowiska. Cosign sprawdza podpis i domyślnie kontroluje twierdzenia podpisanego ładunku o obrazie, w tym jego digest. Opcja --check-claims=false wyłącza tę drugą kontrolę; jest przewidziana między innymi dla innych formatów ładunku. Przy zwykłym podpisie obrazu jej użycie osłabiłoby odpowiedź na pytanie, czy podpis dotyczy właśnie wybranego manifestu.

Podpis bez stałego klucza: sprawdź identity i issuer

W wariancie opartym na certyfikacie użyj cosign verify --certificate-identity=IDENTYFIKATOR --certificate-oidc-issuer=ISSUER_OIDC REGISTRY/OBRAZ@sha256:DIGEST. IDENTYFIKATOR i ISSUER_OIDC są tu symbolami zastępczymi. Wpisz dokładne wartości oczekiwane dla procesu podpisującego; sam certyfikat nie powinien decydować, jak szeroką tożsamość zaakceptujesz.

Tożsamością może być na przykład adres e-mail albo URI procesu automatyzacji. Wystawca OIDC stanowi osobny warunek: zgodna nazwa podpisującego przy innym wystawcy nie spełnia polityki określonej przez tę parę parametrów. Dla obrazu publikowanego przez automatyczny proces wybierz identyfikator właściwy temu procesowi, zamiast ograniczać się do ogólnej nazwy organizacji. Szerokie wyrażenie regularne może dopuścić również tożsamości, których nie zamierzano upoważnić.

Atestacja SLSA: sprawdź podpis, a potem treść

Atestacja pochodzenia opisuje deklarowane okoliczności budowania. Dokumentacja Docker wymienia w danych pochodzenia między innymi materiały wejściowe, informacje o kodzie źródłowym i parametry budowania; dla BuildKit opisuje też domyślny schemat SLSA v0.2 oraz opcjonalny v1. Zakres danych zależy ponadto od trybu atestacji: mode=min zawiera mniej szczegółów niż mode=max.

Jeżeli do obrazu dołączono podpisaną atestację obsługiwaną przez Cosign, weryfikuj ją względem tego samego digestu. Dla atestacji SLSA v1 podpisanej zaakceptowanym kluczem przykładowe polecenie brzmi cosign verify-attestation --key cosign.pub --type slsaprovenance1 REGISTRY/OBRAZ@sha256:DIGEST. Opis polecenia Cosign wymienia również typ slsaprovenance02 oraz parametry tożsamości certyfikatu i wystawcy OIDC. Wybierz typ rzeczywiście opublikowanej atestacji i punkt zaufania właściwy jej wystawcy; nie zakładaj, że atestację podpisała ta sama tożsamość co obraz.

Udana weryfikacja atestacji potwierdza jej podpis względem wybranego punktu zaufania, lecz nadal trzeba ocenić zawarte w niej twierdzenia. Porównaj subject.digest z digestem obrazu, a w predykacie sprawdź dostępne dane o źródle, rewizji, materiałach i procesie budowania. Oczekiwane repozytorium czy rewizja powinny wynikać z wymagań dla wydania. Sama obecność metadanych pochodzenia dołączonych przez narzędzie budujące nie oznacza, że istnieje podpisana atestacja, którą zweryfikuje wskazane polecenie.

Kiedy dopuścić obraz do wdrożenia

Warunek podstawowy obejmuje konkretny digest przeznaczony do uruchomienia oraz podpis pasujący do zaakceptowanego klucza albo pary tożsamość–wystawca OIDC. Jeśli polityka wydania wymaga pochodzenia, dodaj osobny warunek: poprawnie zweryfikowaną atestację SLSA, której subject wskazuje ten obraz, a dane o budowaniu odpowiadają oczekiwanemu źródłu i procesowi. Brak wymaganej atestacji powinien zatrzymać wdrożenie nawet przy poprawnym podpisie obrazu.

Każda kontrola odpowiada na inne pytanie. Podpis wiąże podpisującego z zawartością; atestacja przedstawia twierdzenia o jej wytworzeniu. Dlatego zaakceptowanie atestacji wymaga zarówno zaufania do jej wystawcy, jak i sprawdzenia konkretnych pól, na których opiera się decyzja o wdrożeniu.

Przeczytaj także:

• Podpis elektroniczny może wyglądać poprawnie — sprawdź status, osobę i datę
• C2PA nie mówi, czy obraz jest prawdziwy — czytaj podpis, nie plakietkę
• Jak testować agenta AI: odpowiedź może być dobra, a zadanie niewykonane