در Kubernetes v1.37، قابلیت‌های Pod Certificates و Cluster Trust Bundles به مرحله GA رسیده‌اند و حالا یک پایه جدی برای هویت‌سنجی بومی در محیط‌های production فراهم کرده‌اند. این یعنی Kubernetes فقط برای زمان‌بندی، health check و محدودیت منابع نیست؛ بلکه در بخش identity هم دارد به بلوغ بیشتری می‌رسد. 🔐
تا امروز، اصلی‌ترین مکانیزم هویت تولیدی که داخل Kubernetes وجود داشت، service account JWTها بود. این توکن‌های امضاشده توسط control plane صادر می‌شوند و به workload شما اجازه می‌دهند با سیستم‌های دیگر ارتباط امن برقرار کند. اما یک ضعف مهم دارند: bearer token هستند. یعنی اگر کسی به توکن دسترسی پیدا کند، عملاً همان هویت را در اختیار دارد. این موضوع در محیط‌های production ریسک بالایی ایجاد می‌کند. 😕
برای کاهش این ریسک، Kubernetes در نسخه 1.37 روی proof-of-possession credentialها تمرکز کرده است؛ یعنی به‌جای ارسال کامل credential، فقط اثباتی از در اختیار داشتن آن ارائه می‌شود. در عمل، رایج‌ترین و قابل‌اعتمادترین راه برای این کار در دنیای production همان X.509 certificateها هستند که در TLS و mTLS استفاده می‌شوند.
در مدل جدید، credential شما به دو بخش تقسیم می‌شود: یک private key که بهتر است داخل خود workload یا یک hardware security module ساخته شود و هرگز از آن خارج نشود، و یک certificate که هویت و public key شما را توصیف می‌کند و توسط Certificate Authority امضا می‌شود. هدف Pod Certificates این است که استفاده از X.509 را برای workloadهای Kubernetes به همان سادگی استفاده از service account JWTها کند، بدون اینکه سطح امنیت پایین بیاید. ✅
نکته مهم این است که Pod Certificates نسبت به JWTها انعطاف‌پذیرتر هستند. Kubernetes فقط یک مدل استاندارد برای service account JWT دارد، اما دنیای X.509 متنوع‌تر است و برای کاربردهای مختلف، extensionها و اطلاعات متفاوتی در certificateها قرار می‌گیرد. به همین دلیل، Kubernetes در این قابلیت جدید یک مکانیزم مشترک داخل Kubelet گذاشته، اما در عین حال یک interface قابل‌افزونه هم ارائه می‌دهد تا بتوان چند نوع certificate را هم‌زمان در یک cluster صادر کرد. همین موضوع برای محیط‌های پیچیده devops – sre خیلی ارزشمند است. 🛠️
در ادامه، انتظار می‌رود Kubernetes دست‌کم دو provider داخلی برای certificate ارائه کند: یکی برای صدور server TLS certificate برای DNS nameهای مربوط به Kubernetes Services، و دیگری برای SPIFFE client certificate که همان نقشی را بازی می‌کند که امروز service account JWTها دارند. این حرکت می‌تواند معماری هویت workloadها را بسیار تمیزتر و امن‌تر کند.
وقتی از Pod Certificates و Cluster Trust Bundles استفاده می‌کنید، چند بخش اصلی درگیر می‌شوند: خود application که certificate را در pod spec درخواست می‌کند و key، certificate و trust bundle را از filesystem داخل container می‌خواند؛ Kubelet که به‌جای workload، PodCertificateRequest می‌سازد و ClusterTrustBundleها را می‌خواند؛ و در نهایت signer controller که درخواست‌ها را پاسخ می‌دهد و trust bundleها را منتشر می‌کند. این تقسیم وظایف باعث می‌شود مسیر صدور و توزیع credentialها شفاف‌تر و قابل‌کنترل‌تر باشد. 📦
روند صدور هم به‌صورت مرحله‌ای انجام می‌شود. وقتی pod روی یک node schedule شد، Kubelet همه volume sourceهای مربوط به podCertificate و clusterTrustBundle را در spec شناسایی می‌کند. بعد برای هر podCertificate، یک private key جدید مطابق keyType می‌سازد، یک PodCertificateRequest به signer مشخص‌شده می‌فرستد، و signer تصمیم می‌گیرد که certificate را صادر کند یا نه. اگر درخواست پذیرفته شود، certificate chain در status.certificateChain قرار می‌گیرد و زمان شروع refresh بعدی هم در status.beginRefreshAt ثبت می‌شود تا Kubelet بداند چه زمانی باید renewal را شروع کند.
برای هر clusterTrustBundle هم Kubelet همه bundleهایی را که با نام signer و label selectorهای مشخص‌شده مطابقت دارند جمع می‌کند، سپس certificateها را یکپارچه می‌سازد و با یک ترتیب پایدار روی فایل می‌نویسد تا application به‌صورت ناخواسته به ترتیب خاصی وابسته نشود. بعد از آن، pod شروع به کار می‌کند و application keyها، certificateها و trust bundleها را از filesystem می‌خواند. اگر محتوا تغییر کند، workload باید با inotify یا polling خودش را با تغییرات هماهنگ کند. 🔄
نکته عملی مهم این است که rotation خودکار از ابتدا در این طراحی دیده شده، پس application باید واقعاً آماده‌ی آن باشد. certificateهایی که در آینده توسط signerهای داخلی Kubernetes صادر می‌شوند، حداکثر 24 ساعت اعتبار خواهند داشت و برای signerهای دیگر، سقف اعتبار 91 روز است. برای ساده‌تر شدن مدیریت rotation، Kubelet می‌تواند private key و certificate chain را در یک فایل واحد، یعنی credential bundle، بنویسد تا application فقط همان فایل را مانیتور کند. البته امکان نوشتن key و certificate در فایل‌های جدا هم وجود دارد، اما آن روش ریسک race condition در زمان rotation را بالا می‌برد و نیاز به دقت بیشتری دارد. ⚠️
از نظر امنیتی هم هر جا ممکن بوده، کنترل‌ها داخل kube-apiserver گذاشته شده‌اند تا بار اضافه روی signer یا توسعه‌دهنده application نیفتد. نمونه روشن آن node restriction admission plugin است که node isolation را enforce می‌کند و نمی‌گذارد یک node compromiseشده برای podهایی که روی آن schedule نشده‌اند certificate درخواست کند. این دقیقاً همان نوع safeguardهایی است که در محیط‌های production و مخصوصاً در تیم‌های sre اهمیت زیادی دارند. 🛡️
اگر بخواهید این قابلیت‌ها را امتحان کنید، فعلاً چون Kubernetes هنوز signer داخلی برای Pod Certificates در core ارائه نکرده، باید یک signer شخص ثالث را داخل cluster نصب کنید. برای ساده‌تر شدن این کار، Tinycert معرفی شده است؛ ابزاری که می‌توانید آن را روی cluster اصلی یا حتی یک Kind cluster اجرا کنید. Tinycert یک راه‌حل کامل production نیست، اما برای آزمایش Pod Certificates و حتی ساخت signer اختصاصی، شروع خوبی محسوب می‌شود. 🚀
Tinycert چند قابلیت مهم ارائه می‌دهد: signer مربوط به ahmedtd.github.io/tinycert-service که certificateهایی با DNS SAN برای همه Kubernetes Serviceهایی که pod عضو آن‌هاست صادر می‌کند؛ signer مربوط به ahmedtd.github.io/tinycert-spiffe که certificateهای سازگار با SPIFFE صادر می‌کند و namespace و service account pod را هویت‌دهی می‌کند؛ یک Go library با نام github.com/ahmedtd/tinycert/lib/spiffefsd برای اینکه application بتواند certificate و trust bundle را از یک SPIFFE Filesystem Delivery folder بخواند و تنظیمات TLS را درست انجام دهد؛ و همچنین یک نمونه application برای client و server که با mutual TLS و certificateهای SPIFFE با هم ارتباط برقرار می‌کنند.
اگر بخواهید مسیر را ادامه دهید، بهتر است مستندات Pod Certificates و Cluster Trust Bundles را دقیق‌تر بررسی کنید، روی پیش‌نویس استاندارد SPIFFE Filesystem Delivery بازخورد بدهید، در Kubernetes SIG Auth مشارکت کنید و حتی signer اختصاصی خودتان را بر پایه Tinycert بسازید. این حوزه برای تیم‌های devops – sre فرصت خوبی است تا identity workloadها را تمیزتر، امن‌تر و قابل‌اتکاتر کنند. 😊
