HashiCorp Vault ile Kurumsal Gizli Bilgi Yönetimi: Dinamik Kimlik Bilgileri ve Güvenli Erişim

Modern uygulama mimarilerinde, özellikle mikroservis ve bulut tabanlı sistemlerde, statik kimlik bilgilerinin (veritabanı şifreleri, API anahtarları, bulut sağlayıcı kimlik bilgileri) yönetimi ciddi güvenlik riskleri taşır. Bu tür kimlik bilgilerinin kod içine gömülmesi, yapılandırma dosyalarında saklanması veya ortam değişkenleri aracılığıyla sağlanması, sızıntı durumunda geniş çaplı yetkisiz erişimlere yol açabilir. Bu noktada HashiCorp Vault, merkezi, güvenli ve dinamik bir gizli bilgi yönetimi çözümü olarak devreye girer.

Vault'un Temel Mimarisi ve Bileşenleri

Vault, gizli bilgileri şifreli bir depolama biriminde (storage backend) saklar ve bu bilgilere erişimi kimlik doğrulama (auth methods) ve yetkilendirme (policies) mekanizmalarıyla sıkı bir şekilde kontrol eder. Vault'un kalbindeki temel bileşenler şunlardır:

• Storage Backend: Vault'un tüm verilerini, gizli bilgiler dahil, şifreli olarak sakladığı yerdir. Konsisten depolama sağlar. Yaygın olarak kullanılan backend'ler arasında Consul, S3, Azure Blob Storage veya Raft tabanlı dahili depolama bulunur.
• Seal/Unseal: Vault, başlatıldığında "sealed" (mühürlü) durumdadır, yani şifreli depolama birimine erişemez. "Unseal" (mührü kaldırma) işlemi, Vault'un ana şifreleme anahtarına erişmesini sağlar. Bu anahtar genellikle Shamir's Secret Sharing algoritması ile birden fazla parçaya bölünür ve yetkili kişilere dağıtılır, bu da tek bir kişinin Vault'u açmasını engeller.
• Auth Methods: Uygulamaların veya kullanıcıların Vault'a kimlik doğrulaması yapmasını sağlayan mekanizmalardır. Kubernetes, AWS IAM, AppRole, LDAP, GitHub gibi çeşitli yöntemleri destekler.
• Secret Engines: Farklı türde gizli bilgileri üretmek, depolamak ve yönetmek için kullanılan modüllerdir. KV (key-value), AWS, Database, SSH, PKI gibi motorlar bulunur.
• Audit Devices: Vault üzerindeki tüm işlemleri loglamak için kullanılır. Bu loglar, kimin ne zaman hangi gizli bilgiye eriştiğini veya erişmeye çalıştığını gösterir, güvenlik denetimi için kritik öneme sahiptir.

Dinamik Gizli Bilgi Motorları (Secret Engines)

Vault'un en güçlü özelliklerinden biri, statik şifreler yerine kısa ömürlü, dinamik gizli bilgiler üretebilmesidir. Bu, her erişim talebi için benzersiz bir kimlik bilgisi oluşturulmasını sağlayarak sızıntı riskini minimize eder ve otomatik rotasyon imkanı sunar.

Örnek: AWS Secret Engine

AWS Secret Engine, AWS üzerinde dinamik IAM kullanıcıları veya geçici güvenlik kimlik bilgileri (STS) oluşturabilir. Bir uygulama Vault'tan AWS kimlik bilgisi talep ettiğinde, Vault dinamik olarak belirli bir yetki setiyle bir IAM kullanıcısı oluşturur ve bu kullanıcının anahtar çiftini uygulamaya verir. Bu anahtar çifti, belirli bir yaşam süresine (TTL) sahiptir ve süresi dolduğunda otomatik olarak iptal edilir.

vault secrets enable awsvault write aws/config/root access_key=<AWS_ROOT_ACCESS_KEY> secret_key=<AWS_ROOT_SECRET_KEY>region=eu-central-1vault write aws/roles/my-app-rolepolicy_arns="arn:aws:iam::ACCOUNT_ID:policy/MyS3ReadOnlyPolicy"credential_type="iam_user"# Şimdi bir uygulama bu rolden dinamik kimlik bilgisi alabilirvault read aws/creds/my-app-role

Yukarıdaki komutlar, AWS Secret Engine'i etkinleştirir, Vault'un AWS ile iletişim kurabilmesi için bir root kimlik bilgisi (genellikle production ortamında STS veya IAM Role kullanılır) tanımlar ve son olarak MyS3ReadOnlyPolicy yetkisiyle dinamik IAM kullanıcıları oluşturacak bir rol tanımlar.

Gerçek Dünya Senaryosu: Kubernetes ve Dinamik AWS Kimlik Bilgileri

Bir Kubernetes kümesinde çalışan mikroservislerinizin, S3 kovalarına erişmek için AWS kimlik bilgilerine ihtiyacı olduğunu varsayalım. Geleneksel yaklaşımla, AWS kimlik bilgileri Kubernetes sırları (Secrets) olarak saklanabilir, ancak bu sırların rotasyonu ve yönetimi karmaşıktır ve statik olmaları güvenlik risklerini artırır.

