آموزش Certified Kubernetes Security Specialist (CKS) جلد اول

تهدیدهای امنیتی در Kubernetes

در محیط‌های Kubernetes، چندین نوع تهدید امنیتی وجود دارد که باید به آن‌ها توجه شود:

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

اقدامات امنیتی اولیه در Kubernetes

برای تأمین امنیت در محیط Kubernetes، اقدامات اولیه‌ای که باید انجام شوند شامل موارد زیر است:

1. اعمال سیاست‌های کنترل دسترسی (RBAC)

RBAC (Role-Based Access Control) یکی از مهم‌ترین قابلیت‌های امنیتی Kubernetes است که کنترل دسترسی کاربران به منابع را مدیریت می‌کند. برای مثال، برای تعریف یک نقش فقط خواندنی برای یک کاربر خاص می‌توان از فایل زیر استفاده کرد:

مسیر فایل: role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: read-only-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

اعمال نقش به کاربر:

kubectl apply -f role.yaml
kubectl create rolebinding read-only-binding --role=read-only-role --user=username --namespace=default

2. محدودسازی ارتباطات شبکه‌ای با استفاده از Network Policy

Network Policyها ارتباطات بین پادها را کنترل کرده و از حملات داخلی جلوگیری می‌کنند.

مسیر فایل: network-policy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Ingress
  - Egress
  ingress: []
  egress: []

اعمال سیاست:

kubectl apply -f network-policy.yaml

3. استفاده از Pod Security Standards (PSS)

برای اعمال استانداردهای امنیتی بر روی پادها، می‌توان از Pod Security Admission استفاده کرد. برای مثال، اجرای یک پاد با حداقل مجوزهای لازم:

مسیر فایل: restricted-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: default
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL

اجرای پاد:

kubectl apply -f restricted-pod.yaml

4. بررسی و اعتبارسنجی تصاویر کانتینر

استفاده از ابزارهایی مانند Trivy برای بررسی آسیب‌پذیری‌های موجود در تصاویر Docker:

trivy image nginx:latest

برای اعمال اعتبارسنجی قبل از اجرای پادها، می‌توان از Admission Controller مانند Gatekeeper استفاده کرد.

5. مانیتورینگ و ثبت لاگ‌ها

فعال‌سازی و نظارت مداوم بر رخدادهای Kubernetes از طریق ابزارهایی مانند Falco:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco

Falco به صورت خودکار رویدادهای مشکوک را شناسایی کرده و گزارش می‌دهد.

جمع‌بندی

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

نقش‌های کلیدی در امنیت Kubernetes

1. مدیر خوشه (Cluster Administrator)
   • دسترسی کامل به منابع Kubernetes و مدیریت کلیه تنظیمات امنیتی.
   • پیکربندی و نگهداری کنترل‌های امنیتی مانند RBAC، Network Policies و Pod Security Standards.
   • مدیریت بروزرسانی‌ها و اعمال اصلاحیه‌های امنیتی.
2. مدیر امنیت (Security Administrator)
   • نظارت و اعمال سیاست‌های امنیتی.
   • بررسی رخدادهای امنیتی و اعمال اقدامات اصلاحی.
   • پیکربندی و مانیتورینگ مکانیزم‌های تشخیص نفوذ (IDS/IPS).
3. مدیر شبکه (Network Administrator)
   • مدیریت سیاست‌های شبکه (Network Policies) برای محدودسازی ارتباطات غیرضروری.
   • پیکربندی و نظارت بر فایروال‌های مبتنی بر Kubernetes.
   • مدیریت ingress و egress ترافیک.
4. توسعه‌دهنده (Developer)
   • پیاده‌سازی بهترین شیوه‌های امنیتی در کدها و کانتینرها.
   • استفاده از امضاهای دیجیتال برای تضمین یکپارچگی تصاویر کانتینری.
   • پایبندی به اصل کمترین سطح دسترسی (Least Privilege).
5. اپراتور (Operator)
   • استقرار و نگهداری بارهای کاری (Workloads) در خوشه.
   • رعایت سیاست‌های امنیتی در استقرار برنامه‌ها.
   • نظارت بر لاگ‌های اجرایی جهت شناسایی تهدیدات.

تنظیم دسترسی‌ها با استفاده از RBAC

یکی از ابزارهای اصلی مدیریت دسترسی در Kubernetes، Role-Based Access Control (RBAC) است. این سیستم کنترل دسترسی امکان تعریف نقش‌ها (Roles) و اختصاص آن‌ها به کاربران و سرویس‌ها را فراهم می‌کند.

تعریف یک Role برای محدودسازی دسترسی به Namespace خاص

مسیر فایل: /etc/kubernetes/rbac/namespace-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-namespace
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "create", "delete"]

اختصاص یک Role به یک کاربر خاص

مسیر فایل: /etc/kubernetes/rbac/role-binding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-namespace
  name: developer-binding
subjects:
- kind: User
  name: developer1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

بررسی تنظیمات RBAC با استفاده از kubectl

kubectl get roles --namespace=my-namespace
kubectl get rolebindings --namespace=my-namespace
kubectl auth can-i create pods --as=developer1 --namespace=my-namespace

مدیریت سیاست‌های شبکه برای تفکیک دسترسی‌ها

برای کنترل ارتباطات بین پادها، باید از Network Policies استفاده کرد. این سیاست‌ها ارتباط بین منابع داخل خوشه را محدود کرده و از دسترسی‌های غیرمجاز جلوگیری می‌کنند.

تعریف یک NetworkPolicy برای مسدودسازی ترافیک ورودی به پادها

مسیر فایل: /etc/kubernetes/network/network-policy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: my-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress

اعمال تنظیمات

kubectl apply -f /etc/kubernetes/network/network-policy.yaml
kubectl get networkpolicy -n my-namespace

جمع‌بندی

در Kubernetes، تفکیک مسئولیت‌ها یکی از مهم‌ترین اصول امنیتی است که اجرای صحیح آن می‌تواند سطح حملات را به حداقل برساند. با استفاده از RBAC برای کنترل دسترسی، اعمال سیاست‌های شبکه برای محدودسازی ارتباطات و تعریف نقش‌های امنیتی مشخص، می‌توان از امنیت محیط Kubernetes اطمینان حاصل کرد. اجرای دقیق این موارد نیازمند هماهنگی بین تیم‌های مختلف و نظارت مداوم بر پیکربندی‌های امنیتی است.

• Control Plane Security (امنیت صفحه کنترل)
• Data Plane Security (امنیت صفحه داده)
• Node Security (امنیت نودها)

امنیت Control Plane

Control Plane مسئول مدیریت کل خوشه Kubernetes است و شامل اجزای کلیدی مانند API Server، Controller Manager، Scheduler و غیره می‌باشد. امنیت این بخش بسیار حیاتی است، زیرا در صورت دسترسی غیرمجاز، می‌توان کنترل کامل خوشه را در دست گرفت.

۱. محدودسازی دسترسی به API Server

API Server مهم‌ترین نقطه ورود به Kubernetes است. برای محافظت از آن:

• استفاده از RBAC (Role-Based Access Control):

فایل ClusterRole زیر، فقط دسترسی به مشاهده پادها را فراهم می‌کند:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-pods
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

سپس این ClusterRole را به یک کاربر اختصاص دهید:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: view-pods-binding
  namespace: default
subjects:
- kind: User
  name: example-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view-pods
  apiGroup: rbac.authorization.k8s.io

اعمال تغییرات:

kubectl apply -f clusterrole.yaml
kubectl apply -f rolebinding.yaml

۲. فعال‌سازی Audit Logging در API Server

برای نظارت بر فعالیت‌های کاربران، Audit Logging را فعال کنید. مسیر فایل پیکربندی:

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml و افزودن تنظیمات زیر:

- --audit-log-path=/var/log/kubernetes/audit.log
- --audit-log-maxage=30
- --audit-log-maxbackup=10
- --audit-log-maxsize=100

اعمال تغییرات:

systemctl restart kubelet

امنیت Data Plane

Data Plane شامل منابع اجرایی مانند پادها، سرویس‌ها و شبکه است. برای افزایش امنیت این بخش:

۱. استفاده از Network Policies

یک Network Policy برای مسدود کردن ترافیک ورودی به جز از یک Namespace خاص:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-traffic
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: restricted
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: trusted

اعمال تنظیمات:

kubectl apply -f network-policy.yaml

۲. فعال‌سازی Pod Security Standards (PSS)

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-pss
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535
  readOnlyRootFilesystem: true

اعمال تنظیمات:

kubectl apply -f pss.yaml

امنیت Node Security

نودها پایه اجرای Kubernetes هستند. برای افزایش امنیت نودها:

۱. محدود کردن دسترسی SSH به نودها

nano /etc/ssh/sshd_config

افزودن تنظیمات:

PermitRootLogin no
PasswordAuthentication no
AllowUsers kubernetes-admin

اعمال تغییرات:

systemctl restart sshd

۲. استفاده از AppArmor برای محدودسازی اجرای فرایندها

apt install apparmor-utils -y

فعال‌سازی یک پروفایل محدودکننده برای Nginx:

nano /etc/apparmor.d/usr.sbin.nginx

افزودن محتوا:

profile nginx-profile /usr/sbin/nginx {
  include <abstractions/base>
  capability net_bind_service
  deny network raw
  file,
}

اعمال تغییرات:

apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

جمع‌بندی

در این بخش، سه لایه امنیتی اصلی در Kubernetes مورد بررسی قرار گرفت:

• Control Plane Security: ایمن‌سازی API Server، محدودسازی دسترسی و فعال‌سازی Audit Logging.
• Data Plane Security: اعمال Network Policies و محدودسازی سطح دسترسی پادها.
• Node Security: ایمن‌سازی نودها با محدودسازی دسترسی SSH و استفاده از AppArmor.

با اجرای این اقدامات، امنیت کلی خوشه Kubernetes به طور قابل‌توجهی افزایش می‌یابد.

• احراز هویت (Authentication): بررسی و تأیید هویت کاربران یا سرویس‌ها.
• اجازه‌نامه (Authorization): تعیین سطح دسترسی کاربران پس از احراز هویت موفقیت‌آمیز.

احراز هویت (Authentication)

Kubernetes به‌صورت پیش‌فرض مکانیسم احراز هویت داخلی ندارد و نیاز به پیاده‌سازی روش‌های خارجی دارد. برخی از متداول‌ترین روش‌های احراز هویت در Kubernetes شامل موارد زیر است:

• X.509 Client Certificates
• Static Token File
• Bootstrap Tokens
• Service Account Tokens
• OpenID Connect (OIDC)
• Webhook Token Authentication

تنظیم احراز هویت با استفاده از گواهی‌های X.509

برای استفاده از گواهی‌های X.509 جهت احراز هویت کاربران، باید یک CA (Certificate Authority) برای امضای گواهی‌ها ایجاد شود.

ایجاد کلید خصوصی و درخواست امضای گواهی (CSR):

openssl genrsa -out user.key 2048
openssl req -new -key user.key -out user.csr -subj "/CN=example-user/O=developers"

امضای گواهی با استفاده از CA:

openssl x509 -req -in user.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user.crt -days 365

افزودن کاربر به kubeconfig:

kubectl config set-credentials example-user \
  --client-certificate=user.crt \
  --client-key=user.key

اجازه‌نامه (Authorization)

پس از احراز هویت، Kubernetes نیاز دارد تا بررسی کند که کاربر مجاز به انجام درخواست خود است. این فرآیند شامل چندین روش است:

• RBAC (Role-Based Access Control)
• ABAC (Attribute-Based Access Control)
• Node Authorization
• Webhook Authorization

تنظیم RBAC در Kubernetes

ایجاد یک Role برای خواندن پادها:

مسیر فایل: role-pod-reader.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ایجاد RoleBinding برای کاربر:

مسیر فایل: rolebinding-example-user.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: example-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

اعمال Role و RoleBinding:

kubectl apply -f role-pod-reader.yaml
kubectl apply -f rolebinding-example-user.yaml

جمع بندی

مدیریت هویت و دسترسی‌ها در Kubernetes از دو بخش احراز هویت و اجازه‌نامه تشکیل شده است. احراز هویت تأیید می‌کند که کاربر چه کسی است و از روش‌های مختلفی مانند گواهی‌های X.509، OpenID Connect و توکن‌ها پشتیبانی می‌کند. پس از احراز هویت، Kubernetes از مکانیزم‌های کنترل دسترسی مانند RBAC برای تعیین مجوز کاربران استفاده می‌کند. با پیکربندی صحیح این قابلیت‌ها، امنیت خوشه Kubernetes تا حد زیادی افزایش می‌یابد.

• اجزای Control Plane
• اجزای Node

در ادامه، به بررسی مهم‌ترین این اجزا و نحوه تعامل آن‌ها با یکدیگر می‌پردازیم.

API Server

API Server مهم‌ترین جزء Control Plane است که تمامی ارتباطات داخلی و خارجی خوشه را مدیریت می‌کند. این سرویس درخواست‌های کاربر، سایر کامپوننت‌ها و kubectl را دریافت کرده و پردازش می‌کند.

بررسی پیکربندی API Server

فایل پیکربندی این سرویس معمولاً در مسیر زیر قرار دارد:

/etc/kubernetes/manifests/kube-apiserver.yaml

برای مشاهده وضعیت API Server می‌توان از دستور زیر استفاده کرد:

kubectl get pod -n kube-system -l component=kube-apiserver

Scheduler

Scheduler وظیفه زمان‌بندی و تخصیص Podها به نودهای مناسب را بر عهده دارد. این سرویس وضعیت نودها و منابع آن‌ها را بررسی کرده و براساس سیاست‌های زمان‌بندی، یک نود مناسب برای اجرای هر Pod انتخاب می‌کند.

بررسی پیکربندی Scheduler

فایل تنظیمات مربوط به Scheduler در مسیر زیر قرار دارد:

/etc/kubernetes/manifests/kube-scheduler.yaml

برای بررسی وضعیت آن، از دستور زیر استفاده کنید:

kubectl get pod -n kube-system -l component=kube-scheduler

Controller Manager

Controller Manager شامل مجموعه‌ای از کنترلرهای داخلی Kubernetes است که مسئولیت‌های مختلفی مانند مدیریت Nodeها، تنظیم ReplicaSet، و هماهنگی بین اجزا را بر عهده دارند.

بررسی پیکربندی Controller Manager

فایل تنظیمات این سرویس در مسیر زیر قرار دارد:

/etc/kubernetes/manifests/kube-controller-manager.yaml

برای بررسی وضعیت این سرویس، دستور زیر را اجرا کنید:

kubectl get pod -n kube-system -l component=kube-controller-manager

Etcd

Etcd پایگاه‌داده توزیع‌شده‌ای است که تمام اطلاعات خوشه Kubernetes را ذخیره می‌کند. این سرویس نقش کلیدی در پایداری و مدیریت داده‌های Kubernetes دارد.

بررسی وضعیت Etcd

فایل پیکربندی این سرویس در مسیر زیر قرار دارد:

/etc/kubernetes/manifests/etcd.yaml

برای بررسی وضعیت Etcd، از دستور زیر استفاده کنید:

kubectl get pod -n kube-system -l component=etcd

Kubelet

Kubelet یکی از اجزای مهم Node است که وظیفه اجرای کانتینرها را بر عهده دارد. این سرویس دستورات را از API Server دریافت کرده و اجرای Podها را روی نودها کنترل می‌کند.

بررسی پیکربندی Kubelet

فایل پیکربندی Kubelet معمولاً در مسیر زیر قرار دارد:

/etc/kubernetes/kubelet.conf

برای مشاهده وضعیت Kubelet، از دستور زیر استفاده کنید:

systemctl status kubelet

راه‌اندازی مجدد Kubelet در صورت نیاز:

systemctl restart kubelet

ارتباط بین اجزای Kubernetes

اجزای Control Plane از طریق API Server با یکدیگر و با نودها ارتباط برقرار می‌کنند. Etcd به عنوان پایگاه‌داده مرکزی، اطلاعات مربوط به وضعیت خوشه را ذخیره و بازیابی می‌کند. نودها نیز از طریق Kubelet اطلاعات لازم را دریافت کرده و به API Server ارسال می‌کنند.

مشاهده ارتباطات اجزا با استفاده از kubectl:

kubectl get componentstatuses

مشاهده لاگ‌های API Server:

kubectl logs -n kube-system -l component=kube-apiserver

جمع‌بندی

در این بخش اجزای اصلی Kubernetes شامل API Server، Scheduler، Controller Manager، Etcd و Kubelet بررسی شدند. همچنین، نحوه ارتباط این اجزا با یکدیگر و روش بررسی وضعیت هرکدام ارائه شد. پیکربندی‌ها و مسیر فایل‌های مرتبط نیز مشخص گردیدند تا امکان مدیریت و عیب‌یابی بهینه‌تری فراهم شود.

• ایمن‌سازی ارتباطات API Server
• رمزنگاری داده‌های etcd

ایمن‌سازی ارتباطات API Server

API Server مهم‌ترین مؤلفه در Control Plane است که با سایر اجزای Kubernetes و کاربران خارجی در ارتباط است. اگر این ارتباطات به درستی ایمن‌سازی نشوند، مهاجمان می‌توانند داده‌های حساس را مشاهده یا تغییر دهند. برای ایمن‌سازی API Server، باید موارد زیر را انجام دهیم:

1. فعال‌سازی TLS برای API Server

ارتباطات بین API Server و سایر مؤلفه‌ها باید به وسیله‌ی TLS (Transport Layer Security) رمزنگاری شوند. kube-apiserver باید با استفاده از گواهینامه‌های TLS پیکربندی شود.

مسیر فایل‌های مرتبط:

• فایل کانفیگ kube-apiserver: /etc/kubernetes/manifests/kube-apiserver.yaml
• مسیر گواهینامه‌ها: /etc/kubernetes/pki/

برای ایجاد گواهینامه‌ی TLS، می‌توان از CFSSL یا OpenSSL استفاده کرد. نمونه‌ای از ایجاد یک CA Certificate با OpenSSL:

openssl genrsa -out /etc/kubernetes/pki/ca.key 2048
openssl req -x509 -new -nodes -key /etc/kubernetes/pki/ca.key -subj "/CN=kubernetes-ca" -days 10000 -out /etc/kubernetes/pki/ca.crt

سپس گواهینامه‌ای برای API Server ایجاد کنید:

openssl genrsa -out /etc/kubernetes/pki/apiserver.key 2048
openssl req -new -key /etc/kubernetes/pki/apiserver.key -subj "/CN=kube-apiserver" -out /etc/kubernetes/pki/apiserver.csr
openssl x509 -req -in /etc/kubernetes/pki/apiserver.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /etc/kubernetes/pki/apiserver.crt -days 10000

پس از ایجاد گواهینامه‌ها، باید آنها را در فایل kube-apiserver.yaml پیکربندی کنیم.

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml:

spec:
  containers:
  - command:
    - kube-apiserver
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    - --client-ca-file=/etc/kubernetes/pki/ca.crt

2. محدود کردن دسترسی به API Server

باید دسترسی به API Server را محدود کرد تا فقط درخواست‌های مجاز پذیرفته شوند.

برای بررسی کاربران متصل به API Server:

kubectl get pods --all-namespaces -o wide

برای محدود کردن دسترسی به API Server از RBAC (Role-Based Access Control) استفاده می‌شود. ابتدا یک Role ایجاد کنید:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: read-only-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

سپس این Role را به یک کاربر خاص اختصاص دهید:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-only-binding
  namespace: default
subjects:
- kind: User
  name: read-only-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: read-only-role
  apiGroup: rbac.authorization.k8s.io

با اجرای این تنظیمات، کاربر read-only-user فقط می‌تواند اطلاعات Pods را مشاهده کند و نمی‌تواند تغییراتی ایجاد کند.

رمزنگاری داده‌های etcd

etcd پایگاه‌داده‌ی کلیدی-مقداری است که تمام وضعیت Kubernetes را در خود نگه‌داری می‌کند. اگر داده‌های etcd رمزنگاری نشوند، مهاجمان می‌توانند به داده‌های حساس مانند Secrets و ConfigMaps دسترسی داشته باشند.

1. فعال‌سازی TLS برای etcd

ابتدا باید گواهینامه‌های TLS برای etcd ایجاد شوند:

openssl genrsa -out /etc/kubernetes/pki/etcd.key 2048
openssl req -new -key /etc/kubernetes/pki/etcd.key -subj "/CN=etcd" -out /etc/kubernetes/pki/etcd.csr
openssl x509 -req -in /etc/kubernetes/pki/etcd.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /etc/kubernetes/pki/etcd.crt -days 10000

سپس این گواهینامه‌ها را در فایل etcd.yaml در مسیر /etc/kubernetes/manifests/ تنظیم کنید:

spec:
  containers:
  - command:
    - etcd
    - --cert-file=/etc/kubernetes/pki/etcd.crt
    - --key-file=/etc/kubernetes/pki/etcd.key
    - --trusted-ca-file=/etc/kubernetes/pki/ca.crt

2. رمزنگاری داده‌های etcd

برای فعال‌سازی رمزنگاری در etcd، یک فایل پیکربندی رمزنگاری ایجاد کنید.

ایجاد فایل encryption-config.yaml در مسیر /etc/kubernetes/pki/:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: c2VjcmV0LWtleS1mb3ItZXRjZA==
      - identity: {}

سپس kube-apiserver را به این فایل ارجاع دهید.

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml:

spec:
  containers:
  - command:
    - kube-apiserver
    - --encryption-provider-config=/etc/kubernetes/pki/encryption-config.yaml

بعد از اعمال تغییرات، API Server را ری‌استارت کنید:

systemctl restart kubelet

برای بررسی رمزنگاری داده‌ها:

ETCDCTL_API=3 etcdctl get /registry/secrets/default/mysecret --hex -w table

خروجی این دستور باید مقدار رمزنگاری‌شده‌ی Secret را نمایش دهد.

جمع‌بندی

ایمن‌سازی Control Plane برای جلوگیری از حملات و دسترسی غیرمجاز ضروری است. دو اقدام مهم برای افزایش امنیت در این سطح عبارت‌اند از:

• ایمن‌سازی ارتباطات API Server با استفاده از TLS و اعمال محدودیت‌های دسترسی از طریق RBAC.
• رمزنگاری داده‌های etcd برای جلوگیری از افشای اطلاعات حساس.

اجرای این تنظیمات موجب افزایش امنیت زیرساخت Kubernetes و جلوگیری از حملات احتمالی می‌شود.

