უსაფრთხოების ABC Kubernetes-ში: ავთენტიფიკაცია, ავტორიზაცია, აუდიტი

ადრე თუ გვიან ნებისმიერი სისტემის მუშაობისას დგება უსაფრთხოების საკითხი: ავთენტიფიკაციის უზრუნველყოფა, უფლებების გამიჯვნა, აუდიტი და სხვა ამოცანები. უკვე შექმნილია Kubernetes-ისთვის ბევრი გამოსავალი, რომელიც საშუალებას გაძლევთ მიაღწიოთ სტანდარტებთან შესაბამისობას ძალიან მომთხოვნ გარემოშიც კი... იგივე მასალა ეძღვნება K8-ების ჩაშენებულ მექანიზმებში განხორციელებულ უსაფრთხოების ძირითად ასპექტებს. უპირველეს ყოვლისა, ეს სასარგებლო იქნება მათთვის, ვინც იწყებს Kubernetes-ის გაცნობას - როგორც ამოსავალი წერტილი უსაფრთხოებასთან დაკავშირებული საკითხების შესწავლისთვის.

ავთენტიფიკაცია

Kubernetes-ში ორი ტიპის მომხმარებელია:

• სერვისის ანგარიშები — ანგარიშები, რომელსაც მართავს Kubernetes API;
• მომხმარებელი — „ნორმალური“ მომხმარებლები, რომლებსაც მართავს გარე, დამოუკიდებელი სერვისები.

ამ ტიპებს შორის მთავარი განსხვავება ისაა, რომ სერვისის ანგარიშებისთვის არის სპეციალური ობიექტები Kubernetes API-ში (მათ ასე ეძახიან - ServiceAccounts), რომლებიც დაკავშირებულია სახელთა სივრცესთან და ავტორიზაციის მონაცემების ერთობლიობასთან, რომლებიც ინახება კლასტერში Secrets ტიპის ობიექტებში. ასეთი მომხმარებლები (სერვისის ანგარიშები) ძირითადად გამიზნულია Kubernetes კლასტერში გაშვებული პროცესების Kubernetes API-ზე წვდომის უფლებების მართვისთვის.

ჩვეულებრივ მომხმარებლებს არ აქვთ ჩანაწერები Kubernetes API-ში: ისინი უნდა მართონ გარე მექანიზმებით. ისინი განკუთვნილია კლასტერის გარეთ მცხოვრები ადამიანებისთვის ან პროცესებისთვის.

თითოეული API მოთხოვნა დაკავშირებულია ან სერვისის ანგარიშთან, მომხმარებელთან, ან ითვლება ანონიმურად.

მომხმარებლის ავთენტიფიკაციის მონაცემები მოიცავს:

• მომხმარებლის სახელი — მომხმარებლის სახელი (შემთხვევით მგრძნობიარე!);
• UID - მანქანით წაკითხვადი მომხმარებლის საიდენტიფიკაციო სტრიქონი, რომელიც არის „უფრო თანმიმდევრული და უნიკალური, ვიდრე მომხმარებლის სახელი“;
• ჯგუფები - ჯგუფების სია, რომლებსაც მომხმარებელი ეკუთვნის;
• დამატებითი — დამატებითი ველები, რომელთა გამოყენება შესაძლებელია ავტორიზაციის მექანიზმით.

Kubernetes-ს შეუძლია გამოიყენოს ავთენტიფიკაციის მექანიზმების დიდი რაოდენობა: X509 სერთიფიკატები, Bearer tokens, ავთენტიფიკაციის პროქსი, HTTP Basic Auth. ამ მექანიზმების გამოყენებით, შეგიძლიათ განახორციელოთ ავტორიზაციის სქემები დიდი რაოდენობით: სტატიკური ფაილიდან პაროლებით OpenID OAuth2-მდე.

უფრო მეტიც, შესაძლებელია რამდენიმე ავტორიზაციის სქემის ერთდროულად გამოყენება. ნაგულისხმევად, კლასტერი იყენებს:

• სერვისის ანგარიშის ნიშნები - სერვისის ანგარიშებისთვის;
• X509 - მომხმარებლებისთვის.

საკითხი ServiceAccounts-ის მართვის შესახებ სცილდება ამ სტატიის ფარგლებს, მაგრამ მათთვის, ვისაც სურს უფრო დეტალურად გაეცნოს ამ საკითხს, გირჩევთ დაიწყოთ ოფიციალური დოკუმენტაციის გვერდები. ჩვენ უფრო დეტალურად განვიხილავთ საკითხს, თუ როგორ მუშაობს 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-სერვერის სისწორეს):

    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, ე.ი. რომელმაც მიიღო certificate-authority-data ა.შ.

სერთიფიკატები kubeadm-ით

