Najlepsze narzędzia do zarządzania tajemnicami Kubernetes w 2026 r.: Vault, ESO, zapieczętowane tajemnice i nie tylko

Każdy klaster Kubernetes jest dostarczany z wbudowanym obiektem „Secret”. Wygląda na bezpieczeństwo. To poczucie bezpieczeństwa. To nie jest bezpieczeństwo.

Sekret Kubernetes to domyślnie ciąg znaków zakodowany w base64 przechowywany w pliku etcd — czytelny dla każdego, kto ma dostęp do klastra i łatwy do zdekodowania za pomocą jednowierszowego: echo "c2VjcmV0" | podstawa64 -d. O ile jawnie nie włączono szyfrowania w stanie spoczynku (a większość zespołów tego nie zrobiła), hasła do bazy danych, tokeny API i klucze prywatne TLS pozostają niezaszyfrowane w magazynie danych platformy sterującej klastra. Prześlij manifest Kubernetes zawierający „Sekret” do Git, a dane uwierzytelniające pozostaną na zawsze w historii Twojego repozytorium.

Jest to problem, który ma rozwiązać nowa generacja narzędzi do zarządzania tajemnicami, a w 2026 r. ekosystem znacznie się rozwinie. W tym przewodniku omówiono sześć najważniejszych narzędzi do zarządzania sekretami w środowiskach Kubernetes: co robią, czego nie robią i które z nich odpowiada poziomowi dojrzałości Twojego zespołu.

Powiązana lektura: Jeśli obawiasz się, że tajemnice wyciekają przez Twój potok CI/CD, zapoznaj się z naszym omówieniem najlepszych narzędzi potoku CI/CD. Aby uzyskać szerszy obraz bezpieczeństwa kontenera, zapoznaj się z naszym przewodnikiem po narzędziach do skanowania podatności na ataki.

Dlaczego domyślne klucze tajne Kubernetes są niewystarczające

Zanim zagłębisz się w narzędzia, warto dokładnie określić, czego brakuje Sekretom Kubernetes — ponieważ zrozumienie luki pozwala wybrać właściwe rozwiązanie.

Domyślnie brak szyfrowania w stanie spoczynku. etcd przechowuje tajemnice Kubernetes w formacie base64, a nie zaszyfrowanym. Włączenie szyfrowania w stanie spoczynku to krok konfiguracji na poziomie klastra, który zarządzani dostawcy Kubernetes (EKS, GKE, AKE) obsługują inaczej i wiele samodzielnie zarządzanych klastrów całkowicie go pomija.

Brak rotacji kluczy tajnych. Nie ma wbudowanego mechanizmu, dzięki któremu klucz Kubernetes Secret będzie wiedział, że jego dane uwierzytelniające uległy zmianie. Zmieniasz hasło do bazy danych zewnętrznie, a Twoje kapsuły nadal korzystają ze starego, dopóki ręcznie nie zaktualizujesz klucza tajnego i nie uruchomisz ponownie odpowiednich kapsuł.

Brak dziennika audytu dla tajnego dostępu. Standardowe rejestrowanie dziennika audytu Kubernetes rejestruje modyfikacje tajnych obiektów, ale większość konfiguracji nie rejestruje poszczególnych odczytów — co oznacza, że ​​nie można odpowiedzieć „która usługa uzyskała dostęp do tego tokena i kiedy?”

Git jest z założenia wrogi. Standardowa rada brzmi: „nigdy nie przekazuj Gitowi tajemnic”. Jednak w świecie GitOps, w którym celem jest wszystko jako kod, utrzymanie tego wyjątku jest bolesne.

RBAC jako tępe narzędzie. Kubernetes RBAC umożliwia udzielanie lub odmawianie dostępu do tajnych obiektów na poziomie przestrzeni nazw. Nie może wyrazić „Usługa A może odczytać sekret X, ale nie Y” ani „ten sekret wygasa za 24 godziny”.

Żaden z tych powodów nie jest powodem do porzucenia Kubernetesa — są to powody, dla których warto dodatkowo skorzystać z dedykowanych narzędzi do zarządzania sekretami.

TL;DR — Porównanie funkcji

⚠️ = wymaga dodatkowych komponentów

1. Skarbiec HashiCorp — złoty standard tajemnic przedsiębiorstwa

