2026'da Kubernetes Secrets Yönetimi: External Secrets, Vault ve Mülakat Soruları

Kubernetes secrets yönetimi, konteyner orkestrasyon alanındaki en kritik güvenlik zorluklarından biri olmaya devam etmektedir. Yerel Kubernetes Secrets, hassas verileri base64 kodlu değerler olarak saklar ve varsayılan olarak durağan şifreleme sağlamaz. Bu durum, DevOps işe alım süreçlerinde mülakatçıların sıklıkla araştırdığı güvenlik riskleri oluşturur.

Yerel Kubernetes Secrets Neden Yetersiz Kalır

Yerleşik Secret kaynağı, verileri etcd'de base64 kodlamasıyla saklar. Bu kodlama tek bir komutla tersine çevrilebilir:

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

Base64 şifreleme değildir. Küme erişimi olan herkes secret değerlerini okuyabilir. Kubernetes belgeleri Secrets'ın "varsayılan olarak şifreli olmadığını" açıkça belirtir ve durağan şifrelemenin etkinleştirilmesini önerir.

Üretim dağıtımlarını etkileyen üç temel sınırlama bulunur:

1. Denetim izi yok: Yerel Secrets, kimin hangi değere ne zaman eriştiğini günlüğe kaydetmez
2. Rotasyon mekanizması yok: Bir secreti değiştirmek manuel müdahale ve pod yeniden başlatması gerektirir
3. GitOps uyumsuzluğu: Şifrelenmiş secretleri Git'te saklamak hala şifreleme anahtarı yönetimi sorununu açığa çıkarır

External Secrets Operator Mimarisi

External Secrets Operator (ESO), Kubernetes'i harici secret yönetim sistemleriyle köprüler. 2023'te CNCF Sandbox projesi olarak yayınlanan ve 2026'da v0.10'a ulaşan ESO; AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault ve 15 diğer backend'i destekler.

Mimari üç özel kaynak içerir:

# 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"

Bu ClusterSecretStore, ESO'yu Kubernetes service account tokenları kullanarak Vault ile kimlik doğrulaması yapacak şekilde yapılandırır. kubernetes kimlik doğrulama yöntemi, service account JWT'sini kümenin TokenReview API'sine karşı doğrular.

# 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 her saat Vault'u sorgular (refreshInterval: 1h) ve Kubernetes Secret'ı otomatik olarak günceller. creationPolicy: Owner ayarı, ExternalSecret kaldırıldığında Secret'ın silinmesini sağlar.

HashiCorp Vault Entegrasyon Kalıpları

Vault; dinamik secretler, otomatik rotasyon ve kapsamlı denetim günlüğü sağlar. Vault Kubernetes Auth belgelerinde belgelenen Kubernetes kimlik doğrulama yöntemi, pod'ların uzun ömürlü kimlik bilgileri dağıtmadan kimlik doğrulaması yapmasını sağlar.

Vault kimlik doğrulamasını kurmak üç adım gerektirir:

# 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

Bu yapılandırma, external-secrets service account'unu bir Vault politikasına bağlar. TTL, token geçerliliğini sınırlandırır, yeniden kimlik doğrulamasını zorlar ve tehlikeye atılmış tokenların etki yarıçapını azaltır.

Üretim dağıtımları için politika en az ayrıcalık ilkelerini takip etmelidir:

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

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

Bu politika yalnızca üretim secretleri yoluna salt okuma erişimi verir. Farklı ortamları yöneten ekipler, karşılık gelen yol kısıtlamalarıyla ayrı politikalar alır.

Kesintisiz Secret Rotasyonu

Otomatik rotasyon, secretlerin eski saldırı vektörleri haline gelmesini önler. ESO Kubernetes tarafını yönetir, ancak uygulama yeniden başlatmadan secretleri yeniden yüklemelidir.

Kesintisiz rotasyon için iki yaklaşım mevcuttur:

Dosya izleme ile volume olarak bağlanan secretler:

# 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, bağlanan secret dosyalarını kubelet senkronizasyon periyodunda (varsayılan 1 dakika) günceller. Uygulama, her veritabanı bağlantısında /etc/secrets/password dosyasından kimlik bilgilerini okur ve yeniden başlatma olmadan yeni değerleri alır.

Ortam değişkeni secretleri için Reloader:

Ortam değişkenleri kullanan uygulamalar pod yeniden başlatması gerektirir. Stakater Reloader bu işlemi otomatikleştirir:

# 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, Secret güncellemelerini izler ve kademeli yeniden başlatmalar gerçekleştirir, rotasyon boyunca kullanılabilirliği korur.

Kubernetes Secrets Mülakat Soruları

DevOps mülakatları tutarlı olarak secret yönetimi anlayışını test eder. Bu sorular junior'dan senior seviyeye kadar tüm seviyelerde karşımıza çıkar:

S: Kubernetes Secrets hangi kodlamayı kullanır ve güvenlik için neden yetersizdir?

Secrets, tersine çevrilebilir bir dönüşüm olan base64 kodlaması kullanır, şifreleme değil. Secrets üzerinde get izni olan herhangi bir kullanıcı değerleri çözebilir. Güvenlik, durağan şifreleme (etcd şifrelemeyi etkinleştirme) ve RBAC izinlerini kısıtlama gerektirir. Daha derin Kubernetes kavramları için Kubernetes mülakat temelleri incelenebilir.

