Manajemen Secrets Kubernetes 2026: External Secrets, Vault, dan Pertanyaan Interview

Manajemen secrets Kubernetes tetap menjadi salah satu tantangan keamanan paling kritis dalam orkestrasi container. Native Kubernetes Secrets menyimpan data sensitif sebagai nilai base64-encoded, yang tidak menyediakan enkripsi secara default dan menciptakan risiko keamanan yang sering ditanyakan dalam proses wawancara DevOps.

Mengapa Native Kubernetes Secrets Tidak Memadai

Resource Secret bawaan menyimpan data di etcd dengan encoding base64. Encoding ini dapat dibalik dengan satu perintah:

# decoding-secret.sh
# Decode nilai Kubernetes secret dengan mudah
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Base64 bukan enkripsi. Siapa pun dengan akses cluster dapat membaca nilai secret. Dokumentasi Kubernetes secara eksplisit memperingatkan bahwa Secrets "tidak terenkripsi secara default" dan merekomendasikan pengaktifan enkripsi at rest.

Tiga keterbatasan utama mempengaruhi deployment produksi:

1. Tidak ada audit trail: Native Secrets tidak menyediakan logging siapa yang mengakses nilai apa dan kapan
2. Tidak ada mekanisme rotasi: Mengubah secret memerlukan intervensi manual dan restart pod
3. Tidak kompatibel dengan GitOps: Menyimpan secrets terenkripsi di Git tetap mengekspos masalah manajemen encryption key

Arsitektur External Secrets Operator

External Secrets Operator (ESO) menjembatani Kubernetes dengan sistem manajemen secrets eksternal. Dirilis sebagai proyek CNCF Sandbox pada 2023 dan mencapai v0.10 pada 2026, ESO mendukung AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault, dan 15 backend lainnya.

Arsitektur melibatkan tiga custom resources:

# secret-store.yaml
# ClusterSecretStore mendefinisikan koneksi ke 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"

ClusterSecretStore ini mengkonfigurasi ESO untuk melakukan autentikasi dengan Vault menggunakan token service account Kubernetes. Metode auth kubernetes memvalidasi JWT service account terhadap TokenReview API cluster.

# external-secret.yaml
# ExternalSecret mengambil dan menyinkronkan data secret
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-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

ESO membuat native Kubernetes Secret dari data Vault, memperbarui secara otomatis berdasarkan refreshInterval. Aplikasi menggunakan Secret standar tanpa mengetahui sumbernya.

Integrasi HashiCorp Vault dengan Kubernetes

HashiCorp Vault menyediakan manajemen secrets terpusat dengan enkripsi, kontrol akses, dan audit logging. Mengintegrasikan Vault dengan Kubernetes memerlukan konfigurasi pada kedua sistem.

Mengaktifkan Kubernetes Auth di Vault

# vault-k8s-auth.sh
# Konfigurasi metode autentikasi Kubernetes di Vault
vault auth enable kubernetes

vault write auth/kubernetes/config \
    kubernetes_host="https://kubernetes.default.svc:443" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    token_reviewer_jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token

Konfigurasi ini memungkinkan Vault memverifikasi token service account Kubernetes. Cluster API server memvalidasi token dan mengembalikan identitas service account.

Membuat Vault Policy dan Role

# vault-policy.hcl
# Policy membatasi akses ke path secrets tertentu
path "secret/data/production/*" {
  capabilities = ["read"]
}

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

# create-vault-role.sh
# Membuat role yang mengikat ke service account Kubernetes
vault policy write production-secrets vault-policy.hcl

vault write auth/kubernetes/role/external-secrets \
    bound_service_account_names=external-secrets \
    bound_service_account_namespaces=external-secrets \
    policies=production-secrets \
    ttl=1h

Role mengikat service account Kubernetes tertentu ke Vault policies, mengimplementasikan akses least-privilege.

Rotasi Secret Otomatis

Rotasi secret mencegah eksposur jangka panjang dari kredensial yang dikompromikan. ESO mendukung rotasi otomatis melalui pengaturan refreshInterval, tetapi rotasi database memerlukan koordinasi tambahan.

# rotating-secret.yaml
# ExternalSecret dengan refresh interval pendek untuk rotasi
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: rotating-api-key
  namespace: production
spec:
  refreshInterval: 15m
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: api-credentials
    creationPolicy: Owner
    template:
      type: Opaque
      metadata:
        annotations:
          reloader.stakater.com/match: "true"
  data:
    - secretKey: api-key
      remoteRef:
        key: secret/data/production/api
        property: current-key

Anotasi Reloader memicu restart deployment ketika secret berubah, memastikan aplikasi mengambil kredensial baru.

Database Dynamic Secrets dengan Vault

# vault-database-config.sh
# Konfigurasi dynamic secrets untuk PostgreSQL
vault secrets enable database

vault write database/config/production-postgres \
    plugin_name=postgresql-database-plugin \
    allowed_roles="app-readonly,app-readwrite" \
    connection_url="postgresql://{{username}}:{{password}}@postgres.production:5432/app" \
    username="vault-admin" \
    password="vault-admin-password"

