ABC នៃសន្តិសុខនៅក្នុង Kubernetes: ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ ការអនុញ្ញាត សវនកម្ម

មិនយូរមិនឆាប់ ក្នុងប្រតិបត្តិការនៃប្រព័ន្ធណាមួយ បញ្ហាសុវត្ថិភាពកើតឡើង៖ ការធានាការផ្ទៀងផ្ទាត់ ការបំបែកសិទ្ធិ ការធ្វើសវនកម្ម និងកិច្ចការផ្សេងៗទៀត។ បានបង្កើតរួចហើយសម្រាប់ Kubernetes ដំណោះស្រាយជាច្រើន។ដែលអនុញ្ញាតឱ្យអ្នកសម្រេចបាននូវការអនុលោមតាមស្តង់ដារ សូម្បីតែនៅក្នុងបរិយាកាសដែលមានតម្រូវការខ្លាំង... សម្ភារៈដូចគ្នានេះត្រូវបានឧទ្ទិសដល់ទិដ្ឋភាពជាមូលដ្ឋាននៃសុវត្ថិភាពដែលបានអនុវត្តនៅក្នុងយន្តការដែលភ្ជាប់មកជាមួយនៃ K8s ។ ជាដំបូង វានឹងមានប្រយោជន៍សម្រាប់អ្នកដែលកំពុងចាប់ផ្តើមស្គាល់ Kubernetes - ជាចំណុចចាប់ផ្តើមសម្រាប់ការសិក្សាអំពីបញ្ហាទាក់ទងនឹងសុវត្ថិភាព។

ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ

មានអ្នកប្រើប្រាស់ពីរប្រភេទនៅក្នុង Kubernetes៖

• គណនីសេវាកម្ម - គណនីដែលគ្រប់គ្រងដោយ Kubernetes API;
• អ្នកប្រើ - អ្នកប្រើប្រាស់ "ធម្មតា" គ្រប់គ្រងដោយសេវាកម្មឯករាជ្យខាងក្រៅ។

ភាពខុសគ្នាសំខាន់រវាងប្រភេទទាំងនេះគឺថា សម្រាប់គណនីសេវាកម្មមានវត្ថុពិសេសនៅក្នុង Kubernetes API (ពួកវាត្រូវបានគេហៅថា - ServiceAccounts) ដែលត្រូវបានចងភ្ជាប់ទៅនឹង namespace និងសំណុំនៃទិន្នន័យអនុញ្ញាតដែលរក្សាទុកនៅក្នុង cluster នៅក្នុង objects នៃប្រភេទ Secrets។ អ្នកប្រើប្រាស់បែបនេះ (គណនីសេវាកម្ម) មានគោលបំណងជាចម្បងដើម្បីគ្រប់គ្រងសិទ្ធិចូលដំណើរការទៅកាន់ Kubernetes API នៃដំណើរការដែលកំពុងដំណើរការនៅក្នុងចង្កោម Kubernetes ។

អ្នកប្រើប្រាស់ធម្មតាមិនមានធាតុនៅក្នុង Kubernetes API ទេ៖ ពួកគេត្រូវតែត្រូវបានគ្រប់គ្រងដោយយន្តការខាងក្រៅ។ ពួកវាត្រូវបានបម្រុងទុកសម្រាប់មនុស្ស ឬដំណើរការដែលរស់នៅក្រៅចង្កោម។

សំណើ API នីមួយៗត្រូវបានភ្ជាប់ជាមួយគណនីសេវាកម្ម អ្នកប្រើប្រាស់ ឬត្រូវបានចាត់ទុកថាជាអនាមិក។

ទិន្នន័យផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់រួមមាន:

• ឈ្មោះ​អ្នកប្រើប្រាស់ - ឈ្មោះអ្នកប្រើ (ប្រកាន់អក្សរតូចធំ!);
• យូឌី - ខ្សែអក្សរកំណត់អត្តសញ្ញាណអ្នកប្រើប្រាស់ដែលអាចអានដោយម៉ាស៊ីនដែល "ស៊ីសង្វាក់គ្នា និងប្លែកជាងឈ្មោះអ្នកប្រើប្រាស់" ។
• ក្រុម - បញ្ជីក្រុមដែលអ្នកប្រើប្រាស់ជាកម្មសិទ្ធិ;
• បន្ថែម - វាលបន្ថែមដែលអាចត្រូវបានប្រើដោយយន្តការអនុញ្ញាត។

