DOKS’ta External Secrets Operator’ı Vault ile Yapılandırma Rehberi
Giriş
Bulut tabanlı uygulamaların yükselişiyle birlikte, güvenlik ve özellikle gizlilik yönetimi, modern yazılım geliştirme ve operasyon süreçlerinin kritik bir bileşeni haline gelmiştir. Kubernetes gibi konteyner orkestrasyon platformları, uygulamaları dağıtma ve ölçeklendirme konusunda devrim yaratmış olsa da, hassas verilerin (API anahtarları, veritabanı şifreleri, sertifikalar vb.) güvenli bir şekilde saklanması ve uygulamalara sunulması hala karmaşık bir meydan okumadır. Geleneksel Kubernetes Secrets, Base64 ile kodlanmış olmaları nedeniyle güvenlik açısından yetersiz kalabilir ve merkezi bir gizlilik yönetim sistemi olmadan denetlenebilirlik ve yaşam döngüsü yönetimi zorlaşır.
İşte bu noktada HashiCorp Vault gibi merkezi gizlilik yönetim çözümleri devreye girer. Vault, gizliliklerin güvenli bir şekilde saklanmasını, erişim kontrolünü, denetlenmesini ve dinamik olarak oluşturulmasını sağlayan güçlü bir araçtır. Ancak, Kubernetes uygulamalarının bu gizliliklere doğrudan Vault API’si üzerinden erişmesi, uygulama kodunda Vault entegrasyonu gerektirdiğinden ek bir yük oluşturur. Bu sorunu çözmek için External Secrets Operator (ESO) ortaya çıkmıştır. ESO, Vault gibi harici gizlilik yöneticilerinde depolanan gizlilikleri Kubernetes Secrets olarak otomatik olarak senkronize eden bir Kubernetes operatörüdür. Bu sayede, uygulamalar standart Kubernetes Secrets’ı kullanmaya devam ederken, gizlilik yönetimi Vault’un sağladığı güvenlik ve esneklikten faydalanabilir.
Bu makalede, DigitalOcean Kubernetes Service (DOKS) ortamında External Secrets Operator’ı HashiCorp Vault ile nasıl yapılandıracağımızı adım adım ele alacağız. DOKS, yönetilen bir Kubernetes hizmeti olarak altyapı karmaşıklığını azaltırken, ESO ve Vault entegrasyonu uygulamalarınızın gizliliklerini daha güvenli ve yönetilebilir hale getirecektir. Amacımız, bu entegrasyonun temel prensiplerini, kurulum adımlarını ve en iyi uygulamalarını detaylı bir şekilde açıklayarak, okuyuculara pratik bir rehber sunmaktır.
Neden External Secrets Operator ve Vault?
Modern bulut yerel uygulamalarında gizlilik yönetimi, hem geliştiriciler hem de operasyon ekipleri için önemli bir endişe kaynağıdır. Bu bölümde, neden Vault ve External Secrets Operator kombinasyonunun bu zorlukları aşmak için güçlü bir çözüm sunduğunu inceleyeceğiz.
Kubernetes’te Gizlilik Yönetimi Zorlukları
Kubernetes, uygulamaların dağıtımı ve yönetimi için harika bir platform olsa da, gizlilik yönetimi konusunda bazı temel eksikliklere sahiptir:
* Varsayılan Olarak Şifreleme Yok: Kubernetes Secrets, varsayılan olarak yalnızca Base64 ile kodlanmıştır, şifrelenmemiştir. Bu, küme erişimi olan herkesin gizlilikleri kolayca okuyabileceği anlamına gelir. Hassas veriler için bu durum ciddi bir güvenlik açığıdır.
* Merkezi Yönetim Eksikliği: Her Kubernetes kümesi kendi gizliliklerini yönetir. Birden fazla küme veya ortamınız varsa, gizlilikleri tutarlı bir şekilde yönetmek ve senkronize etmek zorlaşır.
* Erişim Kontrolü Sınırlamaları: Kubernetes RBAC ile gizliliklere erişim kontrol edilebilir, ancak bu, hangi uygulamanın hangi gizliliğe erişebileceği konusunda ince taneli kontroller sağlamakta zorlanabilir. Ayrıca, gizliliklere erişim denetimi (audit trail) sınırlıdır.
* Gizlilik Yaşam Döngüsü Yönetimi: Gizliliklerin düzenli olarak yenilenmesi (rotation), sürelerinin dolması veya iptal edilmesi gibi yaşam döngüsü yönetimi süreçleri, manuel olarak yapıldığında hataya açık ve zaman alıcıdır.
* Geliştirici Deneyimi: Geliştiricilerin, farklı ortamlar için farklı gizlilikleri yönetmesi veya doğrudan Kubernetes API’si ile etkileşime girmesi, geliştirme sürecini karmaşıklaştırabilir.
Vault’un Avantajları
HashiCorp Vault, yukarıda belirtilen zorlukların üstesinden gelmek için tasarlanmış kapsamlı bir gizlilik yönetim çözümüdür:
* Merkezi Gizlilik Deposu: Tüm gizlilikleri tek bir güvenli, merkezi konumda depolar. Bu, gizliliklerin tutarlılığını ve yönetimini kolaylaştırır.
* Şifreleme ve Güvenlik: Gizlilikleri depolarken ve iletirken şifreleme kullanır. Bu, hassas verilerin hem depoda hem de ağda güvende olmasını sağlar.
* Dinamik Gizlilikler: Veritabanı kimlik bilgileri, API anahtarları gibi gizlilikleri “anında” oluşturabilir ve belirli bir süre sonra otomatik olarak iptal edebilir. Bu, saldırı yüzeyini önemli ölçüde azaltır.
* Geniş Yetkilendirme Seçenekleri: Kubernetes, AWS IAM, Azure AD, GitHub ve daha fazlası dahil olmak üzere birçok yetkilendirme yöntemini destekler. Bu, farklı platformlardaki kullanıcıların ve sistemlerin Vault’a güvenli bir şekilde erişmesini sağlar.
* Detaylı Erişim Kontrolü (ACL): Hangi kullanıcının veya uygulamanın hangi gizliliklere erişebileceğini çok ince taneli politikalarla tanımlayabilir.
* Denetim Kayıtları (Audit Logs): Vault’a yapılan her erişim ve işlem, detaylı denetim kayıtlarına kaydedilir. Bu, uyumluluk ve güvenlik analizi için hayati öneme sahiptir.
* Gizlilik Yenileme ve Revoke Etme: Gizliliklerin otomatik olarak yenilenmesini veya iptal edilmesini sağlar, böylece manuel müdahaleye gerek kalmaz.
External Secrets Operator’ın Rolü
External Secrets Operator (ESO), Kubernetes ve harici gizlilik yöneticileri arasındaki köprüdür. Temel işlevi şunlardır:
* Senkronizasyon: Vault gibi harici depolarda bulunan gizlilikleri, Kubernetes kümesi içindeki standart Secret objelerine dönüştürür ve senkronize eder.
* Otomatik Güncelleme: Harici depodaki gizlilikler değiştiğinde, ESO bu değişiklikleri algılar ve ilgili Kubernetes Secret’ını otomatik olarak günceller. Bu, gizlilik yenileme süreçlerini basitleştirir.
* Uygulama Şeffaflığı: Uygulamalar, Vault ile doğrudan etkileşime girmek zorunda kalmaz. Bunun yerine, standart Kubernetes Secrets’ı tüketmeye devam ederler. Bu, uygulama kodunu daha temiz ve taşınabilir hale getirir.
* Güvenlik ve İzolasyon: Gizlilikler, sadece ihtiyaç duyulduğunda Kubernetes’e çekilir ve genellikle belirli bir namespace veya küme kapsamıyla sınırlıdır. Vault’un yetkilendirme mekanizmaları, ESO’nun sadece yetkili gizliliklere erişmesini sağlar.
* Çoklu Depo Desteği: Sadece Vault değil, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault gibi birçok farklı harici gizlilik deposunu destekler.
Özetle, Vault merkezi, güvenli ve denetlenebilir bir gizlilik deposu sağlarken, External Secrets Operator bu gizlilikleri Kubernetes uygulamalarına güvenli ve otomatik bir şekilde ulaştırır. Bu kombinasyon, Kubernetes ortamlarında gizlilik yönetimini basitleştirir, güvenliği artırır ve geliştirici verimliliğini destekler.
Ön Koşullar
Bu makaledeki adımları başarıyla takip edebilmek için aşağıdaki ön koşulların yerine getirilmiş olması gerekmektedir:
* DigitalOcean Kubernetes Service (DOKS) Kümesi: Çalışır durumda bir DOKS kümesine sahip olmanız ve kubectl komut satırı aracıyla bu kümeye erişebiliyor olmanız gerekmektedir. kubectl yapılandırmanızın doğru olduğundan emin olun.
* Helm: Kubernetes’e uygulama dağıtımı için bir paket yöneticisi olan Helm’in yerel makinenizde kurulu olması gerekmektedir. Helm 3 veya üzeri bir sürüm önerilir.
* Vault:
* Vault Kurulumu: Bu makale, Vault’un DOKS üzerinde veya erişilebilir harici bir konumda kurulu ve çalışır durumda olduğunu varsaymaktadır. Demolar için DOKS üzerinde Helm ile basit bir Vault kurulumu gerçekleştireceğiz. Üretim ortamları için Vault’un yüksek erişilebilirlik (HA) modunda ve uygun depolama backend’i ile kurulması şiddetle tavsiye edilir.
* Vault CLI: Vault sunucusuyla etkileşim kurmak için vault komut satırı aracının yerel makinenizde kurulu olması gerekmektedir.
* Vault Erişimi: Vault sunucusunun adresini (VAULT_ADDR) ve bir root token’ını veya yetkili bir token’ı ayarlamış olmanız gerekmektedir. Bu, Vault’u ilk yapılandırmak için gereklidir.
Bu araçların kurulu ve yapılandırılmış olduğundan emin olduktan sonra, entegrasyon adımlarına geçebiliriz.
Vault Kurulumu ve Temel Yapılandırması
External Secrets Operator’ın Vault ile iletişim kurabilmesi için öncelikle bir Vault sunucusuna ihtiyacımız var. Bu bölümde, DOKS üzerinde Helm kullanarak basit bir Vault kurulumunu ve ESO için gerekli temel yapılandırmaları ele alacağız.
DOKS Üzerinde Vault Kurulumu (Geliştirme Ortamı İçin)
Üretim ortamları için Vault’un yüksek erişilebilirlik ve kalıcı depolama ile yapılandırılması gerekir. Ancak bu rehber için, Helm kullanarak tek bir replika ile basit bir Vault sunucusu kuracağız.
1. Vault Helm deposunu ekleyin:
helm repo add hashicorp https://helm.releases.hashicorp.com
helm repo update2. Vault için bir namespace oluşturun:
kubectl create namespace vault3. Vault’u Helm ile kurun:
Basit bir geliştirme kurulumu için server.dev.enabled=true kullanabiliriz. Bu, otomatik olarak başlatma (unseal) ve tek bir replika ile çalışmasını sağlar.
helm install vault hashicorp/vault -n vault --set "server.dev.enabled=true" --set "server.service.type=LoadBalancer" server.service.type=LoadBalancer ile Vault’a dışarıdan erişim sağlayacak bir LoadBalancer servisi oluşturulur. IP adresinin atanması birkaç dakika sürebilir.
4. Vault pod’unun çalıştığını doğrulayın:
kubectl get pods -n vault Pod’un Running durumunda olması gerekir.
5. Vault UI ve API erişimini sağlayın:
LoadBalancer IP adresini alın:
kubectl get svc vault -n vault Çıktıda EXTERNAL-IP sütununda bir IP adresi göreceksiniz (örneğin, 192.0.2.1). Bu adres Vault’unuzun VAULT_ADDR değeri olacaktır.
Vault UI’ye http:// adresinden erişebilirsiniz.
VAULT_ADDR ortam değişkenini ayarlayın:
export VAULT_ADDR="http://:8200" Geliştirme modunda kurduğumuz için VAULT_TOKEN otomatik olarak oluşturulur ve vault-0 pod’unun loglarında bulunur.
kubectl logs vault-0 -n vault | grep "Root Token:" Çıktıdaki Root Token: değerini kopyalayın ve VAULT_TOKEN olarak ayarlayın:
export VAULT_TOKEN="s.YOUR_ROOT_TOKEN" # Kendi token'ınızla değiştirin Artık vault CLI ile Vault sunucusuyla etkileşim kurabilirsiniz. Örneğin:
vault status Sealed: false ve Initialized: true görmelisiniz.
Vault Yetkilendirme Yöntemi Yapılandırması
External Secrets Operator’ın Vault’a güvenli bir şekilde kimlik doğrulayabilmesi için Kubernetes Yetkilendirme Yöntemini (Auth Method) yapılandırmamız gerekir. Bu yöntem, Kubernetes Service Account token’larını kullanarak Vault’a kimlik doğrulaması yapmayı sağlar.
1. Kubernetes Yetkilendirme Yöntemini etkinleştirin:
vault auth enable kubernetes2. Vault’u Kubernetes kümenize bağlayın:
Vault’un Kubernetes API’si ile iletişim kurabilmesi için bazı yapılandırma parametreleri gereklidir.
* kubernetes_host: Kubernetes API sunucusunun URL’si.
* kubernetes_ca_cert: Kubernetes kümenizin CA sertifikası (Base64 kodlu).
* token_reviewer_jwt: Vault’un Kubernetes Service Account token’larını doğrulamak için kullanacağı bir Service Account token’ı.
Önce kubernetes_host ve kubernetes_ca_cert değerlerini alalım:
KUBERNETES_HOST=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
KUBERNETES_CA_CERT=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.certificate-authority-data}') Şimdi Vault için bir token_reviewer_jwt oluşturmalıyız. Bu, Vault’un Kubernetes Service Account token’larını doğrulamak için kullanacağı özel bir Service Account’tur.
kubectl create serviceaccount vault-token-reviewer -n vault
kubectl create clusterrolebinding vault-token-reviewer-binding --clusterrole=system:auth-delegator --serviceaccount=vault:vault-token-reviewer
TOKEN_REVIEWER_JWT=$(kubectl create token vault-token-reviewer -n vault) Not: kubectl create token komutu, Kubernetes 1.24 ve sonrası için Service Account token’ı oluşturmanın tercih edilen yoludur. Daha eski sürümlerde, Service Account’un secret’ından token’ı manuel olarak almanız gerekebilir.
Şimdi tüm bu değerleri kullanarak Vault Kubernetes auth backend’ini yapılandırın:
vault write auth/kubernetes/config \
kubernetes_host="$KUBERNETES_HOST" \
kubernetes_ca_cert="$KUBERNETES_CA_CERT" \
token_reviewer_jwt="$TOKEN_REVIEWER_JWT"Vault Politikaları Oluşturma
Vault’ta gizliliklere erişimi kontrol etmek için politikalar (policies) tanımlamamız gerekir. Bu politika, External Secrets Operator’ın belirli bir gizlilik yolundan okumasına izin verecektir.
1. Bir politika dosyası oluşturun (örneğin eso-policy.hcl):
path "secret/data/my-app/*" {
capabilities = ["read"]
} Bu politika, secret/data/my-app/ yolu altındaki tüm gizliliklere okuma erişimi verir. KV v2 motoru kullandığımız için secret/data/ öneki önemlidir.
2. Politikayı Vault’a yükleyin:
vault policy write eso-policy eso-policy.hclVault Rolleri Oluşturma
Vault rolü, bir Kubernetes Service Account’ını bir veya daha fazla Vault politikasına bağlar. ESO, bu rolü kullanarak kimlik doğrulaması yapacak ve ilgili politikalarla yetkilendirilecektir.
vault write auth/kubernetes/role/eso-role \
bound_service_account_names=external-secrets \
bound_service_account_namespaces=external-secrets \
policies=eso-policy \
ttl=1hBurada:
* eso-role: Oluşturduğumuz rolün adı.
* bound_service_account_names: Bu role bağlanabilecek Service Account’ın adı. ESO’nun varsayılan Service Account’ı external-secrets‘tır.
* bound_service_account_namespaces: Bu role bağlanabilecek Service Account’ın namespace’i. ESO’yu external-secrets namespace’ine kuracağız.
* policies: Bu role atanan Vault politikaları. Daha önce oluşturduğumuz eso-policy‘yi kullanıyoruz.
* ttl: Kimlik doğrulama sonrası verilen token’ın geçerlilik süresi.
Gizlilik Yolu Oluşturma ve Değer Ekleme
Şimdi Vault’a ESO’nun okuyacağı bir gizlilik ekleyelim. KV v2 gizlilik motorunu kullanacağız.
1. KV v2 gizlilik motorunu etkinleştirin (eğer zaten etkin değilse):
vault secrets enable -path=secret kv-v22. Gizliliği ekleyin:
my-app/db yoluna username ve password değerlerini ekleyelim.
vault kv put secret/my-app/db username="dbuser" password="supersecretpassword" Not: KV v2 motorunda secret/data/ yolu otomatik olarak eklenir. Bu nedenle vault kv put secret/my-app/db komutu aslında secret/data/my-app/db yoluna yazar.
3. Gizliliği doğrulayın:
vault kv get secret/my-app/db Çıktıda girdiğiniz username ve password değerlerini görmelisiniz.
Vault tarafındaki tüm temel yapılandırmalarımız tamamlandı. Artık External Secrets Operator’ı kurmaya ve yapılandırmaya geçebiliriz.
External Secrets Operator Kurulumu
External Secrets Operator’ı Kubernetes kümenize Helm kullanarak kurmak oldukça basittir.
1. External Secrets Helm deposunu ekleyin:
helm repo add external-secrets https://charts.external-secrets.io
helm repo update2. External Secrets Operator’ı kurun:
ESO’yu kendi namespace’ine kuracağız.
helm install external-secrets external-secrets/external-secrets -n external-secrets --create-namespace Bu komut, external-secrets adında bir namespace oluşturacak ve ESO’nun tüm bileşenlerini (deployment, service account, rbac vb.) bu namespace’e dağıtacaktır.
3. Kurulumu doğrulayın:
ESO pod’larının çalıştığından emin olun:
kubectl get pods -n external-secrets external-secrets-xxx ve external-secrets-webhook-xxx pod’larının Running durumunda olması gerekir.
External Secrets Operator Kaynaklarını Yapılandırma
ESO kurulduktan sonra, Vault’tan gizlilikleri çekmek için gerekli özel kaynakları (Custom Resources) oluşturmamız gerekir: SecretStore ve ExternalSecret.
Uygulama İçin Service Account Oluşturma
Uygulamamızın tüketeceği Kubernetes Secret’ını oluşturmak ve yönetmek için bir Service Account’a ihtiyacımız yok. Ancak Vault’a kimlik doğrulaması yapacak olan ESO’nun Service Account’ı zaten Helm kurulumu sırasında oluştu (external-secrets namespace’inde external-secrets SA).
Eğer uygulamamız doğrudan Vault’a erişecek olsaydı, o zaman uygulama için bir Service Account oluşturup Vault’ta bir rol tanımlamamız gerekirdi. Ancak ESO senaryosunda, uygulamalar standart Kubernetes Secrets’ı kullanır, bu nedenle doğrudan Vault ile etkileşime girmezler.
SecretStore Oluşturma
SecretStore (veya ClusterSecretStore), External Secrets Operator’a harici gizlilik yöneticisiyle (bu durumda Vault) nasıl iletişim kuracağını ve kimlik doğrulayacağını bildirir. SecretStore bir namespace’e özgüyken, ClusterSecretStore küme genelinde kullanılabilir. Bu örnekte, SecretStore kullanacağız.
1. SecretStore YAML dosyasını oluşturun (örneğin vault-secretstore.yaml):
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: vault-secret-store
namespace: default # Bu SecretStore'u kullanacak uygulamaların namespace'i
spec:
provider:
vault:
server: "http://:8200" # Vault sunucunuzun EXTERNAL-IP'si
path: "kubernetes" # Vault'taki Kubernetes auth method'un yolu
version: "v2" # KV motorunun sürümü
auth:
kubernetes:
mountPath: "kubernetes" # Vault'taki Kubernetes auth method'un yolu
serviceAccountRef:
name: external-secrets # ESO'nun Service Account'ı
namespace: external-secrets # ESO'nun Service Account'ının namespace'i
role: "eso-role" # Vault'ta tanımladığımız rol server alanını Vault’unuzun EXTERNAL_IP‘si ile güncellemeyi unutmayın.
2. SecretStore‘u uygulayın:
kubectl apply -f vault-secretstore.yaml3. SecretStore‘un durumunu kontrol edin:
kubectl get secretstore vault-secret-store -n default READY sütununun True olması gerekir. Herhangi bir hata varsa, kubectl describe secretstore vault-secret-store -n default komutuyla detaylara bakabilirsiniz.
ExternalSecret Oluşturma
ExternalSecret kaynağı, ESO’ya hangi harici gizliliği hangi Kubernetes Secret’ına dönüştüreceğini söyler.
1. ExternalSecret YAML dosyasını oluşturun (örneğin my-app-external-secret.yaml):
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: my-app-db-external-secret
namespace: default # Kubernetes Secret'ının oluşturulacağı namespace
spec:
refreshInterval: "1m" # Gizliliklerin ne sıklıkla yenileneceği
secretStoreRef:
name: vault-secret-store # Kullanılacak SecretStore'un adı
kind: SecretStore
target:
name: my-app-db-secret # Oluşturulacak Kubernetes Secret'ının adı
creationPolicy: Owner # Secret'ın sahibi ExternalSecret olacak
data:
- secretKey: DB_USERNAME # Kubernetes Secret'ındaki anahtar
remoteRef:
key: secret/data/my-app/db # Vault'taki gizliliğin tam yolu (KV v2 için 'data' dahil)
property: username # Vault gizliliğindeki alan adı
- secretKey: DB_PASSWORD # Kubernetes Secret'ındaki anahtar
remoteRef:
key: secret/data/my-app/db # Vault'taki gizliliğin tam yolu
property: password # Vault gizliliğindeki alan adı Burada remoteRef.key alanının secret/data/my-app/db şeklinde olması önemlidir, çünkü KV v2 motoru gizlilikleri dahili olarak data anahtarı altında saklar.
2. ExternalSecret‘ı uygulayın:
kubectl apply -f my-app-external-secret.yaml3. ExternalSecret‘ın durumunu kontrol edin:
kubectl get externalsecret my-app-db-external-secret -n default READY sütununun True olması gerekir.
Uygulama Entegrasyonu ve Test
External Secrets Operator, Vault’tan gizlilikleri başarıyla çekip Kubernetes Secret’ına dönüştürdüğünde, uygulamalarınız bu Secret’ı standart Kubernetes yöntemleriyle kullanabilir.
Kubernetes Secret’ı Doğrulama
ESO’nun ExternalSecret tanımınıza göre bir Kubernetes Secret’ı oluşturup oluşturmadığını kontrol edelim.
kubectl get secret my-app-db-secret -n default -o yamlÇıktı aşağıdaki gibi olmalı (Base64 kodlu değerlerle):
apiVersion: v1
data:
DB_PASSWORD: c3VwZXJzZWNyZXRwYXNzd29yZA== # "supersecretpassword" Base64 kodlu hali
DB_USERNAME: ZGJ1c2Vy # "dbuser" Base64 kodlu hali
kind: Secret
metadata:
name: my-app-db-secret
namespace: default
# ... diğer metadata ...
type: Opaquedata alanındaki değerleri Base64’ten çözerek doğrulayabilirsiniz:
echo "c3VwZXJzZWNyZXRwYXNzd29yZA==" | base64 --decode
echo "ZGJ1c2Vy" | base64 --decodeEğer gizlilik doğru bir şekilde oluşturulduysa, ESO entegrasyonu başarılı demektir.
Uygulamanın Secret’ı Kullanması
Şimdi basit bir test pod’u dağıtarak bu Kubernetes Secret’ını nasıl kullanabileceğimizi gösterelim.
1. Test Pod’u YAML dosyası oluşturun (örneğin test-app-pod.yaml):
apiVersion: v1
kind: Pod
metadata:
name: test-app
namespace: default
spec:
containers:
- name: test-app-container
image: busybox
command: ["sh", "-c", "echo 'DB_USERNAME: $DB_USERNAME' && echo 'DB_PASSWORD: $DB_PASSWORD' && sleep 3600"]
envFrom:
- secretRef:
name: my-app-db-secret # Oluşturduğumuz Kubernetes Secret'ının adı
restartPolicy: Never Bu Pod, my-app-db-secret adlı Secret’taki tüm anahtarları ortam değişkenleri olarak yükler ve bu değerleri ekrana yazdırır.
2. Test Pod’u dağıtın:
kubectl apply -f test-app-pod.yaml3. Pod’un loglarını kontrol edin:
kubectl logs test-app -n defaultLoglarda aşağıdaki gibi bir çıktı görmelisiniz:
DB_USERNAME: dbuser
DB_PASSWORD: supersecretpasswordBu, uygulamanızın Vault’tan ESO aracılığıyla gelen gizlilikleri başarıyla kullandığını gösterir.
Değişikliklerin Senkronizasyonu
External Secrets Operator’ın en güçlü özelliklerinden biri, harici gizlilik deposundaki değişiklikleri otomatik olarak algılayıp Kubernetes Secret’ını güncellemesidir.
1. Vault’taki gizliliği güncelleyin:
vault kv put secret/my-app/db username="newdbuser" password="newsupersecretpassword"2. Birkaç dakika bekleyin (ExternalSecret’taki refreshInterval süresi kadar, örneğin 1 dakika).
3. Kubernetes Secret’ını tekrar kontrol edin:
kubectl get secret my-app-db-secret -n default -o yaml data alanındaki DB_USERNAME ve DB_PASSWORD değerlerinin Base64 kodlu yeni değerlere güncellendiğini göreceksiniz.
4. Test Pod’u silip tekrar oluşturun (eğer ortam değişkenleri kullanıyorsanız, Pod’un yeniden başlatılması gerekir):
kubectl delete pod test-app -n default
kubectl apply -f test-app-pod.yaml
kubectl logs test-app -n defaultLoglarda yeni kullanıcı adı ve şifre değerlerini görmelisiniz. Bu, gizliliklerin başarılı bir şekilde yenilendiğini ve uygulamanın güncel değerleri aldığını gösterir.
Gelişmiş Yapılandırma ve En İyi Uygulamalar
External Secrets Operator ve Vault entegrasyonu, temel kurulumun ötesinde birçok gelişmiş yapılandırma ve en iyi uygulama sunar.
Gizlilik Yenileme (Secret Rotation)
ExternalSecret kaynağındaki refreshInterval parametresi, ESO’nun harici gizlilik deposunu ne sıklıkla kontrol edeceğini ve Kubernetes Secret’ını güncelleyeceğini belirler. Bu, gizlilik yenileme politikalarını otomatikleştirmenin anahtarıdır. Örneğin, veritabanı şifrelerini düzenli olarak değiştiren bir Vault dinamik gizlilik motoru kullanıyorsanız, ESO bu yeni kimlik bilgilerini otomatik olarak Kubernetes’e senkronize edecektir.
Dinamik Gizlilikler (Dynamic Secrets)
Vault’un dinamik gizlilikler özelliği, belirli bir süre için geçerli olan ve otomatik olarak iptal edilen kimlik bilgileri oluşturur (örneğin, bir veritabanı için kısa ömürlü kullanıcı adı/şifre çifti). ESO, bu dinamik gizlilikleri de çekebilir. Tek yapmanız gereken ExternalSecret tanımınızda remoteRef.key alanını dinamik gizlilik yolunu gösterecek şekilde yapılandırmaktır. ESO, token’ın veya gizliliğin TTL’i dolduğunda otomatik olarak yenisini talep edecek ve Kubernetes Secret’ını güncelleyecektir.
Farklı Gizlilik Motorları
Vault, KV (anahtar/değer) motoru dışında birçok farklı gizlilik motorunu destekler:
* Veritabanı Gizlilik Motoru: PostgreSQL, MySQL gibi veritabanları için dinamik kimlik bilgileri oluşturur.
* AWS Gizlilik Motoru: AWS IAM kimlik bilgileri oluşturur.
* PKI Gizlilik Motoru: Sertifikalar ve özel anahtarlar oluşturur.
ESO, bu motorlardan gelen gizlilikleri de çekebilir. SecretStore yapılandırmanızda Vault provider altında kv yerine ilgili motorun yolunu ve versiyonunu belirtmeniz yeterlidir.
Yetkilendirme Stratejileri
* Vault Politikaları: Vault’ta en az ayrıcalık prensibiyle politikalar oluşturun. ESO’nun Service Account’ına sadece ihtiyacı olan gizlilik yollarına erişim izni verin.
* Kubernetes RBAC: Kubernetes içinde SecretStore ve ExternalSecret kaynaklarına erişimi RBAC ile kısıtlayın. Hangi ekibin veya kullanıcının hangi gizlilik tanımlarını oluşturabileceğini kontrol edin.
* Namespace İzolasyonu: Her uygulama veya ekip için ayrı Kubernetes namespace’leri ve bu namespace’lere özel SecretStore‘lar kullanın. Bu, gizlilik erişimini daha da izole eder.
Güvenlik İpuçları
* Vault HA Kurulumu: Üretim ortamlarında Vault’u yüksek erişilebilirlik (HA) modunda dağıtın ve kalıcı depolama backend’i (örneğin, Consul, Integrated Storage) kullanın.
* TLS Kullanımı: Vault ile ESO arasındaki tüm iletişimin TLS üzerinden şifrelendiğinden emin olun. SecretStore tanımında server URL’sini https olarak belirtin ve gerektiğinde sertifika doğrulamasını yapılandırın.
* Denetim Kayıtları: Vault’un denetim kayıtlarını etkinleştirin ve merkezi bir loglama sistemine gönderin. Bu, kimin ne zaman hangi gizliliğe eriştiğini izlemenizi sağlar.
* Gizliliklerin Şifrelenmesi: Kubernetes Secrets’ı, küme düzeyinde KMS (Key Management Service) veya bir şifreleme sağlayıcısı (encryption provider) ile şifreleyerek depoda (at-rest) da güvende tuttuğunuzdan emin olun. DOKS gibi yönetilen Kubernetes hizmetleri genellikle bu özelliği sağlar.
* refreshInterval Optimizasyonu: refreshInterval‘ı çok kısa ayarlamak Vault’a gereksiz yük bindirebilir. Uygulamanızın gizlilik yenileme toleransına göre uygun bir değer seçin.
Üretim Ortamı İçin Dikkat Edilmesi Gerekenler
* Vault Yedekleme ve Geri Yükleme: Vault verilerini düzenli olarak yedekleyin ve felaket kurtarma planlarınızın bir parçası olarak geri yükleme prosedürlerini test edin.
* İzleme ve Uyarılar: Vault ve External Secrets Operator’ın durumunu, performansını ve loglarını izleyin. Herhangi bir hata veya beklenmedik davranış durumunda uyarılar alın.
* Versiyon Yönetimi: Vault ve ESO’nun güncel ve desteklenen versiyonlarını kullandığınızdan emin olun. Güvenlik yamalarını ve yeni özellikleri takip edin.
* Terraform veya GitOps: Tüm bu yapılandırmaları (Vault politikaları, rolleri, ESO kaynakları) Terraform veya GitOps araçları (Argo CD, Flux CD) ile kod olarak yönetmek, tutarlılığı ve tekrarlanabilirliği sağlar.
Sonuç
Bu makalede, DigitalOcean Kubernetes Service (DOKS) ortamında External Secrets Operator’ı HashiCorp Vault ile entegre etmenin kapsamlı bir rehberini sunduk. Kubernetes’in yerel gizlilik yönetimindeki eksikliklerini ve Vault’un merkezi, güvenli ve denetlenebilir bir çözüm olarak nasıl öne çıktığını inceledik. Ardından, External Secrets Operator’ın bu iki dünyayı nasıl bir araya getirdiğini ve uygulamaların standart Kubernetes Secrets’ı kullanmaya devam ederken Vault’un gücünden faydalanmasını sağladığını gösterdik.
Adım adım Vault kurulumu, Kubernetes yetkilendirme yöntemi yapılandırması, politika ve rol tanımlamaları ile Vault’a gizlilik ekleme süreçlerini tamamladık. Daha sonra External Secrets Operator’ı Helm ile kurduk ve SecretStore ile ExternalSecret kaynaklarını oluşturarak Vault’taki gizlilikleri Kubernetes’e senkronize ettik. Son olarak, bir test uygulamasıyla bu entegrasyonun çalıştığını doğruladık ve gizlilik değişikliklerinin otomatik olarak nasıl senkronize edildiğini gözlemledik.
Bu entegrasyon, Kubernetes ortamlarında gizlilik yönetimini önemli ölçüde basitleştirir, güvenliği artırır ve geliştirici verimliliğini destekler. Uygulamalarınızın hassas verilerini güvenli bir şekilde yönetmek için merkezi bir çözüm arıyorsanız, External Secrets Operator ve Vault kombinasyonu güçlü ve esnek bir seçenektir. Gelişmiş yapılandırma ve en iyi uygulamaları takip ederek, bu çözümü üretim ortamlarınızda güvenle kullanabilirsiniz. Bu rehberin, DOKS üzerindeki Kubernetes kümelerinizde güvenli gizlilik yönetimini uygulamanıza yardımcı olacağını umuyoruz.