« Tüm yayınlar

Kubernetes'te Sıfır Güven Kimliği: SPIFFE, SPIRE, Cilium

Kubernetes'te IP tabanlı ağ politikaları neden güvensizdir? SPIFFE, SPIRE ve Cilium ile kriptografik workload kimliği ve mTLS uygulamasını ele alıyoruz.

Kubernetes'te pod IP adresleri sürekli değişir; rolling deployment, node drain veya autoscaler olayları bir pod'un IP'sini anında farklı bir workload'a devredebilir. IP adresine veya etiket eşleşmesine dayanan NetworkPolicy kuralları bu nedenle sahte güvenlik hissi verir, çünkü doğruladıkları şey kimlik değil konumdur. Gerçek çözüm, servislerin veri alışverişinden önce birbirini kriptografik olarak doğrulamasıdır; yani karşılıklı TLS (mTLS).

Bu ihtiyacı karşılayan model SPIFFE (CNCF standardı) ve onun referans uygulaması SPIRE'dır. SPIFFE, her workload'a trust domain ve yola dayalı bir URI kimliği (spiffe://) tanımlar; bu kimlik X.509 veya JWT formatında bir SVID (doğrulanabilir kimlik belgesi) olarak somutlaşır. SPIRE Server merkezi CA görevi görür ve hangi workload'a hangi SPIFFE ID'nin verileceğini tutan bir kayıt defteri işletirken, her node'da DaemonSet olarak çalışan SPIRE Agent node attestation yapar ve workload'ların kimlik talep ettiği Workload API'yi Unix soket üzerinden sunar.

Cilium, bu SPIRE altyapısını eBPF üzerinden kullanarak her pod'a sidecar enjekte etmeden mTLS zorunluluğu getirebiliyor. CiliumNetworkPolicy tanımlarıyla iki servis arasındaki trafiğin yalnızca geçerli, SPIRE tarafından imzalanmış bir sertifika sunulduğunda akmasına izin verilebiliyor; sertifika eşleşmezse bağlantı IP adresinden bağımsız olarak reddediliyor.

Mühendisler için önemi açık: pod'lar yeniden zamanlandıkça veya ölçeklendikçe güvenlik duruşu sessizce zayıflamıyor, çünkü politika artık konuma değil kriptografik kimliğe dayanıyor. Bu yaklaşım mevcut RBAC ve sertifika yönetimi pratiklerini tamamlayan, uygulama koduna dokunmadan uygulanabilen bir zero-trust katmanı sunuyor.

» KaynakHashnode #12