Kubernetes អាចប្រើយន្តការផ្ទៀងផ្ទាត់មួយចំនួនធំ៖ វិញ្ញាបនបត្រ X509, Bearer tokens, ការផ្ទៀងផ្ទាត់ប្រូកស៊ី, HTTP Basic Auth។ ដោយប្រើយន្តការទាំងនេះ អ្នកអាចអនុវត្តគម្រោងការអនុញ្ញាតមួយចំនួនធំ៖ ពីឯកសារឋិតិវន្តដែលមានពាក្យសម្ងាត់ទៅ 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 cluster CA ដើម្បីទទួលបានវិញ្ញាបនបត្រអ្នកប្រើប្រាស់ (ដើម្បីទទួលបានវិញ្ញាបនបត្រ អ្នកត្រូវតែប្រើគណនីដែលមានសិទ្ធិចូលប្រើសោ Kubernetes cluster 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

  • ឬរបៀប មិនមានជម្រើសដែលបានណែនាំ - អ្នកមិនចាំបាច់បញ្ជាក់វិញ្ញាបនបត្រ root (បន្ទាប់មក 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

ដើម្បីធ្វើដូចនេះអ្នកអាចអ៊ិនកូដឯកសារដែលបានបញ្ជាក់នៅក្នុងពួកវាដោយប្រើ base64 ហើយចុះឈ្មោះពួកវាក្នុងការកំណត់ដោយបន្ថែមបច្ច័យទៅឈ្មោះសោ។ -data, i.e. ដែលបានទទួល certificate-authority-data និងដូច។

វិញ្ញាបនប័ត្រជាមួយ kubeadm

ជាមួយនឹងការចេញផ្សាយ Kubernetes ១.១៤ ការធ្វើការជាមួយវិញ្ញាបនបត្របានកាន់តែងាយស្រួល ដោយសារកំណែអាល់ហ្វានៃការគាំទ្ររបស់វានៅក្នុង ឧបករណ៍ប្រើប្រាស់ 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 បានប្រើប្រភេទអនុញ្ញាតដែលហៅថា ABAC (ការគ្រប់គ្រងការចូលប្រើដោយផ្អែកលើគុណលក្ខណៈ) ។ ព័ត៌មានលម្អិតអំពីវាអាចរកបាននៅក្នុង ឯកសារផ្លូវការ. វិធីសាស្រ្តនេះបច្ចុប្បន្នត្រូវបានចាត់ទុកថាជាកេរ្តិ៍ដំណែល ប៉ុន្តែអ្នកនៅតែអាចប្រើវាជាមួយនឹងប្រភេទការផ្ទៀងផ្ទាត់ផ្សេងទៀត។

វិធីបច្ចុប្បន្ន (និងអាចបត់បែនបាន) នៃការបែងចែកសិទ្ធិចូលប្រើទៅកាន់ចង្កោមត្រូវបានគេហៅថា RBAC (ការគ្រប់គ្រងការចូលប្រើដោយតួនាទី) វាត្រូវបានប្រកាសថាមានស្ថេរភាពតាំងពីកំណែ Kubernetes ១.១៤. RBAC អនុវត្តគំរូសិទ្ធិដែលអ្វីៗទាំងអស់ដែលមិនត្រូវបានអនុញ្ញាតច្បាស់លាស់ត្រូវបានហាមឃាត់។
ដើម្បីបើក RBACអ្នកត្រូវចាប់ផ្តើម Kubernetes api-server ជាមួយនឹងប៉ារ៉ាម៉ែត្រ --authorization-mode=RBAC. ប៉ារ៉ាម៉ែត្រត្រូវបានកំណត់នៅក្នុង manifest ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធ api-server ដែលតាមលំនាំដើមមានទីតាំងនៅតាមផ្លូវ /etc/kubernetes/manifests/kube-apiserver.yaml, នៅក្នុងផ្នែក command. ទោះយ៉ាងណាក៏ដោយ RBAC ត្រូវបានបើករួចហើយតាមលំនាំដើម ដូច្នេះអ្នកទំនងជាមិនគួរបារម្ភអំពីវាទេ៖ អ្នកអាចផ្ទៀងផ្ទាត់វាដោយតម្លៃ authorization-mode (នៅក្នុងអ្វីដែលបានរៀបរាប់រួចហើយ kube-apiserver.yaml) ដោយវិធីនេះ ក្នុងចំណោមអត្ថន័យរបស់វា អាចមានប្រភេទផ្សេងទៀតនៃការអនុញ្ញាត (node, webhook, always allow) ប៉ុន្តែយើងនឹងទុកការពិចារណារបស់ពួកគេនៅខាងក្រៅវិសាលភាពនៃសម្ភារៈ។

ដោយវិធីនេះយើងបានបោះពុម្ពរួចហើយ អត្ថបទ ជាមួយនឹងការពិពណ៌នាលម្អិតដោយស្មើភាពនៃគោលការណ៍ និងលក្ខណៈពិសេសនៃការធ្វើការជាមួយ RBAC ដូច្នេះបន្ថែមទៀត ខ្ញុំនឹងដាក់កម្រិតខ្លួនខ្ញុំទៅនឹងបញ្ជីសង្ខេបនៃមូលដ្ឋាន និងឧទាហរណ៍។

អង្គភាព API ខាងក្រោមត្រូវបានប្រើដើម្បីគ្រប់គ្រងការចូលប្រើក្នុង Kubernetes តាមរយៈ RBAC៖

• Role и ClusterRole - តួនាទីដែលបម្រើដើម្បីពិពណ៌នាអំពីសិទ្ធិចូលប្រើ៖
• Role អនុញ្ញាតឱ្យអ្នកពិពណ៌នាអំពីសិទ្ធិក្នុងចន្លោះឈ្មោះ;
• ClusterRole - នៅក្នុងចង្កោម រួមទាំងវត្ថុជាក់លាក់នៃចង្កោម ដូចជាថ្នាំង urls ដែលមិនមែនជាធនធាន (ឧ. មិនទាក់ទងនឹងធនធាន Kubernetes - ឧទាហរណ៍ /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - ប្រើសម្រាប់ចង Role и ClusterRole ទៅកាន់អ្នកប្រើប្រាស់ ក្រុមអ្នកប្រើប្រាស់ ឬគណនីសេវាកម្ម។

Role and RoleBinding entities ត្រូវបានកំណត់ដោយ namespace ពោលគឺឧ។ ត្រូវតែស្ថិតនៅក្នុងចន្លោះឈ្មោះដូចគ្នា។ ទោះជាយ៉ាងណាក៏ដោយ RoleBinding អាចយោងទៅលើ 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 "អាន" pods នៅក្នុង 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

សវនកម្មព្រឹត្តិការណ៍

តាមគ្រោងការណ៍ ស្ថាបត្យកម្ម Kubernetes អាចត្រូវបានតំណាងដូចខាងក្រោម:

សមាសធាតុ Kubernetes សំខាន់ដែលទទួលខុសត្រូវចំពោះដំណើរការសំណើគឺ api-server. ប្រតិបត្តិការទាំងអស់នៅលើចង្កោមឆ្លងកាត់វា។ អ្នកអាចអានបន្ថែមអំពីយន្តការផ្ទៃក្នុងទាំងនេះនៅក្នុងអត្ថបទ "តើមានអ្វីកើតឡើងនៅក្នុង Kubernetes នៅពេលអ្នកដំណើរការ kubectl run?"។

ការធ្វើសវនកម្មប្រព័ន្ធគឺជាលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍នៅក្នុង 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

បន្ថែមពីលើប៉ារ៉ាម៉ែត្រចាំបាច់ទាំងបីនេះ មានការកំណត់បន្ថែមជាច្រើនដែលទាក់ទងនឹងការធ្វើសវនកម្ម៖ ពីការបង្វិលកំណត់ហេតុរហូតដល់ការពិពណ៌នាអំពី webhook ។ ឧទាហរណ៍នៃប៉ារ៉ាម៉ែត្របង្វិលកំណត់ហេតុ៖

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

ប៉ុន្តែយើងនឹងមិនរស់នៅលើពួកវានៅក្នុងលម្អិតបន្ថែមទៀតទេ - អ្នកអាចស្វែងរកព័ត៌មានលម្អិតទាំងអស់នៅក្នុង ឯកសារ kube-apiserver.

ដូចដែលបានបញ្ជាក់រួចមកហើយ ប៉ារ៉ាម៉ែត្រទាំងអស់ត្រូវបានកំណត់នៅក្នុង manifest ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធ 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) កុំកត់ត្រាសំណើដែលមិនបានចូលប្រើធនធាន (ការចូលប្រើ urls ដែលមិនមែនជាធនធាន)។

សំណើទាំងអស់ក៏ឆ្លងកាត់ផងដែរ។ ដំណាក់កាលជាច្រើន។:

• RequestReceived - ដំណាក់កាលនៅពេលដែលសំណើត្រូវបានទទួលដោយ processor និងមិនទាន់ត្រូវបានបញ្ជូនបន្ថែមទៀតតាមខ្សែសង្វាក់នៃ processors ។
• ResponseStarted - ក្បាលឆ្លើយតបត្រូវបានផ្ញើ ប៉ុន្តែមុនពេលដែលផ្នែកឆ្លើយតបត្រូវបានផ្ញើ។ បង្កើតសម្រាប់សំណួរដែលដំណើរការយូរ (ឧទាហរណ៍ watch);
• ResponseComplete - អង្គភាពឆ្លើយតបត្រូវបានផ្ញើ នឹងមិនផ្ញើព័ត៌មានបន្ថែមទេ។
• Panic - ព្រឹត្តិការណ៍ត្រូវបានបង្កើតឡើងនៅពេលដែលស្ថានភាពមិនប្រក្រតីត្រូវបានរកឃើញ។

ដើម្បីរំលងជំហានណាមួយដែលអ្នកអាចប្រើ omitStages.

នៅក្នុងឯកសារគោលការណ៍ យើងអាចពណ៌នាផ្នែកជាច្រើនដែលមានកម្រិតនៃការកត់ត្រាខុសៗគ្នា។ ច្បាប់ដែលត្រូវគ្នាដំបូងដែលរកឃើញនៅក្នុងការពិពណ៌នាអំពីគោលការណ៍នឹងត្រូវបានអនុវត្ត។

ដេមិន kubelet ត្រួតពិនិត្យការផ្លាស់ប្តូរនៅក្នុង manifest ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធ api-server ហើយប្រសិនបើមានណាមួយត្រូវបានរកឃើញ ចាប់ផ្តើមកុងតឺន័រឡើងវិញជាមួយ api-server។ ប៉ុន្តែមានព័ត៌មានលម្អិតសំខាន់មួយ៖ ការផ្លាស់ប្តូរនៅក្នុងឯកសារគោលការណ៍នឹងត្រូវបានមិនអើពើដោយវា។. បន្ទាប់ពីធ្វើការផ្លាស់ប្តូរឯកសារគោលការណ៍ អ្នកនឹងត្រូវចាប់ផ្តើមម៉ាស៊ីនមេ api ឡើងវិញដោយដៃ។ ចាប់តាំងពី api-server ត្រូវបានចាប់ផ្តើមជា pod ឋិតិវន្ត, ក្រុម 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

គោលការណ៍សវនកម្មខាងក្រោមត្រូវបានផ្តល់ជូនជាការបង្ហាញពីការអនុវត្តល្អបំផុតនៅក្នុង ឯកសារ Alibaba 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 ដែលអនុញ្ញាតឱ្យអ្នកបង្កើតគណនីអ្នកប្រើប្រាស់ផ្ទាល់ខ្លួន បំបែកសិទ្ធិរបស់ពួកគេ និងកត់ត្រាសកម្មភាពរបស់ពួកគេ។ ខ្ញុំសង្ឃឹមថាវានឹងមានប្រយោជន៍សម្រាប់អ្នកដែលប្រឈមមុខនឹងបញ្ហាបែបនេះនៅក្នុងទ្រឹស្តីឬក្នុងការអនុវត្ត។ ខ្ញុំក៏សូមណែនាំឱ្យអ្នកអានបញ្ជីសម្ភារៈផ្សេងទៀតលើប្រធានបទសុវត្ថិភាពនៅក្នុង Kubernetes ដែលត្រូវបានផ្តល់ឱ្យនៅក្នុង "PS" - ប្រហែលជាក្នុងចំណោមពួកគេ អ្នកនឹងឃើញព័ត៌មានលម្អិតចាំបាច់អំពីបញ្ហាដែលទាក់ទងនឹងអ្នក។

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «ឧបករណ៍សុវត្ថិភាព Kubernetes 33+»
• «ការណែនាំអំពីគោលការណ៍បណ្តាញ Kubernetes សម្រាប់អ្នកជំនាញផ្នែកសុវត្ថិភាព»
• «ការយល់ដឹងអំពី RBAC នៅក្នុង Kubernetes»
• «ការអនុវត្តល្អបំផុត 9 Kubernetes Security»
• «11 វិធីដើម្បី (មិន) ទទួលបានការ Hack នៅក្នុង Kubernetes"។

ប្រភព: www.habr.com