HashiCorp Vault: Secrets Management

Modern yazılım geliştirme ve altyapı ortamlarında, şifreler, API anahtarları, veritabanı kimlik bilgileri ve TLS sertifikaları gibi hassas verilerin yönetimi kritik bir güvenlik gereksinimidir. Geleneksel yaklaşımlarda bu bilgiler düz metin olarak .env dosyalarında, Ansible group_vars dizinlerinde veya kod deposundaki configuration dosyalarında saklanır. Bu pratik hızlı bir başlangıç sağlasa da ciddi güvenlik açıklarına yol açar: yanlışlıkla git commit'lenmeler, erişim denetimi yapılamaması, secret rotasyonu zorluğu ve kimlerin neye eriştiğinin takipsizliği.

HashiCorp Vault, bu sorunları merkezi bir secrets management çözümüyle ele alır. Vault; erişim kontrolü, denetim günlüğü, dinamik secret üretimi, otomatik rotasyon ve süreli erişim (TTL) yetenekleri sunan açık kaynaklı bir araçtır. Bu makalede HashiCorp Vault'un kurulumundan production yapılandırmasına, erişim politikalarından dinamik secret üretimine kadar tüm kritik konularını kapsamlı şekilde ele alacağız.

2. Secrets Management Neden Gereklidir

2.1. Düz Metin Secret'ların Riskleri

Geleneksel secrets yönetimi pek çok güvenlik açığı barındırır. İlk ve en kritik risk, hassas bilgilerin yanlışlıkla versiyon kontrol sistemine commit edilmesidir. Bir API anahtarı veya veritabanı şifresi yanlışlıkla public bir GitHub reposuna girdiğinde, bu bilgi kalıcı olarak internette kalır ve otomatik botlar tarafından tarama sonucu keşfedilir. İkinci önemli risk, erişim denetiminin olmamasıdır. Düz metin bir şifre dosyasına erişen herkes — bir ekip üyesi, bir otomasyon scripti veya bir saldırgan — aynı yetkiye sahiptir. Üçüncü risk ise rotasyon zorluğudur. Onlarca servis kullanan bir ortamda, bir veritabanı şifresini değiştirmek tüm ilgili servislerin güncellenmesini gerektirir ve bu süreç hata yapmaya açıktır.

2.2. Vault'un Sunduğu Çözümler

HashiCorp Vault, bu risklerin her birine karşı spesifik çözümler sunar. Merkezi secret deposu olarak tüm hassas bilgileri tek bir noktada toplar ve buradan kontrollü erişim sağlar. Token tabanlı kimlik doğrulama ve path bazlı politikalar ile hangi kullanıcı veya servis hangi secret'a erişebilir sorusu kesin olarak cevaplanır. Denetim günlükleri (audit logs) sayesinde her okuma, yazma ve silme işlemi kaydedilir. Dinamik secret üretimi ile veritabanı ve servis kimlik bilgileri istek üzerine anlık olarak oluşturulur ve TTL sonunda otomatik olarak geçersiz kılınır.

2.3. Geleneksel Yöntemlerle Karşılaştırma

Vault, tek başına birçok görevi yerine getirse de ekosistemi içinde düşünülmelidir. Ansible Vault, tek bir ekibin tek bir repo için dosya şifreleme ihtiyacını karşılar ancak merkezi kontrol, denetim ve dinamik secret üretimi sunmaz. SOPS ve GPG tabanlı şifreleme, git'e şifreli secret commit etmeyi mümkün kılar fakat erişim kontrolü ve rotasyon konularında zayıf kalır. Kubernetes Secrets, namespace bazlı izolasyon sağlar ancak şifreleme varsayılan olarak zayıftır ve dış sistemlerle entegrasyonu sınırlıdır.

3. HashiCorp Vault Mimarisi

3.1. Temel Mimarı Bileşenler