حفاظت از ارتباطات بین Podها

یکی از چالش‌های امنیتی در Kubernetes، جلوگیری از ارتباطات غیرمجاز بین Podها است. به‌صورت پیش‌فرض، تمام Podها در یک Namespace می‌توانند با یکدیگر ارتباط برقرار کنند، مگر اینکه سیاست‌های شبکه (Network Policies) مانع آن شوند.

1. ایجاد Network Policy برای محدود کردن ارتباط بین Podها

NetworkPolicy در Kubernetes به ما اجازه می‌دهد که ترافیک ورودی و خروجی بین Podها را کنترل کنیم.

نمونه: مسدود کردن ارتباط تمام Podها به‌جز موارد مجاز

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

اعمال این Network Policy:

kubectl apply -f deny-all.yaml

2. اجازه دادن به یک گروه خاص از Podها برای ارتباط با هم

اگر بخواهیم فقط Podهایی که دارای یک Label خاص هستند، اجازه ارتباط با هم را داشته باشند، از سیاست زیر استفاده می‌کنیم.

نمونه: فقط Podهایی با Label role=db اجازه دریافت ترافیک از app را دارند

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-db-access
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: app

اعمال این Network Policy:

kubectl apply -f allow-db-access.yaml

3. فعال‌سازی ارتباطات رمزگذاری‌شده بین Podها با استفاده از mTLS

برای رمزگذاری ارتباطات بین Podها، می‌توان از Service Mesh مانند Istio یا Linkerd استفاده کرد.

فعال‌سازی mTLS در Istio برای رمزگذاری ارتباطات بین Podها

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

اعمال پیکربندی:

kubectl apply -f peer-auth.yaml

امنیت شبکه Nodeها

Nodeها در Kubernetes مسئول اجرای Podها هستند، بنابراین ایمن‌سازی ارتباطات شبکه بین Nodeها از اهمیت بالایی برخوردار است.

1. محدود کردن دسترسی به Nodeها با فایروال

بستن تمام پورت‌های غیرضروری و اجازه دادن فقط به پورت‌های Kubernetes

iptables -A INPUT -p tcp --match multiport --dports 22,6443,2379,2380,10250,10255 -j ACCEPT
iptables -A INPUT -p tcp --dport 30000:32767 -j ACCEPT
iptables -A INPUT -j DROP

2. استفاده از Calico برای کنترل ترافیک بین Nodeها

اگر از Calico به‌عنوان CNI استفاده شود، می‌توان قوانین امنیتی را مستقیماً روی Nodeها اعمال کرد.

نمونه: فقط Nodeهایی با Label node-role=worker بتوانند با هم ارتباط داشته باشند

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: restrict-node-traffic
spec:
  selector: "node-role == 'worker'"
  types:
    - Egress
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports: [6443, 2379, 2380, 10250, 10255]
  egress:
    - action: Allow
      protocol: TCP
      destination:
        ports: [6443, 2379, 2380, 10250, 10255]

اعمال پیکربندی:

kubectl apply -f restrict-node-traffic.yaml

3. بررسی و جلوگیری از ترافیک غیرمجاز با ابزارهای IDS/IPS

برای بررسی و نظارت بر ترافیک شبکه در Nodeها می‌توان از ابزارهایی مانند Falco یا Suricata استفاده کرد.

نصب Falco برای مانیتورینگ فعالیت‌های مشکوک

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco

بررسی لاگ‌های امنیتی Falco

kubectl logs -l app=falco -n kube-system

جمع‌بندی

• برای حفاظت از ارتباط بین Podها، می‌توان از Network Policy و mTLS با Istio استفاده کرد.
• برای امنیت Nodeها، باید دسترسی‌های شبکه محدود شوند، فایروال تنظیم شود و ابزارهای مانیتورینگ مانند Falco فعال گردند.
• استفاده از CNIهایی مانند Calico می‌تواند کنترل بیشتری روی ارتباطات شبکه در سطح Node و Podها ایجاد کند.

با این روش‌ها، امنیت در سطح Data Plane افزایش یافته و حملات احتمالی مانند حملات شبکه داخلی، شنود ترافیک و دسترسی غیرمجاز به Nodeها کاهش خواهد یافت.

Privilege Escalation (افزایش دسترسی)

Privilege Escalation زمانی رخ می‌دهد که یک کاربر یا Pod با سطح دسترسی محدود بتواند امتیازات بیشتری کسب کند و در نهایت به سطح Administrator یا Cluster Admin برسد. این نوع حملات معمولاً به دلایل زیر رخ می‌دهند:

• Misconfigured Role-Based Access Control (RBAC): دسترسی بیش از حد به کاربران یا Podها.
• Container Privilege Escalation: اجرای کانتینرها با دسترسی root.
• Access to Service Account Tokens: سرقت توکن‌های Service Account برای دسترسی به API Server.

راهکارهای جلوگیری از Privilege Escalation

1. محدود کردن دسترسی کاربران با RBAC

در Kubernetes، RBAC (Role-Based Access Control) مکانیزم اصلی برای مدیریت دسترسی‌ها است. بررسی کاربران با سطح دسترسی بالا:

kubectl get clusterrolebindings

ایجاد یک ClusterRole محدود که فقط اجازه خواندن Pods را بدهد:

فایل: /etc/kubernetes/rbac/restricted-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: restricted-user
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

ایجاد یک ClusterRoleBinding برای اعمال این محدودیت به یک کاربر خاص:

فایل: /etc/kubernetes/rbac/restricted-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: restricted-user-binding
subjects:
- kind: User
  name: user1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: restricted-user
  apiGroup: rbac.authorization.k8s.io

اعمال تنظیمات RBAC:

kubectl apply -f /etc/kubernetes/rbac/restricted-role.yaml
kubectl apply -f /etc/kubernetes/rbac/restricted-rolebinding.yaml

2. اجرای کانتینرها با کاربر غیر از root

بررسی کانتینرهایی که با دسترسی root اجرا شده‌اند:

kubectl get pods --all-namespaces -o json | jq '.items[].spec.containers[].securityContext.runAsUser'

برای جلوگیری از اجرای کانتینرها با root، تنظیمات زیر در PodSpec اضافه می‌شود:

فایل: /etc/kubernetes/pod-security/restrict-root.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: default
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: secure-container
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/pod-security/restrict-root.yaml

3. غیر فعال کردن توکن‌های پیش‌فرض Service Account

بررسی Service Account Tokenهای فعال:

kubectl get serviceaccounts -o yaml

غیرفعال کردن Automount Service Account Token برای همه‌ی Pods:

فایل: /etc/kubernetes/pod-security/restrict-token.yaml

apiVersion: v1
kind: Pod
metadata:
  name: no-token-pod
  namespace: default
spec:
  automountServiceAccountToken: false
  containers:
  - name: nginx
    image: nginx

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/pod-security/restrict-token.yaml

جمع‌بندی

برای جلوگیری از Privilege Escalation در Kubernetes، راهکارهای زیر پیشنهاد می‌شوند:

• محدود کردن دسترسی کاربران با RBAC برای جلوگیری از سوءاستفاده از مجوزهای بیش‌ازحد.
• اجرای کانتینرها با کاربر غیر از root و فعال کردن SecurityContext برای کاهش سطح دسترسی.
• غیرفعال کردن توکن‌های پیش‌فرض Service Account تا از سوءاستفاده مهاجمان جلوگیری شود.

اجرای این اقدامات امنیتی باعث کاهش سطح حمله در Kubernetes و جلوگیری از افزایش سطح دسترسی کاربران غیرمجاز خواهد شد.

روش‌های متداول حمله Resource Exhaustion

• CPU & Memory Overuse: اجرای Pods با مصرف بالای CPU و RAM برای اشباع منابع.
• Storage Exhaustion: پر کردن فضای دیسک با داده‌های غیرضروری.
• Network Flooding: ارسال درخواست‌های بیش‌ازحد به سرویس‌ها و API Server.
• Process Fork Bombs: اجرای مداوم پردازش‌های جدید برای مصرف منابع پردازشی.

راهکارهای جلوگیری از Resource Exhaustion

1. تعیین محدودیت منابع برای Pods

در Kubernetes می‌توان با استفاده از Resource Requests & Limits، میزان مصرف CPU و Memory را کنترل کرد.

بررسی Pods بدون محدودیت منابع:

kubectl get pods --all-namespaces -o json | jq '.items[].spec.containers[].resources'

ایجاد یک Pod با محدودیت مصرف منابع:

فایل: /etc/kubernetes/resource-limits/limited-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: limited-pod
  namespace: default
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: "100m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/resource-limits/limited-pod.yaml

2. استفاده از LimitRange برای کل Namespace

برای جلوگیری از ایجاد Pods با مصرف نامحدود، می‌توان از LimitRange استفاده کرد.

فایل: /etc/kubernetes/resource-limits/namespace-limit.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
  namespace: default
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/resource-limits/namespace-limit.yaml

3. تنظیم ResourceQuota برای Namespace

ResourceQuota محدودیت‌های کلی را برای یک Namespace تعیین می‌کند.

فایل: /etc/kubernetes/resource-limits/namespace-quota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: default
spec:
  hard:
    requests.cpu: "2"
    requests.memory: "2Gi"
    limits.cpu: "4"
    limits.memory: "4Gi"
    pods: "10"

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/resource-limits/namespace-quota.yaml

4. تنظیم Pod Disruption Budget (PDB)

برای جلوگیری از حذف همزمان Pods می‌توان از PDB استفاده کرد.

فایل: /etc/kubernetes/resource-limits/pod-disruption.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-example
  namespace: default
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/resource-limits/pod-disruption.yaml

5. مانیتورینگ و محدودسازی مصرف منابع با ابزارهای امنیتی

برای نظارت بر مصرف منابع و شناسایی تهدیدات مرتبط با Resource Exhaustion، ابزارهای زیر پیشنهاد می‌شوند:

• Metrics Server برای مانیتورینگ میزان استفاده از منابع:

  kubectl top pod --all-namespaces
  

• Prometheus & Grafana برای جمع‌آوری داده‌های مربوط به منابع.
• Kube-bench برای بررسی تنظیمات امنیتی و محدودیت‌های منابع.

جمع‌بندی

برای جلوگیری از حملات Resource Exhaustion، اقدامات زیر ضروری هستند:

• تعیین محدودیت منابع برای Pods با استفاده از requests و limits.
• اعمال LimitRange برای هر Namespace جهت محدود کردن مقدار منابع مصرفی هر Pod.
• ایجاد ResourceQuota برای جلوگیری از استفاده بیش از حد منابع توسط یک Namespace.
• استفاده از PDB برای جلوگیری از حذف ناگهانی چندین Pod.
• استفاده از ابزارهای مانیتورینگ برای شناسایی فعالیت‌های مشکوک و مصرف بیش‌ازحد منابع.

اجرای این راهکارها به جلوگیری از مصرف غیرمجاز منابع و افزایش پایداری Kubernetes Cluster کمک خواهد کرد.

روش‌های حمله DNS Spoofing

• Poisoning CoreDNS Cache: آلوده کردن کش CoreDNS در کلاستر برای تغییر مسیر درخواست‌های DNS.
• Compromising Kube-DNS Pod: دستکاری سرویس Kube-DNS برای ارائه پاسخ‌های جعلی.
• MITM در سطح شبکه: رهگیری و تغییر ترافیک DNS بین Pods و DNS Server.
• استفاده از DNS Rebinding: اجرای اسکریپت‌های مخرب از طریق دستکاری دامنه‌های عمومی.

راهکارهای جلوگیری از DNS Spoofing

1. فعال‌سازی DNSSEC در CoreDNS

DNSSEC مانع از دستکاری و جعل پاسخ‌های DNS می‌شود. برای فعال‌سازی آن، باید تنظیمات CoreDNS ConfigMap تغییر کند.

بررسی ConfigMap مربوط به CoreDNS:

kubectl -n kube-system get configmap coredns -o yaml

ویرایش فایل تنظیمات CoreDNS:

فایل: /etc/kubernetes/coredns/coredns-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        cache 30
        dnssec
        loadbalance
    }

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/coredns/coredns-config.yaml
kubectl -n kube-system rollout restart deployment coredns

2. استفاده از NodeLocal DNSCache برای جلوگیری از Poisoning

اجرای NodeLocal DNSCache باعث افزایش امنیت و کارایی DNS در Kubernetes می‌شود.

نصب NodeLocal DNSCache:

kubectl apply -f https://k8s.io/examples/admin/dns/nodelocaldns.yaml

بررسی وضعیت سرویس NodeLocal DNSCache:

kubectl get pods -n kube-system | grep nodelocaldns

3. محدودسازی ترافیک خروجی DNS با NetworkPolicy

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

فایل: /etc/kubernetes/network-policy/restrict-dns.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.96.0.10/32  # آدرس سرویس CoreDNS در Cluster
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/network-policy/restrict-dns.yaml

4. مانیتورینگ درخواست‌های DNS با ابزارهای امنیتی

• بررسی لاگ‌های CoreDNS برای شناسایی درخواست‌های غیرعادی:

  kubectl -n kube-system logs -l k8s-app=kube-dns -c coredns | grep "A record"
  

• استفاده از Falco برای تشخیص دستکاری‌های DNS:نصب Falco:

  helm repo add falcosecurity https://falcosecurity.github.io/charts
  helm repo update
  helm install falco falcosecurity/falco
  

  بررسی رویدادهای Falco:

  kubectl logs -l app=falco -n falco | grep "DNS"
  

جمع‌بندی

برای جلوگیری از حملات DNS Spoofing در Kubernetes، اقدامات زیر ضروری هستند:

• فعال‌سازی DNSSEC در CoreDNS برای تأمین اعتبار پاسخ‌های DNS.
• استفاده از NodeLocal DNSCache برای جلوگیری از دستکاری کش DNS.
• اعمال NetworkPolicy برای محدودسازی دسترسی DNS فقط به آدرس‌های مجاز.
• مانیتورینگ لاگ‌های CoreDNS و استفاده از Falco برای شناسایی تهدیدات مرتبط با DNS.

اجرای این اقدامات، امنیت DNS در Kubernetes Cluster را به میزان قابل توجهی افزایش می‌دهد و از حملات DNS Spoofing جلوگیری می‌کند.

مشکلات رایج در پیکربندی نادرست RBAC

• اختصاص دسترسی‌های سطح بالا به کاربران غیرضروری
• استفاده از RoleBinding به جای ClusterRoleBinding برای نقش‌های عمومی
• استفاده از wildcards (*) در مجوزها
• عدم محدودسازی دسترسی به Secrets و ConfigMaps
• دادن دسترسی admin یا cluster-admin به کاربران عادی
• عدم تعریف Least Privilege برای سرویس‌ها و کاربران

بررسی دسترسی‌های فعلی در کلاستر

نمایش همه Roleها در یک Namespace مشخص:

kubectl get roles -n default

نمایش تمام ClusterRoleها:

kubectl get clusterroles

بررسی RoleBindingها و ClusterRoleBindingها:

kubectl get rolebindings -n default
kubectl get clusterrolebindings

بررسی دسترسی‌های یک کاربر خاص:

kubectl auth can-i list pods --as=user1

اصلاح Misconfigured RBAC

1. ایجاد یک Role با حداقل دسترسی

فایل: /etc/kubernetes/rbac/readonly-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: readonly-role
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]

اعمال Role:

kubectl apply -f /etc/kubernetes/rbac/readonly-role.yaml

2. ایجاد RoleBinding برای کاربران مشخص

فایل: /etc/kubernetes/rbac/readonly-binding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: readonly-binding
  namespace: default
subjects:
- kind: User
  name: "user1"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: readonly-role
  apiGroup: rbac.authorization.k8s.io

اعمال RoleBinding:

kubectl apply -f /etc/kubernetes/rbac/readonly-binding.yaml

3. بررسی و حذف مجوزهای اضافی

حذف یک ClusterRoleBinding ناامن:

kubectl delete clusterrolebinding cluster-admin-binding

حذف یک RoleBinding ناامن:

kubectl delete rolebinding default-admin -n default

ضعف در امنیت کانتینرها (Container Misconfiguration)

کانتینرها به عنوان یکی از بخش‌های اصلی در Kubernetes اگر به درستی پیکربندی نشوند، ممکن است آسیب‌پذیر شوند. مشکلات رایج شامل اجرای کانتینر با دسترسی Root، نبود Resource Limits، ضعف در مدیریت Secrets و استفاده از تصاویر آسیب‌پذیر است.

مشکلات رایج در پیکربندی کانتینرها

• اجرای کانتینرها به عنوان Root
• عدم تعریف Resource Limits
• ذخیره اطلاعات حساس در Environment Variables
• استفاده از تصاویر ناامن و قدیمی
• عدم محدودسازی قابلیت‌های کانتینر (Capabilities)

روش‌های بهبود امنیت کانتینرها

1. محدود کردن دسترسی Root در Podها

فایل: /etc/kubernetes/pod-security/restrict-root.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: default
spec:
  securityContext:
    runAsNonRoot: true
  containers:
  - name: secure-container
    image: nginx:latest
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

اعمال پیکربندی:

kubectl apply -f /etc/kubernetes/pod-security/restrict-root.yaml

2. تعریف Resource Limits برای جلوگیری از Resource Exhaustion

فایل: /etc/kubernetes/pod-security/resource-limits.yaml

apiVersion: v1
kind: Pod
metadata:
  name: limited-pod
  namespace: default
spec:
  containers:
  - name: limited-container
    image: nginx:latest
    resources:
      limits:
        cpu: "500m"
        memory: "256Mi"
      requests:
        cpu: "250m"
        memory: "128Mi"

اعمال پیکربندی:

kubectl apply -f /etc/kubernetes/pod-security/resource-limits.yaml

3. استفاده از Secrets به جای Environment Variables

فایل: /etc/kubernetes/secrets/db-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
  namespace: default
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQ=  # مقدار base64 شده "password"

اعمال Secret:

kubectl apply -f /etc/kubernetes/secrets/db-secret.yaml

استفاده از Secret در یک Pod:

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: DB_PASSWORD

4. اسکن تصاویر کانتینر با Trivy

نصب Trivy:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

اسکن یک تصویر Docker:

trivy image nginx:latest

جمع‌بندی

Misconfigured RBAC و ضعف در امنیت کانتینرها از مشکلات رایج در Kubernetes هستند که می‌توانند منجر به حملات مختلف شوند. برای افزایش امنیت باید:

• حداقل سطح دسترسی در RBAC را تنظیم و از دادن مجوزهای اضافی خودداری کرد.
• دسترسی‌های غیرضروری به Secrets و ConfigMaps را محدود کرد.
• اجرای کانتینرها به عنوان Root را غیرفعال و قابلیت‌های آن‌ها را محدود کرد.
• Resource Limits را تنظیم کرد تا از حملات Resource Exhaustion جلوگیری شود.
• از Secrets برای مدیریت اطلاعات حساس استفاده کرد و از ذخیره آن‌ها در متغیرهای محیطی خودداری کرد.
• تصاویر کانتینرها را اسکن و از تصاویر به‌روز و امن استفاده کرد.

اجرای این اقدامات می‌تواند سطح امنیتی Kubernetes Cluster را بهبود بخشد و از بسیاری از حملات جلوگیری کند.

پایگاه داده‌های امنیتی مهم

1. CVE (Common Vulnerabilities and Exposures)

CVE یک استاندارد شناخته‌شده برای ثبت آسیب‌پذیری‌های امنیتی است که توسط MITRE مدیریت می‌شود. هر آسیب‌پذیری با یک شناسه یکتا مشخص می‌شود (مثلاً CVE-2023-12345).

2. NVD (National Vulnerability Database)

این پایگاه داده توسط NIST مدیریت می‌شود و اطلاعات کامل‌تری نسبت به CVE ارائه می‌دهد، از جمله رتبه‌بندی شدت آسیب‌پذیری (CVSS) و روش‌های کاهش آسیب‌پذیری.

3. Kubernetes Security Advisories

تیم توسعه Kubernetes یک صفحه رسمی برای گزارش آسیب‌پذیری‌های امنیتی دارد که جدیدترین مشکلات کشف‌شده را شامل می‌شود:
https://kubernetes.io/docs/reference/issues-security/security-advisories/

4. OSV (Open Source Vulnerabilities)

این سرویس توسط Google مدیریت می‌شود و آسیب‌پذیری‌های مرتبط با پروژه‌های متن‌باز را نمایش می‌دهد.

5. CIS Kubernetes Benchmark

راهنمای Center for Internet Security (CIS) شامل بهترین شیوه‌های امنیتی برای تنظیمات Kubernetes است. ابزارهای خودکار مانند kube-bench از این استانداردها برای اسکن امنیتی استفاده می‌کنند.

جستجوی آسیب‌پذیری‌های Kubernetes در پایگاه داده‌های امنیتی

1. جستجوی CVEهای مرتبط با Kubernetes

می‌توان با استفاده از NVD و CVE Details، آسیب‌پذیری‌های جدید مرتبط با Kubernetes را پیدا کرد:

curl -s "https://services.nvd.nist.gov/rest/json/cves/1.0?keyword=kubernetes" | jq .

2. استفاده از Trivy برای اسکن آسیب‌پذیری‌های سیستم و کانتینرها

Trivy یکی از ابزارهای پرکاربرد برای اسکن آسیب‌پذیری‌های CVE در تصاویر کانتینر و Kubernetes است.

نصب Trivy:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

اسکن Kubernetes برای آسیب‌پذیری‌های شناخته‌شده:

trivy k8s --report summary cluster

اسکن یک تصویر کانتینر برای یافتن CVEها:

trivy image nginx:latest

نمونه‌ای از آسیب‌پذیری‌های معروف در Kubernetes

1. CVE-2020-8554: حمله Man-in-the-Middle در Kubernetes Services

این آسیب‌پذیری به مهاجم اجازه می‌دهد تا یک سرویس مخرب ایجاد کند و ترافیک ورودی را رهگیری کند. برای جلوگیری از این مشکل، باید از Network Policies و RBAC برای کنترل دسترسی‌ها استفاده شود.

2. CVE-2021-25741: آسیب‌پذیری در Kubelet

این آسیب‌پذیری به مهاجمان اجازه می‌دهد با سوءاستفاده از symlink، اطلاعات حساس را از میزبان استخراج کنند. برای رفع آن، توصیه می‌شود Kubelet را به‌روز نگه داشته و Policies سختگیرانه‌تری اعمال شود.