vault write database/roles/app-readonly \
    db_name=production-postgres \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Vault membuat kredensial database sementara sesuai permintaan, secara otomatis mencabutnya setelah TTL berakhir.

Implementasi Multi-Cluster Secrets

Organisasi yang menjalankan beberapa cluster Kubernetes memerlukan manajemen secrets terpusat. ESO mendukung konfigurasi multi-tenant dengan namespaced SecretStores.

# multi-cluster-setup.yaml
# SecretStore per cluster dengan isolasi
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: cluster-a-secrets
  namespace: team-alpha
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      namespace: "cluster-a"
      auth:
        kubernetes:
          mountPath: "kubernetes-cluster-a"
          role: "team-alpha"

Setiap cluster melakukan autentikasi dengan Vault mount path sendiri, memungkinkan policy granular per lingkungan.

Pertanyaan Interview Umum DevOps

Pertanyaan wawancara tentang secrets Kubernetes menguji pemahaman praktis tentang keamanan dan operasi.

Pertanyaan: Bagaimana mengamankan Kubernetes Secrets at rest?

Aktifkan enkripsi di level etcd menggunakan EncryptionConfiguration:

# encryption-config.yaml
# Konfigurasi enkripsi untuk secrets di etcd
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_32_BYTE_KEY>
      - identity: {}

Provider aescbc mengenkripsi secrets sebelum menulis ke etcd. Provider identity memungkinkan membaca secrets tidak terenkripsi yang ada selama migrasi.

Pertanyaan: Apa perbedaan antara SecretStore dan ClusterSecretStore?

SecretStore adalah namespaced, hanya dapat direferensi oleh ExternalSecrets di namespace yang sama. ClusterSecretStore adalah cluster-scoped, dapat diakses dari namespace manapun. Gunakan ClusterSecretStore untuk shared secret backends dan SecretStore untuk isolasi tenant.

Pertanyaan: Bagaimana menangani rotasi secrets tanpa downtime?

Implementasi tiga fase rotasi:

1. Dual-write: Tulis kredensial baru sambil mempertahankan yang lama
2. Transition: Perbarui aplikasi untuk menggunakan kredensial baru
3. Cleanup: Hapus kredensial lama setelah semua aplikasi bermigrasi

# dual-credential-secret.yaml
# Support untuk rotasi dual-credential
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: rotating-credentials
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: app-credentials
  data:
    - secretKey: current-password
      remoteRef:
        key: secret/data/app/credentials
        property: current
    - secretKey: previous-password
      remoteRef:
        key: secret/data/app/credentials
        property: previous

Pertanyaan: Bagaimana mengaudit akses secrets di Kubernetes?

Aktifkan audit logging di API server dengan policy yang menangkap operasi secrets:

# audit-policy.yaml
# Audit policy untuk operasi secrets
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Vault menyediakan audit logging bawaan yang mencatat setiap operasi secret dengan timestamp dan identitas.

Troubleshooting Masalah Umum

Masalah deployment ESO biasanya berasal dari kesalahan autentikasi atau konfigurasi.

# debug-external-secret.sh
# Periksa status sinkronisasi ExternalSecret
kubectl get externalsecret -A

# Lihat kondisi detail
kubectl describe externalsecret database-credentials -n production

# Periksa log controller ESO
kubectl logs -n external-secrets -l app.kubernetes.io/name=external-secrets

Kesalahan autentikasi umum:

• Service account tidak ada: Pastikan service account yang direferensikan ada di namespace ESO
• Role binding salah: Verifikasi role Vault mengikat ke service account dan namespace yang benar
• Cluster connectivity: Periksa bahwa ESO dapat menjangkau endpoint Vault

Praktik Terbaik Keamanan

Ikuti panduan ini untuk deployment secrets produksi:

1. Jangan pernah commit secrets ke Git: Gunakan ESO atau sealed-secrets untuk GitOps workflows
2. Implementasi least privilege: Berikan akses hanya ke secrets yang diperlukan
3. Aktifkan audit logging: Lacak semua akses secrets untuk compliance dan forensics
4. Gunakan TTL pendek: Dynamic secrets dengan auto-expiration mengurangi dampak kebocoran
5. Encrypt etcd: Aktifkan enkripsi at rest untuk secrets Kubernetes
6. Network segmentation: Batasi akses ke secret management endpoints

Kesimpulan

Manajemen secrets Kubernetes yang efektif memerlukan lebih dari native Secrets. External Secrets Operator menjembatani gap antara platform secret management enterprise dan workloads Kubernetes, menyediakan sinkronisasi otomatis, rotasi, dan audit capabilities. Memahami arsitektur dan alur operasional ini mempersiapkan kandidat untuk pertanyaan wawancara DevOps dan skenario produksi dunia nyata. Integrasi HashiCorp Vault dengan Kubernetes melalui ESO menciptakan solusi secrets yang aman dan dapat diskalakan yang memenuhi standar kepatuhan enterprise sambil mempertahankan kecepatan developer.