Kubernetes v1.37: Pod Sertifikaları ve Cluster Trust Bundle

⏱️ 5 dk okuma📅 30 Ağustos 2026

Kubernetes v1.37 ile birlikte üretim kimliği (production identity) alanında önemli bir kilometre taşı GA seviyesine ulaştı: Pod Certificates ve buna yakından bağlı Cluster Trust Bundles. Bu iki mekanizma, X.509 sertifika ihracını ve TLS/mTLS için gerekli güven zincirinin dağıtımını doğrudan Kubernetes çekirdeğine taşıyor. Böylece iş yükleri, servis hesabı JWT’lerini kullanır gibi kolay biçimde sertifika tabanlı kimlik doğrulama yapabilecek.

Neden Pod Certificates?

Kubernetes’in yerleşik üretim kimliği çözümü bugüne kadar büyük ölçüde service account JWT‘leriydi. Bunlar, Kubelet tarafından iş yükünün dosya sistemine otomatik yazılan, süresi geldiğinde tazelenen ve kümenin kontrol düzlemi tarafından imzalanan token’lardır. Node restriction admission plugin sayesinde bir token, yalnızca pod’u gerçekten çalıştıran Kubelet tarafından talep edilebiliyor; bu da en az yetki (least privilege) ilkesine uyuyor. Federasyona uygun oldukları için büyük bulut sağlayıcıları dahil pek çok sistemle konuşabiliyorlar.

JWT’lerin temel bir sorunu var ama: bearer token olmaları. Token’a sahip olan, o kimliktir. Kimlik doğrulaması için token’ı karşı tarafa vermek zorunda olduğundan, karşı taraf da teoride sizin gibi davranabilir. Zamana, nesneye ve hedef kitleye (audience) bağlama gibi kısmi önlemler var ama hiçbiri tam bir çözüm değil.

Çözüm, kimlik bilgisinin tamamını değil, ona sahip olduğunuzun kanıtını sunduğunuz proof-of-possession yaklaşımlarında. Pratikte bunlar asimetrik kriptografi (RSA, ECDSA vb.) üzerine kurulu. AWS SigV4, JWT DPoP ve RFC 9421 gibi imzalama tabanlı yöntemler bulunsa da en yaygın ve iyi anlaşılan model, TLS ile birlikte kullanılan X.509 sertifikalarıdır. Bu modelde kimlik iki parçaya ayrılır:

İdeal olarak iş yükü içinde (veya bir donanım güvenlik modülünde) üretilen ve dışarı hiç çıkmayan bir özel anahtar,
Kimliğinizi ve açık anahtarınızı tanımlayan, bir Sertifika Otoritesi tarafından imzalanmış bir sertifika.

Esnek bir imzalayıcı modeli

Kubernetes yalnızca tek tür service account JWT sunarken X.509 ekosistemi çok daha çeşitlidir; farklı amaçlar için farklı uzantılar ve alanlar kullanılır. Bu nedenle Pod Certificates, Kubelet içinde ortak makineye sahip ancak eklenti tabanlı (pluggable) bir arayüz sunuyor. Aynı küme içinde birden fazla imzalayıcı aynı anda çalışabiliyor.

Blog yazısında ileride Kubernetes’in en az iki yerleşik sertifika sağlayıcısı sunmasının beklendiği belirtiliyor:

Kubernetes servislerinin DNS adları için sunucu TLS sertifikaları düzenleyen bir sağlayıcı,
Bugün service account JWT’lerin oynadığı rolü üstlenecek SPIFFE istemci sertifikaları sağlayıcısı.

Mimari: Bileşenler ve akış

Pod Certificates ve Cluster Trust Bundles kullanıldığında üç ana bileşen devreye giriyor:

Uygulama: Pod spec’inde sertifika talep eder; anahtarları, sertifikaları ve güven paketlerini konteyner dosya sisteminden okuyarak (m)TLS için kullanır.
Kubelet: Uygulama adına PodCertificateRequest nesneleri oluşturur ve ClusterTrustBundle nesnelerini okur.
Signer controller: PodCertificateRequest‘lere yanıt verir ve ClusterTrustBundle nesnelerini yayınlar.

Sertifika ihraç süreci

Süreci sırasıyla izlemek en açıklayıcı yol:

Uygulama pod’u bir node’a zamanlandığında Kubelet, spec’teki tüm podCertificate ve clusterTrustBundle projected volume kaynaklarını tespit eder.
Her podCertificate kaynağı için Kubelet, keyType alanına göre yeni bir özel anahtar üretir ve ilgili signer’a hitap eden bir PodCertificateRequest oluşturur.
Signer controller talebi görür ve sertifikayı düzenleyip düzenlemeyeceğine karar verir.
Sertifikayı düzenleyecekse status.certificateChain alanını doldurur.
status.beginRefreshAt alanına da Kubelet’in yenileme denemelerine ne zaman başlaması gerektiğini yazar.
Kubelet düzenlenmiş sertifikayı alır; özel anahtar ile sertifikayı konteynerin dosya sistemine yazar.
Her clusterTrustBundle kaynağı için Kubelet, signer adı ve etiket seçicileriyle eşleşen tüm ClusterTrustBundle‘ları toplar, içerdikleri sertifikaları birleştirip kararlı biçimde yeniden sıralar (uygulamaların belirli bir sıraya yanlışlıkla bağımlı hale gelmesini engellemek için) ve kaynakta belirtilen dosya yoluna yazar.
Uygulama başlar; anahtarları, sertifikaları ve güven bağlantılarını dosya sisteminden okur.
Kubelet, seçili ClusterTrustBundle‘ların içeriği değiştikçe dosyaları düzenli olarak günceller. Uygulama, değişiklikleri inotify veya polling ile yakalamalıdır.
beginRefreshAt zamanı geçtikçe Kubelet süreci baştan işleterek yeni özel anahtar ve sertifika zincirini dosya sistemine yazar; uygulama yine değişiklikleri kendisi izlemelidir.

Öne çıkan tasarım kararları

Otomatik rotasyon yerleşiktir. Uygulamaların bunu doğru şekilde ele alması gerekir. Kaynakta, Kubernetes çekirdeğine dahil edilecek imzalayıcıların en fazla 24 saatlik ömre sahip sertifika düzenleyeceği, diğer imzalayıcılara ise 91 güne kadar izin verildiği belirtiliyor.
Uygulama tarafındaki rotasyon işini kolaylaştırmak için Kubelet, özel anahtar ile sertifika zincirini tek bir dosyaya, yani credential bundle biçiminde yazabilir. Böylece uygulama tek bir dosyayı izleyerek okuma-yazma yarış koşullarından uzak durur. Ayrı dosyalara yazım da destekleniyor ama bu durumda uygulama, rotasyon sırasındaki tutarsızlık risklerini kendisi yönetmelidir.
Güvenlik denetimleri mümkün olduğunca kube-apiserver tarafına konumlandırılmıştır. Örneğin yerleşik node restriction admission plugin sayesinde ele geçirilmiş bir node, üstünde çalışmayan pod’lar için sertifika talep ederek erişimini genişletemez.

Denemek isteyenler için: Tinycert

Kubernetes çekirdeği henüz hazır bir Pod Certificate imzalayıcısıyla gelmediğinden, özellikleri denemek için üçüncü taraf bir signer kurmanız gerekiyor. Bu amaçla yazının yazarı Tinycert adlı bir örnek projeyi tanıtıyor. Tinycert bir üretim çözümü olarak konumlandırılmıyor; Pod Certificates ile deney yapmak ve kendi imzalayıcınızı geliştirmek için başlangıç noktası olarak sunuluyor.

Tinycert şunları içeriyor:

ahmedtd.github.io/tinycert-service imzalayıcısı: Pod’un dahil olduğu tüm Kubernetes Service’ler için DNS SAN’lı sertifikalar düzenler.
ahmedtd.github.io/tinycert-spiffe imzalayıcısı: Pod’un namespace ve service account bilgisini taşıyan SPIFFE uyumlu sertifikalar düzenler. Bu sertifikalar hem istemci hem (belirli bir çabayla) sunucu sertifikası olarak kullanılabilir.
github.com/ahmedtd/tinycert/lib/spiffefsd adlı Go kütüphanesi: Uygulamaların SPIFFE sertifikalarını ve güven paketlerini bir SPIFFE Filesystem Delivery (Draft Standard) dizininden yüklemesine ve Go TLS kütüphanesini istemci/sunucu kimlik doğrulaması için doğru şekilde yapılandırmasına yardım eder.
Karşılıklı TLS ve SPIFFE sertifikalarıyla haberleşen istemci-sunucu uygulamalarına dair bir örnek.

Sonraki adımlar

Konuyu daha ileriye taşımak isterseniz kaynak yazıda önerilen adımlar şunlar: Pod Certificates ve Cluster Trust Bundles belgelerini incelemek, SPIFFE Filesystem Delivery taslak standardını gözden geçirip geri bildirim vermek, Kubernetes SIG Auth çalışmalarına katılmak ve Tinycert’i temel alarak kendi imzalayıcınızı geliştirmek.

Pod Certificates, Kubernetes’te üretim kimliği için X.509 tabanlı, kanıta dayalı (proof-of-possession) bir yaklaşımı service account JWT’ler kadar kolay kullanılabilir hale getiriyor. Rotasyon ve güven paketlerinin dağıtımı gibi zorlu bölümleri Kubelet üstlendiği için uygulama tarafında büyük ölçüde dosyaları izlemek ve doğru şekilde yüklemek yeterli oluyor. Çekirdeğe dahil imzalayıcılar geldiğinde bu modelin bulut yerel iş yükleri için ne kadar merkezi hale geleceği önümüzdeki dönemde belli olacak.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102