HashiCorp Vault to punkt odniesienia, według którego oceniane jest każde inne narzędzie do zarządzania tajemnicami. Był testowany w bojach w środowiskach korporacyjnych przez prawie dekadę, a jego zestaw funkcji odzwierciedla tę głębię.

Podstawową funkcją Vault są dynamiczne sekrety — dane uwierzytelniające generowane na żądanie i automatycznie wygasające. Zamiast przechowywać statyczne hasło PostgreSQL, Vault generuje unikalną parę nazwa użytkownika/hasło dla każdej żądającej usługi, ważną przez konfigurowalny okres dzierżawy (np. jedną godzinę). Po wygaśnięciu umowy najmu uprawnienia zostają cofnięte. Eliminuje to całe klasy rozprzestrzeniania się poświadczeń i znacznie ułatwia powstrzymywanie naruszeń.

W przypadku Kubernetes ścieżkami integracji są Vault Agent Injector lub Vault Secrets Operator. Iniektor działa jako mutujący webhook, który automatycznie przenosi agenta Vault do Twoich podów, który uwierzytelnia się w Vault przy użyciu konta usługi Kubernetes poda i zapisuje klucze tajne we woluminie współdzielonej pamięci. Operator sekretów Vault (VSO), nowsze podejście, synchronizuje sekrety Vault z natywnymi obiektami Kubernetes Secret — bardziej znanymi operatorom, kosztem sekretów krótko istniejących w etcd.

Tajne silniki Vault obejmują imponujący zakres:

• Dane uwierzytelniające bazy danych (PostgreSQL, MySQL, MongoDB i inne)
• AWS, GCP, dynamiczne poświadczenia Azure
• Generowanie certyfikatów PKI i TLS
• Podpisanie certyfikatu SSH
• Tokeny konta usługi Kubernetes

Co Vault radzi sobie dobrze: Dynamiczne dane uwierzytelniające, szczegółowe zasady dostępu, kompleksowy dziennik audytu i dojrzały ekosystem wtyczek. Jeśli potrzebujesz zarządzania sekretami na poziomie zapewniającym zgodność z pełnym zapisem tego, kto, do czego, kiedy uzyskał dostęp, Vault jest często jedyną rozsądną opcją.

Na co należy zwrócić uwagę: Vault ma złożoność operacyjną. Uruchomienie go w trybie wysokiej dostępności wymaga zwrócenia szczególnej uwagi na zaplecze pamięci masowej (obecnie zalecanym wyborem jest Raft), procedury rozpakowywania i ścieżki aktualizacji. Krzywa uczenia się jest prawdziwa. Budżet czasu poświęconego na inżynierię platformy.

Ceny: Wersja open source jest bezpłatna i zaspokaja większość potrzeb. HashiCorp Cloud Platform (HCP) Vault to oferta zarządzana z cenami opartymi na godzinach pracy klastra i tajnych operacjach. Zmiana licencji BSL z 2023 r. doprowadziła do powstania forka OpenTofu dla Terraform, ale odpowiednik forka Vault (OpenBao) wciąż jest w fazie rozwoju.

📚 Zalecana lektura: Hakowanie Kubernetes autorstwa Andrew Martina i Michaela Hausenblasa — doskonałe omówienie powierzchni ataku Kubernetes, w tym scenariuszy tajnej eksfiltracji.

2. Operator tajemnic zewnętrznych (ESO) — warstwa integracji natywnej K8s

External Secrets Operator przyjmuje zasadniczo odmienne podejście do architektury: zamiast być samym magazynem sekretów, jest pomostem między Kubernetesem a dowolnym sklepem zewnętrznym, który już masz. ESO synchronizuje sekrety z AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler i rosnącej listy innych backendów z natywnymi obiektami Kubernetes Secret.

Podstawową abstrakcją jest niestandardowy zasób ExternalSecret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

ESO obserwuje ten zasób, pobiera sekret z Menedżera sekretów AWS (lub gdziekolwiek indziej) i tworzy standardowy sekret Kubernetes. Twoja aplikacja odczytuje „db-creds” tak jak każdy inny sekret Kubernetes — nie są wymagane żadne zmiany w kodzie. Po zaznaczeniu parametru „refreshInterval” ESO ponownie pobiera i automatycznie aktualizuje klucz tajny.

