Terraform Ephemeral Resource'ları Vault Secret'larını State ve Git'in Dışında Tutuyor

Oleksandr Kuryzhev'in dev.to'da yayımlanan, aslında kuryzhev.cloud blogunda önceden yayınlanmış bir rehberi, Terraform'da bir veritabanı parolasına ihtiyaç duyan ekipler için çalışan bir deseni ortaya koyuyor: parolayı HashiCorp Vault'ta tutmak, apply anında çekmek ve depoya ya da state dosyasına hiçbir hassas bilginin sızmasını engellemek.

State dosyası sızıntının kaynağı

Makale tanıdık bir kısayolla başlıyor: biri terraform.tfvars dosyasını bir CI değişkenine yapıştırıyor. Geleneksel alternatif olan vault_kv_secret_v2 data source'unun, yazarın HashiCorp bunu belgelediği için özellikle vurguladığı bir kusuru var: bir data source üzerinden okunan her değer Terraform state'e düz metin olarak yazılıyor. Bir değişkeni sensitive olarak işaretlemek yalnızca CLI çıktısında gizler; değerin kendisi yine de state'i tutan backend'e gidiyor.

Ephemeral değerler boşluğu kapatıyor

Rehbere göre daha yeni Terraform ve Vault provider sürümleri bunu iki özellikle çözüyor: Terraform 1.10'dan itibaren kullanılabilen ephemeral resource'lar ve 1.11 gerektiren write-only argümanlar. Bir ephemeral vault_kv_secret_v2 bloğu, secret'ı planlama ve apply sırasında çekiyor ama değeri hiçbir yere kaydetmiyor. Terraform ayrıca ephemeral değerlere normal attribute'lardan yapılan referansları doğrulama aşamasında reddediyor; böylece bir yanlış yapılandırma sessiz bir sızıntı yerine hata haline geliyor.

Write-only argümanlar desenin karşı ucunu oluşturuyor: değer provider'ın API çağrısına iletiliyor ama hem plan hem de state dosyalarından çıkarılıyor. Örnekte ephemeral secret, bir AWS veritabanı instance'ındaki password_wo argümanına bağlanıyor. Terraform artık değeri saklamadığı için Vault'ta secret değiştiğinde bunu fark edemiyor; bu yüzden örnekteki password_wo_version gibi bir yardımcı argümanın, güncellemeyi zorlamak için elle artırılması gerekiyor.

Benimsenmeden önce ön koşullar kontrol edilmeli: Vault provider'ı ephemeral resource'u içeren bir sürüm olmalı (makale 5.x hattını sabitlemeyi ve changelog'daki minimum sürümü doğrulamayı öneriyor) ve hedef resource gerçekten bir write-only argüman sunmalı; provider'lar bunu yavaş yavaş ekliyor.

Kurulum tuzakları

İki hata modu öne çıkıyor. Birincisi, Vault provider'ı varsayılan olarak bir child token istiyor; bu da auth/token/create üzerinde izin gerektiriyor. Sıkı kapsamlı bir CI politikası, bu yetenek verilmedikçe ya da skip_child_token ayarlanmadıkça 403 hatasıyla başarısız olur. İkincisi, KV v2 politikaları CLI tarzı yol yerine secret/data/... hedeflemeli; secret/app/db'ye kapsamlı bir politika doğru görünse de yine permission denied hatası veriyor.

Kimlik doğrulama için rehber, uzun ömürlü bir root token yerine CI için AppRole veya JWT/OIDC kullanılmasını, sızan bir kimlik bilgisinin çabuk ölmesi için kısa token TTL'leri öneriyor. Erişimi kısıtlı, şifreli bir remote state backend her kurulum varyantında temel gereklilik olmaya devam ediyor.

Write-only kullanılamadığında yedek yöntem

Henüz her resource write-only argümanları desteklemiyor. Data source'un kaçınılmaz olduğu durumlarda makalenin tavsiyesi, state dosyasının secret'ı içerdiğini varsayıp buna göre korumak: şifreli remote backend, okuma erişiminin yalnızca secret'ı görmeye yetkili kişilerle sınırlandırılması ve backend bir S3 ya da G3 bucket olduğunda versioning ile erişim loglama. Vault'un veritabanı ve AWS engine'lerinden gelen dinamik secret'lar bu durumda tercih edilen seçenek; çünkü bir şekilde yakalanan değer, kısa TTL'si dolduğunda işe yaramaz hale geliyor. Yazıda ayrıca, Terraform'un secret'ın değerini kendisi yönettiği durumlar için son provider sürümlerinin write-only bir data_json_wo argümanı eklediği belirtiliyor.

Deseni doğrulama

Rehberdeki test sırası şöyle işliyor: politika, data yoluna karşı vault token capabilities ile doğrulanıyor; terraform validate ve bir plan çalıştırılıyor — bu sırada normal bir attribute'tan gelen geçersiz referans başarısız oluyor — ardından tek kullanımlık bir secret ile apply yapılıp state ve kayıtlı plan içinde o değer aranıyor. Her iki eşleşmenin de sıfır olması gerekiyor; sıfır olmayan bir sonuç, hâlâ bir data source üzerinden okuma yapıldığını gösterir ve terraform state list suçlu data.vault_kv_secret_v2 girdilerini ortaya çıkarır. Rotasyon, Vault'taki secret değiştirilip sürüm argümanı artırılarak ve planın yerinde (in-place) bir güncelleme gösterdiği kontrol edilerek doğrulanıyor.

Neden önemli

State dosyaları, yönetilen secret'ların bir altyapı ekibinden sızmasının en yaygın yollarından biri: düz metinler, geniş kesimlerce okunabilir oluyor ve dikkat git geçmişine odaklandığında gözden kaçması kolay. Bu desen, secret'ı state'ten tamamen çıkarıyor, gizlemeye çalışmıyor; doğrulama zamanındaki koruma da gerilemeleri otomatik yakalıyor. Henüz Terraform 1.11'de olmayan ya da provider'ları write-only desteğinden yoksun ekipler için şifreli backend'ler, kısıtlı erişim ve dinamik kimlik bilgileri yedek yönergesi pratik bir ara kontrol yöntemi.