3. CVE-2019-11247: سوءاستفاده از مجوزهای API Server

در این آسیب‌پذیری، کاربرانی که دارای سطح دسترسی edit یا view بودند، می‌توانستند توکن‌های سطح بالاتر را مشاهده کنند. برای کاهش این ریسک، باید RBAC به درستی تنظیم شود.

بهبود امنیت Kubernetes در برابر آسیب‌پذیری‌ها

1. به‌روز نگه داشتن Kubernetes

بررسی نسخه نصب‌شده:

kubectl version --short

به‌روزرسانی کلاستر Kubernetes در یک سیستم مبتنی بر kubeadm:

kubeadm upgrade plan
kubeadm upgrade apply v1.28.2

2. اجرای اسکن‌های امنیتی دوره‌ای

استفاده از kube-bench برای بررسی تنظیمات امنیتی Kubernetes بر اساس CIS Benchmark:

نصب kube-bench:

curl -L https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench-linux-amd64 -o kube-bench
chmod +x kube-bench

اجرای اسکن امنیتی:

./kube-bench run --benchmark cis-1.6

3. محدود کردن مجوزهای دسترسی با RBAC

بررسی تمامی Roleها و ClusterRoleهای تعریف‌شده:

kubectl get roles,rolebindings -A
kubectl get clusterroles,clusterrolebindings

حذف دسترسی‌های اضافی:

kubectl delete clusterrolebinding cluster-admin-binding

جمع‌بندی

• آسیب‌پذیری‌های Kubernetes معمولاً در پایگاه داده‌های امنیتی مانند CVE، NVD، OSV و Kubernetes Security Advisories ثبت می‌شوند.
• ابزارهایی مانند Trivy، kube-bench و curl برای بررسی آسیب‌پذیری‌های Kubernetes و کانتینرها مفید هستند.
• برخی از آسیب‌پذیری‌های معروف Kubernetes شامل CVE-2020-8554، CVE-2021-25741 و CVE-2019-11247 هستند که باید در برابر آن‌ها تدابیر امنیتی اتخاذ شود.
• اجرای به‌روزرسانی‌های امنیتی، اسکن‌های امنیتی منظم و مدیریت صحیح RBAC برای کاهش خطرات ضروری است.

با رعایت این اقدامات، می‌توان سطح امنیت Kubernetes Cluster را بهبود بخشید و در برابر آسیب‌پذیری‌های شناخته‌شده مقاوم‌تر شد.

ایمن‌سازی API Server در Kubernetes

API Server در Kubernetes نقطه ورودی اصلی برای مدیریت کلاستر است و تأمین امنیت آن می‌تواند از حملات مختلف مانند DoS، حملات تزریق، شنود داده‌ها و سوءاستفاده از مجوزها جلوگیری کند.

1. محدود کردن دسترسی از طریق فایروال

برای کاهش سطح حمله، فقط نودهای مشخصی باید به API Server دسترسی داشته باشند. این کار با تنظیم فایروال امکان‌پذیر است.

در iptables:

iptables -A INPUT -p tcp --dport 6443 -s <trusted-ip> -j ACCEPT
iptables -A INPUT -p tcp --dport 6443 -j DROP

در UFW (Ubuntu):

ufw allow from <trusted-ip> to any port 6443 proto tcp
ufw deny 6443

2. فعال کردن احراز هویت و کنترل مجوزها

یکی از راه‌های ایمن‌سازی API Server، استفاده از RBAC (Role-Based Access Control) است.

فعال‌سازی RBAC در API Server:
فایل پیکربندی API Server در مسیر زیر قرار دارد و باید مقدار --authorization-mode تنظیم شود:

/etc/kubernetes/manifests/kube-apiserver.yaml

- --authorization-mode=Node,RBAC

اعمال تغییرات و راه‌اندازی مجدد API Server:

systemctl restart kubelet

3. محدود کردن درخواست‌های حجیم و مخرب

برای جلوگیری از حملات DoS، می‌توان حداکثر تعداد درخواست‌های همزمان را تنظیم کرد:

- --max-requests-inflight=500
- --max-mutating-requests-inflight=200

این تغییرات در همان فایل /etc/kubernetes/manifests/kube-apiserver.yaml اعمال شده و بعد از آن، باید API Server ریستارت شود:

systemctl restart kubelet

4. فعال کردن TLS و ارتباطات امن

برای اطمینان از رمزگذاری ارتباطات API Server، باید گواهینامه TLS تنظیم شود.

بررسی وضعیت رمزگذاری ارتباطات:

kubectl get csr

ایجاد یک گواهینامه جدید برای API Server:

openssl req -new -key /etc/kubernetes/pki/apiserver.key -out /etc/kubernetes/pki/apiserver.csr -subj "/CN=kube-apiserver"
openssl x509 -req -in /etc/kubernetes/pki/apiserver.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /etc/kubernetes/pki/apiserver.crt -days 365

تنظیم مسیر گواهینامه‌ها در API Server:
فایل /etc/kubernetes/manifests/kube-apiserver.yaml باید مقادیر زیر را شامل شود:

- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

ریستارت Kubelet:

systemctl restart kubelet

5. فعال کردن Audit Logging برای بررسی فعالیت‌های مشکوک

فایل /etc/kubernetes/manifests/kube-apiserver.yaml را ویرایش کرده و موارد زیر را اضافه کنید:

- --audit-log-path=/var/log/kubernetes/kube-apiserver-audit.log
- --audit-log-maxage=30
- --audit-log-maxbackup=10
- --audit-log-maxsize=100

بررسی لاگ‌ها:

tail -f /var/log/kubernetes/kube-apiserver-audit.log

دسترسی محدود به etcd

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

1. محدود کردن دسترسی به etcd از طریق فایروال

پورت‌های حساس etcd را تنها برای نودهای مجاز باز کنید:

iptables -A INPUT -p tcp --dport 2379 -s <trusted-ip> -j ACCEPT
iptables -A INPUT -p tcp --dport 2379 -j DROP

2. فعال‌سازی رمزگذاری داده‌های حساس

در فایل پیکربندی etcd مسیر زیر را ویرایش کنید:

/etc/kubernetes/manifests/etcd.yaml

- --peer-auto-tls=true
- --peer-cert-file=/etc/kubernetes/pki/etcd/server.crt
- --peer-key-file=/etc/kubernetes/pki/etcd/server.key

اعمال تغییرات:

systemctl restart kubelet

3. رمزگذاری داده‌های ذخیره‌شده در etcd

Kubernetes می‌تواند داده‌های حساس را رمزگذاری کند تا حتی در صورت نشت داده، اطلاعات مهم افشا نشود.

ایجاد فایل پیکربندی رمزگذاری در مسیر /etc/kubernetes/enc-config.yaml:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <Base64-encoded-key>
      - identity: {}

تنظیم مسیر این فایل در API Server:
در فایل /etc/kubernetes/manifests/kube-apiserver.yaml مقدار زیر را اضافه کنید:

- --encryption-provider-config=/etc/kubernetes/enc-config.yaml

اعمال تغییرات و راه‌اندازی مجدد API Server:

systemctl restart kubelet

4. بررسی دسترسی‌های etcd

بررسی کاربران و نقش‌های مجاز در etcd:

kubectl get clusterrolebindings | grep etcd
kubectl get clusterroles | grep etcd

حذف مجوزهای غیرضروری:

kubectl delete clusterrolebinding etcd-admin-binding

جمع‌بندی

• ایمن‌سازی API Server شامل محدود کردن دسترسی‌ها، فعال‌سازی TLS، RBAC، Audit Logging و Rate Limiting است.
• etcd باید فقط برای نودهای مورد اعتماد باز باشد و داده‌های آن از طریق رمزگذاری AES و TLS محافظت شود.
• Firewall، نقش‌های دسترسی و پیکربندی‌های امنیتی باید به‌طور مداوم بررسی و بروزرسانی شوند تا احتمال نفوذ کاهش یابد.

با اجرای این اقدامات، امنیت Control Plane در Kubernetes افزایش یافته و از حملات احتمالی جلوگیری خواهد شد.

جداسازی ترافیک Podها با Network Policies

در Kubernetes، Podها به‌صورت پیش‌فرض می‌توانند آزادانه با یکدیگر ارتباط برقرار کنند. برای محدود کردن این ارتباطات، می‌توان از Network Policy استفاده کرد.

1. مسدود کردن تمام ترافیک بین Podها

برای جلوگیری از ارتباط بین Podها مگر در موارد مجاز، می‌توان یک Network Policy که تمام ترافیک را مسدود می‌کند ایجاد کرد.

فایل: deny-all.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

اعمال پیکربندی:

kubectl apply -f deny-all.yaml

2. ایجاد استثناء برای ترافیک مجاز

می‌توان فقط به Podهایی با برچسب مشخص (Label) اجازه ارتباط داد.

فایل: allow-app-to-db.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-to-db
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: app

اعمال پیکربندی:

kubectl apply -f allow-app-to-db.yaml

3. رمزگذاری ارتباطات بین Podها با Istio

با استفاده از Istio، می‌توان ارتباطات بین Podها را رمزگذاری و تأیید هویت کرد.

فایل: mtls-enforce.yaml

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: enforce-mtls
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

اعمال پیکربندی:

kubectl apply -f mtls-enforce.yaml

استفاده از Container Runtime Security

امنیت Container Runtime نقش مهمی در جلوگیری از حملات مانند فرار از کانتینر (Container Escape) و اجرای کدهای مخرب دارد.

1. محدود کردن سطح دسترسی کانتینرها

استفاده از Security Context برای عدم اجرای کانتینرها با کاربر ریشه (root).

فایل: secure-container.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-container
  namespace: default
spec:
  containers:
    - name: secure-app
      image: nginx
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false

اعمال پیکربندی:

kubectl apply -f secure-container.yaml

2. استفاده از Seccomp برای محدود کردن دستورات سیستمی

Seccomp لیستی از سیستم‌کال‌های مجاز و غیرمجاز را تعیین می‌کند.

فعال‌سازی پروفایل restricted در یک کانتینر

securityContext:
  seccompProfile:
    type: RuntimeDefault

3. استفاده از AppArmor برای محدود کردن رفتار کانتینر

با استفاده از AppArmor می‌توان محدودیت‌هایی روی اجرا و دسترسی‌های کانتینر اعمال کرد.

فعال‌سازی پروفایل AppArmor

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/nginx: localhost/default-profile

4. فعال‌سازی RuntimeClass برای انتخاب Runtime امن

RuntimeClass به ما امکان می‌دهد تا از Runtimeهای ایمن‌تر مانند gVisor یا Kata Containers استفاده کنیم.

تعریف یک RuntimeClass جدید

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

اعمال پیکربندی:

kubectl apply -f runtime-class.yaml

5. نصب Falco برای شناسایی فعالیت‌های مشکوک

Falco فعالیت‌های غیرعادی در کانتینرها را شناسایی می‌کند.

نصب Falco با Helm

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco

مشاهده لاگ‌های Falco

kubectl logs -l app=falco -n kube-system

جمع‌بندی

• جداسازی ترافیک بین Podها با Network Policy مانع از ارتباطات غیرمجاز می‌شود.
• فعال‌سازی mTLS با Istio ارتباطات بین Podها را رمزگذاری می‌کند.
• محدود کردن سطح دسترسی کانتینرها از اجرای کدهای مخرب و حملات فرار جلوگیری می‌کند.
• استفاده از Seccomp، AppArmor و RuntimeClass امنیت اجرای کانتینرها را افزایش می‌دهد.
• ابزارهایی مانند Falco فعالیت‌های غیرعادی را تشخیص داده و گزارش می‌کنند.

با این روش‌ها، امنیت Data Plane در Kubernetes بهبود می‌یابد و از حملات احتمالی جلوگیری می‌شود.

چالش‌های امنیتی Kubernetes که نیاز به DevSecOps دارند

1. عدم شفافیت در زنجیره تأمین نرم‌افزار
   • وابستگی‌های مخرب (Supply Chain Attacks)
   • Imageهای آلوده در Registryها
2. پیکربندی‌های نادرست (Misconfiguration)
   • استفاده از RBAC نادرست و نقش‌های بیش از حد باز
   • اجرای کانتینرها با سطح دسترسی بالا (Privileged Mode)
3. عدم نظارت و پاسخگویی به تهدیدات
   • عدم ثبت لاگ‌های امنیتی
   • نبود سیستم تشخیص نفوذ (IDS)
4. مشکلات در Runtime Security
   • حملات فرار از کانتینر (Container Escape)
   • اجرای کدهای مخرب در Podها

راهکارهای DevSecOps برای افزایش امنیت Kubernetes

1. ایمن‌سازی زنجیره تأمین نرم‌افزار (Supply Chain Security)

با ابزارهایی مانند Cosign، SLSA و Sigstore می‌توان اصالت و یکپارچگی Imageها را بررسی کرد.

مثال: امضای یک Image با Cosign

cosign sign --key cosign.key my-registry/my-app:latest

بررسی امضای Image:

cosign verify my-registry/my-app:latest

2. استفاده از RBAC برای محدود کردن دسترسی‌ها

RBAC (Role-Based Access Control) از دسترسی‌های غیرضروری جلوگیری می‌کند.

فایل: readonly-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-only
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list"]

اعمال تنظیمات:

kubectl apply -f readonly-role.yaml

3. استفاده از Admission Controllers برای جلوگیری از پیکربندی‌های ناامن

Admission Controllerها مانع از اجرای تنظیمات ناامن در Kubernetes می‌شوند.

مثال: جلوگیری از اجرای کانتینرهای Privileged

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false

اعمال پیکربندی:

kubectl apply -f restricted-policy.yaml

4. نظارت بر Runtime Security با Falco

Falco لاگ‌های Kubernetes را بررسی کرده و فعالیت‌های مشکوک را شناسایی می‌کند.

نصب Falco با Helm

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco

مشاهده لاگ‌های امنیتی Falco

kubectl logs -l app=falco -n kube-system

5. استفاده از Network Policies برای محدود کردن ارتباطات بین Podها

با استفاده از Network Policies می‌توان ارتباطات غیرمجاز بین Podها را مسدود کرد.

مثال: مسدود کردن تمام ارتباطات غیرضروری

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

اعمال تنظیمات:

kubectl apply -f deny-all.yaml

جمع‌بندی

• DevSecOps امنیت را در کل فرآیند توسعه و استقرار Kubernetes ادغام می‌کند.
• ابزارهایی مانند Cosign، Falco و Network Policies به بهبود امنیت کمک می‌کنند.
• کنترل دقیق دسترسی‌ها با RBAC و Admission Controllers مانع از پیکربندی‌های ناامن می‌شود.
• نظارت بر Runtime Security با ابزارهایی مانند Falco از تهدیدات جلوگیری می‌کند.

با اجرای DevSecOps در Kubernetes، می‌توان ریسک‌های امنیتی را کاهش داده و از حملات سایبری جلوگیری کرد.

مراحل امنیتی در CI/CD و ابزارهای مرتبط

1. بررسی امنیت کد (Static Code Analysis)

یکی از اولین مراحل در DevSecOps بررسی امنیت کد منبع قبل از اجرا و استقرار آن است. ابزارهای SAST (Static Application Security Testing) برای این کار استفاده می‌شوند.

ابزارهای پیشنهادی:

• SonarQube: تحلیل کدهای جاوا، پایتون، جاوا اسکریپت و سایر زبان‌ها
• Semgrep: بررسی آسیب‌پذیری‌های رایج در کدها

مثال: اجرای اسکن امنیتی با SonarQube

sonar-scanner \
  -Dsonar.projectKey=myproject \
  -Dsonar.sources=src \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=YOUR_TOKEN

2. بررسی امنیت وابستگی‌های نرم‌افزاری (Dependency Scanning)

بررسی وابستگی‌ها برای یافتن آسیب‌پذیری‌های شناخته‌شده (CVE) بسیار مهم است. ابزارهای SCA (Software Composition Analysis) برای این کار مناسب هستند.

ابزارهای پیشنهادی:

• Trivy: بررسی امنیتی Imageهای Docker و وابستگی‌ها
• Snyk: تحلیل وابستگی‌های پروژه و کشف آسیب‌پذیری‌ها

مثال: اسکن Imageهای Docker با Trivy

trivy image my-docker-image:latest

3. بررسی امنیت Imageهای Docker

استفاده از Imageهای ناامن و آلوده می‌تواند منجر به اجرای کدهای مخرب شود. برای بررسی امنیت Registryها و Imageها ابزارهای زیر پیشنهاد می‌شوند:

ابزارهای پیشنهادی:

• Clair: تحلیل امنیتی Imageها در Container Registry
• Grype: اسکن Imageها برای شناسایی CVEها

مثال: اسکن Image با Grype

grype my-registry/my-image:latest

4. بررسی و اعمال Policyهای امنیتی در Kubernetes

قبل از استقرار، باید بررسی شود که Podها و منابع Kubernetes مطابق با استانداردهای امنیتی هستند. برای این کار، ابزارهای OPA (Open Policy Agent) و Kyverno مفید هستند.

ابزارهای پیشنهادی:

• OPA (Open Policy Agent): بررسی و اعمال Policyهای امنیتی
• Kyverno: اعتبارسنجی و اعمال Policyها روی منابع Kubernetes

مثال: بررسی Policyها با OPA

opa eval --data policy.rego --input input.json "data.kubernetes.admission.deny"

5. اسکن امنیتی در حین استقرار (Runtime Security)

پس از استقرار در محیط Kubernetes، نیاز به ابزارهای نظارتی و شناسایی رفتارهای مشکوک وجود دارد.

ابزارهای پیشنهادی:

• Falco: نظارت بر رویدادهای امنیتی در Kubernetes
• Sysdig Secure: بررسی تهدیدهای Runtime

مثال: نصب Falco در Kubernetes

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco

6. مدیریت Secrets و جلوگیری از افشای اطلاعات حساس

ذخیره نامناسب توکن‌ها، کلیدهای API و گواهینامه‌های امنیتی می‌تواند امنیت را به خطر بیندازد. برای مدیریت این موارد ابزارهای Secrets Management مورد استفاده قرار می‌گیرند.

ابزارهای پیشنهادی:

• Vault (HashiCorp): مدیریت Secrets به صورت امن
• Sealed Secrets: رمزگذاری Secrets در Kubernetes

مثال: ایجاد یک Secret امن در Kubernetes

kubectl create secret generic my-secret --from-literal=password=SuperSecret

فرآیند پیاده‌سازی امنیت در یک Pipeline CI/CD نمونه

برای پیاده‌سازی امنیت در GitHub Actions، می‌توان از مراحل زیر استفاده کرد:

فایل: .github/workflows/security-pipeline.yml

name: Security Pipeline

on:
  push:
    branches:
      - main

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2

      - name: Scan Dependencies with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'my-docker-image:latest'
          format: 'table'

      - name: Lint Code with Semgrep
        run: |
          pip install semgrep
          semgrep --config=auto .

اجرای این Pipeline امنیتی

git push origin main

جمع‌بندی

• هر مرحله از CI/CD نیازمند بررسی‌های امنیتی است تا از اجرای کدهای ناامن جلوگیری شود.
• ابزارهایی مانند SonarQube، Trivy و Falco به شناسایی آسیب‌پذیری‌ها کمک می‌کنند.
• با اعمال Policyهای امنیتی در Kubernetes می‌توان از اجرای تنظیمات خطرناک جلوگیری کرد.
• مدیریت Secrets باید به صورت امن و با استفاده از ابزارهایی مانند Vault انجام شود.
• ادغام تست‌های امنیتی در GitHub Actions یا Jenkins باعث افزایش امنیت در کل فرآیند CI/CD می‌شود.

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

مراحل امنیت در توسعه و استقرار اپلیکیشن‌ها

1. ایجاد کد امن (Secure Coding)

بررسی کدها برای شناسایی مشکلات امنیتی باید از مراحل اولیه توسعه آغاز شود. استفاده از SAST (Static Application Security Testing) و ابزارهای Code Review به جلوگیری از ورود کدهای آسیب‌پذیر کمک می‌کند.

ابزارهای پیشنهادی:

• SonarQube: بررسی امنیتی کدها و جلوگیری از ضعف‌های رایج مانند Injection و XSS
• Semgrep: تحلیل استاتیک کدها برای یافتن مشکلات امنیتی

مثال: اجرای اسکن امنیتی روی کدهای یک پروژه با SonarQube

sonar-scanner \
  -Dsonar.projectKey=myproject \
  -Dsonar.sources=src \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=YOUR_TOKEN

2. مدیریت وابستگی‌های نرم‌افزاری (Dependency Security)

هر پروژه شامل وابستگی‌هایی به کتابخانه‌های خارجی است که ممکن است دارای آسیب‌پذیری‌های شناخته‌شده باشند. این وابستگی‌ها باید قبل از استفاده بررسی شوند.

ابزارهای پیشنهادی:

• Trivy: بررسی آسیب‌پذیری‌های موجود در Imageهای Docker و وابستگی‌های پروژه
• Snyk: بررسی امنیتی وابستگی‌های پروژه و ارائه راهکار برای برطرف‌سازی آن‌ها

مثال: بررسی وابستگی‌های یک پروژه Node.js با Snyk

snyk test --all-projects

3. مدیریت دسترسی و احراز هویت (IAM – Identity and Access Management)

برای اطمینان از اینکه فقط کاربران مجاز می‌توانند به منابع اپلیکیشن دسترسی داشته باشند، استفاده از احراز هویت قوی و مدیریت دسترسی حداقلی (Least Privilege Access) ضروری است.

ابزارهای پیشنهادی:

• Keycloak: مدیریت احراز هویت و SSO (Single Sign-On)
• OAuth2 و OIDC: پروتکل‌های استاندارد برای مدیریت دسترسی کاربران

مثال: ایجاد یک Client در Keycloak برای احراز هویت اپلیکیشن

kubectl apply -f keycloak-client.yaml

محتوای فایل keycloak-client.yaml

apiVersion: keycloak.org/v1alpha1
kind: KeycloakClient
metadata:
  name: my-app-client
spec:
  realmSelector:
    matchLabels:
      realm: my-realm
  client:
    clientId: my-app
    enabled: true
    publicClient: true
    redirectUris:
      - "https://myapp.com/callback"

4. مدیریت و حفاظت از Secrets و اطلاعات حساس

اطلاعات حساس مانند توکن‌ها، کلیدهای API و گذرواژه‌ها نباید در داخل کدها ذخیره شوند. بهترین روش، استفاده از مدیریت Secrets به‌صورت امن است.

