Kubernetes kümelerinde uygulamalar çoğu zaman veritabanlarına, mesaj kuyruklarına ve diğer mikroservislere API anahtarı, parola veya uzun ömürlü TLS sertifikasıyla bağlanır. Bu sırların Kubernetes Secret içinde tutulması onları düz metin yapılandırma dosyasından daha düzenli yönetir; ancak temel sorunu ortadan kaldırmaz. Bir sır kopyalanabilir, yanlış namespace'e açılabilir, günlük çıktısına düşebilir veya süresi dolmadan saldırgan tarafından kullanılabilir.

SPIFFE ve SPIRE, servisin kimliğini saklanan bir parolaya değil çalıştığı ortama ve doğrulanabilen özelliklerine bağlar. Kubernetes pod'u, yerel SPIRE Agent üzerinden kısa ömürlü bir kimlik belgesi alır. Uygulama bu belgeyi karşı tarafa sunar; iki servis birbirini kriptografik olarak doğrulayabilir ve mTLS bağlantısı kurabilir. Kalıcı özel anahtarın container imajına veya Secret nesnesine yerleştirilmesi gerekmez.

Bu rehberde SPIFFE ID, trust domain, X.509-SVID ve Workload API kavramlarını açıklayacak; SPIRE mimarisini inceleyecek ve Kubernetes üzerinde güvenli bir başlangıç kurulumu için uygulanabilir adımları göstereceğiz.

1. Workload Identity Nedir?

Workload identity, insan kullanıcı yerine çalışan yazılım bileşenine verilen doğrulanabilir kimliktir. Buradaki workload; bir Kubernetes pod'u, container, sanal makine içindeki işlem veya belirli amaçla çalışan başka bir servis olabilir.

Geleneksel modelde uygulama kendisini bir parola ya da API anahtarıyla tanıtır. Bu bilgiye erişen başka bir süreç de aynı kimliğe bürünebilir. Workload identity modelinde ise kimlik verme kararı pod'un namespace'i, service account'u, imaj bilgisi veya node özellikleri gibi doğrulanmış seçicilere dayanır.


  • Kimlik: Servisin kim olduğunu belirtir.
  • Attestation: Kimlik isteyen node veya workload'un iddia ettiği varlık olduğunu doğrular.
  • Yetkilendirme: Doğrulanmış kimliğin hangi kaynağa erişebileceğini belirler.
  • Kısa ömürlü belge: Kimliği X.509 sertifikası veya JWT biçiminde taşır ve düzenli olarak yenilenir.



Kimlik doğrulama ile yetkilendirmeyi ayırmak önemlidir. SPIFFE bir workload'un kimliğini standartlaştırır; bu kimliğin hangi API metoduna erişeceğine servis, proxy veya politika motoru karar verir.

2. SPIFFE ID, Trust Domain ve SVID

SPIFFE, dinamik ve heterojen ortamlarda yazılım sistemlerini tanımlamak için açık standartlar sunar. Temel kimlik bir URI biçimindedir:

CODE TERMINAL
spiffe://trsiber.local/ns/production/sa/payment-api


Bu değerde trsiber.local trust domain, devamındaki yol ise workload kimliğidir. Trust domain, kimlikleri imzalayan güven kökünün ve yönetim sınırının adıdır. DNS adı gibi görünse de mutlaka internette çözümlenen bir alan adı olmak zorunda değildir; kuruluş genelinde benzersiz ve istikrarlı seçilmelidir.

SVID (SPIFFE Verifiable Identity Document), workload'un SPIFFE ID'sini kriptografik olarak kanıtlamasını sağlayan belgedir. Uygulamada en sık iki biçim kullanılır:


  • X.509-SVID: SPIFFE ID sertifikanın URI SAN alanında taşınır. mTLS için doğal tercihtir ve proof-of-possession sağlar.
  • JWT-SVID: HTTP tabanlı veya sertifika kullanamayan entegrasyonlarda yararlı olabilir. Bearer token olduğu için ele geçirilme ve replay riskine karşı hedef kitle kontrolü yapılmalıdır.



SPIFFE belgeleri mümkün olduğunda X.509-SVID kullanılmasını önerir. Bunun nedeni özel anahtarın bağlantı sırasında sahiplik kanıtı sağlaması; JWT'nin ise ele geçirildiğinde geçerlilik süresi boyunca yeniden oynatılabilmesidir.

3. SPIRE Mimarisi Nasıl Çalışır?

SPIRE, SPIFFE standartlarının üretime hazır referans uygulamasıdır. Kubernetes kurulumunda üç temel akış bulunur:


  • SPIRE Server: Trust domain'in imzalama otoritesidir; kimlik kayıtlarını ve attestation politikalarını yönetir.
  • SPIRE Agent: Her Kubernetes node'unda DaemonSet olarak çalışır, node kimliğini kanıtlar ve yerel Workload API soketini sunar.
  • Workload API: Pod'ların hak kazandıkları SVID ve trust bundle'ları yerel Unix domain socket üzerinden almasını sağlar.



