Bir konteyner uygulamasının bulut servislerine erişmesi için kimlik kanıtlaması gerekir. IRSA (IAM Roles for Service Accounts) ve genel karşılığı olan iş yükü kimliği, bu kanıtı pod’un Kubernetes service account jetonuyla sağlar; bulut sağlayıcı bu jetonu doğrulayıp karşılığında geçici bir role ait anahtar döndürür. Böylece uygulama koduna veya ortam değişkenine gömülü sabit erişim anahtarı hiç bulunmaz.

İş yükü kimliği, pod’un zaten sahip olduğu imzalı service account jetonunu buluta güven köprüsü yaparak, uzun ömürlü anahtarı denklemden tümüyle çıkarır.

Nasıl Çalışır?

Kubernetes, her pod’a projected service account token adı verilen, kısa ömürlü ve OIDC uyumlu bir jeton verir. Kümenin OIDC sağlayıcısı bulut hesabında güvenilir olarak tanımlandığında, pod bu jetonu bulut STS servisine sunar. Sağlayıcı jetonun imzasını ve içindeki service account ile namespace bilgisini doğrular, ardından önceden eşlenmiş kimlik ve erişim yönetimi rolüne ait dakikalar ömrü olan anahtarları döndürür. Bu akış, klasik federasyon kimlik yönetimi mantığının konteyner dünyasına uyarlanmış halidir.

Sabit Anahtarı Neden Bırakmalı?

Uzun ömürlü erişim anahtarları, bir kez sızdığında iptal edilene kadar geçerli kalır; git geçmişine, imaj katmanına veya log satırına düşen bir anahtar aylarca fark edilmeden kullanılabilir. İş yükü kimliğinde döndürülen anahtarlar dakikalar içinde sona erdiğinden, bir jetonun ele geçirilmesi bile sınırlı bir pencere açar. Ayrıca her pod kendi service account’una bağlı ayrı bir rol taşıdığından, tek bir küme kimliğinin tüm servislere erişmesi yerine görev bazlı ayrım kurulur.

En Az Yetkiyle Eşleme

Modelin değeri, rol eşlemesinin ne kadar dar tutulduğuyla doğru orantılıdır. Bir ödeme servisinin pod’u yalnızca ilgili kuyruğa ve veritabanına erişmeli, küme genelinde geniş yetki taşımamalıdır. En az yetki ilkesi burada service account başına ayrı rol tanımlamakla uygulanır; güven politikasında namespace ve service account adının açıkça koşula bağlanması, başka bir namespace’in aynı rolü üstlenmesini engeller.

• Kümenin OIDC sağlayıcısını bulut hesabında güvenilir kimlik sağlayıcı olarak tanımlayın.
• Her bulut rolünün güven politikasını belirli namespace ve service account ile sınırlayın.
• Service account’a rol bağını ekleyip pod spec’inde ilgili service account’u atayın.
• Sabit anahtar taşıyan eski secret’ları küme ve imajlardan temizleyin.

Yanlış yapılandırma en çok güven politikasında görülür: koşul çok geniş bırakıldığında farklı bir iş yükü aynı rolü üstlenebilir. Bu yüzden eşlemelerin düzenli denetlenmesi, Kubernetes güvenliği duruşunun temel bir parçasıdır.

Kurumsal Etki

İş yükü kimliğine geçiş, hem sızabilecek anahtar sayısını sıfıra indirir hem de kim neye erişebilir sorusunu denetlenebilir bir haritaya dönüştürür. Privia Security, küme ile bulut arasındaki güven ilişkilerinin doğru kurulduğunu ve rol eşlemelerinin dar tutulduğunu bir altyapı ve mimari gözden geçirme kapsamında inceler.