Dlaczego ESO jest tak popularne w 2026 roku: Dobrze komponuje się z istniejącymi inwestycjami. Twoja organizacja ma już Menedżera sekretów AWS (lub Menedżera sekretów Vault lub GCP) — ESO po prostu udostępnia te sekrety w Kubernetesie bez zmiany kodu aplikacji lub istniejących przepływów pracy związanych z rotacją sekretów.

ESO czy operator Vault Secrets? Jeśli korzystasz z Vault, VSO zapewnia ściślejszą integrację specyficzną dla Vault (dynamiczne sekrety Vault, Vault PKI). Jeśli korzystasz z natywnego tajnego magazynu dostawcy usług w chmurze, ESO jest czystszym wyborem. Wiele zespołów korzysta z obu rozwiązań — ESO dla statycznych sekretów przechowywanych w chmurze, VSO dla dynamicznych danych uwierzytelniających zarządzanych przez Vault.

Ceny: ESO jest darmowym oprogramowaniem typu open source (Apache 2.0), utrzymywanym przez projekt sandbox CNCF przy silnym wsparciu społeczności.

3. Zapieczętowane sekrety — zaszyfrowane sekrety przyjazne dla GitOps

Sealed Secrets autorstwa Bitnami rozwiązuje konkretny problem: jak przechowywać manifesty Kubernetes Secret w Git bez przechowywania rzeczywistego zwykłego tekstu? Odpowiedzią jest szyfrowanie asymetryczne.

Kontroler Sealed Secrets działa w klastrze i przechowuje klucz prywatny. Interfejs CLI „kubeseal” szyfruje manifest Kubernetes Secret kluczem publicznym klastra, tworząc CRD „SealedSecret”. Ten zaszyfrowany manifest można bezpiecznie przekazać do Git — tylko klucz prywatny klastra może go odszyfrować i można go odszyfrować tylko w tym konkretnym klastrze (domyślnie tekst zaszyfrowany jest powiązany z przestrzenią nazw + nazwą).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

Kiedy zastosujesz SealedSecret do klastra, kontroler odszyfruje go i utworzy odpowiedni obiekt Secret.

Co Sealed Secrets sprawdza się dobrze: Przepływy pracy GitOps. Jeśli używasz Argo CD lub Flux i chcesz, aby wszystkie zasoby klastra (w tym sekrety) były deklaratywnie przechowywane w Git, Sealed Secrets idealnie pasuje do tego modelu. Nie wymaga żadnych zewnętrznych zależności poza kontrolerem w klastrze.

Czego nie robi: Rotacja, poświadczenia dynamiczne lub rejestrowanie inspekcji wykraczające poza standardowe zdarzenia Kubernetes. Sealed Secrets to rozwiązanie do przechowywania danych Git, a nie platforma do pełnego zarządzania sekretami. Jeśli Twoje hasło ulegnie zmianie, ponownie szyfrujesz i zatwierdzasz ponownie.

Kopia zapasowa klucza prywatnego jest krytyczna. Jeśli zgubisz klucz prywatny kontrolera, utracisz możliwość odszyfrowania zapieczętowanych sekretów. Utwórz kopię zapasową tajnego klucza „zapieczętowanych tajemnic” w osobnym, bezpiecznym miejscu.

Ceny: Całkowicie darmowe i otwarte oprogramowanie (Apache 2.0).

4. Menedżer tajemnic AWS z Kubernetesem

Jeśli Twoje zadania działają głównie na EKS (lub intensywnie łączą się z usługami AWS), naturalnym rozwiązaniem będzie AWS Secrets Manager w połączeniu ze Secrets Store CSI Driver lub Zewnętrzny operator Secrets. Przechowujesz tajemnice w zarządzanym, zaszyfrowanym i rejestrowanym w dzienniku audycie magazynie AWS i w razie potrzeby ściągasz je do Kubernetes.

Sterownik CSI Secrets Store (SSCSID) to podejście utrzymywane przez CNCF: wpisy tajne są montowane bezpośrednio w zasobnikach jako pliki za pośrednictwem woluminu CSI i nigdy nie są zapisywane w etcd jako obiekty Kubernetes Secret. Jest to ścieżka o najwyższym poziomie bezpieczeństwa — wpisy tajne znajdują się w pamięci modułu, ale nie w magazynie Kubernetes Secret.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