ابزارهای پیشنهادی:

• HashiCorp Vault: مدیریت و ذخیره‌سازی اطلاعات حساس
• Sealed Secrets: رمزگذاری و مدیریت Secrets در Kubernetes

مثال: ایجاد یک Secret در Kubernetes

kubectl create secret generic my-secret --from-literal=password=SuperSecret

5. بررسی امنیت کانتینرها و استقرار امن در Kubernetes

باید اطمینان حاصل شود که Imageهای Docker ایمن هستند و در هنگام اجرای Podها در Kubernetes، سطح دسترسی‌های غیرضروری محدود شده است. همچنین باید Policyهای امنیتی برای جلوگیری از اجرای کانتینرهای ناامن اعمال شود.

ابزارهای پیشنهادی:

• Clair: بررسی امنیت Imageهای Docker
• Kyverno: اعمال Policyهای امنیتی در Kubernetes

مثال: اجرای اسکن امنیتی روی یک Image با Clair

clairctl analyze my-registry/my-app:latest

6. نظارت و شناسایی تهدیدات در زمان اجرا

حتی پس از استقرار اپلیکیشن، نیاز به نظارت بر رفتارهای مشکوک و بررسی رخدادهای امنیتی وجود دارد.

ابزارهای پیشنهادی:

• Falco: نظارت بر رویدادهای امنیتی در Kubernetes
• Sysdig Secure: بررسی فعالیت‌های مشکوک در محیط کانتینری

مثال: نصب Falco در Kubernetes

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco

جمع‌بندی

• امنیت باید از مراحل اولیه توسعه تا استقرار و نگهداری اپلیکیشن اعمال شود.
• ابزارهایی مانند SonarQube، Trivy و Snyk برای بررسی کد و وابستگی‌های نرم‌افزاری استفاده می‌شوند.
• استفاده از احراز هویت قوی و مدیریت حداقلی دسترسی‌ها از حملات احتمالی جلوگیری می‌کند.
• مدیریت Secrets با ابزارهایی مانند Vault و Sealed Secrets به محافظت از اطلاعات حساس کمک می‌کند.
• نظارت بر رویدادهای امنیتی و جلوگیری از اجرای رفتارهای مشکوک در Kubernetes اهمیت بالایی دارد.

با رعایت این اصول، می‌توان اپلیکیشن‌هایی ایمن، مقاوم در برابر تهدیدات سایبری و قابل‌اطمینان در محیط Kubernetes توسعه و اجرا کرد.

ایمن‌سازی API Server

API Server مهم‌ترین جزء در Control Plane است که باید دسترسی‌ها و ارتباطات آن محدود شود.

1. فعال‌سازی Authentication و Authorization

فعال کردن RBAC (Role-Based Access Control) و بررسی TLS Configuration برای جلوگیری از دسترسی‌های غیرمجاز.

فایل پیکربندی: /etc/kubernetes/manifests/kube-apiserver.yaml
ویرایش این فایل و اضافه کردن RBAC و TLS Configuration:

- --authorization-mode=Node,RBAC
- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

2. محدودسازی دسترسی به API Server

استفاده از Network Policies برای محدودسازی درخواست‌ها به API Server.

ایجاد یک NetworkPolicy در مسیر /etc/kubernetes/security/api-server-policy.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-api-access
  namespace: kube-system
spec:
  podSelector:
    matchLabels:
      component: kube-apiserver
  policyTypes:
    - Ingress
  ingress:
    - from:
      - ipBlock:
          cidr: 192.168.1.0/24  # فقط این Subnet اجازه دارد به API Server دسترسی داشته باشد

اعمال پالیسی امنیتی:

kubectl apply -f /etc/kubernetes/security/api-server-policy.yaml

ایمن‌سازی etcd

etcd به عنوان پایگاه داده مرکزی Kubernetes تمامی اطلاعات حساس کلاستر را ذخیره می‌کند، بنابراین باید رمزنگاری و دسترسی به آن کنترل شود.

1. فعال کردن رمزنگاری داده‌های حساس

ویرایش پیکربندی etcd در مسیر /etc/kubernetes/manifests/etcd.yaml:

- --client-cert-auth=true
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
- --cert-file=/etc/kubernetes/pki/etcd/server.crt
- --key-file=/etc/kubernetes/pki/etcd/server.key

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/etcd.yaml

2. محدود کردن دسترسی به etcd

استفاده از فایروال برای بستن دسترسی‌های ناخواسته:

iptables -A INPUT -p tcp --dport 2379 -s 192.168.1.100 -j ACCEPT  # مجاز کردن دسترسی از نود مشخص
iptables -A INPUT -p tcp --dport 2379 -j DROP  # مسدود کردن سایر درخواست‌ها

امنیت Data Plane: حفاظت از Podها و نودها

1. ایجاد Network Policies برای ایزوله‌سازی ترافیک Podها

پیکربندی در مسیر /etc/kubernetes/security/pod-network-policy.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress: []

اعمال تنظیمات:

kubectl apply -f /etc/kubernetes/security/pod-network-policy.yaml

2. استفاده از AppArmor برای محدودسازی دسترسی کانتینرها

فعال‌سازی AppArmor در مسیر /etc/default/grub:

GRUB_CMDLINE_LINUX="apparmor=1 security=apparmor"

بروزرسانی GRUB:

update-grub && reboot

3. اجبار به استفاده از Non-Root User در کانتینرها

پیکربندی در مسیر /etc/kubernetes/security/pod-security.yaml:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrict-root
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot

اعمال پالیسی:

kubectl apply -f /etc/kubernetes/security/pod-security.yaml

نظارت و ثبت گزارشات امنیتی

1. فعال‌سازی Audit Logs برای بررسی رخدادهای کلاستر

ویرایش پیکربندی API Server در مسیر /etc/kubernetes/manifests/kube-apiserver.yaml:

- --audit-log-path=/var/log/kubernetes/audit.log
- --audit-log-maxage=30
- --audit-log-maxbackup=10
- --audit-log-maxsize=100

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

2. استفاده از Falco برای نظارت بر رخدادهای مشکوک

نصب Falco با Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco

جمع‌بندی

• API Server باید از طریق TLS، RBAC و Network Policies ایمن شود.
• داده‌های حساس در etcd باید رمزنگاری شده و دسترسی به آن محدود شود.
• ایزوله‌سازی ترافیک Podها با Network Policies به افزایش امنیت کمک می‌کند.
• استفاده از AppArmor و محدود کردن اجرای کانتینرهای با دسترسی Root سطح امنیت را بالا می‌برد.
• فعال‌سازی Audit Logs و ابزارهایی مانند Falco برای نظارت بر تهدیدات امنیتی ضروری است.

این اقدامات به ایجاد یک کلاستر امن و مقاوم در برابر تهدیدات کمک می‌کند و می‌تواند به‌عنوان بخشی از مستندسازی رسمی تنظیمات امنیتی کلاستر Kubernetes استفاده شود.

بررسی و اعمال آخرین به‌روزرسانی‌های Kubernetes

1. بررسی نسخه‌ی فعلی Kubernetes

اجرای دستور زیر برای مشاهده نسخه‌ی نصب‌شده در کلاستر:

kubectl version --short

2. به‌روزرسانی kubeadm، kubelet و kubectl

قبل از هرگونه به‌روزرسانی، وضعیت نودها را بررسی کنید:

kubectl get nodes -o wide

به‌روزرسانی بسته‌های Kubernetes در هر نود:

apt update && apt upgrade -y kubeadm kubelet kubectl

بررسی نسخه‌ی جدید پس از به‌روزرسانی:

kubectl version --short

اعمال تغییرات در نودها:

systemctl restart kubelet

بررسی و به‌روزرسانی سیاست‌های امنیتی

1. به‌روزرسانی Network Policies

ویرایش پالیسی‌های شبکه در مسیر /etc/kubernetes/security/network-policy.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: updated-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend
      ports:
        - protocol: TCP
          port: 443
  egress:
    - to:
      - ipBlock:
          cidr: 10.0.0.0/16
      ports:
        - protocol: TCP
          port: 53

اعمال پالیسی جدید:

kubectl apply -f /etc/kubernetes/security/network-policy.yaml

2. به‌روزرسانی Pod Security Policies

ویرایش سیاست‌های امنیتی در مسیر /etc/kubernetes/security/pod-security-policy.yaml:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: updated-psp
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1
        max: 65535

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/security/pod-security-policy.yaml

به‌روزرسانی کنترل دسترسی‌ها (RBAC)

1. بررسی نقش‌های فعلی

kubectl get roles --all-namespaces
kubectl get rolebindings --all-namespaces

2. به‌روزرسانی نقش‌ها و دسترسی‌ها

ویرایش فایل تنظیمات دسترسی‌ها در مسیر /etc/kubernetes/security/rbac-config.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: updated-role
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "watch", "list"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/security/rbac-config.yaml

بررسی و حذف منابع ناامن یا قدیمی

1. بررسی منابع ناامن در کلاستر

kubectl get all --all-namespaces -o json | grep -i "privileged"
kubectl get pods --all-namespaces -o wide

2. حذف منابع قدیمی و ناامن

kubectl delete pod old-pod --namespace=default
kubectl delete deployment old-deployment --namespace=default

بررسی و به‌روزرسانی تنظیمات رمزنگاری

1. بررسی پیکربندی رمزنگاری etcd

cat /etc/kubernetes/manifests/etcd.yaml | grep "cert"

2. به‌روزرسانی تنظیمات رمزنگاری

ویرایش فایل /etc/kubernetes/manifests/etcd.yaml برای اعمال گواهینامه‌های جدید:

- --client-cert-auth=true
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
- --cert-file=/etc/kubernetes/pki/etcd/server.crt
- --key-file=/etc/kubernetes/pki/etcd/server.key

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/etcd.yaml

اتوماسیون به‌روزرسانی‌ها با CronJob

1. ایجاد CronJob برای بررسی امنیتی خودکار

پیکربندی در مسیر /etc/kubernetes/security/cronjob-security-check.yaml:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: security-check
  namespace: kube-system
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: security-check
            image: bitnami/kubectl
            command:
            - /bin/sh
            - -c
            - "kubectl get pods --all-namespaces -o wide | grep -i 'privileged'"
          restartPolicy: OnFailure

اعمال CronJob:

kubectl apply -f /etc/kubernetes/security/cronjob-security-check.yaml

جمع‌بندی

• به‌روزرسانی منظم kubeadm، kubelet و kubectl از حملات امنیتی جلوگیری می‌کند.
• Network Policies باید با آخرین تغییرات معماری کلاستر به‌روزرسانی شوند.
• سیاست‌های امنیتی Pod باید محدودیت‌های اجرای روت را اعمال کنند.
• دسترسی‌ها و نقش‌های RBAC باید مرتب بررسی و اصلاح شوند.
• رمزنگاری etcd باید بررسی شده و کلیدها و گواهینامه‌ها به‌روزرسانی شوند.
• ایجاد یک CronJob برای بررسی خودکار امنیتی، به بهبود امنیت کمک می‌کند.

با اجرای این فرآیندها، امنیت کلاستر Kubernetes بهبود پیدا کرده و از تهدیدات احتمالی جلوگیری می‌شود.

نصب و اجرای kube-bench برای بررسی امنیتی بر اساس CIS

1. نصب kube-bench

kube-bench یک ابزار منبع‌باز برای ارزیابی پیکربندی‌های امنیتی Kubernetes بر اساس CIS Benchmarks است.

نصب روی نودهای لینوکسی:

curl -L https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench_$(uname -s)_$(uname -m).tar.gz -o kube-bench.tar.gz
tar -xvf kube-bench.tar.gz
chmod +x kube-bench
mv kube-bench /usr/local/bin/

2. اجرای kube-bench برای بررسی امنیتی

kube-bench run --benchmark cis-1.6

خروجی این دستور شامل لیستی از تنظیمات امنیتی توصیه‌شده و وضعیت آن‌ها در کلاستر است.

بررسی و امن‌سازی etcd

1. بررسی وضعیت etcd

ps -ef | grep etcd

2. افزودن رمزنگاری به etcd

ویرایش فایل /etc/kubernetes/manifests/etcd.yaml و تنظیم گواهینامه‌ها:

- --client-cert-auth=true
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
- --cert-file=/etc/kubernetes/pki/etcd/server.crt
- --key-file=/etc/kubernetes/pki/etcd/server.key

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/etcd.yaml

بررسی و امن‌سازی API Server

1. بررسی تنظیمات API Server

kubectl config view

2. تنظیم محدودیت‌های دسترسی API Server

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml و افزودن تنظیمات زیر:

- --anonymous-auth=false
- --audit-log-path=/var/log/kubernetes/audit.log
- --service-account-lookup=true
- --authorization-mode=Node,RBAC

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

بررسی و امن‌سازی Controller Manager

1. بررسی فرآیند Controller Manager

ps -ef | grep kube-controller-manager

2. افزودن تنظیمات امنیتی برای Controller Manager

ویرایش فایل /etc/kubernetes/manifests/kube-controller-manager.yaml و تنظیم مقدار زیر:

- --use-service-account-credentials=true
- --service-account-private-key-file=/etc/kubernetes/pki/sa.key

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-controller-manager.yaml

بررسی و امن‌سازی Kubelet

1. بررسی وضعیت Kubelet

systemctl status kubelet

2. تنظیمات امنیتی پیشنهادی CIS برای Kubelet

ویرایش فایل /var/lib/kubelet/config.yaml و افزودن مقدار زیر:

authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
authorization:
  mode: Webhook
readOnlyPort: 0
protectKernelDefaults: true

اعمال تغییرات و ری‌استارت Kubelet:

systemctl restart kubelet

بررسی و به‌روزرسانی RBAC

1. بررسی نقش‌های فعلی

kubectl get roles --all-namespaces
kubectl get rolebindings --all-namespaces

2. تنظیمات پیشنهادی CIS برای RBAC

ویرایش فایل /etc/kubernetes/security/rbac-config.yaml و افزودن نقش محدودکننده:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: restricted-user
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/security/rbac-config.yaml

بررسی و امن‌سازی Network Policies

1. بررسی سیاست‌های شبکه

kubectl get networkpolicy --all-namespaces

2. اعمال تنظیمات پیشنهادی CIS برای Network Policy

ویرایش فایل /etc/kubernetes/security/network-policy.yaml و تنظیم مقدار زیر:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-internal-traffic
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend
      ports:
        - protocol: TCP
          port: 443

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/security/network-policy.yaml

بررسی و حذف منابع ناامن

1. شناسایی منابع ناامن

kubectl get all --all-namespaces -o json | grep -i "privileged"

2. حذف منابع ناامن

kubectl delete pod old-pod --namespace=default
kubectl delete deployment old-deployment --namespace=default

اتوماسیون بررسی امنیتی با CronJob

1. ایجاد CronJob برای بررسی خودکار امنیتی

ویرایش فایل /etc/kubernetes/security/cronjob-security-check.yaml و افزودن مقدار زیر:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: security-check
  namespace: kube-system
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: security-check
            image: bitnami/kubectl
            command:
            - /bin/sh
            - -c
            - "kubectl get pods --all-namespaces -o wide | grep -i 'privileged'"
          restartPolicy: OnFailure

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/security/cronjob-security-check.yaml

جمع‌بندی

• نصب و اجرای kube-bench برای ارزیابی امنیتی بر اساس CIS Benchmarks
• به‌روزرسانی etcd با رمزنگاری و گواهینامه‌های معتبر
• تنظیم محدودیت‌های امنیتی برای API Server، Controller Manager و Kubelet
• اعمال سیاست‌های امنیتی RBAC برای کنترل دقیق دسترسی‌ها
• استفاده از Network Policies برای محدود کردن ارتباطات غیرضروری بین پادها
• حذف منابع ناامن و جلوگیری از اجرای پادهای Privileged
• ایجاد CronJob برای بررسی خودکار امنیتی

با اجرای این راهکارها، امنیت Kubernetes مطابق با CIS Benchmarks بهینه شده و از تهدیدات امنیتی جلوگیری خواهد شد.

احراز هویت در API Server

API Server از مکانیزم‌های مختلفی برای احراز هویت کاربران و سرویس‌ها استفاده می‌کند. برخی از روش‌های اصلی شامل موارد زیر هستند:

• Token-based authentication
• X.509 client certificates
• Static password file
• Webhook token authentication
• OIDC (OpenID Connect) authentication

1. فعال‌سازی احراز هویت مبتنی بر X.509

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml و تنظیم مقدار زیر:

- --client-ca-file=/etc/kubernetes/pki/ca.crt

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

2. ایجاد یک گواهینامه برای کاربر جدید

openssl genrsa -out user.key 2048
openssl req -new -key user.key -out user.csr -subj "/CN=user/O=group"
openssl x509 -req -in user.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out user.crt -days 365

این کاربر می‌تواند در فایل kubeconfig ثبت شود تا برای دسترسی به API Server از گواهینامه استفاده کند.

کنترل دسترسی و مجوزدهی در API Server

API Server برای کنترل دسترسی به منابع Kubernetes از مکانیزم RBAC (Role-Based Access Control) استفاده می‌کند.

1. فعال‌سازی RBAC در API Server

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml و تنظیم مقدار زیر:

- --authorization-mode=Node,RBAC

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

2. ایجاد یک نقش محدودکننده برای دسترسی به پادها

ویرایش فایل /etc/kubernetes/security/rbac-restricted-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: restricted-user
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/security/rbac-restricted-role.yaml

3. ایجاد یک RoleBinding برای اختصاص دادن نقش به کاربر

ویرایش فایل /etc/kubernetes/security/rbac-binding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: restricted-user-binding
  namespace: default
subjects:
  - kind: User
    name: user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: restricted-user
  apiGroup: rbac.authorization.k8s.io

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/security/rbac-binding.yaml

رمزنگاری ارتباطات API Server

API Server باید ارتباطات بین کاربران و سایر سرویس‌های داخلی را رمزنگاری کند تا از حملات شنود جلوگیری شود.

1. فعال‌سازی TLS در API Server

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml و افزودن تنظیمات زیر:

- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

2. بررسی استفاده از TLS در API Server

kubectl get --raw '/healthz'

اگر تنظیمات TLS به درستی انجام شده باشند، خروجی ok دریافت خواهد شد.

لاگینگ و مانیتورینگ API Server

1. فعال‌سازی لاگ‌های Audit در API Server

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml و افزودن مقدار زیر:

- --audit-log-path=/var/log/kubernetes/audit.log
- --audit-log-maxage=30
- --audit-log-maxbackup=10
- --audit-log-maxsize=100

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

2. ایجاد یک Audit Policy برای مدیریت لاگ‌های امنیتی

ویرایش فایل /etc/kubernetes/audit-policy.yaml و افزودن مقدار زیر:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    verbs: ["create", "update", "delete"]
    resources:
      - group: ""
        resources: ["pods"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/audit-policy.yaml

3. مشاهده لاگ‌های Audit

tail -f /var/log/kubernetes/audit.log

بررسی و محدودسازی منابع API Server

1. بررسی وضعیت فعلی API Server

kubectl get pods -n kube-system | grep kube-apiserver

2. محدود کردن منابع پردازشی API Server

ویرایش فایل /etc/kubernetes/manifests/kube-apiserver.yaml و افزودن مقدار زیر:

resources:
  limits:
    cpu: "2"
    memory: "4Gi"
  requests:
    cpu: "500m"
    memory: "2Gi"

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml

جمع‌بندی

• فعال‌سازی و بررسی احراز هویت کاربران با X.509 و توکن
• ایجاد و تنظیم RBAC برای مدیریت سطح دسترسی کاربران
• رمزنگاری ارتباطات API Server با TLS
• فعال‌سازی لاگ‌های Audit و بررسی رویدادهای امنیتی
• محدودسازی منابع API Server برای جلوگیری از سوءاستفاده

با اجرای این تنظیمات، امنیت API Server در Kubernetes به‌طور قابل‌توجهی افزایش خواهد یافت و از حملات احتمالی جلوگیری می‌شود.

در این بخش، نحوه ایجاد Role و RoleBinding در Kubernetes برای اعمال محدودیت‌های سطح دسترسی بررسی می‌شود.

مفهوم Role و RoleBinding در RBAC

• Role: مجموعه‌ای از مجوزها (Permissions) که در سطح یک Namespace تعریف می‌شود.
• RoleBinding: این بخش، یک Role را به یک کاربر، گروه یا ServiceAccount خاص اختصاص می‌دهد تا دسترسی‌های تعریف‌شده در آن Role را دریافت کند.

ایجاد یک Role در Kubernetes

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

1. ایجاد Role برای دسترسی محدود به پادها

ویرایش فایل /etc/kubernetes/rbac/read-only-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/read-only-role.yaml

ایجاد RoleBinding برای اختصاص دادن Role به کاربر

پس از ایجاد Role، باید یک RoleBinding تعریف شود تا این نقش به یک کاربر یا گروه خاص اختصاص داده شود.

1. ایجاد RoleBinding برای اختصاص دادن نقش به کاربر مشخص

ویرایش فایل /etc/kubernetes/rbac/read-only-binding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: default
subjects:
  - kind: User
    name: example-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/read-only-binding.yaml

ایجاد Role و RoleBinding برای ServiceAccount

در برخی سناریوها، به جای اختصاص نقش به یک کاربر، ممکن است نیاز باشد که یک ServiceAccount برای یک پاد خاص محدود شود.

1. ایجاد یک ServiceAccount جدید

kubectl create serviceaccount restricted-sa -n default

2. ایجاد یک Role برای محدود کردن دسترسی این ServiceAccount

ویرایش فایل /etc/kubernetes/rbac/sa-restricted-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: sa-pod-manager
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "create", "delete"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/sa-restricted-role.yaml

3. ایجاد RoleBinding برای اختصاص دادن Role به ServiceAccount

ویرایش فایل /etc/kubernetes/rbac/sa-restricted-binding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-pod-manager-binding
  namespace: default
subjects:
  - kind: ServiceAccount
    name: restricted-sa
    namespace: default
roleRef:
  kind: Role
  name: sa-pod-manager
  apiGroup: rbac.authorization.k8s.io

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/sa-restricted-binding.yaml

بررسی و تست دسترسی کاربران با RBAC

1. بررسی سطح دسترسی یک کاربر

برای بررسی اینکه یک کاربر خاص چه دسترسی‌هایی دارد، از دستور زیر استفاده می‌شود:

kubectl auth can-i list pods --as=example-user

2. بررسی سطح دسترسی یک ServiceAccount

kubectl auth can-i create pods --as=system:serviceaccount:default:restricted-sa

جمع‌بندی

• ایجاد Role برای کنترل دسترسی کاربران به منابع خاص
• ایجاد RoleBinding برای اختصاص دادن یک Role به کاربر یا گروه مشخص
• ایجاد Role و RoleBinding برای محدود کردن سطح دسترسی ServiceAccount
• بررسی سطح دسترسی کاربران و ServiceAccount با ابزار kubectl auth can-i

با پیاده‌سازی صحیح RBAC، می‌توان امنیت Kubernetes را بهبود داد و از دسترسی غیرمجاز به منابع جلوگیری کرد.

در این بخش، نحوه ایجاد Role و RoleBinding برای محدودسازی دسترسی کاربران و سرویس‌ها به یک Namespace مشخص بررسی می‌شود.

مفهوم Namespace در RBAC

Namespace یک مرز منطقی در Kubernetes است که به تفکیک منابع کمک می‌کند. محدودسازی سطح دسترسی کاربران یا سرویس‌ها به یک Namespace باعث می‌شود که آن‌ها نتوانند منابع دیگر Namespaceها را مشاهده یا مدیریت کنند.

ایجاد Role برای محدودسازی دسترسی در Namespace

در این مثال، یک Role برای کاربری ایجاد می‌شود که فقط اجازه مشاهده و لیست کردن پادها در Namespace dev را دارد.

1. ایجاد Namespace جدید (در صورت عدم وجود)

kubectl create namespace dev

2. ایجاد Role برای محدودسازی دسترسی به پادها در Namespace dev

ویرایش فایل /etc/kubernetes/rbac/namespace-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/namespace-role.yaml

ایجاد RoleBinding برای اختصاص دادن Role به کاربر مشخص

پس از ایجاد Role، باید یک RoleBinding تعریف شود تا این نقش به یک کاربر خاص اختصاص داده شود.

1. ایجاد RoleBinding برای اختصاص دادن نقش به یک کاربر

ویرایش فایل /etc/kubernetes/rbac/namespace-rolebinding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-pod-reader-binding
  namespace: dev
subjects:
  - kind: User
    name: john.doe
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-pod-reader
  apiGroup: rbac.authorization.k8s.io

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/namespace-rolebinding.yaml

بررسی دسترسی کاربر به Namespace

1. بررسی اینکه کاربر john.doe می‌تواند لیست پادهای dev را مشاهده کند یا خیر

kubectl auth can-i list pods --as=john.doe -n dev

2. بررسی اینکه این کاربر نمی‌تواند به Namespace prod دسترسی داشته باشد

kubectl auth can-i list pods --as=john.doe -n prod

محدودسازی دسترسی ServiceAccount به یک Namespace

در برخی موارد، باید دسترسی یک ServiceAccount را فقط به یک Namespace خاص محدود کرد.

1. ایجاد یک ServiceAccount در Namespace dev

kubectl create serviceaccount dev-sa -n dev

2. ایجاد یک Role برای ServiceAccount

ویرایش فایل /etc/kubernetes/rbac/sa-namespace-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: sa-dev-manager
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "create", "delete"]

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/sa-namespace-role.yaml

