کبرنیٹس میں سیکیورٹی کا اے بی سی: توثیق، اجازت، آڈیٹنگ

جلد یا بدیر، کسی بھی نظام کے آپریشن میں، سیکورٹی کا مسئلہ پیدا ہوتا ہے: تصدیق، حقوق کی علیحدگی، آڈیٹنگ اور دیگر کاموں کو یقینی بنانا۔ پہلے ہی Kubernetes کے لیے بنایا گیا ہے۔ بہت سے حل، جو آپ کو انتہائی مشکل ماحول میں بھی معیارات کی تعمیل کرنے کی اجازت دیتا ہے... وہی مواد K8s کے بلٹ ان میکانزم کے اندر لاگو سیکیورٹی کے بنیادی پہلوؤں کے لیے وقف ہے۔ سب سے پہلے، یہ ان لوگوں کے لیے مفید ہو گا جو Kubernetes سے واقف ہونا شروع کر رہے ہیں - سیکورٹی سے متعلقہ مسائل کا مطالعہ کرنے کے نقطہ آغاز کے طور پر۔

توثیق

Kubernetes میں دو قسم کے صارفین ہیں:

• سروس اکاؤنٹس - Kubernetes API کے زیر انتظام اکاؤنٹس؛
• صارفین - "عام" استعمال کنندگان جو بیرونی، آزاد خدمات کے زیر انتظام ہیں۔

ان اقسام کے درمیان بنیادی فرق یہ ہے کہ سروس اکاؤنٹس کے لیے Kubernetes API میں خاص اشیاء ہیں (انہیں کہا جاتا ہے کہ - ServiceAccounts)، جو نام کی جگہ سے منسلک ہیں اور سیکرٹس کی قسم کی اشیاء میں کلسٹر میں محفوظ کردہ اجازت کے ڈیٹا کے ایک سیٹ سے منسلک ہیں۔ ایسے صارفین (سروس اکاؤنٹس) کا مقصد بنیادی طور پر Kubernetes کلسٹر میں چلنے والے عمل کے Kubernetes API تک رسائی کے حقوق کا انتظام کرنا ہے۔

عام صارفین کے پاس Kubernetes API میں اندراجات نہیں ہیں: ان کا انتظام بیرونی میکانزم سے ہونا چاہیے۔ ان کا مقصد کلسٹر سے باہر رہنے والے لوگوں یا عملوں کے لیے ہے۔

ہر API کی درخواست یا تو سروس اکاؤنٹ، صارف کے ساتھ منسلک ہوتی ہے یا اسے گمنام سمجھا جاتا ہے۔

صارف کی توثیق کے ڈیٹا میں شامل ہیں:

• صارف کا نام - صارف نام (کیس حساس!)
• UID - ایک مشین کے ذریعے پڑھنے کے قابل صارف کی شناخت کا تار جو "صارف نام سے زیادہ مستقل اور منفرد" ہے۔
• گروپس - ان گروپوں کی فہرست جن سے صارف تعلق رکھتا ہے۔
• اضافی - اضافی فیلڈز جو اجازت کے طریقہ کار کے ذریعہ استعمال کیے جاسکتے ہیں۔

Kubernetes بڑی تعداد میں تصدیق کے طریقہ کار کا استعمال کر سکتے ہیں: X509 سرٹیفکیٹس، بیئرر ٹوکنز، تصدیق کرنے والی پراکسی، HTTP بنیادی توثیق۔ ان میکانزم کا استعمال کرتے ہوئے، آپ بڑی تعداد میں اجازت دینے کی اسکیموں کو نافذ کر سکتے ہیں: پاس ورڈز کے ساتھ ایک مستحکم فائل سے OpenID OAuth2 تک۔

مزید برآں، ایک ساتھ کئی اجازت کی اسکیموں کو استعمال کرنا ممکن ہے۔ پہلے سے طے شدہ طور پر، کلسٹر استعمال کرتا ہے:

• سروس اکاؤنٹ ٹوکنز - سروس اکاؤنٹس کے لیے؛
• X509 - صارفین کے لیے۔