Vault kullanarak bu sorunu şöyle çözebiliriz:

1. Vault Kurulumu ve Yapılandırması: Vault sunucunuzu HA modunda Kubernetes dışında (veya Helm ile Kubernetes içinde) kurun. AWS Secret Engine'ı yukarıdaki gibi yapılandırın ve S3 erişimi için bir rol (örneğin s3-reader) tanımlayın.
2. Kubernetes Auth Method Etkinleştirme: Vault'un Kubernetes kümesinden gelen kimlik doğrulama taleplerini işlemesini sağlamak için Kubernetes Auth Method'u yapılandırın. Bu, Kubernetes servis hesaplarının Vault'a kimlik doğrulaması yapmasına olanak tanır.

vault auth enable kubernetesvault write auth/kubernetes/configkubernetes_host="https://<KUBERNETES_API_SERVER_IP>:<PORT>"token_reviewer_jwt="<SERVICE_ACCOUNT_JWT>"# ... diğer yapılandırmalarvault write auth/kubernetes/role/my-app-k8s-rolebound_service_account_names="my-app-service-account"bound_service_account_namespaces="default"policies="s3-read-policy"ttl="1h"

Bu yapılandırma ile default namespace'indeki my-app-service-account adlı servis hesabına sahip bir Pod, s3-read-policy isimli Vault politikasına erişim yetkisi kazanır.

vault policy write s3-read-policy - <<EOFpath "aws/creds/s3-reader" {  capabilities = ["read"]}EOF

// Örnek bir Go kodu (pseudo-code)import "github.com/hashicorp/vault/api"// Kubernetes servis hesabı JWT'sini alclient, err := api.NewClient(api.DefaultConfig())// ... Vault adresi yapılandırmasıclient.Auth().Login(context.Background(), &api.LoginOptions{    Path: "kubernetes",    Mount: "kubernetes",    JSON: map[string]interface{}{        "jwt": "<KUBERNETES_SERVICE_ACCOUNT_JWT>",        "role": "my-app-k8s-role",    },})resp, err := client.Logical().Read("aws/creds/s3-reader")if err != nil {    // Hata yönetimi}accessKey := resp.Data["access_key"].(string)secretKey := resp.Data["secret_key"].(string)sessionToken := resp.Data["security_token"].(string)// Bu kimlik bilgileri ile AWS SDK'yı yapılandır ve S3'e eriş

Bu yaklaşım, uygulamaların doğrudan AWS kimlik bilgilerini depolamadan, kısa ömürlü ve dinamik olarak Vault'tan almasını sağlar. Kimlik bilgileri, Vault tarafından otomatik olarak yönetilir ve belirli bir süre sonra iptal edilir, bu da güvenlik duruşunu önemli ölçüde güçlendirir.

Kiralama ve Yenileme (Leasing and Renewal)

Vault'un ürettiği tüm dinamik gizli bilgiler, bir "kira süresi" (lease) ile gelir. Bu, bir gizli bilginin belirli bir süre boyunca geçerli olacağı anlamına gelir. Süre dolmadan önce uygulamalar, kimlik bilgilerini Vault aracılığıyla yenileyebilir veya süre dolduğunda otomatik olarak iptal edilmelerine izin verebilir. Bu mekanizma, bir gizli bilginin sızması durumunda bile etki alanını ve süresini sınırlar.

Vault Politikaları (Access Control Lists - ACLs)

Vault'a kimlik doğrulayan her istemciye (kullanıcı veya uygulama), Vault kaynaklarına erişim yetkilerini belirleyen bir veya daha fazla politika atanır. Politikalar, HCL (HashiCorp Configuration Language) veya JSON formatında yazılır ve belirli yollar üzerindeki (path) "read", "create", "update", "delete", "list", "sudo" gibi yetenekleri tanımlar.

path "secret/data/my-app/*" {  capabilities = ["read"]}path "aws/creds/s3-reader" {  capabilities = ["read"]}

Bu politika, secret/data/my-app yolundaki tüm gizli bilgilere ve aws/creds/s3-reader yolundaki dinamik AWS kimlik bilgilerine yalnızca okuma yetkisi verir.

Sonuç

HashiCorp Vault, kurumsal düzeyde gizli bilgi yönetimi için esnek, güvenli ve ölçeklenebilir bir platform sunar. Dinamik kimlik bilgileri, sıkı erişim kontrolü, denetlenebilirlik ve çeşitli entegrasyon yetenekleri sayesinde Vault, modern DevOps ve güvenlik pratiklerinin vazgeçilmez bir parçası haline gelmiştir. Statik sır bağımlılığını ortadan kaldırarak ve otomatik rotasyon sağlayarak, organizasyonların güvenlik risklerini azaltmasına ve uyumluluk gereksinimlerini karşılamasına yardımcı olur.