Döndürülmüş Kubernetes service account token'ları son kullanma tarihine kadar geçerli kalır; bağlı Secret'lar bunları iptal eder

Bir Kubernetes service account token'ını döndürmek, eski kimlik bilgisini tamamen kullanılabilir bırakır. Zenxsys'te bir mühendisin dev.to'daki yazısına göre, TokenRequest API üzerinden verilen token'lar exp claim'i sona erene kadar kimlik doğrulamaya devam ediyor — bu süre birkaç saatten yedi güne kadar uzayabiliyor. Yenisini verip orijinalini ortadan kaldırmamak kimlik bilgisi verme işlemidir, iptal değil; önceki token'ı kopyalayan herkes bu süre boyunca erişimini korur.

Naif döndürmenin gözden kaçırdıkları

Herhangi bir değişiklik yapmadan önce yazar, mevcut bir döndürme akışını tek düğümlü bir k3s 1.30.5 kümesinde çalıştırdı. İşe yaradı, ancak önceki token hiçbir zaman geçersiz kılınmadı ve kopyalanmış bir token'ın hâlâ kimlik doğruladığı 24 saatlik ila 7 günlük bir dönem ortaya çıktı. Preflight kontrolü de yoktu, bu yüzden eksik bir RBAC fiili yalnızca döndürme sırasında bir hata olarak ortaya çıkıyordu; eski token bırakılmadan önce yeni token'ın gerçekten kimlik doğrulayıp doğrulamadığı kontrol edilmiyordu; değişimi geç alan tüketiciler için bir genişletilmiş süre (grace period) yoktu; ve yeni token yanlışsa geri dönüş yolu yoktu.

İptali mümkün kılan primitive

TokenRequest endpoint'i POST /api/v1/namespaces/{ns}/serviceaccounts/{sa}/token, spec.boundObjectRef alanını kabul eder. Bir token bir nesneye bağlandığında, API server her kimlik doğrulamada nesnenin hâlâ var olup olmadığını ve aynı UID'yi taşıyıp taşımadığını kontrol eder; böylece nesneyi silmek token'ın çalışmasını durdurur.

Bir Pod'a bağlanma, projected volume'ların zaten yaptığı şeydir; ancak CI sistemleri gibi dış持有ıcıların bağlanacak bir Pod'u yoktur. Yazının çözümü bir işaretleyici Secret — tek görevi var olmak ve bir UID taşımak olan boş bir Opaque nesnesi. Yazarın laboratuvar testlerinde, API server Secret silindikten yaklaşık on saniye sonra bağlı token'ı reddetmeye başladı; süreçler 9,2 ile 11,0 saniye arasında değişti. Gecikme API server'ın kimlik doğrulama önbelleğinden kaynaklanır, dolayısıyla iptal hızlıdır ama anlık değildir.

İki slot, doğrulanmış değişimler ve geri alma

Zenxsys bu deseni just-in-time ayrıcalıklı erişim ürünü zenxPAM'a inşa etti ve yazar bu ürün üzerinde çalıştığını belirtiyor. Yönetilen her kimlik iki işaretleyici slot'u alır, böylece giden token bir genişletilmiş süre boyunca geçerli kalarken yenisini zaten devreye girer. Akış, işaretleyici Secret'ı oluşturur, ona bağlı bir token ister ve ardından yeni kimlik bilgisini, beklenen service account'ı döndürmesi gereken bir SelfSubjectReview ile kanıtlar. 401 hatası döndürmeyi başarısız kılar; sağlamlaştırılmış veya eski bir kümeden gelen 403 veya 404, kontrolün sessizce geçmiş gibi davranmak yerine bir uyarıyla atlandığını işaret eder.

İşaretleyici Secret oluştuktan sonra meydana gelen hatalar telafi edilir — işaretleyici silinir ve vault durumu geri yüklenir. Genişletilmiş süre, eski token'ın kalan ömrüyle sınırlıdır. Sonlandırma (finalize) eski işaretleyiciyi siler ve ardından eski token'ı 30 saniyeye kadar yoklar; bu sürenin sonunda hâlâ kabul ediliyorsa, sonuç başarı varsaymak yerine kanıtla birlikte bir uyarı kaydeder. Geri alma, önceki token'ı geri yüklemeden önce hâlâ kimlik doğruladığını doğrular ve eski token zaten ölüyse hiçbir şeyi değiştirmez.

En az ayrıcalık ve confused-deputy riski

Döndürücünün kendi izinleri dar ve namespace kapsamında kalır: hedef service account ile adla sınırlı serviceaccounts/token üzerinde create, namespace genelinde Secret'lar üzerinde create (Kubernetes oluşturmayı adla sınırlayamaz) ve yalnızca iki slot adıyla sınırlı Secret'lar üzerinde get ve delete. Yazarın kabul ettiği bir uyarı: döndürücü o namespace'te rastgele Secret'lar oluşturabilir, ancak yalnızca kendi iki işaretleyicisini okuyabilir veya silebilir.

Döndürücünün kendisi de bir confused-deputy riski olarak işaretlenir — yapılandırmadan bir API URL'si ve bir admin token okuyup ardından bu URL'yi çağıran bir sistem, kullanışlı bir veri sızdırma aracıdır. zenxPAM'deki önlemler arasında küme adresini ve CA'yı yalnızca cloud-account connector'dan almak (döndürülen kimlikten değil), admin token'lar için vault anahtarlarının K8S_ ile başlamasını zorunlu kılmak ve bir operatör izin listesine eklemedikçe özel veya dahili API host'larını reddetmek yer alır.

Belirtilen sınırlamalar

Testler yalnızca k3s 1.30.5'i kapsadı — EKS, AKS veya GKE'yi değil; bunlar token ömürlerini sınırlayabilir veya SelfSubjectReview'ü kısıtlayabilir; preflight, API server'ın gerçekte verdiği ömrü raporlar. İptal yaklaşık on saniye gecikir. Ve secret bağlama kapatılırsa, eski token basitçe son kullanma tarihine kadar geçerli kalır; araç bunu bitiş saatiyle birlikte raporlar.

Neden önemli

Birçok ekip token döndürmeyi sızan bir kimlik bilgisine verilen tepki olarak görür; ancak TokenRequest ile verilen token'lar için eski kimlik bilgisi, kendi kendine sona erene kadar canlı bir anahtar olarak kalır. Bağlı işaretleyici Secret deseni, silmeyi iptale dönüştürerek bu boşluğu kapatır ve kubectl'den daha egzotik hiçbir şeye gerek olmadan uygulanabilir. Operatörler döndürme araçlarının gerçekte ne yaptığını kontrol etmeli: yeni token'ı geçiş yapmadan önce doğrulayıp doğrulamadığını, yavaş tüketicileri tolere edip etmediğini ve eski token'ın reddedildiğini — ideal olarak bir anı yerine denetlenebilir bir kayıtla — teyit edip etmediğini.