Cosign i External Secrets Operator: baza łańcucha dostaw Kubernetes dla MSP

Ten przewodnik łączy dwa mechanizmy open source, które MSP mogą stosować w zarządzanej flocie Kubernetes: podpisywanie i weryfikację obrazów kontenerów za pomocą Sigstore Cosign oraz trzymanie danych uwierzytelniających poza Gitem dzięki External Secrets Operator. Razem domykają dwie najczęstsze luki w łańcuchu dostaw Kubernetes — niezweryfikowane obrazy i sekrety zapisane na sztywno w manifestach — bez nowej platformy czy uzależnienia od dostawcy.

Podpis przy budowie, weryfikacja przy wdrożeniu

Cosign, część projektu open source Sigstore, podpisuje i weryfikuje obrazy kontenerów, dzięki czemu klaster Kubernetes może potwierdzić, że obraz naprawdę pochodzi z zatwierdzonego pipeline'u budowania, zanim zostanie uruchomiony. Schemat, który liczy się dla MSP, jest prosty: podpisz każdy obraz podczas builda, zweryfikuj ten podpis przy admission lub wdrożeniu i odrzuć wszystko, co nie przejdzie kontroli.

Podpisywać można długożyjącymi kluczami, którymi zarządza zespół bezpieczeństwa, albo bezkluczowym przepływem Sigstore, w którym Fulcio wydaje krótkotrwały certyfikat wiążący efemeryczny klucz z zweryfikowaną tożsamością OpenID Connect — systemem CI lub osobą — podczas gdy dziennik przejrzystości Rekor znakuje zdarzenie czasowo. Weryfikacja odbywa się tam, gdzie obraz ma zostać uruchomiony: admission controller lub bramka wdrożenia sprawdza podpis względem zatwierdzonej tożsamości lub klucza i blokuje wszystko, co niepodpisane lub niezaufane, zanim dotrze do zarządzanego klastra.

Czego podpis nie zastępuje

Podpis dowodzi pochodzenia — że konkretny digest pochodzi z konkretnego pipeline'u lub tożsamości — ale nic nie mówi o tym, czy ten digest zawiera znane podatności. Cosign ma działać obok skanera obrazów, takiego jak Trivy czy Grype, a nie zamiast niego: skaner ocenia, co jest w obrazie, podpis dowodzi, skąd on pochodzi. Traktowanie "podpisany" jako synonimu "bezpieczny" zostawia połowę kontroli bez pokrycia.

Trzymanie sekretów poza Gitem dzięki External Secrets Operator

External Secrets Operator to kontroler Kubernetes, który łączy zewnętrzne menedżery sekretów — między innymi AWS Secrets Manager, HashiCorp Vault i Azure Key Vault — z natywnymi Secretami Kubernetes, dzięki czemu dane uwierzytelniające nie muszą już znajdować się w repozytorium Git ani w chartcie Helm. Obserwuje zasób SecretStore lub ClusterSecretStore i synchronizuje wartości do Secretów Kubernetes według harmonogramu, bez konieczności logowania jawnego tekstu przez sam operator.

Ograniczenie każdego ExternalSecret do przestrzeni nazw i obciążenia, które go rzeczywiście potrzebuje, zmniejsza zasięg skutków w razie skompromitowania poda. Operator nadal zależy od kontroli dostępu i polityki rotacji samego menedżera sekretów: wynosi dane uwierzytelniające poza system kontroli wersji, ale nie zastępuje zabezpieczeń tego menedżera.

Dlaczego to połączenie liczy się dla MSP

Zarządzane floty Kubernetes zwykle gromadzą oba problemy naraz: sekrety zapisane na sztywno dla wygody i obrazy pobierane z rejestru bez kontroli podpisu. Wpięcie External Secrets w ścieżkę wdrożenia usuwa wymówkę przechowywania danych uwierzytelniających w manifestach, a polityka admission Cosign daje MSP jedną, możliwą do audytu bramkę, która ocenia, czy obraz pochodzi z jego własnego pipeline'u.

Żadne z tych narzędzi samo w sobie nie jest kompletnym programem bezpieczeństwa. Weryfikacja Cosign jest tak silna, jak zarządzanie kluczami i zaufanie do stojących za nią wystawców, a najmniejsze uprawnienia, segmentacja sieci i reagowanie na incydenty pozostają osobnym zadaniem. Razem jednak oba mechanizmy tworzą powtarzalną bazę, którą można stosować per tenant, z udokumentowanym procesem wyjątków dla tego, co jeszcze nie spełnia wymagań.

MSP, które muszą wykazać, że te mechanizmy wytrzymują audyt, mogą skorzystać z usług cyberbezpieczeństwa Altovar, obejmujących testy penetracyjne, ocenę podatności, reagowanie na incydenty oraz zgodność z NIS2/DORA/GDPR.

Co zrobić

• Podpisuj każdy obraz podczas builda i weryfikuj go ponownie przy admission lub wdrożeniu; nigdy nie ufaj podpisowi pochodzącemu wyłącznie z etapu builda.
• Najpierw przetestuj ścieżkę awarii: potwierdź, że niepodpisany lub zmanipulowany obraz jest rzeczywiście odrzucany, zanim zaufasz bramce w produkcji.
• Połącz Cosign ze skanerem podatności, takim jak Trivy czy Grype, bo ważny podpis nie zastępuje czystego skanu.
• Wynieś każdą daną uwierzytelniającą z manifestów i chartów Helm do SecretStore zarządzanego przez External Secrets Operator.
• Ogranicz każdy ExternalSecret do przestrzeni nazw i obciążenia, które go potrzebuje, i rotuj klucze lub dane uwierzytelniające według ustalonego harmonogramu.
• Udokumentuj proces wyjątków dla tego, co jeszcze nie spełnia wymagań, i sprawdź zmiany polityki najpierw na klastrze niebedącym produkcją, zanim trafą na całą flotę.

Źródła: GitHub — sigstore/cosign, dokumentacja Sigstore, External Secrets Operator na GitHub.