SOPS i Sealed Secrets: trzymaj dane plaintext z dala od Gita w Kubernetes dla MSP

Dwa ugruntowane projekty open source, getsops/sops i bitnami/sealed-secrets, wypełniają częstą lukę w potokach GitOps: utrzymywanie wartości sekretów poza plaintextem w kontroli wersji, a jednocześnie umożliwianie właściwemu klastrowi automatycznego ich odszyfrowania.

Co robi każde z narzędzi

SOPS, z około 22 000 gwiazdek na GitHubie, szyfruje pliki konfiguracyjne i pliki sekretów przed ich commitowaniem, korzystając z backendów age, PGP lub w stylu chmurowego KMS. Dostęp do odszyfrowania kontroluje ten, kto posiada klucz, niezależnie od tego, kto ma dostęp do odczytu repozytorium. Sealed Secrets, utrzymywane przy około 9 000 gwiazdek, przyjmuje podejście związane z klastrem: narzędzie po stronie klienta szyfruje Secret Kubernetes kluczem publicznym docelowego klastra, tworząc zasób niestandardowy SealedSecret, który można bezpiecznie przechowywać w Git. Tylko kontroler działający w klastrze, posiadający pasujący klucz prywatny, może przekształcić go z powrotem w użyteczny Secret.

Gdzie pasują i czego nie zastępują

Używane razem, oba narzędzia pokrywają uzupełniające się połowy tego samego problemu: SOPS chroni dowolne pliki, zanim trafią do Gita, a Sealed Secrets chroni konkretny przypadek Secretu Kubernetes powiązanego z jednym klastrem. Żadne z nich nie zastępuje rotacji poświadczeń, kontroli dostępu opartej na rolach ani izolacji sieciowej — SealedSecret można bezpiecznie commitować, ale nadal jest to szyfrogram dla konkretnej granicy odszyfrowania, a nie substytut dostępu z zasadą najmniejszych uprawnień. Praktyczna higiena ma tu znaczenie: ogranicz, kto może uruchomić operację odszyfrowania w CI, nigdy nie wypisuj odszyfrowanych wartości do logów budowania i monitoruj kondycję kontrolera Sealed Secrets oraz harmonogram rotacji jego klucza szyfrującego. Waliduj każdą zmianę w którymkolwiek potoku w klastrze nieprodukcyjnym, zanim wdrożysz ją produkcyjnie.

Nawyk wart przyjęcia

Wartością każdego z tych narzędzi jest kontrola, którą wymusza — build, który kończy się niepowodzeniem, gdy do commita wkradnie się plaintextowy sekret, albo granica odszyfrowania, którą może przekroczyć tylko jeden klaster — a nie nazwa narzędzia na slajdzie. Przypinaj wersje, utrzymuj zaszyfrowane pliki w stanie umożliwiającym przegląd w pull requestach i traktuj rotację kluczy jako zaplanowane zadanie, a nie reakcję na incydent.

Źródła: getsops/sops, bitnami/sealed-secrets.