გამოშვებით კუბერნეტი 1.15 სერთიფიკატებთან მუშაობა ბევრად უფრო ადვილი გახდა მისი მხარდაჭერის ალფა ვერსიის წყალობით kubeadm პროგრამა. მაგალითად, ასე გამოიყურება მომხმარებლის კლავიშებით კონფიგურაციის ფაილის გენერირება:

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

NB: აუცილებელია რეკლამის მისამართი შეგიძლიათ იხილოთ api-სერვერის კონფიგურაციაში, რომელიც ნაგულისხმევად მდებარეობს /etc/kubernetes/manifests/kube-apiserver.yaml.

შედეგად მიღებული კონფიგურაცია გამოვა stdout-ში. საჭიროა მისი შენახვა ~/.kube/config მომხმარებლის ანგარიში ან გარემოს ცვლადში მითითებულ ფაილზე KUBECONFIG.

გათხარე უფრო ღრმად

მათთვის, ვისაც სურს უფრო დეტალურად გაიგოს აღწერილი საკითხები:

• ცალკე სტატია კუბერნეტის ოფიციალურ დოკუმენტაციაში სერტიფიკატებთან მუშაობის შესახებ;
• კარგი სტატია Bitnami-დან, რომელშიც სერტიფიკატების გაცემას პრაქტიკული კუთხით შეეხო.
• ზოგადი დოკუმენტაცია ავტორიზაციის შესახებ Kubernetes-ში.

ავტორიზაცია

ნაგულისხმევ ავტორიზებულ ანგარიშს არ აქვს კლასტერზე მუშაობის უფლება. ნებართვების მისაცემად, Kubernetes ახორციელებს ავტორიზაციის მექანიზმს.

1.6 ვერსიამდე Kubernetes იყენებდა ავტორიზაციის ტიპს ე.წ აბაკი (ატრიბუტებზე დაფუძნებული წვდომის კონტროლი). ამის შესახებ დეტალები შეგიძლიათ იხილოთ ოფიციალური დოკუმენტაცია. ეს მიდგომა ამჟამად ითვლება მემკვიდრეობით, მაგრამ თქვენ მაინც შეგიძლიათ გამოიყენოთ იგი ავტორიზაციის სხვა ტიპებთან ერთად.

კლასტერზე წვდომის უფლებების გაყოფის მიმდინარე (და უფრო მოქნილი) გზა ეწოდება RBAC (როლზე დაფუძნებული დაშვების კონტროლი). ვერსიიდან ის გამოცხადდა სტაბილურად კუბერნეტი 1.8. RBAC ახორციელებს უფლებების მოდელს, რომელშიც აკრძალულია ყველაფერი, რაც აშკარად არ არის ნებადართული.
RBAC-ის გასააქტიურებლად, თქვენ უნდა გაუშვათ Kubernetes api-სერვერი პარამეტრით --authorization-mode=RBAC. პარამეტრები დაყენებულია manifest-ში api-სერვერის კონფიგურაციით, რომელიც ნაგულისხმევად მდებარეობს ბილიკის გასწვრივ /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 და RoleBinding ერთეულები შეზღუდულია სახელთა სივრცით, ე.ი. უნდა იყოს იმავე სახელთა სივრცეში. თუმცა, 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 in 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 არქიტექტურა შეიძლება წარმოდგენილი იყოს შემდეგნაირად:

კუბერნეტის ძირითადი კომპონენტი, რომელიც პასუხისმგებელია მოთხოვნების დამუშავებაზე api-სერვერი. კლასტერზე ყველა ოპერაცია გადის მასზე. ამ შიდა მექანიზმების შესახებ მეტი შეგიძლიათ წაიკითხოთ სტატიაში ”რა ხდება Kubernetes-ში, როცა აწარმოებთ kubectl run?".

სისტემის აუდიტი საინტერესო ფუნქციაა Kubernetes-ში, რომელიც ნაგულისხმევად გამორთულია. ის საშუალებას გაძლევთ შეხვიდეთ ყველა ზარის Kubernetes API-ზე. როგორც თქვენ მიხვდით, ყველა მოქმედება, რომელიც დაკავშირებულია მონიტორინგთან და კლასტერის მდგომარეობის შეცვლასთან, ხორციელდება ამ API-ს მეშვეობით. მისი შესაძლებლობების კარგი აღწერა (როგორც ყოველთვის) შეგიძლიათ იხილოთ აქ ოფიციალური დოკუმენტაცია K8s. შემდეგ ვეცდები უფრო მარტივ ენაზე წარმოვადგინო თემა.

აქედან გამომდინარე, აუდიტის გასააქტიურებლად, ჩვენ უნდა გადავცეთ სამი საჭირო პარამეტრი კონტეინერში api-სერვერში, რომლებიც უფრო დეტალურად არის აღწერილი ქვემოთ:

• --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 დოკუმენტაცია.

