به گزارش از وبسایت cncf

ویکتوریا بیسووا، مهندس DevOps، در این مطلب به چالش مدیریت اسرار (secrets) در محیط‌های Kubernetes پرداخته است. با رشد زیرساخت‌ها، تأمین و مدیریت مخفی‌سازی‌ها تا حد زیادی خودکار شده اما همزمان نگهداری و چرخش اعتبارنامه‌های مشترک در مرزهای جداشده عملیاتی، هنوز یک مشکل جدی است. 🤔

سازمان‌ها معمولاً برای افزایش امنیت و کاهش blast radius، بارهای کاری Dev، Staging و Prod را در خوشه‌ها، namespaceها یا حساب‌های ابری جدا می‌کنند. این تفکیک مفید است، اما سؤال عملیاتی تکرارشونده‌ای ایجاد می‌کند: چگونه باید اسرار مشترک را به صورت توزیع‌شده و مداوم در میان این مرزها چرخاند؟

تیم ما هنگام طراحی یک محیط مقیاس‌پذیر روی AWS EKS با همین مسأله روبه‌رو شد. این مشکل خاص AWS نیست — خواه Azure، Google Cloud، محیط‌های چندابری، on-prem یا ابزارهای محلی مثل KIND و Minikube باشد — نقطه درد یکسان است: تضمین همگام‌سازی یکپارچه‌ی secrets در میان محیط‌های ایزوله.

هر محیط (Dev، Staging، Prod) در حساب، namespace یا خوشه جداگانه قرار دارد. این جداسازی برای امنیت مفید است ولی پیچیدگی عملیاتی ایجاد می‌کند: چگونه بدون copy-paste دستی، اسرار مشترک را در این محیط‌های ایزوله تکرار کنیم؟

در این مقاله توضیح داده می‌شود که چگونه مشکل همگام‌سازی مخفی چندحسابی را با استفاده از External Secrets Operator (ESO) و Bitwarden Secrets Manager حل کردیم. 🎯

چالش اصلی مشتری ما این بود که دو اپلیکیشن وابستگی زیادی به ادغام‌های شخص ثالث داشتند. نکات کلیدی مشکل عبارت بودند از:

• اعتبار مشترک: در محیط‌های غیرتولیدی، برنامه‌ها از اعتبارنامه‌های یکسان برای ابزارهای شخص ثالث استفاده می‌کردند.
• ذخیره‌سازی پراکنده: هر خوشه EKS در یک حساب AWS جداگانه قرار داشت، بنابراین استفاده از AWS Secrets Manager در هر حساب به این معنی بود که هنگام چرخش یک API key، باید آن را به‌صورت دستی در همه حساب‌ها به‌روزرسانی می‌کردیم.
• نیاز به مدیریت متمرکز: می‌خواستیم یک منبع واحد از حقیقت برای اعتبارها داشته باشیم تا چرخه‌ی زندگی secret در یک جا انجام شود و به‌صورت خودکار به محیط‌های مصرف‌کننده منتشر گردد.

اولین شرط طراحی، جدا کردن محل ذخیره‌سازی secrets از مکان مصرف آن‌ها بود.

راه حل: استفاده از External Secrets Operator به‌عنوان پلِ همگام‌سازی 🔗

ما اپراتور External Secrets (ESO) را انتخاب کردیم چون یک مدل آشتی (reconciliation) بومی Kubernetes را برای همگام‌سازی secrets از سیستم‌های خارجی به Kubernetes Secret API فراهم می‌کند. این امکان را می‌دهد که برنامه‌ها به مصرف استاندارد Kubernetes Secrets ادامه دهند در حالی که منبع حقیقت در یک سرویس خارجی مرکزی باقی می‌ماند.

برای ذخیره‌سازی پشت‌صحنه، Bitwarden Secrets Manager را انتخاب کردیم. دلیل عملی انتخاب این سرویس این بود که مشتری ما پیش‌تر از Bitwarden برای مدیریت رمز عبور سازمانی استفاده می‌کرد، بنابراین استفاده از Secrets Manager آن‌ها به حفظ کنترل‌های دسترسی سازمانی در یک نقطه کمک کرد.

