Kurum içinde servisler büyüdükçe şu güven modeli kırılır: “Bu IP bizim, o yüzden güven.” IP değişir, NAT girer, mesh gelir, pod ölür doğar… ve siz hâlâ ACL yazarsınız. Modern yaklaşım: güveni workload kimliğine bağlamak.
SPIFFE bu kimliği standartlaştırır, SPIRE ise onu otomatik sertifika üretimi ve rotasyon ile hayata geçirir.
1) Hedef: “kim konuşuyor?” sorusunu cevaplamak
SPIFFE dünyasında kimlik şuna benzer:
spiffe://example.org/ns/payments/sa/api
Bu kimlik:
- IP’ye değil, workload’a aittir
- Sertifika kısa ömürlüdür (dakikalar/saatler)
- Rotasyon otomatik olmalıdır
2) Minimum bileşenler
Kubernetes için tipik kurulum:
- SPIRE Server: CA/kimlik otoritesi + kayıtlar (registration)
- SPIRE Agent: node üzerinde çalışır, workload’lara SVID dağıtır
- Workload attestation: pod/SA/namespace selector’ları ile “bu kimliği şu workload alır” kuralı
3) Kurulum iskeleti (Kubernetes)
Aşağıdaki adımlar “referans iskelet”tir; kendi dağıtım standardınıza göre uyarlayın.
3.1 Trust domain seçimi
- Kurum için tek bir trust domain seçin:
spiffe://corp.example - Ortam ayrımı gerekiyorsa alt domain veya ayrı server düşünün (prod/stage ayrımı net olmalı).
3.2 SPIRE Server/Agent kurulum
Kurulum yöntemleri değişebilir (Helm/manifest). Kritik olanlar:
- Server state’i için dayanıklı storage (persist)
- Agent’ın node üzerinde güvenli çalışması (privileged gerekebilir, minimize edin)
- Server ↔ Agent arasında bootstrap güveni (node attestation)
3.3 Workload kaydı (registration entry)
Mantık: “Şu selector’lar eşleşirse şu SPIFFE ID ver.”
Örnek yaklaşım:
- Namespace:
payments - ServiceAccount:
api - SPIFFE ID:
spiffe://corp.example/ns/payments/sa/api
4) Uygulama entegrasyonu: 2 pratik yol
4.1 Sidecar/proxy üzerinden mTLS (en pratik)
Envoy gibi bir proxy, SVID’i SPIRE Agent’tan alır ve outbound/inbound mTLS’i uygular.
Avantaj:
- Uygulama koduna minimum dokunuş
Risk:
- Proxy doğru “kimlik doğrulama” yapmazsa, mTLS sadece şifreleme olur.
4.2 Uygulama içinde mTLS (kontrollü ama maliyetli)
Uygulama doğrudan SVID’i alır ve TLS stack’ine verir.
Avantaj:
- Tam kontrol
Risk:
- Dil/SDK çeşitliliği ve bakım maliyeti
5) Operasyon: rotasyon, revocation, gözlemlenebilirlik
Minimum operasyon checklist’i:
- SVID TTL: kısa ama gerçekçi (ör. 1 saat)
- Rotasyon: kesintisiz (yenileme penceresi)
- Loglar: mTLS handshake başarısızlık nedenleri (SAN, SPIFFE ID, expiry)
- Metrikler: issued cert sayısı, failed attestation, agent bağlantı hatası
- Denetim: kim, hangi selector ile hangi kimliği aldı?
6) Sık yapılan hata: kimliği “çok esnek” tanımlamak
Selector’ları gevşek tutarsanız:
- Yanlış workload yanlış kimliği alır
- Lateral movement kolaylaşır
- Incident sonrası forensics zorlaşır
Önerim: İlk etapta selector’ları sıkı tutun (namespace + serviceAccount). Sonra ihtiyaç oldukça genişletin.
7) Son söz
SPIFFE/SPIRE ile kurulan workload identity, “sertifika otomasyonu”ndan daha büyüktür: kuruma servis kimliği ve güven modeli kazandırır. IP’nin değiştiği, altyapının hareketli olduğu dünyada kalıcı olan tek şey kimliktir. Bu yüzden güveni kimliğe taşıyın; rotasyonu otomatikleştirin; gözlemlenebilirliği en baştan kurun.