External Secret Manager #

Kubernetes Secret yang dikelola secara native punya keterbatasan serius untuk kebutuhan produksi skala besar: tidak ada audit log per-akses, tidak ada rotasi otomatis, dan nilai sensitif tersimpan di Etcd yang harus dilindungi sendiri. External secret manager hadir untuk mengisi celah ini — mereka adalah sistem khusus yang dirancang untuk menyimpan, mengamankan, dan mengelola siklus hidup secret. Artikel ini membahas cara mengintegrasikan Kubernetes dengan tiga solusi paling populer.

Mengapa External Secret Manager? #

Kubernetes Secret native:
  ✗ Nilai di Etcd — keamanan bergantung sepenuhnya pada keamanan Etcd
  ✗ Tidak ada audit log siapa mengakses secret kapan
  ✗ Tidak ada rotasi otomatis
  ✗ Tidak ada versioning secret
  ✗ Sulit digunakan lintas cluster atau lintas cloud

External secret manager (Vault, AWS SM, GCP SM):
  ✓ Audit log lengkap — siapa, kapan, dari mana
  ✓ Rotasi otomatis dengan lambda/function integration
  ✓ Versioning — bisa rollback ke versi secret sebelumnya
  ✓ Dynamic secret — generate credential sementara yang kadaluarsa otomatis
  ✓ Satu sumber kebenaran untuk banyak cluster dan aplikasi
  ✓ Fine-grained access control per aplikasi

External Secrets Operator (ESO) #

External Secrets Operator adalah operator Kubernetes yang menjembatani antara Kubernetes dan berbagai external secret manager. Ia watch ExternalSecret resource dan mensinkronkan nilai ke Kubernetes Secret.

Cara kerja ESO:

  External Secret Manager          Kubernetes Cluster
  (AWS SM / Vault / GCP SM)
         │                               │
         │                        External Secrets
         │                           Operator
         │                               │
         │    [sync setiap N menit]      │
         │◄──────────────────────────────│
         │                               │
         │    [kembalikan nilai secret]  │
         │───────────────────────────────►
                                         │
                                   Kubernetes
                                     Secret
                                         │
                                      Pod

# Install ESO via Helm
helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets \
  --namespace external-secrets \
  --create-namespace

Integrasi dengan AWS Secrets Manager #

# 1. ClusterSecretStore — koneksi ke AWS SM (cluster-level)
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-secrets-manager
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-southeast-1
      auth:
        # Gunakan IRSA (IAM Roles for Service Accounts) di EKS
        serviceAccount:
          name: external-secrets-sa
          namespace: external-secrets

# 2. ExternalSecret di namespace aplikasi
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: database-credentials    # nama Kubernetes Secret yang dibuat
    creationPolicy: Owner
    deletionPolicy: Retain        # jangan hapus Secret jika ExternalSecret dihapus
  data:
  - secretKey: DB_USERNAME
    remoteRef:
      key: production/database    # path di AWS Secrets Manager
      property: username
  - secretKey: DB_PASSWORD
    remoteRef:
      key: production/database
      property: password
  - secretKey: DB_HOST
    remoteRef:
      key: production/database
      property: host

# Buat secret di AWS Secrets Manager
aws secretsmanager create-secret \
  --name "production/database" \
  --secret-string '{"username":"appuser","password":"S3cur3P@ss","host":"postgres.internal"}'

# Cek status sync
kubectl describe externalsecret database-credentials -n production
# Status: SecretSynced = True

Integrasi dengan HashiCorp Vault #

Vault adalah solusi yang paling fleksibel — mendukung banyak secret engine termasuk dynamic secrets (credential sementara yang di-generate on-demand).

# SecretStore untuk Vault
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-store
  namespace: production
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"              # mount path di Vault
      version: "v2"               # KV secrets engine version
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "production-api"   # Vault role yang sudah dikonfigurasi
          serviceAccountRef:
            name: api-service-account

# ExternalSecret dari Vault
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-secrets
  namespace: production
