Zarządzanie Sekretami w Kubernetes 2026: External Secrets, Vault i Pytania Rekrutacyjne

Zarządzanie sekretami w Kubernetes pozostaje jednym z najważniejszych wyzwań bezpieczeństwa w orkiestracji kontenerów. Natywne Kubernetes Secrets przechowują dane wrażliwe jako wartości zakodowane w base64, co nie zapewnia szyfrowania w spoczynku i stwarza zagrożenia bezpieczeństwa, które rekruterzy często badają podczas procesów rekrutacyjnych na stanowiska DevOps.

Dlaczego Natywne Kubernetes Secrets Są Niewystarczające

Wbudowany zasób Secret przechowuje dane w etcd z kodowaniem base64. To kodowanie można odwrócić jednym poleceniem:

# decoding-secret.sh
# Decode any Kubernetes secret value instantly
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Base64 to nie szyfrowanie. Każdy z dostępem do klastra może odczytać wartości sekretów. Dokumentacja Kubernetes wyraźnie ostrzega, że Secrets "domyślnie nie są szyfrowane" i zaleca włączenie szyfrowania w spoczynku.

Trzy główne ograniczenia wpływają na wdrożenia produkcyjne:

1. Brak śladu audytu: Natywne Secrets nie logują kto, kiedy i do jakiej wartości uzyskał dostęp
2. Brak mechanizmu rotacji: Zmiana sekretu wymaga ręcznej interwencji i restartu podów
3. Niekompatybilność z GitOps: Przechowywanie zaszyfrowanych sekretów w Git nadal odsłania problem zarządzania kluczami szyfrowania

Architektura External Secrets Operator

External Secrets Operator (ESO) łączy Kubernetes z zewnętrznymi systemami zarządzania sekretami. Wydany jako projekt CNCF Sandbox w 2023 roku i osiągając wersję v0.10 w 2026, ESO obsługuje AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault oraz 15 innych backendów.

Architektura obejmuje trzy niestandardowe zasoby:

# secret-store.yaml
# ClusterSecretStore defines the connection to Vault
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "external-secrets"
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

Ten ClusterSecretStore konfiguruje ESO do uwierzytelniania z Vault przy użyciu tokenów konta usługi Kubernetes. Metoda uwierzytelniania kubernetes waliduje JWT konta usługi względem API TokenReview klastra.

# external-secret.yaml
# ExternalSecret fetches and syncs the actual secret data
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

ESO odpytuje Vault co godzinę (refreshInterval: 1h) i automatycznie aktualizuje Secret Kubernetes. Opcja creationPolicy: Owner zapewnia usunięcie Secreta przy usunięciu ExternalSecret.

Wzorce Integracji HashiCorp Vault

Vault dostarcza dynamiczne sekrety, automatyczną rotację i kompleksowe logowanie audytu. Metoda uwierzytelniania Kubernetes, udokumentowana w dokumentacji Vault Kubernetes Auth, umożliwia podom uwierzytelnianie bez dystrybucji długoterminowych poświadczeń.

Konfiguracja uwierzytelniania Vault wymaga trzech kroków:

# vault-k8s-auth.sh
# Enable Kubernetes auth method in Vault
vault auth enable kubernetes

# Configure Vault to validate tokens against the Kubernetes API
vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc:443" \
  kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

# Create a role that binds service accounts to policies
vault write auth/kubernetes/role/external-secrets \
  bound_service_account_names=external-secrets \
  bound_service_account_namespaces=external-secrets \
  policies=readonly-secrets \
  ttl=1h

Ta konfiguracja wiąże konto usługi external-secrets z polityką Vault. TTL ogranicza ważność tokenu, wymuszając ponowne uwierzytelnienie i zmniejszając promień wybuchu przy skompromitowanych tokenach.

Dla wdrożeń produkcyjnych polityka powinna przestrzegać zasady najmniejszych uprawnień:

# readonly-secrets.hcl
# Vault policy granting read-only access to specific paths
path "secret/data/production/*" {
  capabilities = ["read"]
}

path "secret/metadata/production/*" {
  capabilities = ["list"]
}

