آموزش نصب و پیکربندی Cilium در Kubernetes – بخش ۵

cilium-kubernetes-ebpf

در بخش پنجم از سلسه مطلب «آموزش نصب و پیکربندی Cilium در Kubernetes» ، قصد داریم تا در مورد L3/L4 Policy صحبت کنیم.

اعمال L3/L4 Policy:

هنگام استفاده از Cilium، آدرس های endpoint IP هنگام تعریف سیاست های امنیتی (security policies) بی ربط هستند. در عوض، می‌توانید از برچسب‌های (labels) اختصاص داده شده به pod ها برای تعریف سیاست‌های امنیتی استفاده کنید. این سیاست ها بر اساس برچسب‌ها (labels)، صرف نظر از اینکه کجا یا چه زمانی در داخل کلاستر اجرا می‌شود، روی pod های مناسب اعمال می‌شوند.

ما با سیاست پایه ای (basic policy) شروع می‌کنیم که درخواست‌های فرود deathstar را فقط به فضاپیماهایی که دارای برچسب (org=empire) هستند محدود می‌کند. این به هیچ یک از فضاپیماهایی که برچسب org=empire را ندارند اجازه نمی‌دهد حتی با سرویس deathstar ارتباط برقرار کنند. این یک سیاست ساده (simple policy) است که فقط روی پروتکل IP (لایه 3 شبکه) و پروتکل TCP (لایه 4 شبکه) فیلتر می شود، بنابراین اغلب به عنوان یک سیاست امنیتی شبکه L3/L4 نامیده می شود (L3/L4 network security policy).

نکته: Cilium در واقع stateful connection tracking را انجام می‌دهد، به این معنی که اگر policy به frontend اجازه دسترسی به backend را بدهد، به‌طور خودکار به تمام بسته‌های پاسخ مورد نیاز که بخشی از پاسخ‌دهی backend به frontend هستند در چارچوب همان اتصال TCP/UDP اجازه می‌دهد.

L4 Policy با Cilium و Kubernetes:

cilium_http_l3_l4_gsg

با استفاده از CiliumNetworkPolicy زیر می توانیم اینکار را انجام دهیم:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "rule1"
spec:
  description: "L3-L4 policy to restrict deathstar access to empire ships only"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
  - fromEndpoints:
    - matchLabels:
        org: empire
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

CiliumNetworkPolicies با استفاده از “endpointSelector” برای شناسایی sources و destination هایی که این policy برای آنها اعمال می‌شود که با label های pod مطابقت دارند. Policy بالا، ترافیک ارسال شده از هر pod دارای برچسب (org=empire) به pod های deathstar با برچسب (org=empire، class=deathstar) را در پورت TCP 80 در whitelists قرار می دهد.

برای apply کردن این L3/L4 policy می توان دستور زیر را اجرا کرد:

kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.12/examples/minikube/sw_l3_l4_policy.yaml

حال اگر درخواست های فرود را دوباره اجرا کنیم، فقط pod های tiefighter با برچسب org=empire موفق خواهند شد. Pod های xwing مسدود خواهند شد!

kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

این همانطور که انتظار می رود کار می کند. اکنون همان درخواست اجرا شده از یک پاد xwing ناموفق خواهد بود:

kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing

این درخواست hang می کند، بنابراین جهت kill کردن curl کلیدهای Control-C را فشار دهید، یا منتظر بمانید تا time out شود. یک نمونه خروجی از اجرای دستورهای گفته شده را در تصویر پایین مشاهده می کنید:

cilium-policy-output

Inspecting the Policy

اگر cilium endpoint list را دوباره اجرا کنیم، می‌بینیم که pod های دارای برچسب org=empire و class=deathstar اکنون طبق policy بالا، ingress policy enforcement را فعال کرده‌اند:

kubectl -n kube-system exec cilium-rwmwr -- cilium endpoint list

یک نمونه خروجی از اجرای دستور گفته شده را در تصویر پایین مشاهده می کنید:

endpoint-list

شما همچنین می توانید جزئیات policy را از طریق kubectl بررسی کنید:

kubectl get cnp
kubectl describe cnp rule1

یک نمونه خروجی از اجرای دستور گفته شده را در تصویر پایین مشاهده می کنید:

cilium-cnpادامه دارد …

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.