Vault, storage backend, secrets engine, auth method ve audit device bileşenlerinden oluşan bir mimari üzerine kuruludur. Storage backend, encrypted olarak saklanan verilerin fiziksel depolandığı yerdir. Eski nesil tek-node kurulumlarda dosya tabanlı storage yeterli olsa da production ortamlarında Consul, Integrated Raft, PostgreSQL veya AWS S3 gibi dağıtık storage backend'ler tercih edilir.

Secrets engine, farklı türde secret üreten ve yöneten modüler bileşenlerdir. KV (Key-Value), Database, PKI (TLS sertifikası üretimi), SSH, Transit (encryption-as-a-service) ve AWS/Azure/GCP gibi pek çok secrets engine mevcuttur. Auth method, istemcilerin Vault'a kimliklerini kanıtladığı yöntemdir. Token-based, AppRole, LDAP/Active Directory, JWT/OIDC, Kubernetes ve GitHub gibi pek çok yöntem desteklenir.

3.2. Storage Backend Seçimi

Storage backend seçimi, Vault deployment'ının ölçeklenebilirliğini ve dayanıklılığını doğrudan belirler. Integrated Raft, HashiCorp'un kendi dağıtık consensus protokolüdür ve Vault 1.4+ sürümlerinden itibaren varsayılan önerilen storage backend olarak kullanılmaktadır. Raft, ek bir dış bağımlılık gerektirmeden Vault cluster'ı içinde yüksek erişilebilirlik sağlar. Consul, HashiCorp'un kendi service mesh ve storage çözümüdür.

4. Kurulum

4.1. Linux'ta APT ile Kurulum

HashiCorp Vault, Debian ve Ubuntu tabanlı sistemlerde resmi APT repository üzerinden kurulabilir:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install vault -y

GPG anahtarı --dearmor ile işlenerek APT'nin beklediği formatta saklanır. Repository tanımında signed-by direktifi ile bu anahtar dosyası açıkça belirtilir.

4.2. Sistem Gereksinimleri

Vault, hafif bir uygulama olmakla birlikte production ortamlarında belirli kaynak gereksinimlerine ihtiyaç duyar. Minimum kurulum için 2 vCPU ve 4 GB RAM yeterli olsa da audit log'lar, Raft storage ve yüksek erişilebilirlik gereksinimleri göz önünde bulundurulduğunda production ortamları için 2 vCPU ve 8 GB RAM önerilir.

4.3. Dev Mode ve Production Mode

Dev mode, hızlı öğrenme ve geliştirme için tasarlanmıştır. vault server -dev komutuyla başlatılan dev mode, otomatik olarak initialize edilir ve in-memory storage kullanır. Dev mode'da veriler kalıcı değildir. Production mode ise gerçek dünya deployment'ları için tasarlanmıştır ve TLS zorunludur.

5. Production Yapılandırması

5.1. Konfigürasyon Dosyası

storage "raft" {
  path = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/letsencrypt/live/vault.example.com/fullchain.pem"
  tls_key_file  = "/etc/letsencrypt/live/vault.example.com/privkey.pem"
}

api_addr = "https://vault.example.com:8200"
cluster_addr = "https://vault.example.com:8201"
disable_mlock = false
ui = true

disable_mlock = false ayarı, Vault'un memory'sini swap'e yazmamasını sağlar — bu hassas verilerin disk'e clear-text olarak yazılmasını engelleyen önemli bir güvenlik ayarıdır.

5.2. Systemd Servis Dosyası

[Unit]
Description=HashiCorp Vault
Requires=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/vault server -config=/etc/vault.d/vault.hcl
Restart=always
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Servis dosyası oluşturulduktan sonra sudo systemctl enable --now vault komutu ile Vault başlatılır.

5.3. High Availability Yapılandırması

Yüksek erişilebilirlik için Vault cluster'ı kurulabilir. Raft storage ile üç node'dan oluşan bir cluster:

vault operator raft join https://vault-1.example.com:8200
vault operator raft join https://vault-2.example.com:8200
vault operator raft join https://vault-3.example.com:8200

6. Initialization ve Unsealing

6.1. Initialization Süreci

