مدل امنیتی مبتنی بر محیطمحیط سنتی در محیطهای مدرن بومی ابری منسوخ شده است. در یک خوشه کوبرنیتس، بارهای کاری گذرا، پویا و دائماً در حال مقیاسپذیری هستند. تکیه صرف بر دیوارهای آتش در لبه شبکه کافی نیست زمانی که بازیگران مخرب محیط را نفوذ میکنند. اینجاست که دسترسی شبکه با اعتماد صفر (ZTNA) حیاتی میشود. به طور خاص، ایمنسازی ترافیک شرق-غرب—ارتباط بین پادها درون خوشه—نیازمند تغییر از اعتماد ضمنی به تأیید صریح است.
این راهنما بررسی میکند که چگونه اصول ZTNA را در کوبرنیتس با استفاده از سیاستهای شبکه بومی و پراکسیهای آگاه از هویت (IAP) پیادهسازی کنیم. ما فراتر از قوانین ساده «اجازه همه» حرکت میکنیم تا مدلی را ایجاد کنیم که در آن هر فراخوان سرویس، فارغ از مبدأ آن، احراز هویت و مجوزدهی میشود.
چالش ترافیک شرق-غرب
در یک معمونی تکتوده، ترافیک شرق-غرب اغلب نادیده گرفته میشود زیرا همه چیز در یک شبکه قابل اعتماد یکسان زندگی میکند. با این حال، در کوبرنیتس، نفوذ یک پاد واحد میتواند به یک مهاجم اجازه دهد تا خوشه را اسکن کرده و به صورت جانبی به پایگاههای داده حیاتی یا رابطهای مدیریتی حرکت کند. بدون جداسازی سختگیرانه، شعاع انفجار یک نفوذ قابل توجه است. ZTNA با اطمینان از اینکه هیچ پادی نمیتواند با پاد دیگر صحبت کند مگر اینکه به صراحت توسط هویت مجاز شده باشد، نه فقط با آدرس IP، به این موضوع میپردازد.
لایه ۱: سیاستهای شبکه با جزئیات دقیق
لایه اول دفاع، NetworkPolicy کوبرنیتس است. این منابع بومی به شما اجازه میدهند قوانینی برای ارتباط پاد-به-پاد تعریف کنید. اگرچه سیاستهای شبکه استاندارد به خودی خود آگاه از هویت نیستند (آنها بر برچسبهای پاد و نامفضاها متکی هستند)، اما اسکلتبندی معماری Zero Trust ما را تشکیل میدهند. به طور پیشفرض، باید یک سیاست «مسدود کردن همه» ورودی را برای هر نامفضا اعمال کنید.
سناریویی را در نظر بگیرید که یک برنامه فرانتاند نیاز دارد با یک API بکاند ارتباط برقرار کند، اما هیچ سرویس دیگری نباید به API دسترسی داشته باشد. شما میتوانید این کار را با برچسبگذاری پادها و اعمال یک قانون ورودی خاص انجام دهید.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-backend-access
namespace: production
spec:
podSelector:
matchLabels:
app: backend-api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend-app
ports:
- protocol: TCP
port: 8080در این مثال، تنها پادهایی که برچسب app: frontend-app را در همان نامفضا دارند میتوانند به بکاند روی پورت ۸۰۸۰ دسترسی پیدا کنند. هرگونه ترافیک دیگر توسط پلاگین رابط شبکه کانتینری (CNI) دور انداخته میشود و جداسازی سختگیرانه را اعمال میکند.
لایه ۲: پراکسیهای آگاه از هویت
در حالی که سیاستهای شبکه کنترل میکنند که ترافیک *کجا* میتواند برود، ZTNA نیازمند کنترل *چه کسی* درخواست را ارسال میکند است. اینجاست که یک پراکسی آگاه از هویت (IAP) وارد میشود. یک IAP بین کلاینتها و سرویسها قرار میگیرد و هویت فرستنده را قبل از اجازه اتصال تأیید میکند. در زمینه کوبرنیتس، این اغلب شامل استفاده از یک شبکه سرویسدهی مانند Istio یا یک پراکسی کناری اختصاصی است که توکنهای JWT یا اعتبارنامههای OAuth2 را اعتبارسنجی میکند.
با تزریق یک پراکسی کناری به هر پاد، میتوانید الزام کنید که درخواستها دارای توکنهای احراز هویت معتبر باشند. اگر درخواست فاقد توکن معتبر باشد، پراکسی اتصال را بلافاصله قطع میکند و حتی اگر مهاجم از سیاست شبکه عبور کند (مثلاً از طریق فرار از کانتینر)، حرکت جانبی را جلوگیری میکند.
پیادهسازی هویت از طریق شبکه سرویسدهی
استفاده از یک شبکه سرویسدهی به شما اجازه میدهد تأیید هویت را از کد برنامه خود خارج کنید. میتوانید AuthorizationPolicies را تعریف کنید که موضوع درخواست ورودی را با لیستی از هویتهای مجاز بررسی میکند.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-oidc
namespace: production
spec:
selector:
matchLabels:
app: backend-api
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/frontend-sa"]این سیاست تضمین میکند که تنها frontend-sa (حساب سرویس) در نامفضای تولید مجاز به فراخوانی بکاند است. حتی اگر یک IP خارجی تلاش کند ترافیک را جعل کند، تأیید هویت شکست میخورد.
جمعبندی همه موارد
ZTNA مؤثر در کوبرنیتس درباره انتخاب بین سیاستهای شبکه و پراکسیهای آگاه از هویت نیست؛ بلکه درباره لایهبندی آنهاست. سیاستهای شبکه جداسازی شبکه لازم را برای محدود کردن سطح حمله فراهم میکنند، در حالی که IAP اطمینان حاصل میکند که ترافیک عبور از آن بخشها احراز هویت و مجوزدهی میشود.
هنگام پیادهسازی این موارد، به خاطر داشته باشید که امنیت تکراری است. با فعال کردن یک سیاست «مسدود کردن همه» برای درک جریانهای ترافیک خود شروع کنید، سپس به تدریج قوانین «اجازه» را معرفی کنید. همزمان، به سمت یک شبکه سرویسدهی یا الگوی کناری مهاجرت کنید تا تأیید هویت را معرفی کنید. با ترکیب این استراتژیها، شما یک معماری دفاع در عمق قوی ایجاد میکنید که میکروسرویسهای شما را در برابر پیچیدهترین تهدیدات محافظت میکند.
پذیرش Zero Trust یک سفر است، اما تنها مسیر قابل قبول برای ایمنسازی برنامههای مدرن و پویا در ابر است.