3. ایجاد RoleBinding برای محدودسازی دسترسی ServiceAccount

ویرایش فایل /etc/kubernetes/rbac/sa-namespace-rolebinding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-dev-manager-binding
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: dev-sa
    namespace: dev
roleRef:
  kind: Role
  name: sa-dev-manager
  apiGroup: rbac.authorization.k8s.io

اعمال تغییرات:

kubectl apply -f /etc/kubernetes/rbac/sa-namespace-rolebinding.yaml

4. بررسی سطح دسترسی ServiceAccount به Namespace dev

kubectl auth can-i create pods --as=system:serviceaccount:dev:dev-sa -n dev

5. بررسی اینکه این ServiceAccount به Namespace prod دسترسی ندارد

kubectl auth can-i create pods --as=system:serviceaccount:dev:dev-sa -n prod

جمع‌بندی

• با استفاده از Role و RoleBinding می‌توان سطح دسترسی کاربران را به یک Namespace مشخص محدود کرد.
• ایجاد Role برای تعریف مجوزهای مشخص در سطح Namespace.
• ایجاد RoleBinding برای اختصاص دادن Role به کاربر یا ServiceAccount خاص.
• بررسی سطح دسترسی کاربران و ServiceAccount با ابزار kubectl auth can-i.

محدودسازی سطح دسترسی به Namespace یکی از بهترین روش‌های افزایش امنیت و کنترل دقیق دسترسی در Kubernetes است.

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

اصول تعیین مجوزهای حداقلی در RBAC

• کاربران و سرویس‌ها نباید به تمام منابع یا Namespaceها دسترسی داشته باشند.
• هر کاربر یا سرویس فقط باید به منابعی که نیاز دارد، آن هم با کمترین سطح دسترسی (مثلاً فقط خواندن یا فقط نوشتن) دسترسی داشته باشد.
• باید از Role به جای ClusterRole استفاده شود مگر در مواردی که نیاز به سطح دسترسی سراسری (Cluster-Wide) باشد.
• هر Role باید فقط برای یک وظیفه خاص تعریف شود.
• RoleBinding باید فقط کاربران یا سرویس‌های مشخصی را به Role مربوطه متصل کند.

ایجاد Role با حداقل سطح دسترسی برای کاربران

در این مثال، یک Role برای کاربری ایجاد می‌شود که فقط می‌تواند پادها را در Namespace dev مشاهده کند و هیچ مجوز دیگری ندارد.

1. ایجاد Role با حداقل سطح دسترسی

ویرایش فایل /etc/kubernetes/rbac/minimal-user-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-viewer
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

اعمال Role در Kubernetes:

kubectl apply -f /etc/kubernetes/rbac/minimal-user-role.yaml

ایجاد RoleBinding برای محدودسازی سطح دسترسی کاربر

1. ایجاد RoleBinding برای کاربر مشخص

ویرایش فایل /etc/kubernetes/rbac/minimal-user-rolebinding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-viewer-binding
  namespace: dev
subjects:
  - kind: User
    name: john.doe
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io

اعمال RoleBinding در Kubernetes:

kubectl apply -f /etc/kubernetes/rbac/minimal-user-rolebinding.yaml

2. بررسی سطح دسترسی کاربر

kubectl auth can-i list pods --as=john.doe -n dev

kubectl auth can-i delete pods --as=john.doe -n dev

خروجی دستور دوم باید no باشد، زیرا کاربر فقط اجازه مشاهده پادها را دارد.

ایجاد Role با حداقل سطح دسترسی برای ServiceAccount

در برخی موارد، باید مجوزهای حداقلی را برای ServiceAccountها نیز تعیین کرد.

1. ایجاد یک ServiceAccount

kubectl create serviceaccount limited-sa -n dev

2. ایجاد Role برای ServiceAccount با حداقل سطح دسترسی

ویرایش فایل /etc/kubernetes/rbac/minimal-sa-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-lister
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

اعمال Role در Kubernetes:

kubectl apply -f /etc/kubernetes/rbac/minimal-sa-role.yaml

3. ایجاد RoleBinding برای ServiceAccount

ویرایش فایل /etc/kubernetes/rbac/minimal-sa-rolebinding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-lister-binding
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: limited-sa
    namespace: dev
roleRef:
  kind: Role
  name: pod-lister
  apiGroup: rbac.authorization.k8s.io

اعمال RoleBinding در Kubernetes:

kubectl apply -f /etc/kubernetes/rbac/minimal-sa-rolebinding.yaml

4. بررسی سطح دسترسی ServiceAccount

kubectl auth can-i get pods --as=system:serviceaccount:dev:limited-sa -n dev

kubectl auth can-i delete pods --as=system:serviceaccount:dev:limited-sa -n dev

خروجی دستور دوم باید no باشد، زیرا این ServiceAccount فقط اجازه خواندن پادها را دارد.

جمع‌بندی

• اصل حداقل مجوز (PoLP) در RBAC باعث افزایش امنیت در Kubernetes می‌شود.
• کاربران و ServiceAccountها باید فقط به منابع ضروری و آن هم با حداقل سطح دسترسی ممکن دسترسی داشته باشند.
• به‌جای ClusterRole از Role استفاده شود مگر در موارد خاص.
• RoleBinding برای اختصاص Role به کاربران و ServiceAccountها استفاده می‌شود.
• دستورات kubectl auth can-i برای بررسی سطح دسترسی کاربران و سرویس‌ها کاربرد دارد.

با این روش، دسترسی‌های غیرضروری حذف شده و امنیت کلاستر بهبود می‌یابد.

برای ایجاد کاربر جدید در Kubernetes، مراحل زیر انجام می‌شود:

• ایجاد یک جفت کلید خصوصی و عمومی برای کاربر
• ایجاد یک فایل CSR (Certificate Signing Request) و امضای آن توسط CA کلاستر
• ایجاد یک context در kubectl برای کاربر جدید
• تخصیص سطح دسترسی به کاربر از طریق RBAC

ایجاد کلید خصوصی و گواهینامه برای کاربر جدید

در این مثال، کاربری با نام ali ایجاد می‌شود و به او مجوز خواندن پادها در Namespace dev داده می‌شود.

1. ایجاد کلید خصوصی برای کاربر جدید

openssl genrsa -out /etc/kubernetes/certs/ali.key 2048

2. ایجاد درخواست CSR برای امضای CA

ویرایش فایل /etc/kubernetes/certs/ali.csr.cnf و افزودن مقدار زیر:

[ req ]
default_bits       = 2048
prompt            = no
default_md        = sha256
distinguished_name = dn

[ dn ]
CN = ali
O = dev-team

3. ایجاد فایل CSR

openssl req -new -key /etc/kubernetes/certs/ali.key -out /etc/kubernetes/certs/ali.csr -config /etc/kubernetes/certs/ali.csr.cnf

4. ایجاد CSR در Kubernetes

ویرایش فایل /etc/kubernetes/certs/ali-csr.yaml و افزودن مقدار زیر:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: ali-csr
spec:
  request: $(cat /etc/kubernetes/certs/ali.csr | base64 | tr -d '\n')
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth

اعمال CSR در Kubernetes:

kubectl apply -f /etc/kubernetes/certs/ali-csr.yaml

5. بررسی CSR و تأیید آن توسط ادمین

kubectl get csr ali-csr
kubectl certificate approve ali-csr

6. دانلود و ذخیره گواهینامه امضا شده

kubectl get csr ali-csr -o jsonpath='{.status.certificate}' | base64 --decode > /etc/kubernetes/certs/ali.crt

اضافه کردن کاربر به kubectl و ایجاد Context

1. اضافه کردن کاربر به kubectl

kubectl config set-credentials ali --client-certificate=/etc/kubernetes/certs/ali.crt --client-key=/etc/kubernetes/certs/ali.key

2. اضافه کردن Context برای کاربر

kubectl config set-context ali-context --cluster=kubernetes --namespace=dev --user=ali

3. انتخاب Context برای کاربر

kubectl config use-context ali-context

4. بررسی Context فعال

kubectl config current-context

تعیین سطح دسترسی کاربر در Kubernetes

1. ایجاد Role برای کاربر جدید

ویرایش فایل /etc/kubernetes/rbac/ali-role.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

اعمال Role در Kubernetes:

kubectl apply -f /etc/kubernetes/rbac/ali-role.yaml

2. ایجاد RoleBinding برای اتصال کاربر به Role

ویرایش فایل /etc/kubernetes/rbac/ali-rolebinding.yaml و افزودن مقدار زیر:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: dev
subjects:
  - kind: User
    name: ali
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

اعمال RoleBinding در Kubernetes:

kubectl apply -f /etc/kubernetes/rbac/ali-rolebinding.yaml

بررسی سطح دسترسی کاربر جدید

1. بررسی توانایی خواندن پادها

kubectl auth can-i list pods --as=ali -n dev

2. بررسی توانایی حذف پادها

kubectl auth can-i delete pods --as=ali -n dev

دستور دوم باید خروجی no بدهد، چون کاربر فقط مجوز خواندن پادها را دارد.

جمع‌بندی

• Kubernetes به‌صورت داخلی کاربران را مدیریت نمی‌کند و باید کاربران از طریق کلید خصوصی و گواهینامه ایجاد شوند.
• CSR باید توسط ادمین تأیید شده و امضا شود تا کاربر بتواند احراز هویت کند.
• کاربران با kubectl config به کلاستر اضافه شده و از طریق Context مدیریت می‌شوند.
• با استفاده از RBAC، سطح دسترسی کاربران محدود و مدیریت می‌شود.
• دستور kubectl auth can-i برای بررسی سطح دسترسی کاربران استفاده می‌شود.

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

در این بخش، نحوه استفاده از kubectl برای کنترل دسترسی کاربران و سرویس‌ها را بررسی خواهیم کرد.

بررسی دسترسی‌های فعلی کاربران با kubectl auth can-i

برای بررسی اینکه یک کاربر چه سطح دسترسی دارد، از دستور زیر استفاده می‌کنیم:

بررسی دسترسی برای کاربر فعلی

kubectl auth can-i list pods

بررسی دسترسی برای یک کاربر خاص

kubectl auth can-i delete pods --as=ali -n dev

خروجی yes یا no خواهد بود که نشان می‌دهد آیا کاربر ali مجوز حذف پادها را در فضای dev دارد یا نه.

بررسی سطح دسترسی کل کاربر

kubectl auth can-i --list --as=ali

این دستور لیستی از مجوزهای کاربر را نمایش می‌دهد.

ایجاد و مدیریت نقش‌ها و RoleBinding با kubectl

ایجاد یک Role جدید برای مدیریت پادها

kubectl create role pod-manager --verb=create,delete --resource=pods -n dev

بررسی Role ایجاد شده

kubectl get role pod-manager -n dev -o yaml

ایجاد RoleBinding برای تخصیص Role به کاربر

kubectl create rolebinding ali-pod-manager-binding --role=pod-manager --user=ali -n dev

بررسی RoleBinding ایجاد شده

kubectl get rolebinding ali-pod-manager-binding -n dev -o yaml

مدیریت ClusterRole و ClusterRoleBinding با kubectl

در برخی موارد، نیاز است که یک دسترسی سراسری (Cluster-wide) به کاربران یا سرویس‌حساب‌ها داده شود.

ایجاد یک ClusterRole برای مدیریت همه پادهای کلاستر

kubectl create clusterrole cluster-pod-admin --verb=create,delete --resource=pods

ایجاد ClusterRoleBinding برای اختصاص این نقش به کاربر ali

kubectl create clusterrolebinding ali-cluster-admin-binding --clusterrole=cluster-pod-admin --user=ali

بررسی سطح دسترسی کل کاربر

kubectl auth can-i --list --as=ali

مدیریت سرویس‌حساب‌ها (ServiceAccounts) با kubectl

ایجاد یک ServiceAccount جدید

kubectl create serviceaccount sa-reader -n dev

بررسی ServiceAccount ایجاد شده

kubectl get serviceaccount sa-reader -n dev -o yaml

ایجاد Role برای ServiceAccount

kubectl create role pod-reader --verb=get,list --resource=pods -n dev

اتصال ServiceAccount به Role

kubectl create rolebinding sa-reader-binding --role=pod-reader --serviceaccount=dev:sa-reader -n dev

مشاهده Token مربوط به ServiceAccount

kubectl get secret $(kubectl get serviceaccount sa-reader -n dev -o jsonpath='{.secrets[0].name}') -n dev -o jsonpath='{.data.token}' | base64 --decode

مشاهده و مدیریت Role و RoleBinding‌های موجود

مشاهده لیست Role‌های موجود

kubectl get roles -n dev

مشاهده Role خاص

kubectl describe role pod-manager -n dev

مشاهده RoleBinding‌های موجود

kubectl get rolebindings -n dev

حذف RoleBinding خاص

kubectl delete rolebinding ali-pod-manager-binding -n dev

جمع‌بندی

• ابزار kubectl امکانات کاملی برای مدیریت دسترسی‌ها و مجوزها در Kubernetes ارائه می‌دهد.
• با kubectl auth can-i می‌توان سطح دسترسی کاربران را بررسی کرد.
• با kubectl create role و kubectl create rolebinding می‌توان سطح دسترسی کاربران را مشخص کرد.
• ClusterRole و ClusterRoleBinding برای مدیریت سطح دسترسی در کل کلاستر استفاده می‌شوند.
• ServiceAccountها را می‌توان برای برنامه‌ها و سرویس‌ها ایجاد و به نقش‌های خاصی متصل کرد.
• دسترسی‌های تعریف‌شده را می‌توان با kubectl get و kubectl describe بررسی کرد.

با استفاده صحیح از kubectl، می‌توان مدیریت سطح دسترسی را به‌صورت دقیق و کارآمد انجام داد.

در این بخش، نحوه ایجاد، مدیریت و تخصیص Service Account به پادها بررسی خواهد شد.

ایجاد یک Service Account جدید

دستور ایجاد Service Account جدید

kubectl create serviceaccount custom-sa -n dev

بررسی Service Account ایجاد شده

kubectl get serviceaccount custom-sa -n dev -o yaml

مشاهده لیست تمام Service Accountها در یک Namespace

kubectl get serviceaccounts -n dev

مشاهده Secret مرتبط با Service Account

kubectl get secret $(kubectl get serviceaccount custom-sa -n dev -o jsonpath='{.secrets[0].name}') -n dev -o yaml

تخصیص یک Service Account به یک پاد

پس از ایجاد یک Service Account، برای اختصاص آن به یک پاد باید در فایل پیکربندی پاد، مقدار serviceAccountName را تنظیم کنیم.

فایل YAML برای پاد با Service Account مشخص

مسیر فایل: pod-with-sa.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-sa
  namespace: dev
spec:
  serviceAccountName: custom-sa
  containers:
  - name: nginx
    image: nginx

اجرای پاد با Service Account اختصاصی

kubectl apply -f pod-with-sa.yaml

بررسی پاد و Service Account تخصیص داده شده

kubectl get pod pod-with-sa -n dev -o jsonpath='{.spec.serviceAccountName}'

ایجاد Role و RoleBinding برای کنترل سطح دسترسی

ایجاد یک Role برای اجازه مشاهده پادها

kubectl create role pod-viewer --verb=get,list --resource=pods -n dev

ایجاد RoleBinding برای اتصال Role به Service Account

kubectl create rolebinding sa-pod-viewer-binding --role=pod-viewer --serviceaccount=dev:custom-sa -n dev

بررسی RoleBinding ایجاد شده

kubectl get rolebinding sa-pod-viewer-binding -n dev -o yaml

بررسی سطح دسترسی Service Account با kubectl auth can-i

بررسی سطح دسترسی اختصاص داده‌شده به Service Account

kubectl auth can-i list pods --as=system:serviceaccount:dev:custom-sa -n dev

بررسی تمام مجوزهای Service Account

kubectl auth can-i --list --as=system:serviceaccount:dev:custom-sa -n dev

حذف یک Service Account

حذف Service Account

kubectl delete serviceaccount custom-sa -n dev

حذف RoleBinding مرتبط

kubectl delete rolebinding sa-pod-viewer-binding -n dev

حذف Role مرتبط

kubectl delete role pod-viewer -n dev

جمع‌بندی

• Service Account در Kubernetes برای کنترل سطح دسترسی پادها به منابع استفاده می‌شود.
• با kubectl create serviceaccount می‌توان یک Service Account ایجاد کرد.
• با serviceAccountName در فایل پاد می‌توان یک Service Account خاص به آن تخصیص داد.
• با Role و RoleBinding می‌توان سطح دسترسی Service Account را مدیریت کرد.
• دستورات kubectl auth can-i برای بررسی سطح دسترسی استفاده می‌شوند.
• مدیریت صحیح Service Accountها باعث افزایش امنیت و کنترل بهتر دسترسی در کلاستر می‌شود.

غیرفعال کردن استفاده از Service Account پیش‌فرض برای پادها

بررسی Service Account پیش‌فرض در Namespace خاص

kubectl get serviceaccount default -n dev -o yaml

ایجاد یک Role که دسترسی Service Account پیش‌فرض را محدود کند

kubectl create role restrict-sa --verb=get,list --resource=pods -n dev

ایجاد RoleBinding برای اتصال Role به Service Account پیش‌فرض

kubectl create rolebinding restrict-default-sa --role=restrict-sa --serviceaccount=dev:default -n dev

بررسی RoleBinding ایجاد شده

kubectl get rolebinding restrict-default-sa -n dev -o yaml

اجبار به استفاده از Service Account اختصاصی در پادها

ایجاد یک Service Account امن

kubectl create serviceaccount secure-sa -n dev

ایجاد یک پاد که از Service Account اختصاصی استفاده می‌کند

مسیر فایل: secure-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: dev
spec:
  serviceAccountName: secure-sa
  containers:
  - name: nginx
    image: nginx

اجرای پاد با Service Account امن

kubectl apply -f secure-pod.yaml

بررسی اختصاص Service Account به پاد

kubectl get pod secure-pod -n dev -o jsonpath='{.spec.serviceAccountName}'

جلوگیری از استفاده از Service Account پیش‌فرض با Policy

برای اطمینان از این‌که پادها از Service Account پیش‌فرض استفاده نمی‌کنند، می‌توان از Pod Security Admission (PSA) یا Kyverno برای اعمال یک سیاست امنیتی استفاده کرد.

اعمال یک Policy برای جلوگیری از استفاده از Service Account پیش‌فرض

مسیر فایل: restrict-default-sa.yaml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-default-sa
spec:
  validationFailureAction: Enforce
  rules:
  - name: block-default-sa
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "استفاده از Service Account پیش‌فرض مجاز نیست. لطفاً یک Service Account اختصاصی تعیین کنید."
      pattern:
        spec:
          serviceAccountName: "!default"

اجرای Policy در کلاستر

kubectl apply -f restrict-default-sa.yaml

بررسی Policyهای اعمال‌شده

kubectl get clusterpolicy restrict-default-sa -o yaml

بررسی سطح دسترسی Service Account پیش‌فرض

بررسی تمام مجوزهای Service Account پیش‌فرض

kubectl auth can-i --list --as=system:serviceaccount:dev:default -n dev

بررسی دسترسی خاص (مثلاً لیست کردن پادها)

kubectl auth can-i list pods --as=system:serviceaccount:dev:default -n dev