Vault, ilk çalıştırıldığında sealed (mühürlü) durumdadır. Initialization süreci:

vault operator init

Bu komut, 5 adet unseal key ve 1 adet root token üretir. Varsayılan olarak 3/5 threshold uygulanır — yani Vault'u açmak için 5 unseal key'den en az 3'ünün girilmesi gerekir.

6.2. Unseal Süreci

vault operator unseal <key1>
vault operator unseal <key2>
vault operator unseal <key3>

Her unseal key girişinde Vault, kaç key'in daha gerektiğini belirtir. Unseal key'lerin güvenli saklanması kritik öneme sahiptir.

6.3. Auto-Unseal

Production ortamlarında manuel unseal süreci operasyonel yük getirebilir. Auto-unseal bu sorunu, cloud tabanlı Key Management Service (KMS) kullanarak otomatikleştirir:

seal "awskms" {
  region = "eu-central-1"
  kms_key_id = "alias/vault-unseal-key"
}

7. Temel Komutlar ve KV Secrets Engine

7.1. KV Secrets Engine

KV (Key-Value) Secrets Engine, Vault'un en temel ve en yaygın kullanılan secrets engine'idir. Secret yazmak:

vault kv put secret/myapp/database username="appuser" password="GucluSifre123!" host="10.10.10.21" port="3306"

Okuma:

vault kv get secret/myapp/database
vault kv get -field=password secret/myapp/database

7.2. Versionlama ve Geri Alma

KV v2'nin sunduğu en güçlü özelliklerden biri versionlama desteğidir:

vault kv get -version=1 secret/myapp/database
vault kv rollback -version=1 secret/myapp/database

8. Policies ve Erişim Kontrolü

8.1. Policy Yapısı

Vault policies, hangi path'lerin kimler tarafından hangi yetkilerle erişilebileceğini tanımlar:

path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}
path "secret/metadata/myapp/*" {
  capabilities = ["read", "list"]
}

Yetenek listesi: create, read, update, delete, list, deny ve sudo.

8.2. Policy Uygulama

vault policy write myapp-read - 'EOF'
path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}
EOF

vault token create -policy="myapp-read" -ttl=24h

8.3. Sudo Yetkisi

path "auth/token/accessors" {
  capabilities = ["sudo", "list"]
}

9. Authentication Metodları

9.1. Token Authentication

Token, Vault'un varsayılan kimlik doğrulama metodudur:

vault token create -policy="myapp-read" -ttl=8h
vault token lookup <token>
vault token revoke <token>

9.2. AppRole Authentication

AppRole, makineler arası kimlik doğrulama için tasarlanmıştır:

vault write auth/approle/role/myapp-role \
    token_ttl=1h \
    token_policies="myapp-read" \
    secret_id_num_uses=0 \
    secret_id_ttl=1h

ROLE_ID="..."
SECRET_ID="..."
VAULT_TOKEN=$(vault write -field=token auth/approle/login \
    role_id="$ROLE_ID" \
    secret_id="$SECRET_ID")

9.3. Kubernetes Authentication

vault write auth/kubernetes/role/myapp \
    bound_service_account_names=myapp-sa \
    bound_service_account_namespaces=default \
    policies=myapp-read \
    ttl=1h

10. Dynamic Secrets

10.1. Dynamic Secrets Kavramı

Dynamic secrets, Vault'un en güçlü özelliklerinden biridir. Geleneksel (statik) secrets yaklaşımında, bir veritabanı kullanıcı adı ve şifresi önceden oluşturulur ve süresiz olarak geçerlidir. Dynamic secrets yaklaşımında ise Vault, her istekte benzersiz bir veritabanı kullanıcısı ve güvenli bir şifre oluşturur. Bu kimlik bilgisi yalnızca belirtilen TTL süresi boyunca geçerlidir ve süre dolduğunda otomatik olarak veritabanından silinir.

10.2. MySQL için Dynamic Secrets

vault secrets enable database