یکی از مزایای ESO طراحی provider-based آن است؛ این اپراتور از backendهای متعددی مانند HashiCorp Vault، AWS Secrets Manager، Azure Key Vault، Google Secret Manager، Bitwarden Secrets Manager و موارد دیگر پشتیبانی می‌کند. الگوی کلی پیاده‌سازی مستقل از ارائه‌دهنده این‌گونه است: اسرار را به‌صورت مرکزی ذخیره کنید و اجازه دهید ESO آن‌ها را به Kubernetes Secrets در هر خوشه و حساب همگام‌سازی کند.

معماری کلی شامل سه جزء است:

1) یک سیستم مدیریت مخفی متمرکز که به‌عنوان منبع حقیقت عمل می‌کند.
2) اپراتور External Secrets که در هر خوشه Kubernetes اجرا می‌شود.
3) Kubernetes Secrets که توسط ESO برای مصرف برنامه‌ها تولید و نگهداری می‌شوند.

زمانی که یک منبع ExternalSecret ایجاد می‌شود، ESO مقدار مرجع را از ارائه‌دهنده خارجی می‌خواند و Kubernetes Secret متناظر را ایجاد یا به‌روزرسانی می‌کند. حلقه‌ی تطبیق (reconciliation loop) به‌صورت مداوم به‌روزرسانی‌ها را بررسی کرده و تغییرات را مطابق با بازه‌ی refresh پیکربندی‌شده همگام‌سازی می‌کند. این رویکرد ذخیره‌سازی را از مصرف جدا می‌کند در حالی که برنامه‌ها از مکانیزم‌های بومی Kubernetes استفاده می‌کنند.

پیاده‌سازی — راهنمای گام‌به‌گام

در ادامه یک راهنمای گام‌به‌گام برای پیکربندی این الگو در Kubernetes آمده است. ما تمام منابع را با Terraform خودکار کردیم، اما این راهنما شامل دستورات مستقیم برای شفافیت است. برای کد اتوماسیون به مخزن GitHub مربوطه مراجعه کنید.

پیش‌نیازها: یک خوشه Kubernetes (EKS، AKS، GKE یا مشابه)، ابزارهای kubectl و helm نصب‌شده، و دسترسی به یک ارائه‌دهنده secrets پشتیبانی‌شده. این مثال از Bitwarden Secrets Manager استفاده می‌کند، اما همین گردش‌کار را می‌توان برای سایر providers نیز به‌کار برد.

مرحله 1: امن‌سازی ارتباط بین ESO و Bitwarden SDK

ادغام ESO با Bitwarden SDK نیازمند ارتباط امن HTTPS است. برای مدیریت پویا گواهی‌های TLS در کلاستر، ابتدا Cert Manager را نصب کردیم. دستورات نصب helm به‌صورت نمونه در ادامه آمده است:

[pyaml]
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager
–namespace cert-manager
–create-namespace
–set installCRDs=true
[/yaml]

سپس یک ClusterIssuer با امضای خود (self-signed) قابل ایجاد است تا Cert Manager بتواند گواهی‌ها را صادر کند.

ادامهٔ مراحل شامل پیکربندی provider Bitwarden، نصب External Secrets Operator در هر خوشه، و تعریف منابع ExternalSecret برای هر secret مشترک است تا ESO آن‌ها را به Kubernetes Secret تبدیل و نگهداری کند. این گردش‌کار به شما امکان می‌دهد چرخش یک‌باره‌ی مخفی را در منبع مرکزی انجام داده و تغییرات به‌طور خودکار به محیط‌های جداشده توزیع شوند، بدون نیاز به به‌روزرسانی دستی در هر حساب یا خوشه. 🔁

این روش کنترل مرکزی، کاهش خطاهای انسانی و همخوانی با سیاست‌های دسترسی سازمانی را تسهیل می‌کند و در عین حال از الگوهای مرسوم Kubernetes برای مصرف secrets بهره می‌برد.

اگر مایلید، می‌توانم مراحل بعدی شامل مثال‌های YAML کامل برای ExternalSecret و نحوهٔ پیکربندی Bitwarden provider را هم تهیه کنم. ✅