Natywne możliwości AWS Secrets Manager obejmują automatyczną rotację obsługiwanych usług (RDS, Redshift, DocumentDB i poprzez Lambda do niestandardowej rotacji), dostęp między kontami i głęboką integrację z CloudTrail na potrzeby ścieżek audytu zgodności.

Uwzględnienie kosztów: AWS Secrets Manager pobiera opłaty za sekret miesięcznie i za wywołanie API. W przypadku dużych flot z wieloma małymi tajemnicami koszty mogą się sumować. Zapoznaj się z naszym przewodnikiem optymalizacji kosztów chmury, aby poznać strategie zarządzania wydatkami na AWS związanymi z tajemnicą.

Najlepsze dla: zespołów natywnych dla EKS, które już zainwestowały w ekosystem AWS, a chcą ścisłej integracji IAM i natywnej rotacji poświadczeń RDS.

5. Doppler — platforma tajemnic SaaS dla programistów

Doppler stosuje podejście oparte na SaaS, które przedkłada doświadczenie programisty nad złożoność operacyjną. Definiujesz sekrety w interfejsie użytkownika Dopplera (lub poprzez CLI/API), organizujesz je według środowiska (programowanie, przemieszczanie, produkcja), a operator Doppler Kubernetes automatycznie synchronizuje je z sekretami Kubernetes.

Operator odpytuje Dopplera pod kątem zmian i aktualizuje odpowiedni klucz Kubernetes Secret, opcjonalnie wyzwalając ponowne uruchomienie poda w przypadku zmiany kluczy tajnych. Konfiguracja to pojedyncza instalacja wykresu Helm:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

Tam, gdzie Doppler świeci: Rozwój lokalny i integracja CI/CD z Kubernetesem. Doppler CLI całkowicie zastępuje pliki środowiska („uruchom dopplera – twoje-polecenie”), udostępniając te same sekrety w środowiskach lokalnych, CI i produkcyjnych. W przypadku potoków CI/CD natywne integracje Dopplera z GitHub Actions, CircleCI i innymi eliminują potrzebę kopiowania sekretów do zmiennych środowiskowych potoku.

Czego nie obejmuje Doppler: Dane uwierzytelniające dynamicznej bazy danych. Doppler to statyczny magazyn sekretów z historią wersji i rejestrowaniem audytów — nie jest to silnik generujący sekrety taki jak Vault.

Cennik: Doppler oferuje bezpłatny poziom dla małych zespołów. Płatne plany obejmują logowanie jednokrotne, żądania dostępu i funkcje zgodności. Sprawdź stronę z cenami Dopplera, aby sprawdzić aktualne poziomy (zmiany cen; sprawdź przed ustaleniem budżetu).

6. Infisical — alternatywa dla repozytorium typu open source

Infisical to najsilniejszy konkurent open source dla duopolu Vault/Doppler. Zapewnia internetowy interfejs użytkownika, interfejs CLI, zestawy SDK i operatora Kubernetes — do wdrożenia na własnym serwerze lub do wykorzystania jako usługa w chmurze.

Firma Infiical dodała obsługę dynamicznych sekretów w 2024 r., mając na celu generowanie danych uwierzytelniających bazy danych na wzór silnika sekretów bazy danych Vault. Operator Infisical Kubernetes synchronizuje CRD „InfisicalSecret” z natywnymi sekretami Kubernetes z konfigurowalnymi interwałami odświeżania.

Dla zespołów, które chcą UX na poziomie SaaS (panel WWW, przepływy pracy żądań dostępu, dzienniki audytu), ale nie mogą korzystać z zewnętrznej SaaS ze względu na wymagania zgodności, samodzielny hosting Infisical jest atrakcyjny. Jest znacznie łatwiejszy w obsłudze niż Vault i zapewnia bardziej przyjazne dla programistów środowisko wdrażania.

Ceny: Rdzeń open source jest bezpłatny. Wersja hostowana w chmurze ma warstwę bezpłatną i płatne plany dotyczące zaawansowanych funkcji. Licencja korporacyjna na własnym serwerze jest dostępna dla środowisk wymagających dużej zgodności.