Ta polityka przyznaje dostęp tylko do odczytu ścieżki sekretów produkcyjnych. Zespoły zarządzające różnymi środowiskami otrzymują oddzielne polityki z odpowiednimi ograniczeniami ścieżek.

Rotacja Sekretów Bez Przestojów

Automatyczna rotacja zapobiega przedawnieniu sekretów jako wektorów ataku. ESO obsługuje stronę Kubernetes, ale aplikacja musi przeładować sekrety bez restartu.

Istnieją dwa podejścia do rotacji bez przestojów:

Sekrety montowane jako wolumeny z obserwacją plików:

# deployment-volume-secrets.yaml
# Mount secrets as files that update automatically
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
        - name: api
          image: api:v2.1.0
          volumeMounts:
            - name: secrets
              mountPath: /etc/secrets
              readOnly: true
      volumes:
        - name: secrets
          secret:
            secretName: db-secret

Kubernetes aktualizuje zamontowane pliki sekretów w okresie synchronizacji kubeleta (domyślnie 1 minuta). Aplikacja odczytuje poświadczenia z /etc/secrets/password przy każdym połączeniu z bazą danych, pobierając nowe wartości bez restartu.

Reloader dla sekretów zmiennych środowiskowych:

Aplikacje używające zmiennych środowiskowych wymagają restartu podów. Stakater Reloader automatyzuje ten proces:

# deployment-with-reloader.yaml
# Annotation triggers rolling restart when secret changes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  annotations:
    reloader.stakater.com/auto: "true"
spec:
  template:
    spec:
      containers:
        - name: api
          envFrom:
            - secretRef:
                name: db-secret

Reloader obserwuje aktualizacje Secretów i wykonuje stopniowe restarty, utrzymując dostępność podczas rotacji.

Pytania Rekrutacyjne o Kubernetes Secrets

Rozmowy kwalifikacyjne DevOps konsekwentnie testują zrozumienie zarządzania sekretami. Poniższe pytania pojawiają się na wszystkich poziomach zaawansowania:

P: Jakiego kodowania używają Kubernetes Secrets i dlaczego jest to niewystarczające dla bezpieczeństwa?

Secrets używają kodowania base64, które jest odwracalną transformacją, nie szyfrowaniem. Każdy użytkownik z uprawnieniami get na Secrets może zdekodować wartości. Bezpieczeństwo wymaga szyfrowania w spoczynku (włączenie szyfrowania etcd) i ograniczenia uprawnień RBAC. Dla głębszego zrozumienia koncepcji Kubernetes warto przejrzeć podstawy rozmów o Kubernetes.

P: Jak zapobiec pojawianiu się sekretów w repozytoriach Git przy GitOps?

External Secrets Operator przechowuje w Git tylko referencje do sekretów, nie same wartości. Manifest ExternalSecret zawiera ścieżkę do sekretu w Vault lub AWS Secrets Manager, podczas gdy rzeczywisty sekret nigdy nie dotyka repozytorium. Sealed Secrets od Bitnami oferuje alternatywne podejście wykorzystujące szyfrowanie asymetryczne.

P: Wyjaśnij różnicę między SecretStore a ClusterSecretStore.

SecretStore jest ograniczony do namespace: ExternalSecrets w tym samym namespace mogą się do niego odwoływać. ClusterSecretStore jest dostępny w całym klastrze: każdy namespace może się do niego odwoływać. ClusterSecretStore stosuje się gdy wiele zespołów współdzieli jedną instancję Vault, a SecretStore gdy każdy namespace ma izolowane backendy sekretów.

P: Pod nie może uzyskać dostępu do swoich sekretów po wdrożeniu. Jak przeprowadzić diagnostykę?

Należy zacząć od statusu ExternalSecret:

# troubleshoot-secrets.sh
# Check ExternalSecret sync status and conditions
kubectl get externalsecret database-credentials -o yaml

# Verify the Secret was created
kubectl get secret db-secret -o yaml

# Check ESO controller logs for auth errors
kubectl logs -n external-secrets deployment/external-secrets

Typowe awarie obejmują wygasłe tokeny Vault, nieprawidłowe ścieżki sekretów i błędy konfiguracji RBAC w ClusterSecretStore.

P: Jak obsłużyć rotację poświadczeń bazy danych w produkcji?

