مدیریت امنیت شبکه در یک محیط Kubernetes چندمستاجره (Multi-Tenant) معمولاً نیازمند ایجاد تعادل بین دو نیاز متفاوت است: توسعه‌دهندگان می‌خواهند مایکروسرویس‌هایشان به‌راحتی با یکدیگر ارتباط برقرار کنند، در حالی که تیم‌های پلتفرم و امنیت باید انطباق با مقررات (Compliance) را حفظ کنند، از حرکت جانبی (Lateral Movement) مهاجمان جلوگیری کنند و محدودیت‌های سراسری برای کل خوشه (Cluster-Wide Guardrails) تعیین نمایند.

از گذشته، NetworkPolicy استاندارد Kubernetes ابزار اصلی این کار بوده است. هرچند برای ایزوله‌سازی تک‌فضانامه (Single-Namespace) مؤثر است، اما NetworkPolicy استاندارد به‌طور دقیق به فضانامه‌های فردی محدود می‌شود و حول محور سلف‌سرویس توسعه‌دهندگان طراحی شده است. زمانی که مدیران خوشه بخواهند از آن برای اعمال امنیت سراسری استفاده کنند، با تضاد سیاست‌ها (Policy Conflicts) و چالش‌های عملیاتی مواجه می‌شوند.

🛡️ ClusterNetworkPolicy (CNP) چیست؟

برای حل این مشکل، گوگل ClusterNetworkPolicy (CNP) را معرفی کرده است — یک استاندارد متن‌باز که توسط گروه کاری SIG-Policy پروژه Kubernetes توسعه یافته و به سرویس Google Kubernetes Engine (GKE) اضافه شده است. CNP که برای مقیاس طراحی شده، یک منبع در سطح خوشه (Cluster-Wide Resource) است که به مدیران اجازه می‌دهد امنیت شبکه را به‌صورت متمرکز مدیریت کنند و سازوکاری برای مسئولان امنیت سراسری فراهم می‌آورد تا سیاست‌های یکپارچه و غیرقابل دور زدن (Non-Bypassable) پیاده‌سازی کنند.

🏗 سیستم سلسله‌مراتب (Tier System)

قابلیت اصلی ClusterNetworkPolicy، سیستم سلسله‌مراتب سطوح (Hierarchical Tier System) آن است. به‌جای تلاش برای سازش دادن همزمان قوانین مسطح و متضاد (Flat, Conflicting Rules)، CNP یک سلسله‌مراتب ارزیابی قطعی و از بالا به پایین (Deterministic, Top-to-Bottom Evaluation Hierarchy) برقرار می‌کند:

• سطح مدیریت (Admin Tier): بالاترین سطح اولویت. قوانین این سطح قبل از هر سیاست دیگری اعمال می‌شوند.
• سطح سیاست شبکه (Network Policy Tier): سطح استاندارد فضانامه، جایی که توسعه‌دهندگان سیاست‌های اپلیکیشن خود را مدیریت می‌کنند.
• سطح پایه (Baseline Tier): کمترین اولویت؛ رفتار پیش‌فرض خوشه را زمانی که هیچ سیاست دیگری اعمال نمی‌شود تعیین می‌کند و می‌تواند با سیاست‌های سطح فضانامه بازنویسی شود.

این ساختار لایه‌ای به هماهنگ‌سازی امنیت شبکه با نقش‌های سازمانی کمک می‌کند. با استفاده از کنترل دسترسی مبتنی بر نقش (RBAC) استاندارد، می‌توانید سطح مدیریت را برای اعمال الزامات انطباق مدیریت کنید، تیم‌های پلتفرم می‌توانند از سطح پایه برای تعیین حالت پیش‌فرض «رد همه» (Deny-All) با رویکرد صفر اعتماد (Zero-Trust) در کل خوشه استفاده کنند، و در همان زمان توسعه‌دهندگان می‌توانند سیاست‌های شبکه استاندارد را برای اپلیکیشن‌های خود بنویسند بدون اینکه الزامات امنیتی اصلی را بازنویسی کنند.

🔀 اکشن Pass: تفویض هوشمند تصمیم

این روش ارزیابی قطعی از بالا به پایین، تضاد بین سیاست‌های تیم‌های مختلف را حل می‌کند. سطح مدیریت یک اکشن صریح Pass معرفی می‌کند که به تیم‌های امنیتی اجازه می‌دهد ترافیک را با قوانین سراسری بررسی کنند و سپس تصمیم نهایی Accept یا Deny را به سیاست فضانامه توسعه‌دهنده واگذار کنند. این ویژگی هم نظارت متمرکز (Central Oversight) و هم مدیریت توزیع‌شده (Distributed Management) را همزمان ممکن می‌سازد.

📋 موارد استفاده رایج

این معماری لایه‌ای، الزامات امنیتی پیچیده را به قوانین متمرکز ساده تبدیل می‌کند. سناریوهای رایجی که ClusterNetworkPolicy راه‌حل عملی ارائه می‌دهد:

• ایزوله‌سازی workloadهای حساس: می‌توانید یک قانون رد سراسری در سطح مدیریت اعمال کنید تا فضانامه‌های خاص — مانند آن‌هایی که برای پردازش پرداخت یا داده‌های انطباقی استفاده می‌شوند — از بقیه خوشه ایزوله شوند. این اکشن هر سیاست توسعه‌دهنده سهل‌گیرانه‌ای که ممکن است این محیط‌ها را در معرض خطر قرار دهد، بازنویسی می‌کند.
• محافظت از سرویس‌های حیاتی: برای جلوگیری از پیکربندی‌هایی که ممکن است عملیات داخلی را مختل کنند، مدیران می‌توانند یک قانون Allow سراسری در سطح مدیریت برای سرویس‌های حیاتی مانند kube-dns ایجاد کنند. این اطمینان را می‌دهد که این سرویس‌ها بدون توجه به هر سیاست فضانامه‌ای که اشتباه پیکربندی شده، قابل دسترس باقی بمانند.
• مدیریت ترافیک خروجی (Egress): با استفاده از تطبیق محدوده آدرس IP، ترافیک خروجی می‌تواند در سطح خوشه کنترل شود. این قابلیت به شما اجازه می‌دهد دسترسی به شبکه‌های داخلی سازمان یا محدوده‌های IP خارجی را به‌صراحت محدود یا مجاز کنید و به‌عنوان محافظی در برابر خروج غیرمجاز داده (Data Exfiltration) عمل می‌کند.

📝 مثال عملی: گاردریل ایزوله‌سازی پلتفرم

یک نیاز رایج سازمانی را در نظر بگیرید: workloadهای اپلیکیشن در همه فضانامه‌ها باید اجازه دسترسی به زیرساخت‌های مرکزی پلتفرم (مانند سرویس‌های احراز هویت و تله‌متری مشترک) را داشته باشند، در حالی که دسترسی به محیط‌های حساس — مانند یک فضانامه Vault محدود — به‌شدت ممنوع است. در عین حال، ترافیک معمول مایکروسرویس‌ها به سیاست‌های سطح فضانامه که توسط توسعه‌دهندگان مدیریت می‌شود، واگذار شده است.

ClusterNetworkPolicy این کار را ساده می‌کند. مدیر پلتفرم به‌سادگی یک گاردریل در سطح مدیریت به‌صورت متمرکز تعریف می‌کند:

apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: platform-isolation-guardrail
spec:
  tier: Admin
  priority: 10
  subject:
    # Target all application tenant namespaces, excluding system and core infrastructure
    namespaces:
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["kube-system", "shared-services", "restricted-vault"]
  egress:
    # 1. Mandate access to central shared platform services
    - name: allow-shared-services
      action: Accept
      to:
      - namespaces:
          matchLabels:
            kubernetes.io/metadata.name: shared-services

    # 2. Enforce strict block on accessing the restricted vault namespace
    - name: block-restricted-vault
      action: Deny
      to:
      - namespaces:
          matchLabels:
            kubernetes.io/metadata.name: restricted-vault

    # 3. Explicitly delegate all remaining traffic to developer namespace policies
    - name: delegate-remaining-egress
      action: Pass
      to:
      - namespaces: {}
      - networks:
        - 0.0.0.0/0
        - ::/0

🌍 توسعه بر پایه استانداردهای متن‌باز

به‌جای ساخت این قابلیت به‌صورت افزونه‌های اختصاصی (Proprietary Extensions)، گوگل با جامعه Kubernetes همکاری کرد تا API مستقل ClusterNetworkPolicy (policy.networking.k8s.io) را طراحی کند — آن را از API فضانامه‌محور NetworkPolicy (networking.k8s.io) متمایز می‌کند. علاوه بر این، گوگل با جامعه Cilium همکاری نزدیکی داشته تا پیاده‌سازی این API را بسازد.

چون این سیستم بر استانداردهای متن‌باز ساخته شده، GKE اطمینان می‌دهد که پیکربندی‌های امنیتی در محیط‌های مختلف قابل حمل (Portable) باقی می‌مانند. API ClusterNetworkPolicy به‌صورت بومی از انتخاب سطح (Tier Selection) پشتیبانی می‌کند و ارزیابی سیاست را شفاف و قطعی می‌سازد. این رویکرد به مدیران اجازه می‌دهد گاردریل‌های امنیتی مستحکمی اعمال کنند و در عین حال انعطاف عملیاتی مورد نیاز تیم‌های توسعه را حفظ کنند.

✅ جمع‌بندی

ClusterNetworkPolicy در GKE امنیت شبکه workloadها را ارتقا می‌دهد — عملیات را از قوانین محدود به فضانامه به حاکمیت یکپارچه و سراسری خوشه منتقل می‌کند. این قابلیت در حال حاضر در نسخه پیش‌نمایش (Preview) از نسخه ۱.۳۶ به بعد در دسترس است. برای یادگیری بیشتر و شروع کار، می‌توانید مشخصات API ClusterNetworkPolicy گروه SIG-Network پروژه Kubernetes را مطالعه کنید.

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

منبع اصلی: New ClusterNetworkPolicy in GKE | Google Cloud Blog — نویسندگان: Srini Jasti و Blaz Zupan