حذف دسترسی‌های Service Account پیش‌فرض

kubectl delete rolebinding restrict-default-sa -n dev
kubectl delete role restrict-sa -n dev

غیرفعال کردن توکن‌های خودکار برای Service Account پیش‌فرض

ویرایش پیکربندی Service Account پیش‌فرض و غیرفعال کردن توکن‌ها

kubectl patch serviceaccount default -n dev -p '{"automountServiceAccountToken": false}'

بررسی مقدار automountServiceAccountToken

kubectl get serviceaccount default -n dev -o jsonpath='{.automountServiceAccountToken}'

غیرفعال کردن automountServiceAccountToken برای همه پادهای جدید

مسیر فایل: disable-sa-token.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: dev
spec:
  automountServiceAccountToken: false
  containers:
  - name: nginx
    image: nginx

اجرای پاد با توکن غیرفعال

kubectl apply -f disable-sa-token.yaml

جمع‌بندی

• Service Account پیش‌فرض ممکن است دسترسی‌های ناخواسته داشته باشد، بنابراین باید استفاده از آن را محدود کرد.
• می‌توان از Role و RoleBinding برای کنترل دسترسی‌های Service Account پیش‌فرض استفاده کرد.
• با استفاده از سیاست‌های امنیتی مانند Kyverno می‌توان از تخصیص Service Account پیش‌فرض به پادها جلوگیری کرد.
• غیرفعال کردن automountServiceAccountToken باعث کاهش سطح حمله می‌شود.
• تخصیص یک Service Account اختصاصی به پادها باعث افزایش امنیت در Kubernetes می‌شود.

اهمیت استفاده از Network Policies

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

بررسی Network Policy در Kubernetes

بررسی پشتیبانی از Network Policies در کلاستر

kubectl get networkpolicy --all-namespaces

بررسی CNI Plugin مورد استفاده در کلاستر

kubectl get pods -n kube-system -o wide | grep -i cni

نکته: برای اعمال Network Policy، باید یک CNI (Container Network Interface) Plugin مانند Calico، Cilium یا Weave در کلاستر فعال باشد.

تعریف اولین Network Policy در Kubernetes

ایجاد یک Namespace جدید

kubectl create namespace secure-app

ایجاد یک Deployment ساده برای تست ارتباطات

مسیر فایل: app-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app
  namespace: secure-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

اجرای Deployment در Namespace موردنظر

kubectl apply -f app-deployment.yaml

ایجاد یک Network Policy برای مسدود کردن تمام ارتباطات ورودی

مسیر فایل: deny-all.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: secure-app
spec:
  podSelector: {}
  policyTypes:
  - Ingress

اعمال Policy برای جلوگیری از ترافیک ورودی به همه پادها

kubectl apply -f deny-all.yaml

بررسی Policy اعمال‌شده

kubectl get networkpolicy -n secure-app -o yaml

اعمال یک Network Policy برای مجاز کردن ترافیک خاص

ایجاد یک Network Policy برای اجازه دادن به درخواست‌های ورودی از یک پاد خاص

مسیر فایل: allow-specific.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-web
  namespace: secure-app
spec:
  podSelector:
    matchLabels:
      app: test
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 80

اعمال Policy برای مجاز کردن ارتباط از پادهای دارای برچسب app: web

kubectl apply -f allow-specific.yaml

بررسی ارتباط بین پادهای مجاز و غیرمجاز

kubectl exec -n secure-app -it $(kubectl get pods -n secure-app -l app=web -o jsonpath='{.items[0].metadata.name}') -- curl -m 5 http://test-app

نکته: اگر ارتباط برقرار شود، درخواست موفقیت‌آمیز خواهد بود. در غیر این صورت، اتصال timeout خواهد شد.

محدود کردن خروجی پادها با Network Policy

ایجاد یک Network Policy برای جلوگیری از ارتباطات خروجی غیرمجاز

مسیر فایل: restrict-egress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: secure-app
spec:
  podSelector:
    matchLabels:
      app: test
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.0/24
    ports:
    - protocol: TCP
      port: 443

اعمال Policy برای مسدود کردن تمام ارتباطات خروجی به‌جز آدرس‌های مشخص‌شده

kubectl apply -f restrict-egress.yaml

بررسی ارتباط خروجی از پاد test-app

kubectl exec -n secure-app -it $(kubectl get pods -n secure-app -l app=test -o jsonpath='{.items[0].metadata.name}') -- curl -m 5 https://example.com

نکته: اگر Network Policy به درستی اعمال شده باشد، این درخواست باید مسدود شود.

حذف و بررسی Network Policies

لیست کردن تمام Network Policies در یک Namespace خاص

kubectl get networkpolicy -n secure-app

بررسی جزئیات یک Network Policy خاص

kubectl describe networkpolicy allow-from-web -n secure-app

حذف یک Network Policy مشخص

kubectl delete networkpolicy allow-from-web -n secure-app

حذف تمام Network Policies در یک Namespace

kubectl delete networkpolicy --all -n secure-app

جمع‌بندی

• Network Policies در Kubernetes برای کنترل دقیق دسترسی‌های شبکه‌ای بین پادها استفاده می‌شوند.
• به‌طور پیش‌فرض، پادها در یک Namespace می‌توانند با یکدیگر ارتباط برقرار کنند، اما می‌توان این رفتار را تغییر داد.
• می‌توان ترافیک ورودی (Ingress) و خروجی (Egress) را برای پادها کنترل کرد.
• Network Policies فقط روی CNIهایی که از آن‌ها پشتیبانی می‌کنند (مانند Calico، Cilium و Weave) قابل اجرا هستند.
• ایجاد و مدیریت درست این سیاست‌ها به افزایش امنیت و جلوگیری از حملات داخلی در کلاستر کمک می‌کند.

تعریف Ingress و Egress در Network Policies

• Ingress: تعیین می‌کند که چه ترافیکی اجازه ورود به یک Pod را دارد.
• Egress: مشخص می‌کند که یک Pod به چه منابعی در خارج از خود می‌تواند متصل شود.

به‌طور پیش‌فرض، اگر هیچ Network Policyای در یک Namespace تعریف نشده باشد، تمامی پادها در آن Namespace می‌توانند آزادانه با یکدیگر ارتباط برقرار کنند. اما با اعمال یک Network Policy، فقط ترافیکی که صراحتاً مجاز شده باشد، برقرار خواهد شد.

ایجاد Namespace و Deployment برای تست Network Policies

ایجاد یک Namespace جدید

kubectl create namespace secure-app

ایجاد یک Deployment برای تست ارتباطات

مسیر فایل: app-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app
  namespace: secure-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

اجرای Deployment در Namespace موردنظر

kubectl apply -f app-deployment.yaml

بررسی Podهای ایجادشده

kubectl get pods -n secure-app -o wide

تعریف یک Network Policy برای مسدود کردن تمام ارتباطات ورودی (Ingress)

ایجاد Policy برای مسدود کردن تمام ترافیک ورودی

مسیر فایل: deny-all-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: secure-app
spec:
  podSelector: {}
  policyTypes:
  - Ingress

اعمال Policy برای جلوگیری از ارتباطات ورودی

kubectl apply -f deny-all-ingress.yaml

بررسی Policy اعمال‌شده

kubectl get networkpolicy -n secure-app

تست عدم دسترسی به پادها از سایر پادهای Namespace

kubectl run --rm -it --image=busybox test-client -- /bin/sh
wget -qO- http://test-app.secure-app.svc.cluster.local

نتیجه: ارتباط برقرار نخواهد شد.

اجازه دادن به ترافیک ورودی از یک Pod خاص

ایجاد یک Network Policy برای اجازه دادن به ارتباطات از پادهای دارای برچسب app: web

مسیر فایل: allow-specific-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-web
  namespace: secure-app
spec:
  podSelector:
    matchLabels:
      app: test
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 80

اعمال Policy برای مجاز کردن ارتباط از پادهای دارای برچسب app: web

kubectl apply -f allow-specific-ingress.yaml

تست دسترسی مجاز

kubectl run web --rm -it --image=busybox --labels app=web -- /bin/sh
wget -qO- http://test-app.secure-app.svc.cluster.local

نتیجه: ارتباط برقرار خواهد شد.

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

kubectl run other --rm -it --image=busybox --labels app=other -- /bin/sh
wget -qO- http://test-app.secure-app.svc.cluster.local

نتیجه: ارتباط برقرار نخواهد شد.

محدود کردن ترافیک خروجی (Egress) برای جلوگیری از ارتباطات ناخواسته

ایجاد یک Network Policy برای مسدود کردن تمام ارتباطات خروجی

مسیر فایل: deny-all-egress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: secure-app
spec:
  podSelector: {}
  policyTypes:
  - Egress

اعمال Policy برای مسدود کردن تمام ارتباطات خروجی

kubectl apply -f deny-all-egress.yaml

بررسی عدم دسترسی به اینترنت از داخل پادها

kubectl exec -n secure-app -it $(kubectl get pods -n secure-app -l app=test -o jsonpath='{.items[0].metadata.name}') -- curl -m 5 https://www.google.com

نتیجه: درخواست باید timeout شود.

اجازه دادن به ارتباطات خروجی فقط به یک محدوده خاص از آدرس‌های IP

ایجاد یک Network Policy برای مجاز کردن ارتباطات خروجی فقط به یک IP مشخص

مسیر فایل: allow-specific-egress.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-egress
  namespace: secure-app
spec:
  podSelector:
    matchLabels:
      app: test
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.0/24
    ports:
    - protocol: TCP
      port: 443

اعمال Policy برای اجازه دادن به ارتباطات خروجی فقط به محدوده 192.168.1.0/24

kubectl apply -f allow-specific-egress.yaml

تست دسترسی مجاز به محدوده مشخص‌شده

kubectl exec -n secure-app -it $(kubectl get pods -n secure-app -l app=test -o jsonpath='{.items[0].metadata.name}') -- curl -m 5 https://192.168.1.10

نتیجه: ارتباط برقرار خواهد شد.

تست عدم دسترسی به سایر IPها

kubectl exec -n secure-app -it $(kubectl get pods -n secure-app -l app=test -o jsonpath='{.items[0].metadata.name}') -- curl -m 5 https://www.google.com

نتیجه: ارتباط برقرار نخواهد شد.

حذف و بررسی Network Policies

لیست کردن تمامی Network Policies در یک Namespace

kubectl get networkpolicy -n secure-app

بررسی جزئیات یک Network Policy خاص

kubectl describe networkpolicy allow-specific-ingress -n secure-app

حذف یک Network Policy خاص

kubectl delete networkpolicy allow-specific-ingress -n secure-app

حذف تمامی Network Policies در یک Namespace

kubectl delete networkpolicy --all -n secure-app

جمع‌بندی

• Ingress و Egress در Network Policies برای کنترل دسترسی ورودی و خروجی پادها در Kubernetes استفاده می‌شوند.
• به‌طور پیش‌فرض، پادها در یک Namespace می‌توانند آزادانه با یکدیگر ارتباط برقرار کنند، اما با اعمال Network Policy این رفتار محدود می‌شود.
• با استفاده از Policyهای مناسب، می‌توان دسترسی بین پادها را مدیریت کرده و امنیت را افزایش داد.
• Network Policies فقط در صورتی کار می‌کنند که CNI Plugin مورد استفاده از آن‌ها پشتیبانی کند (مانند Calico، Cilium و Weave).

Calico: پیاده‌سازی و پیکربندی

معرفی Calico

Calico یک CNI Plugin محبوب است که برای مدیریت شبکه در Kubernetes استفاده می‌شود. این ابزار Networking و Network Policy را ارائه می‌دهد و قابلیت پشتیبانی از BGP، VXLAN و eBPF را دارد. همچنین از امنیت شبکه و فایروال سطح پاد پشتیبانی می‌کند.

نصب Calico در یک کلاستر Kubernetes

برای نصب Calico، ابتدا باید Kubernetes را روی bare metal یا Cloud Provider موردنظر اجرا کرد. سپس مراحل زیر را برای پیاده‌سازی انجام دهید:

دانلود و اعمال فایل نصب Calico

مسیر فایل: calico-install.yaml

curl https://raw.githubusercontent.com/projectcalico/calico/v3.26/manifests/calico.yaml -o calico-install.yaml
kubectl apply -f calico-install.yaml

بررسی وضعیت اجرای Calico

kubectl get pods -n kube-system -l k8s-app=calico-node

بررسی وضعیت CNI

kubectl get nodes -o wide

تست شبکه Calico با اجرای پاد تست

kubectl run test-pod --image=busybox --restart=Never -- sleep 3600
kubectl exec -it test-pod -- ping 8.8.8.8

تنظیم Network Policy در Calico

مسیر فایل: calico-policy.yaml

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-http
  namespace: default
spec:
  selector: app == "web"
  ingress:
  - action: Allow
    protocol: TCP
    destination:
      ports:
      - 80

اعمال Policy برای مجاز کردن ترافیک HTTP

kubectl apply -f calico-policy.yaml

بررسی Policy‌های فعال در Calico

calicoctl get policy

Cilium: پیاده‌سازی و پیکربندی

معرفی Cilium

Cilium یک CNI Plugin مبتنی بر eBPF است که امنیت و عملکرد شبکه را در Kubernetes بهینه‌سازی می‌کند. Cilium قابلیت‌هایی مانند امنیت لایه ۷ (HTTP، gRPC)، مسیریابی پویا و observability پیشرفته را ارائه می‌دهد.

نصب Cilium در Kubernetes

برای راه‌اندازی Cilium در Kubernetes، می‌توان از روش‌های مختلفی مانند Helm یا Manifests استفاده کرد.

دانلود و نصب CLI ابزار Cilium

curl -L --remote-name https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64
chmod +x cilium-linux-amd64
sudo mv cilium-linux-amd64 /usr/local/bin/cilium

نصب Cilium با Helm

helm repo add cilium https://helm.cilium.io/
helm repo update
helm install cilium cilium/cilium --namespace kube-system

بررسی وضعیت اجرای Cilium

kubectl get pods -n kube-system -l k8s-app=cilium

بررسی وضعیت CNI

kubectl get nodes -o wide

تست ارتباط شبکه در Cilium

kubectl run test-pod --image=busybox --restart=Never -- sleep 3600
kubectl exec -it test-pod -- ping 8.8.8.8

تنظیم Network Policy در Cilium

مسیر فایل: cilium-policy.yaml

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-http
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: web
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

اعمال Policy برای مجاز کردن ارتباط HTTP بین frontend و web

kubectl apply -f cilium-policy.yaml

بررسی Policy‌های فعال در Cilium

cilium policy get

حذف و مدیریت CNI Plugins

حذف Calico

kubectl delete -f calico-install.yaml

حذف Cilium

helm uninstall cilium -n kube-system

بررسی تنظیمات CNI پس از حذف

kubectl get pods -n kube-system | grep cni

جمع‌بندی

• CNI در Kubernetes برای مدیریت شبکه بین پادها و تأمین امنیت ارتباطات مورد استفاده قرار می‌گیرد.
• Calico و Cilium از محبوب‌ترین CNI Plugins هستند که قابلیت‌هایی مانند Network Policies و امنیت شبکه‌ای پیشرفته را ارائه می‌دهند.
• Calico از BGP و VXLAN پشتیبانی کرده و راهکاری مبتنی بر فایروال برای کنترل ترافیک ارائه می‌دهد.
• Cilium مبتنی بر eBPF است و قابلیت‌هایی مانند کنترل سطح لایه ۷ و بهینه‌سازی عملکرد شبکه را دارد.
• برای استفاده از هرکدام از این ابزارها، باید به درستی آن‌ها را نصب، پیکربندی و تست کرد تا از عملکرد صحیح آن‌ها در شبکه Kubernetes اطمینان حاصل شود.

• Baseline: حداقل سیاست‌های امنیتی که برای اکثر بارهای کاری استاندارد مناسب است.
• Restricted: سطح امنیتی بالاتر که بسیاری از قابلیت‌های بالقوه ناامن را مسدود می‌کند.
• Privileged: سطح دسترسی کامل بدون هیچ محدودیتی (برای استفاده‌های خاص مانند مدیریت زیرساخت).

نحوه پیاده‌سازی Pod Security Standards

در نسخه‌های جدید Kubernetes، PSS از طریق Pod Security Admission (PSA) مدیریت می‌شود. این قابلیت با استفاده از Namespace Labels سیاست‌های امنیتی را بر پادها اعمال می‌کند.

بررسی فعال بودن Pod Security Admission

kubectl api-resources | grep podsecurity

پیاده‌سازی Baseline Policy

Baseline Policy حداقل سیاست‌های امنیتی را اعمال می‌کند تا از اجرای پادهای کاملاً ناامن جلوگیری کند، اما همچنان سازگاری را حفظ می‌کند.

ایجاد Namespace و اعمال سطح امنیتی Baseline

kubectl create namespace baseline-ns
kubectl label namespace baseline-ns pod-security.kubernetes.io/enforce=baseline
kubectl label namespace baseline-ns pod-security.kubernetes.io/audit=baseline
kubectl label namespace baseline-ns pod-security.kubernetes.io/warn=baseline

اجرای یک پاد در این Namespace

مسیر فایل: baseline-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: baseline-pod
  namespace: baseline-ns
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]

اعمال پیکربندی پاد Baseline

kubectl apply -f baseline-pod.yaml

بررسی لاگ‌های مربوط به سیاست امنیتی Baseline

kubectl get events --namespace baseline-ns

پیاده‌سازی Restricted Policy

Restricted Policy سخت‌گیرانه‌ترین سیاست امنیتی است که اکثر قابلیت‌های پرریسک را غیرفعال می‌کند، از جمله:

• اجرای پادها بدون root privileges.
• جلوگیری از Privilege Escalation.
• ممنوعیت HostPath Volume.

ایجاد Namespace و اعمال سطح امنیتی Restricted

kubectl create namespace restricted-ns
kubectl label namespace restricted-ns pod-security.kubernetes.io/enforce=restricted
kubectl label namespace restricted-ns pod-security.kubernetes.io/audit=restricted
kubectl label namespace restricted-ns pod-security.kubernetes.io/warn=restricted

اجرای یک پاد در این Namespace

مسیر فایل: restricted-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
  namespace: restricted-ns
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      allowPrivilegeEscalation: false

اعمال پیکربندی پاد Restricted

kubectl apply -f restricted-pod.yaml

بررسی لاگ‌های مربوط به سیاست امنیتی Restricted

kubectl get events --namespace restricted-ns

پیاده‌سازی Privileged Policy

Privileged Policy بدون هیچ محدودیتی به پادها اجازه اجرا می‌دهد و معمولاً برای موارد خاص مانند اجرای ابزارهای مانیتورینگ، سیستمی یا زیرساختی استفاده می‌شود.

ایجاد Namespace و اعمال سطح امنیتی Privileged

kubectl create namespace privileged-ns
kubectl label namespace privileged-ns pod-security.kubernetes.io/enforce=privileged
kubectl label namespace privileged-ns pod-security.kubernetes.io/audit=privileged
kubectl label namespace privileged-ns pod-security.kubernetes.io/warn=privileged

اجرای یک پاد در این Namespace

مسیر فایل: privileged-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
  namespace: privileged-ns
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      privileged: true

اعمال پیکربندی پاد Privileged

kubectl apply -f privileged-pod.yaml

بررسی لاگ‌های مربوط به سیاست امنیتی Privileged

kubectl get events --namespace privileged-ns

بررسی سطح امنیتی یک Namespace

برای مشاهده سطح امنیتی تنظیم‌شده در یک Namespace، از دستور زیر استفاده کنید:

kubectl get ns --show-labels

حذف یک سطح امنیتی از Namespace

برای حذف سیاست امنیتی از یک Namespace، برچسب‌های مربوطه را پاک کنید:

kubectl label namespace baseline-ns pod-security.kubernetes.io/enforce-
kubectl label namespace restricted-ns pod-security.kubernetes.io/enforce-
kubectl label namespace privileged-ns pod-security.kubernetes.io/enforce-

جمع‌بندی

• Pod Security Standards (PSS) در Kubernetes برای کنترل سطح دسترسی و امنیت پادها استفاده می‌شود.
• سه سطح امنیتی مختلف وجود دارد: Baseline، Restricted و Privileged.
• Baseline حداقل سیاست‌های امنیتی را اعمال می‌کند.
• Restricted سیاست‌های سخت‌گیرانه‌تری را برای جلوگیری از تهدیدات امنیتی اجرا می‌کند.
• Privileged به پادها اجازه اجرای آزادانه بدون محدودیت را می‌دهد.
• Pod Security Admission (PSA) مکانیزم اعمال PSS در Kubernetes است و از Namespace Labels برای تنظیم این سیاست‌ها استفاده می‌شود.
• برای مدیریت امنیت Kubernetes، استفاده از سیاست‌های PSS بسیار ضروری است و می‌تواند از حملات امنیتی و آسیب‌پذیری‌ها جلوگیری کند.

• جلوگیری از اجرای Podها با دسترسی root
• محدودسازی اجرای کانتینرها در Namespaceهای خاص

جلوگیری از اجرای Podها با دسترسی root

به‌صورت پیش‌فرض، اگر در Kubernetes محدودیتی برای سطح دسترسی پادها تعیین نشود، کانتینرها می‌توانند با دسترسی root اجرا شوند. برای جلوگیری از این موضوع، می‌توان از SecurityContext در تعریف پاد استفاده کرد.

ایجاد یک پاد بدون محدودیت امنیتی (ناامن)

مسیر فایل: insecure-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]

اعمال پاد ناامن

kubectl apply -f insecure-pod.yaml

بررسی سطح دسترسی این پاد

kubectl exec -it insecure-pod -- whoami

این دستور خروجی root را نمایش می‌دهد که نشان‌دهنده‌ی سطح دسترسی بالا و ناامن است.

ایجاد پاد با محدودیت اجرای root

مسیر فایل: secure-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      allowPrivilegeEscalation: false

اعمال پاد امن

kubectl apply -f secure-pod.yaml

بررسی سطح دسترسی این پاد

kubectl exec -it secure-pod -- whoami

این بار خروجی چیزی غیر از root خواهد بود که نشان می‌دهد این پاد با یک کاربر غیر root اجرا شده است.

محدودسازی اجرای کانتینرها در Namespaceهای خاص

برای محدودسازی اجرای کانتینرها در Namespaceهای خاص، می‌توان از Pod Security Admission (PSA) استفاده کرد و Pod Security Policies (در نسخه‌های قدیمی‌تر Kubernetes) را به کار برد.