Silnik sekretów bazy danych Vault generuje dynamiczne, krótkoterminowe poświadczenia. ESO konfiguruje się z refreshInterval krótszym niż TTL poświadczeń. Dla statycznych poświadczeń wymagających rotacji używa się API rotacji Vault w połączeniu z Reloaderem do restartu podów po aktualizacjach. Aplikacja powinna obsługiwać błędy połączenia z gracją podczas okna rotacji.

AWS Secrets Manager z ESO

Integracja z AWS Secrets Manager wymaga IAM roles for service accounts (IRSA). Ten wzorzec całkowicie eliminuje statyczne poświadczenia:

# aws-secret-store.yaml
# ClusterSecretStore for AWS Secrets Manager with IRSA
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-secrets
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-west-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets

Adnotacja konta usługi łączy się z rolą IAM:

# service-account-irsa.yaml
# Service account with IAM role annotation
apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-secrets-sa
  namespace: external-secrets
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/external-secrets

AWS automatycznie rotuje sekrety utworzone przez Secrets Manager za pomocą funkcji Lambda. W połączeniu z interwałem odświeżania ESO, sekrety propagują się do Kubernetes w skonfigurowanym okresie odpytywania.

Synchronizacja Sekretów w Wielu Klastrach

Organizacje uruchamiające wiele klastrów potrzebują spójnej dystrybucji sekretów. Dwa wzorce adresują to wymaganie:

Hub-and-spoke z ClusterSecretStore:

Wszystkie klastry łączą się z centralną instancją Vault. Instalacja ESO każdego klastra odwołuje się do tych samych sekretów, a Vault obsługuje kontrolę dostępu przez polityki oparte na namespace.

Replikacja z Vault Enterprise:

Vault Enterprise obsługuje replikację wydajności między regionami. Każdy klaster łączy się z lokalną repliką Vault, redukując opóźnienia przy zachowaniu spójności. Dokumentacja replikacji Vault obejmuje tryby disaster recovery i replikacji wydajności.

Dla zespołów używających ArgoCD, artykuł o wzorcach wdrożeń GitOps omawia ApplicationSets wdrażające ExternalSecrets w wielu klastrach.

Wzmacnianie RBAC dla Dostępu do Sekretów

Domyślne role klastra przyznają nadmierny dostęp do sekretów. Wzmocnienie RBAC wymaga tworzenia minimalnych ról:

# restricted-role.yaml
# Role allowing secret access only in specific namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
    resourceNames: ["db-secret", "api-key"]

Pole resourceNames ogranicza dostęp do jawnie wymienionych sekretów. Bez tego pola rola przyznaje dostęp do wszystkich sekretów w namespace.

Logowanie audytu przechwytuje próby dostępu do sekretów:

# audit-policy.yaml
# Kubernetes audit policy for secret operations
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["get", "list", "watch"]

Ta polityka loguje pełne żądanie i odpowiedź dla operacji na sekretach, umożliwiając zespołom bezpieczeństwa wykrywanie nieautoryzowanych wzorców dostępu.

Lista Kontrolna Produkcyjna dla Kubernetes Secrets

• Włączenie szyfrowania etcd w spoczynku przy użyciu zasobu API EncryptionConfiguration
• Wdrożenie External Secrets Operator v0.10+ z ClusterSecretStore wskazującym na Vault lub dostawcę chmury
• Konfiguracja refreshInterval poniżej TTL poświadczeń dla aktualizacji sekretów przed wygaśnięciem
• Użycie IRSA (AWS), Workload Identity (GCP) lub uwierzytelniania Kubernetes (Vault) zamiast statycznych poświadczeń
• Ograniczenie RBAC z resourceNames do limitowania dostępu do konkretnych nazwanych sekretów
• Włączenie logowania audytu Kubernetes dla operacji na sekretach z poziomem RequestResponse
• Wdrożenie Reloadera dla aplikacji używających zmiennych środowiskowych do obsługi aktualizacji sekretów
• Testowanie rotacji sekretów w środowisku staging przed wdrożeniem produkcyjnym
• Dokumentacja procedur odzyskiwania na wypadek awarii backendu sekretów wpływającej na planowanie podów