ڪبرنيٽس ۾ سيڪيورٽي جو ABC: تصديق، اختيار، آڊيٽنگ

جلدي يا بعد ۾، ڪنهن به سسٽم جي آپريشن ۾، سيڪيورٽي جو مسئلو پيدا ٿئي ٿو: تصديق ڪرڻ، حقن جي الڳ ٿيڻ، آڊيٽنگ ۽ ٻين ڪمن کي يقيني بڻائڻ. اڳ ۾ ئي Kubernetes لاء ٺهيل آهي ڪيترائي حل, جيڪي توهان کي معيار جي تعميل حاصل ڪرڻ جي اجازت ڏين ٿيون جيتوڻيڪ تمام گهڻي گهرج واري ماحول ۾ ... ساڳيو مواد K8s جي تعمير ٿيل ميڪانيزم ۾ لاڳو ڪيل سيڪيورٽي جي بنيادي حصن لاء وقف آهي. سڀ کان پهريان، اهو انهن لاءِ ڪارآمد هوندو جيڪي ڪبرنيٽس سان واقف ٿيڻ شروع ڪري رهيا آهن - سيڪيورٽي سان لاڳاپيل مسئلن جي مطالعي لاءِ شروعاتي نقطي جي طور تي.

تصديق

ڪبرنيٽس ۾ صارفين جا ٻه قسم آهن:

• سروس اڪائونٽس - ڪبرنيٽس API پاران منظم ڪيل اڪائونٽس؛
• رڪنن - "عام" استعمال ڪندڙ خارجي، آزاد خدمتن پاران منظم.

انهن قسمن جي وچ ۾ بنيادي فرق اهو آهي ته سروس اڪائونٽس لاءِ Kubernetes API ۾ خاص شيون آهن (انهن کي سڏيو ويندو آهي - ServiceAccounts)، جيڪي نالا اسپيس سان ڳنڍيل آهن ۽ رازداري قسم جي شين ۾ ڪلستر ۾ محفوظ ڪيل اختيار واري ڊيٽا جو هڪ سيٽ. اهڙا استعمال ڪندڙ (سروس اڪائونٽس) بنيادي طور تي Kubernetes ڪلستر ۾ هلندڙ عملن جي Kubernetes API تائين رسائي جي حقن کي منظم ڪرڻ لاءِ آهن.