S: GitOps kullanırken secretlerin Git depolarında görünmesini nasıl önlersiniz?

External Secrets Operator, Git'te değerleri değil yalnızca secretlere referansları saklar. ExternalSecret manifesti, Vault veya AWS Secrets Manager'daki secretin yolunu içerirken, gerçek secret asla depoya dokunmaz. Bitnami'nin Sealed Secrets'ı, asimetrik şifreleme kullanan alternatif bir yaklaşım sunar.

S: SecretStore ve ClusterSecretStore arasındaki farkı açıklayın.

SecretStore namespace kapsamlıdır: aynı namespace'teki ExternalSecrets ona referans verebilir. ClusterSecretStore küme genelindedir: herhangi bir namespace ona referans verebilir. Birden fazla ekip tek bir Vault örneğini paylaştığında ClusterSecretStore, her namespace izole secret backend'lerine sahip olduğunda SecretStore kullanılır.

S: Bir pod dağıtımdan sonra secretlerine erişemiyorsa, nasıl sorun giderirsiniz?

ExternalSecret durumu ile başlanmalıdır:

# 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

Yaygın hatalar arasında süresi dolmuş Vault tokenları, yanlış secret yolları ve ClusterSecretStore'daki RBAC yapılandırma hataları bulunur.

S: Üretimde veritabanı kimlik bilgileri rotasyonunu nasıl yönetirsiniz?

Vault'un veritabanı secrets motoru dinamik, kısa ömürlü kimlik bilgileri oluşturur. ESO, kimlik bilgisi TTL'sinden daha kısa bir refreshInterval ile yapılandırılır. Rotasyon gerektiren statik kimlik bilgileri için, güncellemelerden sonra pod'ları yeniden başlatmak üzere Reloader ile birlikte Vault'un rotasyon API'si kullanılır. Uygulama, rotasyon penceresi sırasında bağlantı hatalarını zarif bir şekilde yönetmelidir.

ESO ile AWS Secrets Manager

AWS Secrets Manager entegrasyonu, service accountlar için IAM rolleri (IRSA) gerektirir. Bu kalıp statik kimlik bilgilerini tamamen ortadan kaldırır:

# 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

Service account annotation'ı IAM rolüne bağlanır:

# 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, Secrets Manager aracılığıyla oluşturulan secretleri bir Lambda fonksiyonuyla otomatik olarak döndürür. ESO'nun yenileme aralığıyla birleştirildiğinde, secretler yapılandırılmış sorgulama periyodunda Kubernetes'e yayılır.

Çok Kümeli Secret Senkronizasyonu

Birden fazla küme çalıştıran kuruluşlar tutarlı secret dağıtımına ihtiyaç duyar. İki kalıp bu gereksinimi karşılar:

ClusterSecretStore ile Hub-and-spoke:

Tüm kümeler merkezi bir Vault örneğine bağlanır. Her kümenin ESO kurulumu aynı secretlere referans verir ve Vault, namespace tabanlı politikalar aracılığıyla erişim kontrolünü yönetir.

Vault Enterprise ile replikasyon:

Vault Enterprise, bölgeler arası performans replikasyonunu destekler. Her küme yerel Vault replikasına bağlanır, tutarlılığı korurken gecikmeyi azaltır. Vault replikasyon belgeleri, olağanüstü durum kurtarma ve performans replikasyon modlarını kapsar.

ArgoCD kullanan ekipler için GitOps dağıtım kalıpları makalesi, birden fazla kümede ExternalSecrets dağıtan ApplicationSets'i kapsar.

Secret Erişimi İçin RBAC Güçlendirme

Varsayılan küme rolleri aşırı secret erişimi verir. RBAC güçlendirme, minimal roller oluşturmayı gerektirir:

# 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"]

resourceNames alanı erişimi açıkça listelenen secretlerle kısıtlar. Bu alan olmadan, rol namespace'teki tüm secretlere erişim verir.

Denetim günlüğü, secret erişim girişimlerini yakalar:

# 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"]

Bu politika, secret işlemleri için tam istek ve yanıtı günlüğe kaydeder, güvenlik ekiplerinin yetkisiz erişim kalıplarını tespit etmesini sağlar.

Kubernetes Secrets İçin Üretim Kontrol Listesi

• EncryptionConfiguration API kaynağı kullanarak durağan etcd şifrelemeyi etkinleştirme
• Vault veya bulut sağlayıcısına işaret eden ClusterSecretStore ile External Secrets Operator v0.10+ dağıtma
• Secretlerin sona ermeden önce güncellenmesi için refreshInterval'i kimlik bilgisi TTL'sinin altında yapılandırma
• Statik kimlik bilgileri yerine IRSA (AWS), Workload Identity (GCP) veya Kubernetes auth (Vault) kullanma
• Secret erişimini belirli adlandırılmış secretlerle sınırlamak için resourceNames ile RBAC kısıtlama
• RequestResponse seviyesiyle secret işlemleri için Kubernetes denetim günlüğünü etkinleştirme
• Secret güncellemelerini yönetmek için ortam değişkenleri kullanan uygulamalar için Reloader dağıtma
• Üretim dağıtımından önce staging'de secret rotasyonunu test etme
• Pod planlamasını etkileyen secret backend kesintileri için kurtarma prosedürlerini belgeleme