როგორც უკვე აღვნიშნეთ, ყველა პარამეტრი დაყენებულია manifest-ში api-სერვერის კონფიგურაციით (ნაგულისხმევად /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-სერვერის პროცესისთვის, ამიტომ ჩვენ აღვწერთ მის მონტაჟს ანალოგიურად:

     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) არ დაარეგისტრიროთ მოთხოვნები, რომლებსაც არ ჰქონდათ წვდომა რესურსებზე (წვდომა ე.წ. არარესურსების url-ებზე).

ასევე ყველა მოთხოვნა გადის რამდენიმე ეტაპი:

• RequestReceived - ეტაპი, როდესაც მოთხოვნა მიღებულია პროცესორის მიერ და ჯერ კიდევ არ არის გადაცემული პროცესორების ჯაჭვის გასწვრივ;
• ResponseStarted — პასუხის სათაურები იგზავნება, მაგრამ სანამ რეაგირების ორგანო გაიგზავნება. შექმნილია გრძელვადიანი მოთხოვნებისთვის (მაგალითად, watch);
• ResponseComplete — საპასუხო ორგანო გაიგზავნა, მეტი ინფორმაცია არ გაიგზავნება;
• Panic — მოვლენები წარმოიქმნება არანორმალური სიტუაციის გამოვლენისას.

ნებისმიერი ნაბიჯის გამოტოვებისთვის შეგიძლიათ გამოიყენოთ omitStages.

პოლიტიკის ფაილში, ჩვენ შეგვიძლია აღვწეროთ რამდენიმე განყოფილება სხვადასხვა დონის ანგარიშებით. გამოყენებული იქნება პირველი შესატყვისი წესი, რომელიც ნაპოვნია პოლიტიკის აღწერაში.

kubelet daemon აკვირდება მანიფესტის ცვლილებებს api-სერვერის კონფიგურაციით და, თუ რომელიმე აღმოჩენილია, გადატვირთავს კონტეინერს api-სერვერით. მაგრამ არის მნიშვნელოვანი დეტალი: პოლიტიკის ფაილში ცვლილებები იგნორირებული იქნება. პოლიტიკის ფაილში ცვლილებების შეტანის შემდეგ, თქვენ უნდა გადატვირთოთ api-სერვერი ხელით. ვინაიდან api-სერვერი დაწყებულია როგორც სტატიკური პოდიუმი, გუნდი kubectl delete არ გამოიწვევს მის გადატვირთვას. ხელით მოგიწევთ ამის გაკეთება docker stop kube-masters-ზე, სადაც შეიცვალა აუდიტის პოლიტიკა:

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

აუდიტის ჩართვისას მნიშვნელოვანია გახსოვდეთ ეს კუბე-აპისერვერზე დატვირთვა იზრდება. კერძოდ, იზრდება მეხსიერების მოხმარება მოთხოვნის კონტექსტის შესანახად. შესვლა იწყება მხოლოდ პასუხის სათაურის გაგზავნის შემდეგ. დატვირთვა ასევე დამოკიდებულია აუდიტის პოლიტიკის კონფიგურაციაზე.

პოლიტიკის მაგალითები

მოდით შევხედოთ პოლიტიკის ფაილების სტრუქტურას მაგალითების გამოყენებით.

აქ არის მარტივი ფაილი 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-ში.

აუდიტის მოვლენებზე სწრაფად რეაგირება შესაძლებელია აღწერეთ ვებჰუკი. ეს საკითხი დაფარულია ოფიციალური დოკუმენტაცია, მე მას ამ სტატიის ფარგლებს გარეთ დავტოვებ.

შედეგები

სტატიაში მოცემულია უსაფრთხოების ძირითადი მექანიზმების მიმოხილვა Kubernetes კლასტერებში, რომლებიც საშუალებას გაძლევთ შექმნათ პერსონალიზებული მომხმარებლის ანგარიშები, გამოყოთ მათი უფლებები და ჩაწეროთ მათი ქმედებები. ვიმედოვნებ, რომ ეს სასარგებლო იქნება მათთვის, ვინც მსგავსი საკითხების წინაშე დგას თეორიულად თუ პრაქტიკაში. ასევე გირჩევთ, წაიკითხოთ Kubernetes-ში უსაფრთხოების თემაზე სხვა მასალების სია, რომელიც მოცემულია "PS" -ში - შესაძლოა მათ შორის იპოვოთ საჭირო დეტალები თქვენთვის აქტუალური პრობლემების შესახებ.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «33+ Kubernetes უსაფრთხოების ინსტრუმენტები";
• «შესავალი Kubernetes ქსელის პოლიტიკაში უსაფრთხოების პროფესიონალებისთვის";
• «RBAC-ის გაგება Kubernetes-ში";
• «9 საუკეთესო პრაქტიკა Kubernetes უსაფრთხოებისთვის";
• «11 გზა, რათა (არ) გახდე კუბერნეტის ჰაკის მსხვერპლი".

წყარო: www.habr.com