ایجاد Namespace و اعمال محدودیت عدم اجرای پادهای غیرامن

kubectl create namespace restricted-ns
kubectl label namespace restricted-ns pod-security.kubernetes.io/enforce=restricted

تست اجرای یک پاد بدون محدودیت در این Namespace

مسیر فایل: restricted-test-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: restricted-test-pod
  namespace: restricted-ns
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]

اعمال پاد

kubectl apply -f restricted-test-pod.yaml

این پاد به دلیل سیاست‌های محدودکننده در Namespace مربوطه اجرا نخواهد شد.

مشاهده دلیل عدم اجرای پاد

kubectl get events --namespace restricted-ns

جمع‌بندی

• برای جلوگیری از اجرای پادها با دسترسی root باید runAsNonRoot: true و allowPrivilegeEscalation: false را در SecurityContext تعریف کرد.
• برای محدودسازی اجرای کانتینرها در Namespaceهای خاص می‌توان از Pod Security Admission استفاده کرد و Namespace را به‌صورت restricted تنظیم کرد.
• اجرای یک پاد ناامن در Namespace محدودشده باعث رد شدن درخواست و ایجاد خطای امنیتی خواهد شد.
• این روش‌ها نقش مهمی در افزایش امنیت محیط Kubernetes و جلوگیری از سوءاستفاده‌های امنیتی دارند.

• Kube-bench: برای ارزیابی وضعیت امنیتی کلاستر
• OPA/Gatekeeper: برای پیاده‌سازی سیاست‌های امنیتی

Kube-bench: ارزیابی وضعیت امنیتی کلاستر

Kube-bench ابزاری است که بر اساس CIS Kubernetes Benchmark کلاستر را اسکن کرده و وضعیت امنیتی آن را بررسی می‌کند.

نصب Kube-bench

برای نصب kube-bench می‌توان از Docker یا اجرای مستقیم باینری استفاده کرد.

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

یا برای اجرای مستقیم روی گره‌های کلاستر:

curl -L https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench_$(uname -s)_$(uname -m) -o /usr/local/bin/kube-bench
chmod +x /usr/local/bin/kube-bench

اجرای Kube-bench روی نودهای کلاستر

kube-bench run --config-dir /etc/kube-bench/cfg --config /etc/kube-bench/cfg/config.yaml

بررسی خروجی Kube-bench

cat /var/log/kube-bench.log

این ابزار بررسی می‌کند که آیا تنظیمات امنیتی Kubernetes مطابق با استانداردهای CIS هستند یا خیر و گزارش دقیقی ارائه می‌دهد.

OPA/Gatekeeper: پیاده‌سازی سیاست‌های امنیتی

OPA (Open Policy Agent) ابزاری برای تعریف و اعمال سیاست‌های امنیتی در Kubernetes است. Gatekeeper نسخه‌ای از OPA است که به‌صورت کنترلر Kubernetes عمل می‌کند.

نصب Gatekeeper

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

ایجاد یک سیاست برای جلوگیری از اجرای کانتینرهای با دسترسی root

مسیر فایل: restrict-root.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPNoPrivilege
metadata:
  name: restrict-root
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]

اعمال سیاست امنیتی

kubectl apply -f restrict-root.yaml

بررسی سیاست‌های فعال در Gatekeeper

kubectl get constraints

تست اجرای یک پاد غیرامن

مسیر فایل: insecure-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]

اعمال پاد ناامن

kubectl apply -f insecure-pod.yaml

این دستور با خطای “violates policy: restrict-root” مواجه می‌شود که نشان می‌دهد سیاست امنیتی به‌درستی اعمال شده است.

جمع‌بندی

• Kube-bench یک ابزار بررسی امنیتی برای کلاستر Kubernetes است که استانداردهای CIS را ارزیابی می‌کند.
• OPA/Gatekeeper ابزارهایی برای پیاده‌سازی سیاست‌های امنیتی هستند که اجازه اجرای تنظیمات ناامن را نمی‌دهند.
• با استفاده از Gatekeeper می‌توان سیاست‌هایی مانند جلوگیری از اجرای کانتینرهای با دسترسی root را اعمال کرد.
• ابزارهای متن‌باز مانند Kube-bench و OPA/Gatekeeper نقش مهمی در افزایش امنیت Kubernetes دارند و استفاده از آن‌ها در محیط‌های عملیاتی توصیه می‌شود.

ابزارهای مورد بررسی شامل موارد زیر هستند:

• Kube-bench: بررسی امنیتی بر اساس CIS Benchmark
• Kube-hunter: شناسایی آسیب‌پذیری‌ها در کلاستر
• Trivy: اسکن آسیب‌پذیری‌های تصویر کانتینر
• OPA/Gatekeeper: پیاده‌سازی سیاست‌های امنیتی در Kubernetes

Kube-bench: بررسی امنیتی کلاستر بر اساس استاندارد CIS

Kube-bench یک ابزار بررسی امنیتی برای Kubernetes است که تنظیمات کلاستر را با استانداردهای CIS Kubernetes Benchmark مقایسه می‌کند.

نصب Kube-bench

Kube-bench را می‌توان مستقیماً روی گره‌های Kubernetes اجرا کرد یا به‌عنوان یک پاد در کلاستر مستقر نمود.

curl -L https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench_$(uname -s)_$(uname -m) -o /usr/local/bin/kube-bench
chmod +x /usr/local/bin/kube-bench

اجرای Kube-bench برای بررسی امنیتی

kube-bench run --config-dir /etc/kube-bench/cfg --config /etc/kube-bench/cfg/config.yaml

مشاهده گزارش امنیتی

cat /var/log/kube-bench.log

Kube-hunter: اسکن و شناسایی آسیب‌پذیری‌ها

Kube-hunter ابزاری برای اسکن کلاستر Kubernetes به‌منظور یافتن مشکلات امنیتی و نقاط ضعف شبکه‌ای است.

نصب Kube-hunter

pip install kube-hunter

اجرای Kube-hunter برای جستجوی آسیب‌پذیری‌ها

• اسکن لوکال:

kube-hunter --local

• اسکن آدرس خاص:

kube-hunter --remote <K8S-API-ADDRESS>

• اسکن شبکه:

kube-hunter --network

مشاهده گزارش Kube-hunter

cat /var/log/kube-hunter.log

Trivy: اسکن امنیتی تصاویر کانتینر

Trivy ابزاری برای اسکن آسیب‌پذیری‌های تصاویر کانتینر، پادها و مخازن است.

نصب Trivy

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh
mv trivy /usr/local/bin/

اسکن تصویر کانتینر با Trivy

trivy image nginx:latest

اسکن کلاستر Kubernetes با Trivy

trivy k8s --report all cluster

OPA/Gatekeeper: پیاده‌سازی سیاست‌های امنیتی

Open Policy Agent (OPA) و Gatekeeper برای کنترل دسترسی‌ها و اجرای سیاست‌های امنیتی Kubernetes استفاده می‌شوند.

نصب Gatekeeper

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

ایجاد سیاست برای جلوگیری از اجرای کانتینرهای با دسترسی root

مسیر فایل: restrict-root.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPNoPrivilege
metadata:
  name: restrict-root
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]

اعمال سیاست امنیتی

kubectl apply -f restrict-root.yaml

بررسی سیاست‌های فعال

kubectl get constraints

جمع‌بندی

• Kube-bench امنیت کلاستر را بر اساس CIS Benchmark بررسی می‌کند.
• Kube-hunter آسیب‌پذیری‌های شبکه‌ای را در کلاستر کشف و گزارش می‌کند.
• Trivy برای اسکن آسیب‌پذیری‌های تصاویر کانتینر و کلاستر استفاده می‌شود.
• OPA/Gatekeeper سیاست‌های امنیتی را در Kubernetes اعمال و کنترل می‌کند.
• استفاده از این ابزارها به تقویت امنیت کلاستر Kubernetes کمک می‌کند و اجرای آن‌ها برای محیط‌های عملیاتی توصیه می‌شود.

ابزارهای مورد استفاده:

• Trivy: اسکن آسیب‌پذیری‌های تصاویر کانتینر
• Kube-bench: بررسی امنیتی کلاستر بر اساس CIS Benchmark
• Kube-hunter: شناسایی آسیب‌پذیری‌های شبکه‌ای
• OPA/Gatekeeper: پیاده‌سازی سیاست‌های امنیتی
• GitHub Actions/GitLab CI: اجرای خودکار تست‌های امنیتی

ایجاد Pipeline امنیتی در CI/CD

۱. تنظیم فایل CI/CD برای بررسی امنیتی (GitHub Actions)

مسیر فایل: .github/workflows/security-check.yml

name: Security Check Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  security-checks:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Code
      uses: actions/checkout@v3

    - name: Install Trivy
      run: |
        curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh
        sudo mv trivy /usr/local/bin/

    - name: Scan Container Image with Trivy
      run: trivy image my-app:latest

    - name: Install kube-bench
      run: |
        curl -L https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench_$(uname -s)_$(uname -m) -o kube-bench
        chmod +x kube-bench
        sudo mv kube-bench /usr/local/bin/

    - name: Run kube-bench for security compliance
      run: kube-bench run --config-dir /etc/kube-bench/cfg --config /etc/kube-bench/cfg/config.yaml

    - name: Install kube-hunter
      run: pip install kube-hunter

    - name: Run kube-hunter for vulnerability scanning
      run: kube-hunter --remote ${{ secrets.K8S_API_URL }}

۲. تنظیم فایل CI/CD برای بررسی امنیتی (GitLab CI)

مسیر فایل: .gitlab-ci.yml

stages:
  - security_scan

security_scan:
  image: alpine:latest
  before_script:
    - apk add --no-cache curl bash
  script:
    - curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh
    - mv trivy /usr/local/bin/
    - trivy image my-app:latest
    - apk add --no-cache python3 py3-pip
    - pip install kube-hunter
    - kube-hunter --remote $K8S_API_URL

۳. تنظیم OPA/Gatekeeper برای اعتبارسنجی در CI/CD

برای بررسی سیاست‌های امنیتی قبل از استقرار، می‌توان OPA/Gatekeeper را در CI/CD ادغام کرد.

مسیر فایل: policy-check.yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPNoPrivilege
metadata:
  name: restrict-root
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]

اجرای بررسی امنیتی در CI/CD

kubectl apply -f policy-check.yaml
kubectl get constraints

۴. اجرای بررسی امنیتی در Kubernetes به‌صورت خودکار

برای اجرای خودکار بررسی‌های امنیتی در محیط Kubernetes، می‌توان از CronJob استفاده کرد.

مسیر فایل: security-cronjob.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: security-check
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: security-check
            image: bitnami/kubectl:latest
            command: ["/bin/sh", "-c"]
            args:
              - |
                trivy image my-app:latest
                kube-bench run
                kube-hunter --network
          restartPolicy: OnFailure

اعمال تنظیمات:

kubectl apply -f security-cronjob.yaml

جمع‌بندی

• CI/CD می‌تواند برای خودکارسازی بررسی‌های امنیتی در مراحل مختلف استقرار استفاده شود.
• ابزارهایی مانند Trivy، Kube-bench و Kube-hunter در GitHub Actions و GitLab CI قابل ادغام هستند.
• OPA/Gatekeeper سیاست‌های امنیتی را قبل از استقرار بررسی می‌کند.
• استفاده از Kubernetes CronJob برای بررسی امنیتی خودکار و مداوم توصیه می‌شود.

اجرای این فرآیند به افزایش امنیت، کاهش ریسک و شناسایی سریع مشکلات امنیتی کمک خواهد کرد.

ایجاد و مدیریت گواهینامه‌های SSL/TLS در Kubernetes

۱. ایجاد یک گواهینامه خودامضا شده

در صورتی که از یک CA خارجی استفاده نشود، می‌توان یک گواهینامه TLS خودامضا ایجاد کرد.

ایجاد کلید خصوصی و گواهینامه SSL:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt \
  -subj "/CN=mydomain.com/O=myorg"

ایجاد Secret برای ذخیره گواهینامه در Kubernetes:

kubectl create secret tls my-tls-secret \
  --cert=tls.crt --key=tls.key

۲. فعال‌سازی TLS در Ingress Controller

برای فعال‌سازی HTTPS در NGINX Ingress Controller، باید Secret TLS ایجاد شده را به Ingress مرتبط کنیم.

مسیر فایل: ingress-tls.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - mydomain.com
    secretName: my-tls-secret
  rules:
  - host: mydomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 443

اعمال تنظیمات:

kubectl apply -f ingress-tls.yaml

۳. استفاده از cert-manager برای مدیریت خودکار گواهینامه‌ها

cert-manager یک راهکار خودکار برای دریافت و مدیریت گواهینامه‌های SSL/TLS از Let’s Encrypt یا سایر CAها است.

نصب cert-manager

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

ایجاد Issuer برای دریافت گواهینامه از Let’s Encrypt

مسیر فایل: issuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@mydomain.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

اعمال تنظیمات:

kubectl apply -f issuer.yaml

ایجاد گواهینامه با cert-manager

مسیر فایل: certificate.yaml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-tls-cert
spec:
  secretName: my-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: mydomain.com
  dnsNames:
  - mydomain.com

اعمال تنظیمات:

kubectl apply -f certificate.yaml

۴. فعال‌سازی ارتباطات TLS بین سرویس‌های داخلی

برای ایمن‌سازی ارتباطات بین سرویس‌ها، می‌توان از mTLS در Service Mesh مانند Istio استفاده کرد.

نصب Istio

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo -y

فعال‌سازی mTLS در Istio

مسیر فایل: mtls-policy.yaml

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

اعمال تنظیمات:

kubectl apply -f mtls-policy.yaml

۵. اجباری کردن TLS برای دسترسی به API Server

برای فعال‌سازی و اجباری کردن SSL/TLS در API Server، باید تنظیمات Kube-API Server را بررسی و پیکربندی کنیم.

ویرایش فایل تنظیمات API Server: مسیر فایل: /etc/kubernetes/manifests/kube-apiserver.yaml

- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
- --client-ca-file=/etc/kubernetes/pki/ca.crt

اعمال تغییرات و ریستارت سرویس Kube-API Server:

systemctl restart kubelet

جمع‌بندی

• برای ایمن‌سازی ارتباطات در Kubernetes، می‌توان از SSL/TLS استفاده کرد.
• ایجاد گواهینامه خودامضا یا دریافت گواهینامه از Let’s Encrypt امکان‌پذیر است.
• برای مدیریت خودکار گواهینامه‌ها، cert-manager پیشنهاد می‌شود.
• برای ایمن‌سازی ارتباطات داخلی، استفاده از mTLS در Istio مناسب است.
• API Server باید با TLS فعال و اجباری پیکربندی شود.

فعال‌سازی TLS امنیت ارتباطات را افزایش داده و از حملات MITM و شنود داده‌ها جلوگیری می‌کند.

• رمزنگاری داده‌ها در etcd
• محدود کردن دسترسی به etcd فقط برای کنترل پلن

رمزنگاری داده‌ها در etcd

رمزنگاری داده‌های حساس در etcd باعث محافظت از اطلاعات محرمانه Kubernetes می‌شود. این فرآیند با استفاده از EncryptionConfiguration انجام شده و به kube-apiserver ابلاغ می‌شود که اطلاعات حساس را قبل از ذخیره‌سازی رمزگذاری کند.

۱. ایجاد فایل تنظیمات رمزنگاری

برای رمزنگاری داده‌های etcd، یک فایل تنظیمات رمزنگاری باید در مسیر /etc/kubernetes ایجاد شود.

مسیر فایل: /etc/kubernetes/encryption-config.yaml

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: c2VjcmV0LWVuY3J5cHRpb24ta2V5LTI1Ng==
      - identity: {}

نکات:

• کلید AES-CBC به صورت Base64 است. می‌توان یک کلید جدید با دستور زیر ایجاد کرد:

  head -c 32 /dev/urandom | base64
  

۲. تنظیم kube-apiserver برای استفاده از رمزنگاری

فایل تنظیمات kube-apiserver باید تغییر کند تا etcd را مجبور به استفاده از رمزنگاری کند.

مسیر فایل: /etc/kubernetes/manifests/kube-apiserver.yaml

- --encryption-provider-config=/etc/kubernetes/encryption-config.yaml

۳. ری‌استارت kube-apiserver برای اعمال تغییرات

systemctl restart kubelet

۴. بررسی رمزنگاری شدن داده‌ها

می‌توان بررسی کرد که آیا داده‌ها در etcd رمزگذاری شده‌اند یا خیر:

ETCDCTL_API=3 etcdctl get /registry/secrets/default/my-secret \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key | hexdump -C

اگر رمزنگاری فعال باشد، داده‌های خروجی به صورت کدگذاری شده نمایش داده می‌شوند.

محدود کردن دسترسی به etcd فقط برای کنترل پلن

برای جلوگیری از دسترسی غیرمجاز به etcd، بهتر است فقط نودهای کنترل‌پلن مجاز به ارتباط با etcd باشند. این کار با پیکربندی فایروال و تنظیمات etcd انجام می‌شود.

۱. محدود کردن دسترسی از طریق فایروال

در سیستم‌های مبتنی بر iptables، می‌توان فقط کنترل‌پلن را به etcd متصل کرد.

iptables -A INPUT -s <control-plane-ip> -p tcp --dport 2379 -j ACCEPT
iptables -A INPUT -p tcp --dport 2379 -j DROP

در firewalld (سیستم‌های مبتنی بر RHEL و CentOS):

firewall-cmd --zone=trusted --add-source=<control-plane-ip>
firewall-cmd --zone=trusted --add-port=2379/tcp
firewall-cmd --reload

۲. فعال‌سازی احراز هویت و مجوزها در etcd

برای افزایش امنیت و جلوگیری از دسترسی غیرمجاز، etcd باید از احراز هویت و مجوزهای دسترسی استفاده کند.

فعال‌سازی احراز هویت در etcd:

export ETCDCTL_API=3
etcdctl user add root --interactive
etcdctl auth enable

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

۳. تنظیم مجوزها برای kube-apiserver

اعطای مجوز root به kube-apiserver برای دسترسی به etcd:

etcdctl role add kubernetes
etcdctl role grant-permission kubernetes readwrite --prefix=true /
etcdctl user add kube-apiserver:<password>
etcdctl user grant-role kube-apiserver kubernetes

این کار باعث می‌شود که فقط kube-apiserver قادر به دسترسی به etcd باشد.

۴. محدود کردن etcd فقط به localhost

برای اطمینان از اینکه etcd فقط به درخواست‌های کنترل پلن پاسخ می‌دهد، باید آن را محدود به localhost کنیم.

مسیر فایل: /etc/kubernetes/manifests/etcd.yaml

- --listen-client-urls=https://127.0.0.1:2379
- --advertise-client-urls=https://127.0.0.1:2379

اعمال تغییرات:

systemctl restart kubelet

این تنظیمات تضمین می‌کنند که etcd فقط از نود کنترل پلن قابل دسترسی است و سایر نودها قادر به برقراری ارتباط با آن نیستند.

جمع‌بندی

• رمزنگاری داده‌ها در etcd از افشای اطلاعات حساس جلوگیری می‌کند.
• تنظیمات احراز هویت و مجوزهای etcd باعث کاهش سطح دسترسی کاربران غیرمجاز می‌شود.
• استفاده از فایروال و تنظیمات etcd دسترسی به نود کنترل‌پلن را محدود می‌کند.
• کاهش سطح دسترسی به localhost مانع از اتصال غیرمجاز نودهای دیگر می‌شود.

این اقدامات باعث می‌شوند که etcd کاملاً ایمن شده و فقط کنترل پلن Kubernetes به آن دسترسی داشته باشد.

جمع‌آوری لاگ‌های API Server برای شناسایی تهدیدات

kube-apiserver تمامی درخواست‌ها، خطاها و فعالیت‌های مربوط به کاربران، سرویس‌ها و کنترل پلن را ثبت می‌کند. این لاگ‌ها به ما کمک می‌کنند که فعالیت‌های غیرمجاز، حملات احتمالی و خطاهای عملیاتی را شناسایی کنیم.

۱. فعال‌سازی لاگ‌گیری در API Server

برای فعال‌سازی لاگ‌گیری در API Server، تنظیمات آن باید تغییر کند.

مسیر فایل: /etc/kubernetes/manifests/kube-apiserver.yaml

- --audit-log-path=/var/log/kubernetes/apiserver-audit.log
- --audit-log-maxage=30
- --audit-log-maxbackup=10
- --audit-log-maxsize=100

توضیحات:

• --audit-log-path: مسیر ذخیره لاگ‌های Audit.
• --audit-log-maxage: مدت زمان نگهداری لاگ‌ها (بر حسب روز).
• --audit-log-maxbackup: تعداد فایل‌های پشتیبان.
• --audit-log-maxsize: حداکثر اندازه هر فایل لاگ (بر حسب مگابایت).

۲. ری‌استارت kube-apiserver برای اعمال تغییرات

systemctl restart kubelet

۳. تنظیم Policy برای لاگ‌های Audit

kube-apiserver به یک فایل Policy نیاز دارد تا تعیین کند چه لاگ‌هایی باید ثبت شوند.

مسیر فایل: /etc/kubernetes/audit-policy.yaml

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    verbs: ["create", "update", "delete"]
    resources:
      - group: ""
        resources: ["pods", "deployments", "secrets"]
  - level: RequestResponse
    verbs: ["create", "delete"]
    resources:
      - group: ""
        resources: ["secrets"]

نکات:

• درخواست‌های create، update و delete روی pods، deployments و secrets لاگ می‌شوند.
• تمامی درخواست‌های create و delete روی secrets همراه با بدنه درخواست و پاسخ ذخیره می‌شوند.

۴. معرفی Policy به kube-apiserver

فایل تنظیمات kube-apiserver.yaml باید تغییر کند تا audit-policy.yaml را استفاده کند.

مسیر فایل: /etc/kubernetes/manifests/kube-apiserver.yaml

- --audit-policy-file=/etc/kubernetes/audit-policy.yaml

ری‌استارت API Server برای اعمال تنظیمات:

systemctl restart kubelet

۵. جمع‌آوری لاگ‌های API Server با Fluentd

Fluentd یک ابزار محبوب برای جمع‌آوری لاگ‌ها و ارسال آن‌ها به ElasticSearch، Loki یا دیگر ابزارهای ذخیره‌سازی لاگ است.

