Kısa ömürlü SPIFFE/SPIRE SVID’lerinin node bütünlüğüne neden bağımlı olduğunu, laboratuvarda gösterilen cgroup taklidinin kapsamını ve etkiyi sınırlayan Kubernetes kontrollerini açıklar.
SPIFFE, hizmetlere SVID adı verilen kısa ömürlü kriptografik kimlik belgeleri sağlar. İş yükleri bu belgeleri TLS bağlantısı kurmak veya JWT token imzalamak ve doğrulamak için kullanabilir. Resmî SPIFFE genel bakışı bu modeli tanımlar.
Kimlik kararı nerede oluşuyor?
SPIRE, SVID üretmek için node ve iş yükü doğrulaması (attestation) yapar. İş yükü doğrulaması sırasında SPIRE aracısı, sürecin özelliklerini yerel işletim sistemi çekirdeği veya aynı node’daki kubelet gibi kaynaklardan belirler. Ardından bu özellikleri kayıt girdisindeki selector koşullarıyla karşılaştırır. Başarılı bir eşleşme sürece hangi SPIFFE ID’nin verileceğini belirler. Mekanizmanın ayrıntıları SPIRE kavramları belgesinde yer alır.
Laboratuvar bulgusunun kapsamı
Bu mekanizmada SVID’nin kriptografik olarak geçerli olması ile doğru sürece verilmesi farklı konulardır. Unit 42’nin laboratuvar araştırması, Kubernetes node’unda önceden root erişimi bulunan bir saldırganın Linux cgroup bilgisini taklit ederek SPIRE aracısını yanıltabildiğini ve aynı node’daki başka bir iş yüküne ait geçerli bir SVID alabildiğini gösterdi. Teknik akış Unit 42 araştırmasında açıklanıyor.
Unit 42, bu tekniğin gerçek saldırılarda kullanıldığını gözlemlemediğini açıkça belirtiyor. Dolayısıyla bulgu aktif sömürü kanıtı olmayıp root erişimi node güvenini bozduktan sonra ortaya çıkan erişim sonrası bir riski gösteriyor.
Node riski için savunma modeli
Node ele geçirilmesi, savunma planlamasında o node kapsamındaki tüm iş yükü kimliklerinin ele geçirilmesiyle eşdeğer kabul edilmelidir. Unit 42’nin önerileri, ayrıcalıklı konteynerleri ve ana sisteme doğrudan erişimi sınırlandırmayı, zayıf veya kolay taklit edilebilen selector’lara bağımlılığı azaltmayı içeriyor. Bu kapsam otomatik olarak tüm kümeyi (cluster) değil, ele geçirilen node’u ifade etmektedir.
Pod ve node yetkilerini azaltmak
Kubernetes Pod Security Standards içindeki Restricted profili ayrıcalıklı podların engellenmesini, ayrıcalık yükseltmenin kapatılmasını ve konteynerlerin root olmayan kullanıcılarla çalıştırılmasını öngörmektedir. Resmi güvenlik kontrol listesi de seccomp’ın konteyner'ların erişebildiği Linux çekirdeği sistem çağrısı yüzeyini azaltabileceğini belirtir. Ayrıntılar Pod Security Standards ile Kubernetes güvenlik kontrol listesinde bulunmaktadır.
Selector koşullarını güven sınırının parçası saymak
Selector’lar yalnızca eşleştirme ayrıntıları değildir. Doğrulama kararında hangi yerel özelliklerin dikkate alınacağını da belirler. Bu nedenle incelemede koşulun hangi işletim sistemi veya kubelet verisine dayandığı ve root erişimi altında bu verinin taklit edilip edilemeyeceği değerlendirmelidir. Amaç, geniş veya zayıf koşullar yerine iş yüklerini daha dar ayıran selector’lara dayanılmasıdır.
Hassasiyet düzeylerini ve ek kimlik bilgilerini ayırmak
Kubernetes ayrıca farklı hassasiyet düzeyindeki iş yüklerinin ayrı node’lara yerleştirilmesini ve ihtiyaç duymayan pod’lara servis hesabı token’ı bağlanmamasını önerir. Her iki kontrol de resmî güvenlik kontrol listesinde açıklanmaktadır.
Node ayrımı, bir konteyner kaçışından sonra daha hassas uygulamalara doğrudan geçişi zorlaştırmayı amaçlar. Servis hesabı token’ını bağlamamak ise SVID’den ayrı gereksiz bir kimlik bilgisinin pod içinde bulunmasını önler.
Pratik inceleme sırası
Bu güven sınırı, yapılandırma ile iş yükü yerleşimini birlikte ele alan kısa bir inceleme sırasına dönüştürülebilir:
1. Kimlik kapsamı
Her node’un kapsamına hangi SPIFFE ID’leri giriyor ve o node’da hangi hassasiyet düzeyleri birlikte çalışıyor?2. Doğrulama girdileri
Selector’lar hangi işletim sistemi veya kubelet verilerine dayanıyor ve root erişimi bu verileri taklit edebilir mi?3. Node yetkileri
Hangi pod’lar ayrıcalıklı çalışıyor, ana sisteme erişiyor, ayrıcalık yükseltebiliyor veya root kullanıcıyla çalışıyor?4. Ek kimlik bilgileri
Hangi pod’lara ihtiyaç duymadıkları halde servis hesabı token’ı bağlanıyor?
Sonuç, SVID’lerin etkisiz olduğu değildir. Sağladıkları kriptografik kimlik güvencesi, doğrulamanın gerçekleştiği node’un bütünlüğüyle birlikte değerlendirilmelidir. Dayanıklı bir model için kısa ömürlü iş yükü kimliğini pod hardening, dar selector koşulları, hassasiyete göre node ayrımı ve gereksiz kimlik bilgilerinin kaldırılması gerekecektir.
