W klastrach GKE włączono autoryzację binarną (Binary Authorization). Cloud Build uruchamia testy regresyjne i publikuje obrazy. Jak zapewnić, że tylko przetestowane obrazy mogą zostać wdrożone?

Prawidłowa odpowiedź zakłada użycie atestatora i polityki w Binary Authorization. Po pomyślnych testach regresyjnych, Kritis Signer (część Binary Authorization) jest uruchamiany w Cloud Build, aby utworzyć kryptograficzny atest (zaświadczenie) dla obrazu. Ten atest potwierdza, że obraz przeszedł wymagane testy. Polityka Binary Authorization w GKE jest skonfigurowana tak, aby zezwalać na wdrożenie tylko tych obrazów, które posiadają ważny atest od zaufanego atestatora. Pozostałe opcje są nieprawidłowe: Wdrożenie Voucher Server i Voucher Client nie jest standardowym mechanizmem Binary Authorization w GKE do zapewniania integralności obrazów po testach. Ustawienie Pod Security Standard na Restricted wzmacnia bezpieczeństwo podów, ale nie zapewnia, że tylko przetestowane obrazy są wdrażane; cyfrowe podpisywanie obrazów jest częścią procesu, ale bez odpowiedniej polityki i atestatora w Binary Authorization nie gwarantuje wymuszenia. Utworzenie atestatora i polityki jest konieczne, ale samo "utworzenie atestacji" bez użycia narzędzia takiego jak Kritis Signer do kryptograficznego podpisania i powiązania z atestatorem, nie jest kompletnym i bezpiecznym rozwiązaniem w kontekście Binary Authorization.