Kubernetes tarafında en çok yanlış anlaşılan konulardan biri “Secret” kavramıdır. Secret nesnesi; şifrelenmiş bir kasa değil, çoğu kurulumda base64 kodlu bir veridir. Bu veri ETCD’de düz metin olarak (encoding haricinde) duruyorsa, kontrol düzlemi ele geçirildiğinde veya ETCD snapshot’ı sızdığında problem büyür.
Bu yazıda iki hedef var:
- Encryption at Rest ile ETCD’deki hassas veriyi şifrelemek
- Bu şifrelemeyi “dosyaya anahtar koymak” yerine KMS ile operasyona uygun hale getirmek
Sorun: Secret’lar nerede duruyor, kim okuyabilir?
Risk yüzeyi genelde üç kanaldan gelir:
- ETCD erişimi (disk/snapshot/backup)
- Control-plane node ele geçirilmesi (encryption config + cert/key erişimi)
- Yedekleme zinciri (S3 bucket, repo, backup agent)
Encryption at rest, ilk iki riski “sıfırlamaz”; ama ETCD verisini tek başına “okunabilir” olmaktan çıkarır.
Kubernetes Encryption at Rest: Mantık (kısa)
Kubernetes, belirli kaynak türlerini (örn. secrets, configmaps) ETCD’ye yazmadan önce şifreleyebilir. Temel parça:
EncryptionConfigurationdosyası- API Server’ın bu dosyayı kullanarak write path’te şifreleme uygulaması
Bu modelde kritik gerçek:
- Şifreleme, yazım sırasında olur.
- Daha önce yazılmış objeler, özel bir süreçle yeniden yazılmadıkça eski formatta kalabilir.
KMS neden şart?
Statik anahtarlar (dosyada duran AES anahtarı) kısa vadede hızlıdır ama kurumsal operasyon için zayıftır:
- Anahtar rotasyonu zor
- Erişim denetimi ve audit zayıf
- “Kim, ne zaman anahtarı kullandı?” sorusuna net cevap yok
KMS ile hedef:
- Anahtar yaşam döngüsünü merkezi yönetmek
- Kullanımı audit etmek
- Rotasyonu “planlı bakım” ritmine oturtmak
Tasarım: KMS entegrasyonunu nasıl “operasyonel” kılarsın?
1) Yüksek erişilebilir KMS endpoint’i
KMS erişilemezse API Server write path etkilenir. Bu yüzden:
- En az iki endpoint (veya HA servis) düşünün
- Timeout/retry davranışlarını ölçün
- KMS’in bakım pencerelerini platform bakım takvimine bağlayın
2) Hata modunu baştan kararlaştır
Üç tip yaklaşım görülür:
- Fail-closed: KMS yoksa yazma yok (güvenlik yüksek, operasyon riski yüksek)
- Fail-open: KMS yoksa şifresiz yaz (operasyon kolay, risk yüksek)
- Kontrollü degradasyon: sadece belirli kaynaklarda fail-closed
Kurumsal pratikte en gerçekçi model:
secretsiçin fail-closed (ama HA ve runbook şart)- daha düşük riskli kaynaklarda kontrollü tolerans
3) Anahtar rotasyonu: “planlı ve ölçümlü”
Rotasyon hedefi:
- Yeni yazılan veriler yeni anahtarla şifrelensin
- Eski veriler zaman içinde güvenli biçimde yeniden şifrelensin
Operasyon önerisi:
- Rotasyon öncesi: API latency ve error budget trendini kontrol et
- Canary: tek cluster/segmentte anahtar sırasını değiştir
- Yayılım: kademeli restart / kontrollü rollout
- Post-rotasyon: yeniden şifreleme işini “taksitli” yap
Minimum viable runbook: KMS sorunu yaşarsan
Belirti:
- API Server 5xx / write timeouts
secretscreate/update problemleri
Triage soruları:
- KMS endpoint erişilebilir mi? (network/DNS/MTLS)
- KMS latency artmış mı? (throttling / quota)
- API Server log’larında KMS plugin hatası var mı?
İlk müdahale:
- KMS endpoint’ini sağlığa döndür (en iyi çözüm)
- Eğer incident büyüyorsa ve risk kabul ediliyorsa: önceden yazılmış break-glass planına göre encryption config’i “geçici” sadeleştir
Gözlem: Şifreleme varsa bile kör kalma
Bu tasarımın sağlıklı çalışması için izlenecek sinyaller:
- API server latency (özellikle write path)
- KMS request rate + latency + error oranı
- ETCD backup/snapshot hattında “şifreli veri” beklentisi
- Anahtar rotasyon tarihleri ve erişim audit’leri
Sonuç
Kubernetes’te encryption at rest, “compliance checkbox” değil; control-plane riskini azaltan ciddi bir mimari karardır. Ama tek başına yetmez: KMS erişilebilirliği, rotasyon ritmi, failover ve break-glass runbook’u yoksa, güvenlik kazanımı operasyonel kırılganlığa dönüşür. Doğru tasarım; güvenliği platform davranışı haline getirir, incident anında sürpriz çıkarmaz.