قرار دادن API سرویس EKS پشت VPN: ترتیب عملیات

نقطه پایانی خصوصی را فعال کنید، ثابت کنید که kubectl به آن رسیده است، سپس نقطه پایانی عمومی را ببندید. یک رانبوک مرحله‌ای با دستورها و بررسی‌های میان هر گام.

نسخه خطرناک این تغییر یک دستور است که نقطه پایانی را عوض می‌کند و همه مدیران را هم‌زمان قفل می‌کند. نسخه ایمن هر دو مسیر را باز نگه می‌دارد، ثابت می‌کند مسیر خصوصی از طریق VPN کار می‌کند و تنها پس از آن نقطه پایانی عمومی را بازنشسته می‌کند. کلاستر موجود، تونل تأییدشده به VPC آن و kubeconfigی را که از قبل کار می‌کند فرض کنید؛ کار، دسترسی خصوصی به API کوبرنتیز است، نه نودهای خصوصی و نه مدل مجوز جدید. هر گام زیر یک بررسی دارد که می‌توانید در آن به‌طور ایمن شکست بخورید.

1. نقطه پایانی را فهرست کنید و راه بازگشت را نگه دارید

پیش از تغییر، وضعیت فعلی را ثبت کنید، از جمله فهرست CIDR مجاز عمومی و گروه امنیتی کلاستر. همین دو مورد را وقتی چیزی از کار می‌افتد مقایسه می‌کنید و فهرست مجاز همچنین مسیر بازگشت شماست اگر مسیر خصوصی اشتباه از آب دربیاید.

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

REGION و CLUSTER در اینجا جای‌نگهدار هستند. توجه کنید که پرچم خصوصی اکنون چه می‌خواند، چون کلاستری که با دسترسی خصوصی از قبل فعال ساخته شده، گام اول متفاوتی از کلاستری نیاز دارد که هرگز آن را نداشته است. در طول گذار دست‌کم یک مسیر مدیریتی تأییدشده را باز نگه دارید؛ VPNی که به در دسترس بودن همان کلاستر وابسته است، مسیر بازیابی نیست.

2. دسترسی خصوصی را با مسیر شبکه آماده فعال کنید

روشن کردن پرچم نیمه آسان است. تونل به مسیری به آدرس‌های خصوصی نقطه پایانی نیاز دارد و گروه امنیتی کلاستر به TCP 443 از منبعی که VPN واقعاً ارائه می‌کند نیاز دارد. انجمن Client VPN، دروازه سایت‌به‌سایت و VPC همتا می‌توانند آدرس‌های مبدأ متفاوتی ارائه کنند، پس مدلی را که مستقر کرده‌اید به کار ببرید، نه یک محدوده خصوصی عمومی.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

به‌روزرسانی ناهمگام است. شناسه به‌روزرسانی را تا زمانی که موفقیت گزارش کند بررسی کنید، نه اینکه تعداد ثابتی ثانیه صبر کنید و فرض بگیرید. هنگام انجام این کار ترافیک نودها و صفحه کنترل را به حال خود بگذارید: جایگزین کردن کل گروه امنیتی کلاستر با قاعده‌ای برای لپ‌تاپ شما همان راهی است که یک صفحه داده سالم به حادثه دوم تبدیل می‌شود.

مستندات نقاط پایانی EKS ارزش یک بار خواندن کامل را دارد، چون می‌گوید دسترسی فقط خصوصی می‌تواند از VPC یا شبکه متصل بیاید. همان جمله تمام دلیل ممکن بودن این مهاجرت است و همچنین دلیل وجود گام بعدی.

3. ثابت کنید ایستگاه کار از مسیر خصوصی استفاده کرده است

با فعال بودن هر دو نقطه پایانی، موفقیت kubectl get ns هیچ چیز درباره اینکه کدام پاسخ داده ثابت نمی‌کند. نام میزبان نقطه پایانی را حل کنید و بررسی کنید آدرسی که گرفته‌اید به محدوده خصوصی تعلق دارد یا عمومی. اگر شبکه متصل شما نمای خصوصی را از طریق DNS دریافت نکند، دستور از طریق نقطه پایانی عمومی موفق می‌شود و مسیر عمومی را بر پایه شواهد نادرست بازنشسته می‌کنید. این رایج‌ترین راهی است که این مهاجرت اشتباه پیش می‌رود و دقیقاً شبیه موفقیت به نظر می‌رسد.

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

نام میزبان و اعتبارسنجی گواهی را دقیقاً همان‌گونه که هستند نگه دارید. جایگزین کردن یک IP خصوصی در kubeconfig و رد کردن بررسی TLS همان مهاجرتی نیست که در سابقه تغییر توصیف کردید و دوباره در لحظه‌ای که نقطه پایانی می‌چرخد شکست می‌خورد.

4. دسترسی عمومی را آگاهانه بازنشسته کنید

به‌محض اینکه مسیر خصوصی اثبات شد و گردش کار بازیابی تأیید شد، نقطه پایانی عمومی را ببندید. این یک تغییر واقعی است نه پیش‌نمایش، پس آن را روی حساب و تنظیماتی اجرا کنید که واقعاً منظورتان است.

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

در حالت فقط خصوصی، نام DNS عمومی از داخل VPC به آدرس‌های خصوصی نقطه پایانی حل می‌شود، پس حل شدن و دسترسی‌پذیری دیگر یکی نیستند. هر چیزی که به آدرس عمومی تکیه داشت، از جمله اجراکننده‌های CI یا لپ‌تاپی در شبکه‌ای دیگر، اکنون مسیر ورود خودش را لازم دارد.

5. سیاست شبکه و سیاست هویت را جدا نگه دارید

فهرست CIDR دسترسی عمومی فقط نقطه پایانی عمومی را اداره می‌کند. نقطه پایانی خصوصی را محدود نمی‌کند، که در عوض با گروه امنیتی کلاستر و سیاست شبکه متصل محدود می‌شود. اگر نقطه پایانی عمومی را نگه می‌دارید، فهرست مجاز آن باید با خروجی عمومی که کلاینت‌های API و نودهای شما واقعاً استفاده می‌کنند هم‌خوان باشد؛ آدرس استخر VPN به‌ندرت آن منبع است.

هیچ‌یک از این‌ها IAM یا Kubernetes RBAC را تغییر نمی‌دهد. تنظیمات نقطه پایانی یک اقدام مدیریتی است و کاربران عادی نباید اجازه شل کردن مرز را فقط برای رسیدن به API بگیرند. وضعیت نهایی، تاریخ و مسیر بازیابی را در رانبوک بنویسید، سپس مسیر بازیابی را یک بار وقتی هنوز آسان است آزمایش کنید.

مقالات مرتبط