spec:
  refreshInterval: "15m"
  secretStoreRef:
    name: vault-store
    kind: SecretStore
  target:
    name: api-secrets
  data:
  - secretKey: STRIPE_KEY
    remoteRef:
      key: production/payment     # path di Vault KV
      property: stripe_key
  - secretKey: SENDGRID_KEY
    remoteRef:
      key: production/email
      property: api_key

Dynamic Secrets dengan Vault #

Salah satu fitur paling powerful Vault: generate database credential sementara yang otomatis kadaluarsa:

# Vault Database Secret Engine
# Vault generate username/password baru setiap kali diminta
# Credential kadaluarsa setelah TTL yang ditentukan

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
spec:
  target:
    name: db-dynamic-creds
  data:
  - secretKey: username
    remoteRef:
      key: database/creds/production-role   # Vault database engine path
      property: username
  - secretKey: password
    remoteRef:
      key: database/creds/production-role
      property: password
  # ESO refresh setiap kali TTL mendekati expiry
  refreshInterval: "1h"

Integrasi dengan GCP Secret Manager #

# SecretStore untuk GCP Secret Manager
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: gcp-secret-manager
spec:
  provider:
    gcpsm:
      projectID: "my-gcp-project"
      auth:
        workloadIdentity:
          clusterLocation: asia-southeast1
          clusterName: production-cluster
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets

# ExternalSecret dari GCP SM
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
  namespace: production
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: gcp-secret-manager
    kind: ClusterSecretStore
  target:
    name: app-secrets
  data:
  - secretKey: FIREBASE_KEY
    remoteRef:
      key: production-firebase-key   # nama secret di GCP SM
      version: latest

Memilih External Secret Manager #

HashiCorp Vault:
  Cocok jika:
  ✓ Multi-cloud atau hybrid cloud
  ✓ Butuh dynamic secrets (credential sementara)
  ✓ Banyak tim dan workload yang butuh fine-grained access control
  ✓ Ingin satu solusi untuk semua jenis secret (database, PKI, SSH)
  Pertimbangan: lebih kompleks untuk di-setup dan di-maintain

AWS Secrets Manager:
  Cocok jika:
  ✓ Semua workload di AWS/EKS
  ✓ Butuh integrasi native dengan RDS automatic rotation
  ✓ Tim sudah familiar dengan AWS ecosystem
  Pertimbangan: biaya per-secret dan per-API call; vendor lock-in AWS

GCP Secret Manager:
  Cocok jika:
  ✓ Semua workload di GKE/GCP
  ✓ Integrasi dengan Google Cloud IAM dan audit logging
  Pertimbangan: lebih sederhana dari Vault; biaya per-access

Azure Key Vault:
  Cocok jika:
  ✓ Semua workload di AKS/Azure
  ✓ Integrasi dengan Azure AD dan managed identities
  Pertimbangan: hanya untuk ekosistem Azure

Ringkasan #

  • External secret manager untuk produksi skala besar — audit log, rotasi otomatis, versioning, dan dynamic secrets tidak ada di Kubernetes Secret native.
  • External Secrets Operator sebagai jembatan universal — mendukung AWS SM, Vault, GCP SM, Azure Key Vault, dan lainnya dengan pola yang konsisten.
  • refreshInterval mengontrol frekuensi sync — nilai lebih pendek berarti secret lebih cepat ter-update tapi lebih banyak API call ke secret manager; sesuaikan dengan kebutuhan rotasi.
  • Dynamic secrets Vault untuk keamanan maksimal — credential database di-generate on-demand dengan TTL pendek; tidak ada credential permanen yang bisa dicuri.
  • Pilih berdasarkan cloud provider dan kompleksitas — AWS SM untuk EKS, GCP SM untuk GKE, Vault untuk multi-cloud atau kebutuhan yang lebih kompleks.
  • IRSA/Workload Identity untuk autentikasi — jangan gunakan static credentials untuk ESO mengakses secret manager; gunakan IAM roles yang terikat ke service account Kubernetes.

← Sebelumnya: Secret Management Best Practice   Berikutnya: ConfigMap vs Secret →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact