چرا kubectl از طریق VPN کار می‌کند اما AKS مقیاس‌بندی را متوقف می‌کند

آدرس عمومی VPN دفتر را به فهرست مجاز سرور API در AKS اضافه می‌کنید و kubectl کار می‌کند. یک هفته بعد، مقیاس‌بندی یک node pool شکست می‌خورد، یک کار CI نمی‌تواند به خوشه برسد و پورتال خطایی نشان می‌دهد که هیچ اشاره‌ای به محدوده‌های IP ندارد. هیچ‌کس فهرست مجاز را تغییر نداده است. کنترلی که فعال کرده‌اید یک فیلتر IP عمومی جلوی سرور API است و نمی‌داند چه کسی تماس می‌گیرد، فقط می‌داند تماس از کدام آدرس آمده است. VPN یکی از چند آدرسی است که خوشه به آن نیاز دارد و به‌ندرت همان اولی است که می‌شکند.

فهرست مجاز با یک آدرس مطابقت دارد، نه با یک شخص

--api-server-authorized-ip-ranges بلوک‌های CIDR را می‌پذیرد، نه کاربران یا گروه‌ها را. وقتی درخواست یک توسعه‌دهنده از سرور VPN به سمت Azure خارج می‌شود، آدرس مبدأ در سرور API همان خروجی عمومی سرور VPN است. بنابراین هر کسی در آن VPN یک ورودی مشترک دارد و هر کسی خارج از VPN پیش از آنکه احراز هویت حتی رخ دهد رد می‌شود.

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

چیزی که اول می‌شکند معمولاً kubectl نیست

فهرست مجاز برای نقطه پایانی عمومی سرور API اعمال می‌شود، بنابراین هر چیزی بیرون از آدرس‌های فهرست‌شده شما بلافاصله از کار می‌افتد. قربانیان آشکار، دفتر دوم بدون مسیر VPN، یک اجراکننده CI در یک خط لوله میزبانی‌شده و لپ‌تاپی هستند که اتصال را فراموش کرده است. این‌ها آسان تشخیص داده می‌شوند چون انسانی در انتظار است.

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

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

کل فهرست را در یک دستور بسازید

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

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

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

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

آنچه فهرست مجاز هرگز پوشش نداد

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

هیچ ارتباطی با بارهای کاری ندارد. Pods و Services با فعال بودن فهرست به کار ادامه می‌دهند، و رسیدن به یک برنامه از طریق VPN مسئله‌ای جداست: Service که فقط یک IP خوشه‌ای دارد هنوز به یک متعادل‌کننده بار داخلی، یک ingress یا یک port-forward نیاز دارد تا لپ‌تاپی بتواند آن را باز کند. آمیختن این دو طراحی بلیت تغییری می‌سازد که ادعا می‌کند توسعه‌دهندگان را محدود می‌کند و در واقع چیزی از برنامه‌ها را محدود نمی‌کند.

از هر دو طرف بررسی کنید، سپس یک عملیات واقعی اجرا کنید

با یک کلاینت تازه در VPN و با کلاینتی بیرون از آن آزمایش کنید. تلاش بیرونی باید در سرور API رد شود، نه در حل نام؛ اگر نام حل نمی‌شود، شما در حال آزمایش DNS هستید و چیزی درباره فیلتر یاد نگرفته‌اید. سپس عملیاتی را اجرا کنید که یک فراخوانی تعاملی kubectl نیست، مانند مقیاس‌بندی node pool یا بررسی ارتقا، و تأیید کنید که کامل می‌شود به جای آنکه فرض کنید خواهد شد.

مقدار قبلی فهرست را کنار تغییر ثبت کنید و مقدار مؤثر را پس از به‌روزرسانی دوباره بخوانید، به جای اعتماد به دستور تایپ‌شده. مستندات AKS درباره محدوده‌های IP مجاز پارامترهای پشتیبانی‌شده و الزامات پلتفرم را که به همان فهرست تعلق دارند فهرست می‌کند و این همان بخشی است که بیشتر توصیف‌های بلیت آن را جا می‌اندازند.