سروس اکاؤنٹس کے انتظام کے بارے میں سوال اس مضمون کے دائرہ کار سے باہر ہے، لیکن ان لوگوں کے لیے جو اس مسئلے سے خود کو مزید تفصیل سے واقف کرانا چاہتے ہیں، میں تجویز کرتا ہوں کہ سرکاری دستاویزات کے صفحات. ہم X509 سرٹیفکیٹس کے کام کرنے کے طریقے کے مسئلے پر گہری نظر ڈالیں گے۔

صارفین کے لیے سرٹیفکیٹ (X.509)

سرٹیفکیٹ کے ساتھ کام کرنے کے کلاسک طریقہ میں شامل ہیں:

• کلیدی نسل:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• سرٹیفکیٹ کی درخواست تیار کرنا:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• Kubernetes کلسٹر CA کلیدوں کا استعمال کرتے ہوئے ایک سرٹیفکیٹ کی درخواست پر کارروائی کرنا، صارف کا سرٹیفکیٹ حاصل کرنا (سرٹیفکیٹ حاصل کرنے کے لیے، آپ کو ایک ایسا اکاؤنٹ استعمال کرنا چاہیے جس کی رسائی Kubernetes کلسٹر CA کلید تک ہو، جو پہلے سے طے شدہ طور پر /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500

• کنفیگریشن فائل بنانا:
  • کلسٹر کی تفصیل (کسی مخصوص کلسٹر کی تنصیب کے لیے CA سرٹیفکیٹ فائل کا پتہ اور مقام کی وضاحت کریں):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • یا کیسے؟ کوئیتجویز کردہ آپشن - آپ کو روٹ سرٹیفکیٹ کی وضاحت کرنے کی ضرورت نہیں ہے (پھر kubectl کلسٹر کے api-server کی درستگی کی جانچ نہیں کرے گا):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • کنفیگریشن فائل میں صارف کو شامل کرنا:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • سیاق و سباق شامل کرنا:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • پہلے سے طے شدہ سیاق و سباق تفویض:

    kubectl config use-context mynewuser-context

مندرجہ بالا ہیرا پھیری کے بعد، فائل میں .kube/config اس طرح کی ایک تشکیل بنائی جائے گی:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

اکاؤنٹس اور سرورز کے درمیان کنفیگریشن کی منتقلی کو آسان بنانے کے لیے، درج ذیل کلیدوں کی قدروں میں ترمیم کرنا مفید ہے۔

• certificate-authority
• client-certificate
• client-key

ایسا کرنے کے لیے، آپ بیس 64 کا استعمال کرتے ہوئے ان میں مخصوص فائلوں کو انکوڈ کر سکتے ہیں اور کنفیگریشن میں ان کو رجسٹر کر سکتے ہیں، چابیاں کے نام میں لاحقہ شامل کر سکتے ہیں۔ -data، یعنی موصول ہونے کے بعد certificate-authority-data وغیرہ

kubeadm کے ساتھ سرٹیفکیٹ

رہائی کے ساتھ کبرنیٹس 1.15 میں اس کی حمایت کے الفا ورژن کی بدولت سرٹیفکیٹس کے ساتھ کام کرنا بہت آسان ہو گیا ہے۔ kubeadm افادیت. مثال کے طور پر، صارف کی چابیاں کے ساتھ کنفیگریشن فائل بنانا اب ایسا نظر آتا ہے:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: درکار ہے۔ ایڈریس کی تشہیر کریں api-server config میں پایا جا سکتا ہے، جس میں بطور ڈیفالٹ واقع ہوتا ہے۔ /etc/kubernetes/manifests/kube-apiserver.yaml.

نتیجے میں ترتیب stdout میں آؤٹ پٹ ہوگی۔ اس میں محفوظ کرنے کی ضرورت ہے۔ ~/.kube/config صارف اکاؤنٹ یا ماحولیاتی متغیر میں مخصوص فائل میں KUBECONFIG.

گہرا کھودو

ان لوگوں کے لیے جو بیان کردہ مسائل کو مزید اچھی طرح سمجھنا چاہتے ہیں:

• علیحدہ مضمون سرکاری Kubernetes دستاویزات میں سرٹیفکیٹ کے ساتھ کام کرنے پر؛
• Bitnami سے اچھا مضمون، جس میں سرٹیفکیٹ کے اجراء کو عملی نقطہ نظر سے چھو لیا گیا ہے۔
• عام دستاویزات Kubernetes میں تصدیق پر۔

اجازت

پہلے سے طے شدہ مجاز اکاؤنٹ کے پاس کلسٹر پر کام کرنے کے حقوق نہیں ہیں۔ اجازتیں دینے کے لیے، Kubernetes اجازت دینے کا طریقہ کار نافذ کرتا ہے۔

ورژن 1.6 سے پہلے، Kubernetes نامی ایک اجازت کی قسم استعمال کرتا تھا۔ اے بی اے سی۔ (انتساب پر مبنی رسائی کنٹرول)۔ اس کی تفصیلات اس میں دیکھی جا سکتی ہیں۔ سرکاری دستاویزات. اس نقطہ نظر کو فی الحال میراث سمجھا جاتا ہے، لیکن آپ اب بھی اسے دیگر تصدیقی اقسام کے ساتھ استعمال کر سکتے ہیں۔

کلسٹر تک رسائی کے حقوق کو تقسیم کرنے کا موجودہ (اور زیادہ لچکدار) طریقہ کہلاتا ہے۔ آر بی اے سی۔ (کردار پر مبنی رسائی کنٹرول۔)۔ اسے ورژن کے بعد سے مستحکم قرار دیا گیا ہے۔ کبرنیٹس 1.8. RBAC حقوق کا ایک ماڈل نافذ کرتا ہے جس میں ہر وہ چیز جس کی واضح طور پر اجازت نہیں ہے ممنوع ہے۔
RBAC کو فعال کرنے کے لیے، آپ کو پیرامیٹر کے ساتھ Kubernetes api-server شروع کرنے کی ضرورت ہے۔ --authorization-mode=RBAC. پیرامیٹرز مینی فیسٹ میں api-server کنفیگریشن کے ساتھ سیٹ کیے گئے ہیں، جو پہلے سے طے شدہ راستے کے ساتھ واقع ہوتی ہے۔ /etc/kubernetes/manifests/kube-apiserver.yaml، سیکشن میں command. تاہم، RBAC پہلے سے ہی ڈیفالٹ کے طور پر فعال ہے، لہذا زیادہ تر امکان ہے کہ آپ کو اس کے بارے میں فکر نہیں کرنی چاہئے: آپ اس کی تصدیق قدر سے کر سکتے ہیں authorization-mode (پہلے ہی ذکر میں kube-apiserver.yaml)۔ ویسے، اس کے معانی میں اجازت کی دوسری قسمیں بھی ہوسکتی ہیں (node, webhook, always allow)، لیکن ہم ان کے غور کو مواد کے دائرہ کار سے باہر چھوڑ دیں گے۔

ویسے ہم پہلے ہی شائع کر چکے ہیں۔ مضمون RBAC کے ساتھ کام کرنے کے اصولوں اور خصوصیات کی کافی تفصیلی وضاحت کے ساتھ، لہذا مزید میں خود کو بنیادی باتوں اور مثالوں کی مختصر فہرست تک محدود رکھوں گا۔

درج ذیل API اداروں کو RBAC کے ذریعے Kubernetes میں رسائی کو کنٹرول کرنے کے لیے استعمال کیا جاتا ہے:

• Role и ClusterRole - وہ کردار جو رسائی کے حقوق کو بیان کرتے ہیں:
• Role آپ کو نام کی جگہ کے اندر حقوق بیان کرنے کی اجازت دیتا ہے۔
• ClusterRole - کلسٹر کے اندر، بشمول کلسٹر کے لیے مخصوص اشیاء جیسے نوڈس، غیر وسائل والے یو آر ایل (یعنی Kubernetes وسائل سے متعلق نہیں - مثال کے طور پر، /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - پابند کرنے کے لئے استعمال کیا جاتا ہے Role и ClusterRole صارف، صارف گروپ یا سروس اکاؤنٹ کو۔

رول اور رول بائنڈنگ ادارے نام کی جگہ کے ذریعہ محدود ہیں، یعنی اسی نام کی جگہ کے اندر ہونا چاہیے۔ تاہم، رول بائنڈنگ ایک کلسٹر رول کا حوالہ دے سکتی ہے، جو آپ کو عام اجازتوں کا ایک سیٹ بنانے اور ان کا استعمال کرتے ہوئے رسائی کو کنٹرول کرنے کی اجازت دیتا ہے۔

رولز پر مشتمل قوانین کے سیٹ کا استعمال کرتے ہوئے حقوق کی وضاحت کرتے ہیں:

• API گروپس - دیکھیں سرکاری دستاویزات apiGroups اور آؤٹ پٹ کے ذریعہ kubectl api-resources;
• حوالہ جات (وسائل: pod, namespace, deployment اور اسی طرح.)؛
• فعل (فعل: set, update اور اسی طرح.).
• وسائل کے نام (resourceNames) - اس صورت میں جب آپ کو کسی مخصوص وسائل تک رسائی فراہم کرنے کی ضرورت ہو، نہ کہ اس قسم کے تمام وسائل تک۔

Kubernetes میں اجازت کا مزید تفصیلی تجزیہ صفحہ پر پایا جا سکتا ہے۔ سرکاری دستاویزات. اس کے بجائے (یا اس کے علاوہ) میں مثالیں دوں گا جو اس کے کام کو واضح کرتی ہیں۔

RBAC اداروں کی مثالیں۔

سادہ Role، جو آپ کو پوڈز کی فہرست اور حیثیت حاصل کرنے اور نام کی جگہ پر ان کی نگرانی کرنے کی اجازت دیتا ہے۔ target-namespace:

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

مثال کے طور پر ClusterRole، جو آپ کو پوڈز کی فہرست اور حیثیت حاصل کرنے اور پورے کلسٹر میں ان کی نگرانی کرنے کی اجازت دیتا ہے:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

مثال کے طور پر RoleBinding، جو صارف کو اجازت دیتا ہے۔ mynewuser نام کی جگہ میں پوڈز کو "پڑھیں" my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

واقعہ کا آڈٹ

سکیماتی طور پر، Kubernetes فن تعمیر کو مندرجہ ذیل طور پر پیش کیا جا سکتا ہے:

درخواستوں پر کارروائی کے لیے ذمہ دار کلیدی Kubernetes جزو ہے۔ اے پی آئی سرور. کلسٹر کے تمام آپریشنز اس کے ذریعے ہوتے ہیں۔ آپ مضمون میں ان داخلی میکانزم کے بارے میں مزید پڑھ سکتے ہیں۔جب آپ kubectl رن چلاتے ہیں تو Kubernetes میں کیا ہوتا ہے؟'.

سسٹم آڈیٹنگ Kubernetes میں ایک دلچسپ خصوصیت ہے، جو بطور ڈیفالٹ غیر فعال ہے۔ یہ آپ کو تمام کالز کوبرنیٹس API پر لاگ ان کرنے کی اجازت دیتا ہے۔ جیسا کہ آپ اندازہ لگا سکتے ہیں، کلسٹر کی حالت کی نگرانی اور تبدیلی سے متعلق تمام کارروائیاں اس API کے ذریعے انجام دی جاتی ہیں۔ اس کی صلاحیتوں کی اچھی تفصیل (ہمیشہ کی طرح) میں مل سکتی ہے۔ سرکاری دستاویزات K8s آگے میں موضوع کو آسان زبان میں پیش کرنے کی کوشش کروں گا۔

اس طرح، آڈیٹنگ کو فعال کرنے کے لیے، ہمیں api-server میں کنٹینر میں تین مطلوبہ پیرامیٹرز کو منتقل کرنے کی ضرورت ہے، جو ذیل میں مزید تفصیل سے بیان کیے گئے ہیں:

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

ان تین ضروری پیرامیٹرز کے علاوہ، آڈیٹنگ سے متعلق بہت سی اضافی ترتیبات ہیں: لاگ روٹیشن سے لے کر ویب ہک کی تفصیل تک۔ لاگ گردش کے پیرامیٹرز کی مثال:

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

لیکن ہم ان پر مزید تفصیل سے غور نہیں کریں گے - آپ کو تمام تفصیلات اس میں مل سکتی ہیں۔ kube-apiserver دستاویزات.

جیسا کہ پہلے ہی ذکر کیا گیا ہے، تمام پیرامیٹرز مینی فیسٹ میں api-server کنفیگریشن کے ساتھ سیٹ کیے گئے ہیں (بطور ڈیفالٹ /etc/kubernetes/manifests/kube-apiserver.yaml)، سیکشن میں command. آئیے 3 مطلوبہ پیرامیٹرز پر واپس آتے ہیں اور ان کا تجزیہ کرتے ہیں:

1. audit-policy-file - آڈٹ پالیسی کو بیان کرنے والی YAML فائل کا راستہ۔ ہم بعد میں اس کے مشمولات پر واپس جائیں گے، لیکن فی الحال میں نوٹ کروں گا کہ فائل کو api-server کے عمل سے پڑھنے کے قابل ہونا چاہیے۔ لہذا، اسے کنٹینر کے اندر نصب کرنا ضروری ہے، جس کے لیے آپ مندرجہ ذیل کوڈ کو ترتیب کے مناسب حصوں میں شامل کر سکتے ہیں:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - لاگ فائل کا راستہ۔ api-server کے عمل کے لیے راستہ بھی قابل رسائی ہونا چاہیے، اس لیے ہم اس کے بڑھنے کو اسی طرح بیان کرتے ہیں:

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format - آڈٹ لاگ فارمیٹ۔ پہلے سے طے شدہ ہے۔ json، لیکن میراثی متن کی شکل بھی دستیاب ہے (legacy).

آڈٹ پالیسی

اب ذکر شدہ فائل کے بارے میں جو لاگنگ پالیسی کو بیان کرتی ہے۔ آڈٹ پالیسی کا پہلا تصور ہے۔ level, لاگنگ کی سطح. وہ درج ذیل ہیں:

• None - لاگ ان نہ کریں؛
• Metadata - لاگ درخواست کا میٹا ڈیٹا: صارف، درخواست کا وقت، ہدف کا وسیلہ (پوڈ، نام کی جگہ، وغیرہ)، عمل کی قسم (فعل)، وغیرہ؛
• Request - لاگ میٹا ڈیٹا اور درخواست کی باڈی؛
• RequestResponse - لاگ میٹا ڈیٹا، درخواست باڈی اور رسپانس باڈی۔

آخری دو درجے (Request и RequestResponse) ان درخواستوں کو لاگ ان نہ کریں جنہوں نے وسائل تک رسائی حاصل نہیں کی (نام نہاد غیر وسائل والے یو آر ایل تک رسائی)۔

اس کے علاوہ تمام درخواستیں گزر جاتی ہیں۔ کئی مراحل:

• RequestReceived - وہ مرحلہ جب پروسیسر کے ذریعہ درخواست موصول ہوتی ہے اور ابھی تک پروسیسرز کی زنجیر کے ساتھ مزید منتقل نہیں کی گئی ہے۔
• ResponseStarted — رسپانس ہیڈر بھیجے جاتے ہیں، لیکن اس سے پہلے کہ رسپانس باڈی بھیجی جائے۔ طویل عرصے سے چلنے والے سوالات کے لیے تیار کیا گیا (مثال کے طور پر، watch);
• ResponseComplete - جوابی ادارہ بھیج دیا گیا ہے، مزید معلومات نہیں بھیجی جائیں گی۔
• Panic - واقعات اس وقت پیدا ہوتے ہیں جب کسی غیر معمولی صورتحال کا پتہ چل جاتا ہے۔

کسی بھی قدم کو چھوڑنے کے لیے جو آپ استعمال کر سکتے ہیں۔ omitStages.

پالیسی فائل میں، ہم مختلف لاگنگ لیولز کے ساتھ کئی حصوں کی وضاحت کر سکتے ہیں۔ پالیسی کی تفصیل میں ملنے والا پہلا مماثل اصول لاگو کیا جائے گا۔

کیوبلیٹ ڈیمون مینی فیسٹ میں ہونے والی تبدیلیوں کو اے پی آئی سرور کنفیگریشن کے ساتھ مانیٹر کرتا ہے اور، اگر کسی کا پتہ چل جاتا ہے، تو کنٹینر کو اے پی آئی سرور کے ساتھ دوبارہ شروع کرتا ہے۔ لیکن ایک اہم تفصیل ہے: پالیسی فائل میں تبدیلیوں کو نظر انداز کر دیا جائے گا۔. پالیسی فائل میں تبدیلیاں کرنے کے بعد، آپ کو api-server کو دستی طور پر دوبارہ شروع کرنے کی ضرورت ہوگی۔ چونکہ api-server شروع کیا گیا ہے۔ جامد پھلی، ٹیم kubectl delete اسے دوبارہ شروع کرنے کا سبب نہیں بنے گا۔ آپ کو اسے دستی طور پر کرنا پڑے گا۔ docker stop kube-masters پر، جہاں آڈٹ پالیسی تبدیل کر دی گئی ہے:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

آڈیٹنگ کو فعال کرتے وقت، یہ یاد رکھنا ضروری ہے۔ kube-apiserver پر بوجھ بڑھتا ہے۔. خاص طور پر، درخواست کے سیاق و سباق کو ذخیرہ کرنے کے لیے میموری کی کھپت بڑھ جاتی ہے۔ جوابی ہیڈر بھیجے جانے کے بعد ہی لاگنگ شروع ہوتی ہے۔ بوجھ بھی آڈٹ پالیسی کی ترتیب پر منحصر ہے۔

پالیسیوں کی مثالیں۔

آئیے مثالوں کا استعمال کرتے ہوئے پالیسی فائلوں کی ساخت کو دیکھتے ہیں۔

یہاں ایک سادہ فائل ہے۔ policyسطح پر ہر چیز کو لاگ ان کرنے کے لئے Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

پالیسی میں آپ صارفین کی فہرست بتا سکتے ہیں (Users и ServiceAccounts) اور صارف گروپس۔ مثال کے طور پر، اس طرح ہم سسٹم کے صارفین کو نظر انداز کر دیں گے، لیکن باقی تمام چیزوں کو سطح پر لاگ ان کریں گے۔ Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

اہداف کو بیان کرنا بھی ممکن ہے:

• نام کی جگہیں (namespaces);
• فعل (فعل: get, update, delete اور دوسرے)؛
• حوالہ جات (وسائل، یعنی: pod, configmaps وغیرہ) اور وسائل کے گروپ (apiGroups).

توجہ دینا! وسائل اور وسائل کے گروپس (API گروپس، یعنی apiGroups) کے ساتھ ساتھ کلسٹر میں نصب ان کے ورژن، کمانڈز کا استعمال کرتے ہوئے حاصل کیے جا سکتے ہیں:

kubectl api-resources
kubectl api-versions

مندرجہ ذیل آڈٹ پالیسی بہترین طریقوں کے مظاہرے کے طور پر فراہم کی گئی ہے۔ علی بابا کلاؤڈ دستاویزات:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для стандартных ресурсов API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

آڈٹ پالیسی کی ایک اور اچھی مثال ہے۔ GCE میں استعمال شدہ پروفائل.

آڈٹ کے واقعات کا فوری جواب دینے کے لیے، یہ ممکن ہے۔ ویب ہک کی وضاحت کریں۔. اس مسئلے کا احاطہ کیا گیا ہے۔ سرکاری دستاویزات، میں اسے اس مضمون کے دائرہ کار سے باہر چھوڑ دوں گا۔

کے نتائج

مضمون Kubernetes کلسٹرز میں بنیادی حفاظتی میکانزم کا ایک جائزہ فراہم کرتا ہے، جو آپ کو ذاتی صارف اکاؤنٹس بنانے، ان کے حقوق کو الگ کرنے اور ان کے اعمال کو ریکارڈ کرنے کی اجازت دیتا ہے۔ مجھے امید ہے کہ یہ ان لوگوں کے لیے کارآمد ثابت ہوگا جنہیں نظریہ یا عملی طور پر ایسے مسائل کا سامنا ہے۔ میں یہ بھی تجویز کرتا ہوں کہ آپ Kubernetes میں سیکورٹی کے موضوع پر دیگر مواد کی فہرست پڑھیں، جو "PS" میں دی گئی ہے - شاید ان میں سے آپ کو ان مسائل کے بارے میں ضروری تفصیلات مل جائیں گی جو آپ سے متعلقہ ہیں۔

PS

ہمارے بلاگ پر بھی پڑھیں:

• «33+ Kubernetes سیکیورٹی ٹولز؛ "
• «سیکورٹی پروفیشنلز کے لیے Kubernetes نیٹ ورک کی پالیسیوں کا ایک تعارف؛ "
• «Kubernetes میں RBAC کو سمجھنا؛ "
• «Kubernetes سیکیورٹی کے لیے 9 بہترین طریقے؛ "
• «کبرنیٹس ہیک کا شکار بننے کے (نہیں) 11 طریقے'.

ماخذ: www.habr.com