عام استعمال ڪندڙن کي ڪبرنيٽس 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 چاٻين کي استعمال ڪندي سرٽيفڪيٽ جي درخواست تي عمل ڪندي، صارف سرٽيفڪيٽ حاصل ڪرڻ (هڪ سرٽيفڪيٽ حاصل ڪرڻ لاء، توهان کي هڪ اڪائونٽ استعمال ڪرڻ گهرجي جنهن کي ڪبرنيٽس ڪلستر 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

  • يا ڪيئن نهتجويز ڪيل اختيار - توھان کي روٽ سرٽيفڪيٽ بيان ڪرڻ جي ضرورت نه آھي (پوءِ ڪبيڪٽل ڪلستر جي api-سرور جي صحيحيت جي جانچ نه ڪندو):

    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

مٿين manipulations کان پوء، فائل ۾ .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، i.e. حاصل ڪرڻ 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 کان اڳ، ڪبرنيٽس استعمال ڪيو هڪ اختيار جو قسم سڏيو ويندو آهي ABAC (صفت جي بنياد تي رسائي ڪنٽرول). ان بابت تفصيل هن ۾ ملي سگهي ٿو سرڪاري دستاويز. اهو طريقو هن وقت ميراث سمجهيو ويندو آهي، پر توهان اڃا تائين ان کي استعمال ڪري سگهو ٿا ٻين تصديق جي قسمن سان گڏ.

ڪلستر تائين رسائي جي حقن کي ورهائڻ جو موجوده (۽ وڌيڪ لچڪدار) طريقو سڏيو ويندو آهي آر بي سي (ڪردار جي بنياد تي رسائي ڪنٽرول). اهو نسخو کان مستحڪم قرار ڏنو ويو آهي ڪبرنيٽز 1.8. RBAC هڪ حقن جي ماڊل کي لاڳو ڪري ٿو جنهن ۾ هر شيء جيڪا واضح طور تي اجازت نه آهي منع ٿيل آهي.
RBAC کي فعال ڪرڻ لاء، توهان کي شروع ڪرڻ جي ضرورت آهي Kubernetes api-server parameter سان --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 ذريعي:

• Role и ClusterRole - ڪردار جيڪي رسائي جي حقن کي بيان ڪن ٿا:
• Role توھان کي اجازت ڏئي ٿو بيان ڪرڻ جي حق جي نالي جي اندر اندر؛
• ClusterRole - ڪلستر جي اندر، بشمول ڪلستر-مخصوص شين جهڙوڪ نوڊس، غير وسيلا urls (يعني ڪبرنيٽس وسيلن سان لاڳاپيل ناهي - مثال طور، /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 "پڙھيو" پوڊس namespace ۾ 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

واقعي جي چڪاس

Schematically، Kubernetes فن تعمير هيٺ ڏنل نمائندگي ڪري سگهجي ٿو:

درخواستن جي پروسيسنگ لاءِ ذميوار Kubernetes جزو آهي api-سرور. ڪلستر تي سڀ عمل ان جي ذريعي وڃو. توھان وڌيڪ پڙھي سگھوٿا ھنن اندروني ميڪانيزم بابت آرٽيڪل ۾ڪبرنيٽس ۾ ڇا ٿيندو جڏهن توهان ڪبيڪٽل رن هلائيندا آهيو؟».

سسٽم آڊيٽنگ 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 - لاگ فائل ڏانهن رستو. رستو لازمي طور تي اي پي-سرور جي عمل تائين رسائي لائق هجڻ گهرجي، تنهنڪري اسان ان جي چڙهڻ کي ساڳئي طريقي سان بيان ڪريون ٿا:

     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) درخواستن کي لاگ ان نه ڪريو جيڪي وسيلن تائين رسائي نٿا ڪن (نام نهاد غير وسيلن جي urls تائين رسائي).

پڻ سڀني درخواستن جي ذريعي وڃو ڪيترائي مرحلا:

• RequestReceived - اسٽيج جڏهن درخواست پروسيسر طرفان ملي ٿي ۽ اڃا تائين پروسيسرز جي زنجير سان وڌيڪ منتقل نه ڪيو ويو آهي؛
• ResponseStarted - جوابي هيڊر موڪليا ويا آهن، پر ان کان اڳ جو جوابي جسم موڪليو ويو آهي. ڊگھي ھلندڙ سوالن لاءِ ٺاھيو ويو (مثال طور، watch);
• ResponseComplete - جوابي جسم موڪليو ويو آهي، وڌيڪ معلومات نه موڪلي ويندي؛
• Panic - واقعا پيدا ٿين ٿا جڏهن هڪ غير معمولي صورتحال معلوم ٿئي ٿي.

ڪنهن به قدم کي ڇڏڻ لاءِ توهان استعمال ڪري سگهو ٿا omitStages.

پاليسي فائل ۾، اسان مختلف لاگنگ سطحن سان ڪيترن ئي حصن کي بيان ڪري سگھون ٿا. پاليسي جي وضاحت ۾ مليل پهريون ملندڙ قاعدو لاڳو ڪيو ويندو.

ڪوبيليٽ ڊيمون مينيفيسٽ ۾ تبديلين کي مانيٽر ڪري ٿو api-server configuration سان ۽، جيڪڏهن ڪو به معلوم ٿئي ٿو، ڪنٽينر کي api-server سان ٻيهر شروع ڪري ٿو. پر اتي هڪ اهم تفصيل آهي: پاليسي فائل ۾ تبديليون ان کي نظر انداز ڪيو ويندو. پاليسي فائل ۾ تبديليون ڪرڻ کان پوء، توهان کي دستي طور تي 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

ھيٺ ڏنل آڊٽ پاليسي ۾ بهترين عملن جي مظاھري طور مهيا ڪئي وئي آھي علي بابا Cloud دستاويز:

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 ۾ استعمال ٿيل پروفائل.

آڊٽ جي واقعن کي جلدي جواب ڏيڻ لاء، ممڪن آهي وضاحت ڪريو webhook. هن مسئلي ۾ شامل آهي سرڪاري دستاويز، مان ان کي ڇڏي ڏيندس هن مضمون جي دائري کان ٻاهر.

نتيجو

آرٽيڪل Kubernetes ڪلسٽرز ۾ بنيادي حفاظتي ميڪانيزم جو هڪ جائزو پيش ڪري ٿو، جيڪي توهان کي ذاتي صارف اڪائونٽ ٺاهڻ، انهن جي حقن کي الڳ ڪرڻ، ۽ انهن جي عملن کي رڪارڊ ڪرڻ جي اجازت ڏين ٿا. مون کي اميد آهي ته اهو انهن لاء مفيد ٿيندو جيڪي نظرياتي يا عملي طور تي اهڙن مسئلن سان منهن ڏيڻ وارا آهن. مان پڻ سفارش ڪريان ٿو ته توهان ڪبرنيٽس ۾ سيڪيورٽي جي موضوع تي ٻين مواد جي فهرست پڙهي، جيڪا "PS" ۾ ڏنل آهي - شايد انهن مان توهان کي انهن مسئلن تي ضروري تفصيل ملندا جيڪي توهان سان لاڳاپيل آهن.

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

• «33+ Kubernetes حفاظتي اوزار"؛
• «سيڪيورٽي پروفيشنلز لاءِ ڪبرنيٽس نيٽورڪ پاليسين جو هڪ تعارف"؛
• «Kubernetes ۾ RBAC کي سمجھڻ"؛
• «ڪبرنيٽس سيڪيورٽي لاءِ 9 بهترين طريقا"؛
• «11 طريقا (نه) هڪ ڪبرنيٽس هيڪ جو شڪار ٿيڻ».

جو ذريعو: www.habr.com