Bir pod Workload API'ye bağlandığında doğrudan parola göndermez. Agent, çağıran süreci işletim sistemi ve Kubernetes bağlamından tanır; namespace ve service account gibi seçicileri kayıt politikalarıyla karşılaştırır. Eşleşme varsa ilgili SPIFFE ID için kısa ömürlü SVID verir.

Bu yaklaşımda Workload API soketi kritik bir güven sınırıdır. Soketi bütün pod'lara gelişigüzel bağlamak veya hostPath izinlerini genişletmek, başka workload'ların kimlik belgelerine erişme riskini doğurabilir. CSI Driver gibi desteklenen dağıtım yöntemleri ve en az ayrıcalıklı erişim kullanılmalıdır.

4. Kubernetes Üzerinde SPIRE Kurulumuna Hazırlık

Üretim kurulumu öncesinde ayrı bir test kümesi veya namespace kullanın. Yönetici erişimine sahip kubectl ve Helm istemcileri gerekir. Bu makale hazırlanırken SPIFFE'nin desteklenen Kubernetes dağıtım yöntemi hardened Helm chart deposudur.

Önce depo eklenir:

CODE TERMINAL
helm repo add spiffe https://spiffe.github.io/helm-charts-hardened/
helm repo update
helm search repo spiffe


Kuruluma geçmeden önce chart değerlerini dosyaya çıkarıp sürüm kontrolünde incelemek güvenli bir pratiktir:

CODE TERMINAL
helm show values spiffe/spire > spire-values-reference.yaml
helm show chart spiffe/spire


Chart sürümünü üretimde sabitleyin. Test edilmemiş yeni bir chart'ın otomatik olarak devreye alınması, kimlik altyapısında beklenmeyen değişikliklere yol açabilir.

5. Güvenli Başlangıç Yapılandırması

Aşağıdaki minimal değer dosyası bir başlangıç örneğidir. Gerçek alan adını, cluster adını, depolama ve yüksek erişilebilirlik seçeneklerini kendi ortamınıza göre belirleyin:

CODE TERMINAL
global:
  spire:
    trustDomain: trsiber.local
    clusterName: production-cluster

spire-server:
  controllerManager:
    identities:
      clusterSPIFFEIDs:
        default:
          enabled: true


Hardened chart, varsayılan olarak pod'lara namespace ve service account bilgisinden türetilen kimlikler verebilir. Ortaya çıkan yapı genel olarak şu biçimdedir:

CODE TERMINAL
spiffe://trsiber.local/ns/production/sa/payment-api


Kurulumu ayrı namespace içinde gerçekleştirin:

CODE TERMINAL
kubectl create namespace spire-system

helm upgrade --install spire spiffe/spire \
  --namespace spire-system \
  --values values.yaml \
  --wait


Bu komut kümede kaynak oluşturur. Önce test ortamında uygulanmalı; chart'ın istediği RBAC izinleri helm template ile incelenmelidir:

CODE TERMINAL
helm template spire spiffe/spire \
  --namespace spire-system \
  --values values.yaml > rendered-spire.yaml


6. Kurulumu ve Kimlik Dağıtımını Doğrulama

Bileşenlerin durumunu kontrol edin:

CODE TERMINAL
kubectl get pods -n spire-system
kubectl get daemonset,statefulset,deployment -n spire-system
kubectl get csidriver


Agent'ın her uygun node'da çalışması, Server bileşenlerinin hazır görünmesi ve CSI Driver'ın kaydedilmesi gerekir. Ardından test workload'unun elde ettiği kimlik, Workload API istemcisi veya SPIFFE uyumlu bir uygulamayla doğrulanmalıdır.

Doğrulamada yalnızca “sertifika geldi” sonucuna bakmayın:


  • URI SAN içindeki SPIFFE ID beklenen namespace ve service account'u gösteriyor mu?
  • Sertifikanın issuer bilgisi doğru trust domain'e ait mi?
  • Geçerlilik süresi kurum politikasına uygun ve kısa mı?
  • Pod yeniden oluşturulduğunda kimlik yenileniyor mu?
  • Yetkisiz service account aynı SVID'yi alamıyor mu?



7. X.509-SVID ile Otomatik mTLS

mTLS bağlantısında iki taraf da sertifika sunar. İstemci sunucunun, sunucu da istemcinin kimliğini doğrular. SPIFFE uyumlu uygulama veya sidecar/proxy, Workload API akışını açık tutarak yeni X.509-SVID geldiğinde sertifikayı kesinti oluşturmadan değiştirebilir.

Yetkilendirme politikası DNS adına veya pod IP'sine değil SPIFFE ID'ye bağlanabilir:

CODE TERMINAL
ALLOW spiffe://trsiber.local/ns/frontend/sa/web
TO    spiffe://trsiber.local/ns/backend/sa/payment-api
PORT  8443


Bu örnek kavramsal bir politikadır. Uygulama içinde SPIFFE kütüphanesi, Envoy SDS entegrasyonu veya desteklenen bir service mesh kullanılabilir. Önemli olan sertifikayı dosyaya bir kez yazıp unutmak değil, Workload API'nin yenileme akışını sürekli izlemektir.