📚 Aby głębiej poznać architekturę bezpieczeństwa Kubernetes: Bezpieczeństwo i obserwowalność Kubernetes na Amazon obejmuje tajemnice, RBAC, zasady sieciowe i zabezpieczenia środowiska wykonawczego w jednej spójnej strukturze.

Wskazówki dotyczące wdrożenia

Zacznij od szyfrowania w stanie spoczynku. Przed dodaniem jakichkolwiek dodatkowych narzędzi włącz szyfrowanie Kubernetes itp. w stanie spoczynku. W przypadku klastrów zarządzanych jest to często pojedyncze pole wyboru. W przypadku klastrów samozarządzających postępuj zgodnie z oficjalnym przewodnikiem. To natychmiast podnosi podstawowy poziom bezpieczeństwa.

Zastosuj RBAC o najniższych uprawnieniach dla obiektów tajnych. Sprawdź, które konta usług mają uprawnienia „pobierania”, „listowania” lub „obserwowania” obiektów tajnych. Domyślne konta usług na wielu wykresach Helm mają nadmiar zasobów. Dokręć RBAC przed przejściem do magazynu zewnętrznego.

Zaplanuj konwencje nazewnictwa sekretów wcześniej. Sekrety szybko się mnożą. Spójna hierarchia ({env}/{service}/{credential-type}) znacznie upraszcza automatyzację, zasady RBAC i przepływy pracy w zakresie rotacji we wszystkich narzędziach.

Nie pomijaj tajnych testów rotacji. Niezależnie od tego, jakie narzędzie wybierzesz, przeprowadź ćwiczenie rotacyjne, zanim będzie potrzebne. Sprawdź, czy aplikacja pobiera nowe dane uwierzytelniające bez przestojów. Dynamiczne sekrety w Vault lub ESO sprawiają, że jest to znacznie łatwiejsze niż ręcznie aktualizowane statyczne sekrety.

Monitoruj rozprzestrzenianie się sekretów. Wraz z rozwojem Twojej platformy gromadzą się sekrety. Zintegruj raportowanie dotyczące zarządzania sekretami z pulpitami inżynieryjnymi platformy. Zobacz nasz przewodnik po narzędziach monitorowania Kubernetes, aby zapoznać się z narzędziami umożliwiającymi obserwację, które mogą śledzić wzorce tajnego dostępu.

Które narzędzie dla jakiego zespołu?

Mały zespół, natywnie chmurowy (AWS/GCP/Azure): Zacznij od zewnętrznego operatora sekretów łączącego się z natywnym magazynem sekretów Twojego dostawcy chmury. Minimalne koszty operacyjne, solidna integracja audytu, bezpłatnie.

Pierwszy zespół GitOps (Argo CD / Flux): Zapieczętowane sekrety dla konfiguracji przechowywanej w GitOps, w połączeniu z ESO w celu uzyskania poufnych danych uwierzytelniających środowiska wykonawczego, które nie powinny być nawet szyfrowane w Git.

Przedsiębiorstwo spełniające wymogi zgodności (SOC 2, PCI, HIPAA): HashiCorp Vault — albo samodzielnie hostowany klaster Raft, albo zarządzany przez HCP Vault. Dziennik audytu, dynamiczne dane uwierzytelniające i szczegółowy silnik zasad są trudne do odtworzenia gdzie indziej.

Środowisko mieszane zorientowane na doświadczenie programisty (K8s + lokalne + CI/CD): Doppler dla ujednoliconego DX w różnych środowiskach lub własny host Infisical, jeśli miejsce przechowywania danych ma znaczenie.

Duży zespół ds. platformy zarządzający środowiskami wieloklastrowymi: Zewnętrzny operator sekretów jako warstwa abstrakcji po stronie K8s, wspierany przez Vault lub sklep natywny w chmurze. Centralizacja źródła prawdy w jednym magazynie przy jednoczesnym wykorzystaniu ESO jako uniwersalnego adaptera w klastrach to dobrze sprawdzony wzorzec w roku 2026.

Powiązane: Informacje na temat zagrożeń bezpieczeństwa wprowadzanych przez narzędzia do kodowania AI do manifestów Kubernetes i potoków CI/CD można znaleźć w naszym przewodniku na temat zagrożeń bezpieczeństwa kodowania vibe w 2026 r..

Często zadawane pytania