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

> External Secrets Operator ve HashiCorp Vault ile Kubernetes secrets yönetiminde uzmanlaşma rehberi. Güvenli kalıplar, en iyi uygulamalar ve DevOps mülakat soruları.

- Published: 2026-09-02
- Updated: 2026-09-02
- Author: Anthony Fillion-Maillet
- Tags: kubernetes, secrets, vault, external-secrets, security, devops
- Reading time: 12 min

---

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.

> **Mülakat İçin Hızlı Cevap**
>
> Kubernetes secrets güvenliği hakkında sorulduğunda: yerel Secrets base64 kodludur, şifreli değildir. Üretim ortamları HashiCorp Vault veya AWS Secrets Manager gibi harici secret yöneticileri gerektirir ve External Secrets Operator (ESO) aracılığıyla senkronize edilir. Bu ayrım, secretlerin asla Git depolarında bulunmamasını garanti eder.

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

```bash
# 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](https://kubernetes.io/docs/concepts/configuration/secret/) 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:

```yaml
# 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.

```yaml
# 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](https://developer.hashicorp.com/vault/docs/auth/kubernetes) 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:

```bash
# 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:

```hcl
# 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:**

```yaml
# 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](https://github.com/stakater/Reloader) bu işlemi otomatikleştirir:

```yaml
# 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](/technologies/devops/interview-questions/kubernetes-basics) 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:

```bash
# 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:

```yaml
# 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:

```yaml
# 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](https://developer.hashicorp.com/vault/docs/enterprise/replication), olağanüstü durum kurtarma ve performans replikasyon modlarını kapsar.

ArgoCD kullanan ekipler için [GitOps dağıtım kalıpları](/blog/devops/argocd-gitops-kubernetes-continuous-deployment-interview-questions) 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:

```yaml
# 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:

```yaml
# 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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/tr/blog/devops/kubernetes-secrets-management-2026-external-secrets-vault-interview