vault write database/config/myapp-mysql \
    plugin_name=mysql-database-plugin \
    connection_url="{{username}}:{{password}}@tcp(10.10.10.21:3306)/" \
    allowed_roles="readonly" \
    username="vaultadmin" \
    password="VaultAdminSifresi"

vault write database/roles/readonly \
    db_name=myapp-mysql \
    creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON *.* TO '{{name}}'@'%';" \
    default_ttl="1h" \
    max_ttl="24h"

10.3. Dynamic Credential Kullanımı

vault read database/creds/readonly

# Sonuç:
# username: v-token-readonly-xyz789
# password: A1b2C3d4E5f6G7h8I9j0
# lease_duration: 1h

11. Kubernetes Entegrasyonu

11.1. Helm ile Kurulum

helm repo add hashicorp https://helm.releases.hashicorp.com
helm repo update
helm install vault hashicorp/vault -n vault --create-namespace

# Dev mode:
helm install vault hashicorp/vault \
    -n vault \
    --set='server.dev.enabled=true' \
    --set='ui.enabled=true' \
    --set='ui.serviceType=LoadBalancer'

11.2. Production Kubernetes Deployment

helm install vault hashicorp/vault \
    -n vault \
    --set='server.dev.enabled=false' \
    --set='server.ha.enabled=true' \
    --set='server.ha.raft.enabled=true' \
    --set='server.dataStorage.enabled=true' \
    --set='server.dataStorage.size=10Gi'

12. En İyi Uygulamalar

12.1. Güvenlik Best Practices

TLS zorunlu olmalıdır — Vault, network üzerinden plaintext iletişim kabul etmemelidir.
Auto-unseal kullanılmalıdır — manuel unseal, operasyonel risk ve gecikme yaratır.
Unseal key'ler güvenli saklanmalıdır — bir güvenlik kutusu, HSM veya ayrı bir KMS kullanılabilir.
Network erişimi kısıtlanmalıdır — Vault portu (8200) yalnızca yetkili uygulama sunucularına ve VPN aracılığıyla erişime açık olmalıdır.
Audit log'lar etkinleştirilmelidir — her API isteği ve yanıtı loglanmalı ve log'lar ayrı bir güvenli sistemde saklanmalıdır.
Minimum yetki ilkesi uygulanmalıdır — her servis ve kullanıcı yalnızca ihtiyaç duyduğu path'lere erişim sağlamalıdır.

12.2. Operasyonel Best Practices

Düzenli yedekleme yapılmalıdır — storage backend'in snapshot'ları alınmalıdır.
Vault'un yeni sürümleri düzenli olarak takip edilmeli ve güvenlik yamaları hızla uygulanmalıdır.
Policy'ler versiyon kontrolünde tutulmalıdır — Terraform veya Vault HCL dosyaları git reposunda yönetilmelidir.
Monitoring etkinleştirilmelidir — Vault'un /v1/sys/metrics endpoint'i Prometheus'a entegre edilerek izleme sağlanmalıdır.

13. Sonuç ve Sonraki Adımlar

HashiCorp Vault, modern altyapılarda secrets management'ın temel taşı haline gelmiştir. Düz metin secret'ların risklerini ortadan kaldıran, dinamik kimlik bilgisi üretimi ile güvenliği bir üst seviyeye taşıyan ve token tabanlı erişim kontrolü ile denetlenebilirlik sağlayan Vault, DevOps ve güvenlik ekiplerinin vazgeçilmez aracıdır.

HashiCorp Vault öğrenmeye devam etmek için:

Transit secrets engine ile encryption-as-a-service fonksiyonelliğini keşfetmek
PKI secrets engine ile otomatik TLS sertifika üretimi ve rotasyonu yapılandırmak
Terraform Vault provider ile infrastructure kodundan Vault politikalarını yönetmek
Kubernetes Vault entegrasyonunu derinlemesine incelemek

HashiCorp Vault, sadece bir secret deposu değil — tüm altyapınızın güvenlik omurgasını oluşturan kapsamlı bir secrets management platformudur.