۵.۱. نصب Fluentd روی نودهای Kubernetes

kubectl apply -f https://raw.githubusercontent.com/fluent/fluentd-kubernetes-daemonset/master/fluentd-daemonset-elasticsearch.yaml

این دستور یک DaemonSet برای جمع‌آوری لاگ‌های Kubernetes ایجاد می‌کند.

۵.۲. بررسی وضعیت Fluentd

kubectl get pods -n kube-system | grep fluentd

۵.۳. ارسال لاگ‌های API Server به Fluentd

فایل /etc/kubernetes/manifests/kube-apiserver.yaml را ویرایش کرده و مسیر لاگ‌ها را مشخص کنید.

- --audit-log-path=/var/log/kubernetes/apiserver-audit.log

سپس باید Fluentd را پیکربندی کنیم تا این لاگ‌ها را بخواند.

مسیر فایل: /etc/fluent/fluent.conf

<source>
  @type tail
  path /var/log/kubernetes/apiserver-audit.log
  pos_file /var/log/kubernetes/apiserver-audit.pos
  tag kubernetes.audit
  format json
</source>

<match kubernetes.audit>
  @type elasticsearch
  host elasticsearch.kube-system.svc
  port 9200
  logstash_format true
</match>

ری‌استارت Fluentd برای اعمال تغییرات:

systemctl restart fluentd

۶. تحلیل لاگ‌ها با Kibana و Loki

۶.۱. مشاهده لاگ‌های API Server در Kibana

بعد از تنظیم Fluentd و Elasticsearch، می‌توان به Kibana متصل شد و لاگ‌ها را مشاهده کرد.

دریافت آدرس Kibana:

kubectl get svc -n kube-system | grep kibana

سپس Kibana را در مرورگر باز کرده و شاخص kubernetes.audit را تنظیم کنید.

۶.۲. ارسال لاگ‌ها به Loki

برای ارسال لاگ‌ها به Loki (Grafana)، باید خروجی Fluentd را تغییر دهیم.

مسیر فایل: /etc/fluent/fluent.conf

<match kubernetes.audit>
  @type loki
  url "http://loki.kube-system.svc:3100/api/prom/push"
  labels {"job":"kubernetes-audit"}
</match>

ری‌استارت Fluentd برای اعمال تغییرات:

systemctl restart fluentd

جمع‌بندی

• فعال‌سازی لاگ‌گیری در API Server با استفاده از تنظیمات kube-apiserver.yaml.
• ایجاد Policy برای تعیین لاگ‌های مهم و جلوگیری از ثبت اطلاعات غیرضروری.
• استفاده از Fluentd برای جمع‌آوری و ارسال لاگ‌های API Server.
• ذخیره‌سازی و تحلیل لاگ‌ها در Elasticsearch و Loki برای نظارت بر تهدیدات و رویدادهای غیرمجاز.

این تنظیمات به شما کمک می‌کنند تا رویدادهای مهم امنیتی را شناسایی کرده و پاسخ مناسبی به تهدیدات بدهید.

بررسی وضعیت انقضای گواهینامه‌ها

برای مشاهده تاریخ انقضای گواهینامه‌های فعلی در کلاستر از دستور زیر استفاده کنید:

sudo kubeadm certs check-expiration

این دستور لیستی از گواهینامه‌های مربوط به کنترل پلن را به همراه تاریخ انقضای آن‌ها نمایش می‌دهد.

خودکارسازی چرخش گواهینامه‌ها با استفاده از kubeadm

در صورتی که کلاستر شما با kubeadm مدیریت می‌شود، می‌توانید به صورت خودکار تمامی گواهینامه‌ها را با دستور زیر چرخش دهید:

sudo kubeadm certs renew all

پس از اجرای دستور فوق، لازم است سرویس kubelet را ریستارت کنید تا تغییرات اعمال شود:

sudo systemctl restart kubelet

برای بررسی موفقیت‌آمیز بودن چرخش، مجدداً تاریخ انقضای گواهینامه‌ها را با دستور زیر مشاهده کنید:

sudo kubeadm certs check-expiration

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

در صورتی که نیاز به چرخش دستی گواهینامه‌ها داشته باشید، مراحل زیر را دنبال کنید. در این مثال، گواهینامه API Server را به‌روزرسانی می‌کنیم.

ایجاد کلید خصوصی جدید

openssl genrsa -out /etc/kubernetes/pki/apiserver-new.key 2048

ایجاد فایل درخواست امضای گواهینامه (CSR)

در یک فایل متنی به نام apiserver-new.csr.cnf (مسیر: /etc/kubernetes/pki/apiserver-new.csr.cnf) محتویات زیر را قرار دهید:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn

[ dn ]
CN = kube-apiserver
O = system:masters

سپس با دستور زیر فایل CSR را ایجاد کنید:

openssl req -new -key /etc/kubernetes/pki/apiserver-new.key -out /etc/kubernetes/pki/apiserver-new.csr -config /etc/kubernetes/pki/apiserver-new.csr.cnf

امضای CSR توسط CA داخلی

با استفاده از گواهینامه CA موجود، CSR را امضا کنید:

openssl x509 -req -in /etc/kubernetes/pki/apiserver-new.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /etc/kubernetes/pki/apiserver-new.crt -days 365

جایگزینی گواهینامه‌های قدیمی در فایل manifest API Server

در فایل تنظیمات API Server که در مسیر زیر قرار دارد:

/etc/kubernetes/manifests/kube-apiserver.yaml

سطرهای مربوط به گواهینامه را به صورت زیر به‌روز کنید:

- --tls-cert-file=/etc/kubernetes/pki/apiserver-new.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver-new.key

ریستارت kubelet برای اعمال تغییرات

sudo systemctl restart kubelet

بررسی صحت اعمال گواهینامه‌های جدید

با استفاده از دستور زیر می‌توانید بررسی کنید که API Server از گواهینامه‌های جدید استفاده می‌کند:

sudo kubeadm certs check-expiration

نکات تکمیلی

• همیشه قبل از چرخش گواهینامه‌ها، از گواهینامه‌های قدیمی و پیکربندی‌های موجود پشتیبان تهیه کنید.
• اطمینان حاصل کنید که تمام مسیرهای فایل (مانند /etc/kubernetes/pki) به درستی تعیین شده باشند.
• در محیط‌های تولیدی توصیه می‌شود از روش خودکار با kubeadm استفاده شود تا خطاهای دستی کاهش یابد.
• پس از چرخش، وضعیت تمام کنترل پلن با استفاده از دستور زیر بررسی شود:

kubectl get pods -n kube-system

جمع‌بندی

• استفاده از دستور kubeadm certs renew all امکان چرخش خودکار گواهینامه‌های کنترل پلن را فراهم می‌کند.
• پس از چرخش، ریستارت kubelet برای اعمال تغییرات ضروری است.
• در صورت نیاز به چرخش دستی، با استفاده از OpenSSL می‌توان گواهینامه‌های جدید ایجاد و جایگزین گواهینامه‌های قدیمی کرد.
• بررسی دقیق مسیرهای فایل و پشتیبان‌گیری از تنظیمات قبلی از الزامات این فرآیند است.

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

ایجاد Namespaceهای اختصاصی برای تیم‌ها و پروژه‌ها

برای ایجاد Namespace، از دستور زیر استفاده کنید:

kubectl create namespace team-alpha

همچنین می‌توان با استفاده از فایل YAML، Namespace را تعریف کرد. این روش برای ثبت دائمی پیکربندی‌ها مفید است.

ایجاد فایل YAML برای Namespace (مسیر: namespaces/team-alpha.yaml)

apiVersion: v1
kind: Namespace
metadata:
  name: team-alpha
  labels:
    team: alpha

سپس دستور زیر را اجرا کنید:

kubectl apply -f namespaces/team-alpha.yaml

ایجاد محدودیت منابع برای Namespaceها

برای اطمینان از اینکه هر تیم بیش از حد مجاز از منابع استفاده نکند، می‌توان ResourceQuota تنظیم کرد.

تعریف محدودیت منابع در فایل YAML (مسیر: resource-quotas/team-alpha-quota.yaml)

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

اعمال تنظیمات با استفاده از دستور زیر:

kubectl apply -f resource-quotas/team-alpha-quota.yaml

مدیریت دسترسی کاربران به Namespaceها

برای کنترل دسترسی کاربران به Namespace خاص، می‌توان از Role-Based Access Control (RBAC) استفاده کرد.

تعریف Role برای دسترسی کاربر به Namespace (مسیر: rbac/role-team-alpha.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-alpha
  name: team-alpha-developer
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "deployments"]
    verbs: ["get", "list", "create", "update", "delete"]

تعریف RoleBinding برای اختصاص نقش به کاربر خاص (مسیر: rbac/rolebinding-team-alpha.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: team-alpha
  name: team-alpha-developer-binding
subjects:
  - kind: User
    name: "dev-user"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: team-alpha-developer
  apiGroup: rbac.authorization.k8s.io

اعمال تنظیمات:

kubectl apply -f rbac/role-team-alpha.yaml
kubectl apply -f rbac/rolebinding-team-alpha.yaml

بررسی و مانیتورینگ Namespaceها

برای مشاهده لیست Namespaceهای موجود:

kubectl get namespaces

برای مشاهده منابع اختصاص داده‌شده به یک Namespace:

kubectl get resourcequotas -n team-alpha

برای مشاهده سطح دسترسی کاربران در یک Namespace:

kubectl get rolebindings -n team-alpha

جمع‌بندی

• با استفاده از Namespace، می‌توان تیم‌ها و پروژه‌ها را از هم جدا کرد و از مدیریت بهتر منابع بهره برد.
• تنظیم ResourceQuota برای جلوگیری از استفاده بیش از حد منابع ضروری است.
• با استفاده از RBAC، می‌توان دسترسی‌های کاربران را محدود کرد و نقش‌های اختصاصی به آن‌ها داد.
• بررسی مستمر وضعیت منابع و سطح دسترسی‌ها از طریق دستورات kubectl ضروری است.

مدیریت صحیح Namespace‌ها باعث افزایش امنیت، بهره‌وری بهتر و کنترل دقیق‌تر بر روی پروژه‌های مختلف در Kubernetes خواهد شد.

• ResourceQuota: مقدار کل منابعی که یک Namespace می‌تواند مصرف کند را محدود می‌کند.
• LimitRange: مقدار حداقل و حداکثر منابعی که هر Pod یا Container می‌تواند درخواست کند را تعیین می‌کند.

ایجاد ResourceQuota برای محدود کردن مصرف منابع

یک ResourceQuota می‌تواند محدودیت‌هایی روی موارد زیر اعمال کند:

• تعداد Pod‌ها، Service‌ها، PersistentVolumeClaim‌ها و غیره.
• مقدار کلی CPU و Memory قابل استفاده در یک Namespace.

تعریف ResourceQuota (مسیر: resource-quotas/team-alpha-quota.yaml)

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"          # حداکثر مجموع درخواست CPU در Namespace
    requests.memory: "8Gi"      # حداکثر مجموع درخواست RAM در Namespace
    limits.cpu: "8"             # حداکثر مجموع CPU مصرفی
    limits.memory: "16Gi"       # حداکثر مجموع RAM مصرفی
    pods: "20"                  # حداکثر تعداد Podها در این Namespace
    persistentvolumeclaims: "5" # حداکثر تعداد Persistent Volume Claims

اعمال ResourceQuota:

kubectl apply -f resource-quotas/team-alpha-quota.yaml

مشاهده ResourceQuotaها در یک Namespace:

kubectl get resourcequotas -n team-alpha

تعریف LimitRange برای کنترل منابع هر Pod/Container

LimitRange میزان حداقل و حداکثر درخواست منابع را برای هر Pod یا Container تنظیم می‌کند تا از مصرف بیش از حد منابع توسط یک کانتینر جلوگیری شود.

تعریف LimitRange برای محدود کردن منابع (مسیر: limit-ranges/team-alpha-limit.yaml)

apiVersion: v1
kind: LimitRange
metadata:
  name: team-alpha-limit
  namespace: team-alpha
spec:
  limits:
  - type: Container
    max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "250m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"

اعمال LimitRange:

kubectl apply -f limit-ranges/team-alpha-limit.yaml

مشاهده LimitRangeها در یک Namespace:

kubectl get limitranges -n team-alpha

تست و بررسی محدودیت‌های اعمال شده

برای بررسی این‌که یک Pod محدودیت‌های تعیین‌شده را رعایت می‌کند، یک Pod تستی ایجاد می‌کنیم:

ایجاد یک Pod که درخواست بیش از حد منابع دارد (مسیر: pods/high-resource-pod.yaml)

apiVersion: v1
kind: Pod
metadata:
  name: high-resource-pod
  namespace: team-alpha
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: "3"         # بیش از مقدار مجاز در LimitRange
        memory: "5Gi"    # بیش از مقدار مجاز در LimitRange
      limits:
        cpu: "4"
        memory: "6Gi"

اعمال این Pod:

kubectl apply -f pods/high-resource-pod.yaml

اگر مقدار منابع درخواست‌شده از LimitRange فراتر رود، با خطای زیر مواجه خواهید شد:

Error from server (Forbidden): pods "high-resource-pod" is forbidden: 
maximum cpu usage per container is 2, but request is 3.

جمع‌بندی

• ResourceQuota میزان مصرف منابع در سطح Namespace را محدود می‌کند.
• LimitRange حداقل و حداکثر مقدار CPU و RAM را برای هر Pod یا Container مشخص می‌کند.
• اعمال LimitRange و ResourceQuota از سوء‌مصرف منابع توسط تیم‌ها جلوگیری کرده و پایداری کلاستر را افزایش می‌دهد.
• با دستورات kubectl get resourcequotas و kubectl get limitranges می‌توان وضعیت محدودیت‌های اعمال‌شده را بررسی کرد.

مدیریت صحیح منابع در Kubernetes باعث بهینه‌سازی عملکرد کلاستر و جلوگیری از مصرف نامتعادل منابع بین تیم‌ها و پروژه‌های مختلف خواهد شد.

• kube-bench: بررسی تطابق کلاستر با CIS Benchmark
• kube-hunter: شناسایی آسیب‌پذیری‌های عمومی در کلاستر
• Trivy: اسکن تصاویر داکر و پیکربندی‌ها
• OPA/Gatekeeper: اعمال سیاست‌های امنیتی
• Kubescape: آنالیز امنیتی بر اساس استانداردهای معروف مانند NSA و MITRE ATT&CK

بررسی امنیت کلاستر با kube-bench

ابزار kube-bench، کلاستر را بر اساس CIS Kubernetes Benchmark بررسی کرده و موارد امنیتی که باید رعایت شوند را نمایش می‌دهد.

نصب kube-bench (مسیر: /usr/local/bin/kube-bench)

curl -L https://github.com/aquasecurity/kube-bench/releases/latest/download/kube-bench-linux-amd64 -o /usr/local/bin/kube-bench
chmod +x /usr/local/bin/kube-bench

اجرای تست امنیتی روی کل کلاستر:

kube-bench run --benchmark cis-1.6

اجرای تست فقط روی control plane:

kube-bench run --targets master

اجرای تست فقط روی worker nodeها:

kube-bench run --targets node

شناسایی آسیب‌پذیری‌های عمومی با kube-hunter

ابزار kube-hunter کلاستر را برای شناسایی آسیب‌پذیری‌های شناخته‌شده اسکن می‌کند.

نصب kube-hunter (مسیر: /usr/local/bin/kube-hunter)

pip install kube-hunter

اجرای kube-hunter برای شناسایی آسیب‌پذیری‌ها:

kube-hunter --remote <KUBERNETES_API_SERVER>

اجرای kube-hunter روی کل کلاستر:

kube-hunter --internal

اسکن تصاویر Docker و پیکربندی‌ها با Trivy

Trivy برای بررسی آسیب‌پذیری‌های امنیتی در Container Images و Kubernetes Manifests استفاده می‌شود.

نصب Trivy (مسیر: /usr/local/bin/trivy)

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh
mv trivy /usr/local/bin/

اسکن یک تصویر Docker:

trivy image nginx:latest

اسکن Kubernetes Manifest (مسیر: deployments/app-deployment.yaml)

trivy k8s --report summary -f json -o trivy-report.json -n default -f yaml -k deployment app-deployment

اعمال سیاست‌های امنیتی با OPA/Gatekeeper

Open Policy Agent (OPA) همراه با Gatekeeper به شما امکان می‌دهد تا Policy-as-Code را برای امنیت Kubernetes پیاده‌سازی کنید.

نصب Gatekeeper:

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

تعریف یک Policy برای ممنوعیت استفاده از privileged container‌ها (مسیر: policies/privileged-container.yaml)

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sprivilegedcontainer
spec:
  crd:
    spec:
      names:
        kind: K8sPrivilegedContainer
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sprivilegedcontainer
        violation[{"msg": "Privileged containers are not allowed"}] {
          input.review.object.spec.containers[_].securityContext.privileged == true
        }

اعمال این Policy:

kubectl apply -f policies/privileged-container.yaml

بررسی امنیت کلی کلاستر با Kubescape

Kubescape ابزاری برای بررسی امنیتی کلاستر است که بر اساس استانداردهای NSA, MITRE ATT&CK, و CIS Kubernetes Benchmark تست انجام می‌دهد.

نصب Kubescape (مسیر: /usr/local/bin/kubescape)

curl -s https://raw.githubusercontent.com/kubescape/kubescape/main/install.sh | /bin/bash

اجرای اسکن کامل:

kubescape scan --submit --format json --output kubescape-report.json

جمع‌بندی

• kube-bench برای بررسی تطابق کلاستر با CIS Benchmark استفاده می‌شود.
• kube-hunter آسیب‌پذیری‌های عمومی را شناسایی می‌کند.
• Trivy برای اسکن آسیب‌پذیری‌های Container Images و Kubernetes Manifest استفاده می‌شود.
• OPA/Gatekeeper سیاست‌های امنیتی را روی Kubernetes اعمال می‌کند.
• Kubescape تحلیل‌های امنیتی کاملی بر اساس استانداردهای امنیتی شناخته‌شده انجام می‌دهد.

با اجرای منظم این تست‌ها، امنیت Kubernetes Cluster افزایش می‌یابد و از تهدیدات احتمالی جلوگیری می‌شود.

• پشتیبان‌گیری و بازیابی داده‌ها
• استفاده از چندین Replica و Pod Anti-Affinity
• برنامه‌ریزی Failover برای Control Plane و Nodeها
• ایجاد Disaster Recovery Plan با Velero
• مانیتورینگ و هشداردهی سریع در زمان وقوع بحران

پشتیبان‌گیری و بازیابی داده‌ها

برای بازیابی سریع پس از بحران، تهیه Backup از Persistent Volume (PV) و Etcd Database ضروری است.

پشتیبان‌گیری از etcd (مسیر: /backup/etcd-backup.db)

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-backup.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key

بازیابی etcd از پشتیبان (مسیر: /backup/etcd-backup.db)

ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-backup.db \
--data-dir=/var/lib/etcd

استفاده از چندین Replica و Pod Anti-Affinity

برای افزایش مقاومت در برابر خرابی، می‌توان تعداد Replicaها را افزایش داد و با Pod Anti-Affinity، توزیع مناسب روی Nodeها را تضمین کرد.

تعریف Deployment با ۳ Replica و Pod Anti-Affinity (مسیر: deployments/web-app.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - web
              topologyKey: "kubernetes.io/hostname"
      containers:
        - name: web-app
          image: nginx:latest

اعمال این تنظیمات در کلاستر:

kubectl apply -f deployments/web-app.yaml

برنامه‌ریزی Failover برای Control Plane و Worker Nodeها

بررسی وضعیت Control Plane:

kubectl get nodes -o wide

بررسی وضعیت kube-apiserver:

kubectl get pods -n kube-system -l component=kube-apiserver -o wide

فعال‌سازی Control Plane در چندین Node (HA Control Plane)

kubeadm init --control-plane

اتصال Worker Node جدید برای افزایش ظرفیت Failover:

kubeadm join <master-ip>:6443 --token <your-token> \
--discovery-token-ca-cert-hash sha256:<your-hash>

ایجاد Disaster Recovery Plan با Velero

Velero ابزاری برای پشتیبان‌گیری و بازیابی Kubernetes است.

نصب Velero (مسیر: /usr/local/bin/velero)

curl -L https://github.com/vmware-tanzu/velero/releases/latest/download/velero-linux-amd64.tar.gz -o velero.tar.gz
tar -xvf velero.tar.gz
mv velero-linux-amd64/velero /usr/local/bin/

پیکربندی پشتیبان‌گیری روی فضای ذخیره‌سازی (مثلاً S3):

velero install --provider aws --bucket <your-bucket> \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--backup-location-config region=<your-region>

ایجاد یک Backup از کل Namespace production:

velero backup create production-backup --include-namespaces production

بررسی وضعیت Backup:

velero backup get

بازیابی اطلاعات در زمان بحران:

velero restore create --from-backup production-backup

مانیتورینگ و هشداردهی سریع در زمان وقوع بحران

نصب Prometheus برای نظارت بر سلامت کلاستر

kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/bundle.yaml

فعال‌سازی Alerting در Prometheus (مسیر: monitoring/alert-rules.yaml)

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: high-cpu-usage
  namespace: monitoring
spec:
  groups:
    - name: cpu-alerts
      rules:
        - alert: HighCPUUsage
          expr: process_cpu_seconds_total > 80
          for: 2m
          labels:
            severity: critical
          annotations:
            description: "CPU usage is above 80% for more than 2 minutes."

اعمال Alert Rule در Prometheus:

kubectl apply -f monitoring/alert-rules.yaml

جمع‌بندی

• Etcd Backup & Restore: جلوگیری از از دست رفتن تنظیمات کلاستر.
• Replica & Pod Anti-Affinity: جلوگیری از Single Point of Failure.
• HA Control Plane & Worker Node Failover: افزایش دسترس‌پذیری بالا.
• Velero Backup & Restore: برنامه‌ریزی برای Disaster Recovery.
• Prometheus & Alerting: هشداردهی خودکار در زمان بحران.

با اجرای این استراتژی‌ها، احتمال از دست رفتن داده‌ها و Downtime در زمان بحران کاهش می‌یابد.

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

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

📩 اگر سوالی دارید یا به مشکلی برخوردید، همین حالا مطرح کنید!
ما در کوتاه‌ترین زمان ممکن پاسخ شما را ارائه خواهیم داد. 🙌