در Kubernetes 1.37 یکی از مهمترین تغییرات امنیتی برای محیطهای Production به مرحله پایدار رسیده است: Pod Certificates و قابلیت مرتبط با آن یعنی Cluster Trust Bundles. این دو قابلیت، صدور و توزیع گواهیهای X.509 برای TLS و mTLS را مستقیماً وارد هسته Kubernetes میکنند و به تیمهای DevOps اجازه میدهند هویت workloadها را با وابستگی کمتر به توکنهای Bearer مدیریت کنند.
اگر هنوز با مفاهیم پایه کوبرنتیز آشنا نیستید، ابتدا مقاله Kubernetes چیست؟ را بخوانید. در ادامه دقیقاً بررسی میکنیم Pod Certificate چیست، Cluster Trust Bundle چه نقشی دارد و چرا این تغییر در Kubernetes 1.37 برای امنیت کلاسترها مهم است.
Pod Certificates در Kubernetes چیست؟
تا پیش از این، یکی از اصلیترین مکانیزمهای هویت داخلی در Kubernetes، توکنهای ServiceAccount مبتنی بر JWT بود. این توکنها برای احراز هویت workloadها بسیار کاربردی هستند، اما ماهیت Bearer Token دارند؛ یعنی هر کسی که به خود توکن دسترسی پیدا کند، در محدوده اعتبار و مجوزهای آن میتواند از آن استفاده کند.
در Kubernetes 1.37، زیرساخت Pod Certificates به مرحله GA رسیده است. ایده اصلی این است که هر Pod بتواند یک هویت X.509 دریافت کند و از همان گواهی برای ارتباط امن TLS یا mTLS با سرویسهای دیگر استفاده کند. این رویکرد برای معماریهای Zero Trust و سرویسبهسرویس بسیار مناسبتر است، چون هویت workload به کلید خصوصی و گواهی متصل میشود.
Cluster Trust Bundles چیست؟
صدور گواهی فقط نیمی از مسئله است. هر workload باید بداند به کدام CA یا زنجیره اعتماد کند. Cluster Trust Bundle در Kubernetes یک منبع cluster-scoped برای نگهداری و توزیع Trust Anchorهای X.509 است. طبق مستندات رسمی Kubernetes، این آبجکت میتواند مجموعهای از Root Certificateها را در اختیار workloadها قرار دهد تا آنها بتوانند گواهی طرف مقابل را اعتبارسنجی کنند.
در عمل، Pod Certificates هویت را فراهم میکنند و Cluster Trust Bundles مشخص میکنند چه مرجع صدور گواهی قابل اعتماد است. ترکیب این دو، پایه مناسبی برای ارتباطات mTLS درون کلاستر ایجاد میکند.
چه چیزی در Kubernetes 1.37 تغییر کرده است؟
طبق اعلام رسمی Kubernetes در 28 اوت 2026، پایه فناوری جدید هویت Production در نسخه 1.37 به مرحله GA رسیده است. Kubernetes اکنون صدور گواهی X.509 برای workloadها را بهصورت یکپارچهتر در هسته خود فراهم میکند و Kubelet میتواند گواهی و کلید موردنیاز را پیش از شروع workload در فایلسیستم کانتینر قرار دهد و آن را بهصورت خودکار بهروز نگه دارد.
این موضوع از نظر عملیاتی مهم است؛ چون برنامه لازم نیست خودش یک فرایند جداگانه برای دریافت و تمدید گواهی بنویسد. در بسیاری از سناریوها، چرخه دریافت و Rotation گواهی میتواند توسط زیرساخت Kubernetes مدیریت شود.
مزیت Pod Certificates نسبت به ServiceAccount Token چیست؟
- مناسب برای TLS و mTLS: گواهی X.509 مستقیماً برای برقراری ارتباط رمزنگاریشده قابل استفاده است.
- هویت مبتنی بر کلید: اعتبار گواهی به کلید خصوصی مرتبط است و صرف داشتن یک رشته Bearer Token کافی نیست.
- Rotation خودکار: Kubernetes میتواند گواهیهای workload را بهصورت خودکار تازه نگه دارد.
- مدیریت Trust استانداردتر: Cluster Trust Bundles توزیع CAهای قابل اعتماد را در سطح کلاستر سادهتر میکنند.
- مناسب برای معماری Zero Trust: سرویسها میتوانند هویت یکدیگر را با گواهیهای کوتاهعمر و قابل اعتبارسنجی بررسی کنند.
آیا Pod Certificates جای ServiceAccount JWT را میگیرد؟
خیر، لزوماً. ServiceAccount Token همچنان برای بسیاری از سناریوهای احراز هویت با Kubernetes API یا سرویسهایی که JWT را میپذیرند مناسب است. Pod Certificates بیشتر یک گزینه جدید برای هویت X.509 و ارتباطات TLS/mTLS فراهم میکنند.
بهترین انتخاب به معماری شما بستگی دارد. اگر یک workload فقط باید با Kubernetes API احراز هویت کند، JWT همچنان ساده و مؤثر است. اگر چند سرویس داخلی باید هویت یکدیگر را در یک کانال mTLS اعتبارسنجی کنند، Pod Certificates گزینه جذابتری خواهد بود.
سناریوی کاربردی: mTLS بین دو سرویس
فرض کنید دو سرویس داخلی با نامهای API و Worker در یک کلاستر دارید. هدف این است که هیچ سرویس ناشناسی نتواند به API متصل شود. در مدل جدید میتوان برای workloadها گواهی X.509 صادر کرد و Trust Bundle مربوط به CA معتبر را نیز در اختیار Podها قرار داد.
در زمان برقراری ارتباط، هر طرف گواهی طرف دیگر را بررسی میکند و فقط در صورتی ارتباط ادامه پیدا میکند که زنجیره اعتماد معتبر باشد. این الگو نسبت به اعتماد صرف به شبکه داخلی یا IP بسیار امنتر است و برای محیطهای Microservice مناسب است.
Cluster Trust Bundle چگونه به امنیت کمک میکند؟
در محیطهای بزرگ، یکی از مشکلات همیشگی توزیع CA Certificateها بین دهها یا صدها workload است. اگر این فایلها بهصورت دستی داخل Image یا Secret قرار بگیرند، بهروزرسانی آنها دشوار میشود و خطر باقی ماندن CA قدیمی افزایش پیدا میکند.
Cluster Trust Bundles یک روش استاندارد در سطح Kubernetes برای معرفی Trust Anchorها ایجاد میکنند. این موضوع مدیریت چرخه CA، مهاجرت بین CAها و Rotation گواهیهای ریشه را سادهتر میکند.
نکات مهم قبل از استفاده در Production
- ابتدا مشخص کنید چه Signer یا CA قرار است گواهی workloadها را صادر کند.
- مدت اعتبار گواهیها را کوتاه و متناسب با سیاست امنیتی سازمان تنظیم کنید.
- دسترسی به منابع مربوط به Certificate و Trust Bundle را با RBAC محدود کنید.
- Rotation گواهی و CA را قبل از مهاجرت کامل در محیط Staging آزمایش کنید.
- اپلیکیشن باید بتواند Reload شدن فایل Certificate یا Key را بدون Downtime مدیریت کند.
- لاگها و خطاهای TLS را مانیتور کنید تا Expiration یا Trust Failure سریع شناسایی شود.
تفاوت Pod Certificates با cert-manager چیست؟
cert-manager همچنان یک پروژه قدرتمند برای مدیریت گواهیها در Kubernetes است و Integrations گستردهای با ACME، Let’s Encrypt و CAهای مختلف دارد. Pod Certificates اما بخشی از مسیر داخلی Kubernetes برای هویت workload است. بنابراین این دو الزاماً رقیب کامل هم نیستند و حتی در برخی معماریها میتوانند کنار هم قرار بگیرند.
اگر هدف شما صدور گواهی عمومی برای Ingress یا دامنههای اینترنتی باشد، cert-manager همچنان انتخاب رایجی است. اگر هدف هویت داخلی Pod و ارتباط mTLS بین workloadها باشد، Pod Certificates و Cluster Trust Bundles ارزش بررسی جدی دارند.
برای مدیران Kubernetes چه کاری لازم است؟
اگر کلاستر شما به Kubernetes 1.37 ارتقا پیدا میکند، لازم نیست بلافاصله تمام سیستم هویت را تغییر دهید. ابتدا سرویسهایی را شناسایی کنید که ارتباط Service-to-Service حساس دارند و بیشترین سود را از mTLS میبرند. سپس یک Pilot محدود برای Pod Certificates اجرا کنید و رفتار Rotation، Trust Bundle و اپلیکیشن را زیر بار واقعی بررسی کنید.
اگر هنوز کلاستر خود را راهاندازی نکردهاید، راهنمای نصب و پیکربندی Kubernetes روی لینوکس میتواند نقطه شروع مناسبی باشد.
Pod Certificates برای چه پروژههایی مناسب است؟
- Microserviceهایی که نیاز به mTLS داخلی دارند.
- کلاسترهای Multi-Tenant با نیاز امنیتی بالا.
- زیرساختهای Zero Trust.
- سرویسهایی که باید هویت workload را بهصورت رمزنگاریشده اثبات کنند.
- تیمهایی که میخواهند مدیریت دستی Certificate و CA را کاهش دهند.
جمعبندی
Pod Certificates و Cluster Trust Bundles در Kubernetes 1.37 یک قدم مهم برای استانداردسازی هویت X.509 در سطح workload هستند. این قابلیتها میتوانند صدور گواهی، Rotation و توزیع Trust Anchor را سادهتر کنند و مسیر پیادهسازی TLS و mTLS را در کلاسترهای Production شفافتر سازند.
اگر زیرساخت Kubernetes شما روی سرور مجازی اجرا میشود، انتخاب منابع پایدار CPU، RAM، Storage و شبکه روی عملکرد کل کلاستر تأثیر مستقیم دارد. برای راهاندازی Nodeهای Kubernetes میتوانید سرویسهای VPS وانسرور را نیز بررسی کنید.