8. Sertifika Rotasyonu ve Kesinti Senaryoları

Kısa ömürlü SVID'ler çalınan kimliğin kullanılabileceği pencereyi daraltır; fakat SPIRE altyapısının kullanılabilirliği için planlama gerektirir. Agent mevcut SVID'leri önbelleğe alabilir, ancak uzun süreli Server veya Agent kesintisi sonunda workload kimlik yenileyemez.


  • SVID TTL değerini yalnızca “en kısa daha güvenlidir” düşüncesiyle belirlemeyin; yenileme sıklığı ve arıza giderme süresini birlikte değerlendirin.
  • SPIRE Server veritabanını ve upstream CA entegrasyonunu yedekleyin.
  • Root ve intermediate anahtar rotasyonunu önce test trust domain'inde deneyin.
  • Agent ve Server zaman senkronizasyonunu izleyin; saat sapması sertifika doğrulamasını bozabilir.
  • SVID yenileme hataları, attestation başarısızlıkları ve bundle güncellemeleri için alarm üretin.



9. Federation Ne Zaman Gerekir?

Birden fazla trust domain birbirinin workload kimliklerini doğrulayacaksa SPIFFE Federation kullanılabilir. Federation, bir domain'in imzalama özel anahtarını diğer kümeye taşımaz; doğrulama için gereken trust bundle'ların güvenli biçimde paylaşılmasını sağlar.

Federasyon özellikle farklı ekiplerin yönettiği kümelerde ve şirketler arası servis iletişiminde değerlidir. Buna karşılık her kümeye ayrı trust domain vermek zorunlu değildir. Yönetim, güven kökü ve olay müdahalesi sınırları aynıysa ortak domain daha sade olabilir. Trust domain tasarımı ağ topolojisine değil güven ve idari sınırlara göre yapılmalıdır.

10. Sık Yapılan Güvenlik Hataları


  • Service account'u paylaşmak: Birçok uygulamayı default service account ile çalıştırmak kimlik ayrımını ortadan kaldırır.
  • Aşırı geniş seçiciler: Yalnızca namespace'e göre kimlik vermek, o namespace'teki bütün workload'ları aynı yetkiye yaklaştırabilir.
  • JWT audience kontrolünü atlamak: JWT-SVID doğrulamasında hedef kitle doğrulanmazsa token farklı bir serviste yeniden kullanılabilir.
  • Workload API soketini herkese açmak: Soket erişimi workload sınırlarıyla birlikte tasarlanmalıdır.
  • SPIFFE ID'yi yetki sanmak: Geçerli kimlik, bütün kaynaklara erişim hakkı anlamına gelmez; ayrıca allowlist veya politika gerekir.
  • Uzun TTL kullanmak: Operasyon kolaylığı için günlerce geçerli belge vermek, kısa ömürlü kimlik modelinin avantajını azaltır.
  • Sertifika konusunu loglamak: Özel anahtar, SVID veya JWT'nin hata ayıklama loglarına düşmediğinden emin olun.



11. Üretim Kontrol Listesi


  • Her uygulama için ayrı Kubernetes service account kullanın.
  • Trust domain ve SPIFFE ID adlandırma standardını yazılı hâle getirin.
  • Chart ve container imaj sürümlerini sabitleyin.
  • RBAC, Pod Security ve NetworkPolicy kurallarını en az ayrıcalıkla sınırlandırın.
  • SPIRE Server için yüksek erişilebilirlik ve kalıcı datastore tasarlayın.
  • Upstream CA anahtarlarını HSM veya yönetilen KMS ile korumayı değerlendirin.
  • SVID yaşam döngüsü, attestation ve bundle metriklerini merkezi olarak izleyin.
  • Yetkisiz namespace ve service account'larla negatif testler yapın.
  • Federation endpoint'lerini yalnızca gerekli domain'lere açın.
  • Acil durumda kimlik kaydını iptal etme ve trust bundle döndürme prosedürünü test edin.



Sonuç

SPIFFE ve SPIRE, Kubernetes servis kimliğini kalıcı parolalardan ve elle dağıtılan sertifikalardan ayırır. Workload; çalıştığı node, namespace ve service account gibi doğrulanmış özellikler üzerinden kimlik kazanır. Kısa ömürlü X.509-SVID'ler otomatik yenilenerek mTLS bağlantılarında kullanılabilir.

Bu mimari tek başına bütün Zero Trust gereksinimlerini karşılamaz. Sağlam bir kurulum; dar kapsamlı seçiciler, ayrı service account'lar, açık yetkilendirme politikaları, güvenli Workload API erişimi ve izlenen sertifika rotasyonuyla tamamlanmalıdır. Küçük bir test trust domain'iyle başlayıp negatif erişim testlerini başarıyla geçirdikten sonra üretim servislerini aşamalı taşımak en güvenli yaklaşımdır.

Resmî Kaynaklar

TR Siber Ekibi Yazar · X
Kaynak bağlantısı ← Ana sayfaya dön