Kubernetesdə Təhlükəsizlik ABC: Doğrulama, Avtorizasiya, Audit

Gec-tez hər hansı bir sistemin işində təhlükəsizlik məsələsi yaranır: autentifikasiyanın təmin edilməsi, hüquqların ayrılması, audit və digər tapşırıqlar. Artıq Kubernetes üçün yaradılmışdır çoxlu həllər, hətta çox tələbkar mühitlərdə də standartlara uyğunluğa nail olmağa imkan verir... Eyni material K8-lərin daxili mexanizmləri çərçivəsində həyata keçirilən təhlükəsizliyin əsas aspektlərinə həsr olunub. İlk növbədə, Kubernetes ilə tanış olmağa başlayanlar üçün faydalı olacaq - təhlükəsizliklə bağlı məsələləri öyrənmək üçün başlanğıc nöqtəsi kimi.

İdentifikasiyası

Kubernetes-də iki növ istifadəçi var:

• Xidmət Hesabları — Kubernetes API tərəfindən idarə olunan hesablar;
• İstifadəçilər — xarici, müstəqil xidmətlər tərəfindən idarə olunan “normal” istifadəçilər.

Bu növlər arasındakı əsas fərq ondan ibarətdir ki, Xidmət Hesabları üçün Kubernetes API-də xüsusi obyektlər mövcuddur (onlara belə deyilir - ServiceAccounts), sirlər tipli obyektlərdə klasterdə saxlanılan ad sahəsinə və icazə məlumat dəstinə bağlıdır. Belə istifadəçilər (Xidmət Hesabları) ilk növbədə Kubernetes klasterində işləyən proseslərin Kubernetes API-yə giriş hüquqlarını idarə etmək üçün nəzərdə tutulub.

Adi İstifadəçilərin Kubernetes API-də girişləri yoxdur: onlar xarici mexanizmlər tərəfindən idarə edilməlidir. Onlar klasterdən kənarda yaşayan insanlar və ya proseslər üçün nəzərdə tutulub.

Hər bir API sorğusu ya Xidmət Hesabı, İstifadəçi ilə əlaqələndirilir və ya anonim hesab olunur.

İstifadəçi identifikasiyası məlumatlarına daxildir:

• İstifadəçi adı — istifadəçi adı (hərflərə həssasdır!);
• UID - “istifadəçi adından daha ardıcıl və unikal olan” maşın tərəfindən oxuna bilən istifadəçi identifikasiyası sətri;
• Qruplar — istifadəçinin aid olduğu qrupların siyahısı;
• əlavə — avtorizasiya mexanizmi tərəfindən istifadə edilə bilən əlavə sahələr.

Kubernetes çoxlu sayda autentifikasiya mexanizmlərindən istifadə edə bilər: X509 sertifikatları, Taşıyıcı tokenləri, autentifikasiya edən proksi, HTTP Əsas Doğrulama. Bu mexanizmlərdən istifadə edərək çoxlu sayda avtorizasiya sxemlərini həyata keçirə bilərsiniz: parolları olan statik fayldan OpenID OAuth2-ə qədər.

Üstəlik, eyni vaxtda bir neçə avtorizasiya sxemindən istifadə etmək mümkündür. Varsayılan olaraq, klaster istifadə edir:

• xidmət hesabı nişanları - Xidmət Hesabları üçün;
• X509 - İstifadəçilər üçün.

ServiceAccounts-un idarə edilməsi ilə bağlı sual bu məqalənin əhatə dairəsindən kənardadır, lakin bu məsələ ilə daha ətraflı tanış olmaq istəyənlər üçün məndən başlamağı məsləhət görürəm. rəsmi sənəd səhifələri. X509 sertifikatlarının necə işlədiyi məsələsini daha yaxından nəzərdən keçirəcəyik.

İstifadəçilər üçün sertifikatlar (X.509)

Sertifikatlarla işləməyin klassik üsuluna aşağıdakılar daxildir:

• əsas nəsil:

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

• sertifikat sorğusu yaratmaq:

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

• Kubernetes klaster CA açarlarından istifadə edərək sertifikat sorğusunun işlənməsi, istifadəçi sertifikatının əldə edilməsi (sertifikat əldə etmək üçün siz Kubernetes klaster CA açarına girişi olan hesabdan istifadə etməlisiniz, o, standart olaraq /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

• konfiqurasiya faylı yaratmaq:
  • klaster təsviri (xüsusi klaster quraşdırılması üçün CA sertifikat faylının ünvanını və yerini göstərin):

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

  • və ya necə heç birtövsiyə olunan seçim - kök sertifikatını göstərməyə ehtiyac yoxdur (sonra kubectl klasterin api-serverinin düzgünlüyünü yoxlamaz):

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

  • konfiqurasiya faylına istifadəçi əlavə etmək:

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

  • kontekst əlavə etmək:

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

  • standart kontekst təyinatı:

    kubectl config use-context mynewuser-context

Yuxarıdakı manipulyasiyalardan sonra faylda .kube/config belə bir konfiqurasiya yaradılacaq:

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

Hesablar və serverlər arasında konfiqurasiyanın ötürülməsini asanlaşdırmaq üçün aşağıdakı düymələrin dəyərlərini redaktə etmək faydalıdır:

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

Bunu etmək üçün, siz base64 istifadə edərək, onlarda göstərilən faylları kodlaya və düymələrin adına şəkilçi əlavə edərək konfiqurasiyada qeyd edə bilərsiniz. -data, yəni. almış certificate-authority-data və s.

kubeadm ilə sertifikatlar

Buraxılış ilə Kubernetes 1.15 -də dəstəyinin alfa versiyası sayəsində sertifikatlarla işləmək xeyli asanlaşıb kubeadm yardım proqramı. Məsələn, istifadəçi düymələri ilə konfiqurasiya faylı yaratmaq indi belə görünə bilər:

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

NB: Tələb olunur reklam ünvanı api-server konfiqurasiyasında tapıla bilər, bu da standart olaraq yerləşir /etc/kubernetes/manifests/kube-apiserver.yaml.

Nəticə konfiqurasiya stdout-a çıxarılacaq. Onu saxlamaq lazımdır ~/.kube/config istifadəçi hesabına və ya mühit dəyişənində göstərilən fayla KUBECONFIG.

Dərin qazmaq

Daha ətraflı təsvir olunan məsələləri anlamaq istəyənlər üçün:

• ayrı məqalə rəsmi Kubernetes sənədlərində sertifikatlarla işləmək üzrə;
• Bitnamidən yaxşı məqalə, burada sertifikatlar məsələsinə praktiki baxımdan toxunulur.
• ümumi sənədlər Kubernetes-də autentifikasiya haqqında.

Icazə

Defolt səlahiyyətli hesabın klasterdə işləmək hüququ yoxdur. İcazələr vermək üçün Kubernetes avtorizasiya mexanizmini tətbiq edir.

1.6 versiyasından əvvəl Kubernetes adlı avtorizasiya növündən istifadə edirdi ABAC (Atribut əsaslı giriş nəzarəti). Bununla bağlı təfərrüatları burada tapa bilərsiniz rəsmi sənədlər. Bu yanaşma hazırda miras sayılır, lakin siz onu hələ də digər autentifikasiya növləri ilə birlikdə istifadə edə bilərsiniz.

Klasterə giriş hüquqlarının bölünməsinin cari (və daha çevik) yolu adlanır RBAC (Rol əsaslı giriş nəzarəti). Versiyadan bəri stabil elan edilmişdir Kubernetes 1.8. RBAC açıq şəkildə icazə verilməyən hər şeyin qadağan edildiyi hüquq modelini həyata keçirir.
RBAC-ı aktivləşdirmək üçün, parametrlə Kubernetes api-serverini işə salmalısınız --authorization-mode=RBAC. Parametrlər, standart olaraq yol boyunca yerləşən api-server konfiqurasiyası ilə manifestdə təyin olunur. /etc/kubernetes/manifests/kube-apiserver.yaml, bölməsində command. Bununla belə, RBAC artıq defolt olaraq aktivdir, buna görə də çox güman ki, bu barədə narahat olmamalısınız: bunu dəyərlə yoxlaya bilərsiniz authorization-mode (artıq qeyd olunanda kube-apiserver.yaml). Yeri gəlmişkən, onun mənaları arasında icazənin başqa növləri də ola bilər (node, webhook, always allow), lakin biz onların nəzərdən keçirilməsini materialın əhatə dairəsindən kənarda qoyacağıq.

Yeri gəlmişkən, biz artıq dərc etmişik Məqalə RBAC ilə işləməyin prinsipləri və xüsusiyyətlərinin kifayət qədər ətraflı təsviri ilə, buna görə də daha sonra özümü əsasların və nümunələrin qısa siyahısı ilə məhdudlaşdıracağam.

Aşağıdakı API obyektləri RBAC vasitəsilə Kubernetes-də girişi idarə etmək üçün istifadə olunur:

• Role и ClusterRole — giriş hüquqlarını təsvir etməyə xidmət edən rollar:
• Role ad məkanında hüquqları təsvir etməyə imkan verir;
• ClusterRole - çoxluq daxilində, o cümlədən qovşaqlar, qeyri-resurs URL-ləri (yəni Kubernetes resursları ilə əlaqəli olmayan) kimi klasterə aid obyektlərə - məsələn, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - bağlamaq üçün istifadə olunur Role и ClusterRole istifadəçiyə, istifadəçi qrupuna və ya ServiceAccount-a.

Rol və Rol Bağlama obyektləri ad sahəsi ilə məhdudlaşır, yəni. eyni ad məkanında olmalıdır. Bununla belə, RoleBinding ClusterRole-a istinad edə bilər ki, bu da sizə ümumi icazələr dəsti yaratmağa və onlardan istifadə edərək girişi idarə etməyə imkan verir.

Rollar aşağıdakıları ehtiva edən qaydalar toplusundan istifadə edərək hüquqları təsvir edir:

• API qrupları - bax rəsmi sənədlər apiGroups və çıxış tərəfindən kubectl api-resources;
• resursları (resursları: pod, namespace, deployment və s.);
• Fe'llər (fe'llər: set, update və s.).
• resurs adları (resourceNames) - bu tip bütün resurslara deyil, müəyyən bir mənbəyə çıxış təmin etməyiniz lazım olduğu halda.

Kubernetes-də avtorizasiyanın daha ətraflı təhlilini səhifədə tapa bilərsiniz rəsmi sənədlər. Bunun əvəzinə (daha doğrusu, buna əlavə olaraq) onun işini göstərən nümunələr verəcəyəm.

RBAC müəssisələrinin nümunələri

Sadə Role, bu sizə podların siyahısını və statusunu əldə etməyə və ad məkanında onlara nəzarət etməyə imkan verir 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"]

Misal ClusterRole, bu sizə podların siyahısını və statusunu əldə etməyə və bütün klasterdə onlara nəzarət etməyə imkan verir:

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

Misal RoleBindingistifadəçiyə imkan verir mynewuser ad məkanında podları "oxumaq" 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

Hadisə auditi

Sxematik olaraq, Kubernetes arxitekturasını aşağıdakı kimi təqdim etmək olar:

Sorğuların işlənməsi üçün cavabdeh olan əsas Kubernetes komponentidir api-server. Klasterdəki bütün əməliyyatlar ondan keçir. Bu daxili mexanizmlər haqqında daha çox məqalədə oxuya bilərsiniz "Kubernetes-də kubectl run-u işlədəndə nə baş verir?.

Sistem auditi Kubernetes-də defolt olaraq qeyri-aktiv olan maraqlı bir xüsusiyyətdir. Bütün zəngləri Kubernetes API-yə daxil etməyə imkan verir. Təxmin etdiyiniz kimi, klasterin vəziyyətinin monitorinqi və dəyişdirilməsi ilə bağlı bütün hərəkətlər bu API vasitəsilə həyata keçirilir. Onun imkanlarının yaxşı təsvirini (hər zamankı kimi) tapa bilərsiniz rəsmi sənədlər K8s. Sonra mövzunu daha sadə dildə təqdim etməyə çalışacağam.

Belə ki, auditin aparılmasına imkan yaratmaq, api-serverdəki konteynerə üç tələb olunan parametri ötürməliyik, bunlar aşağıda daha ətraflı təsvir edilmişdir:

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

Bu üç zəruri parametrə əlavə olaraq, auditlə bağlı bir çox əlavə parametrlər var: jurnalın fırlanmasından veb-hook təsvirlərinə qədər. Günlük fırlanma parametrlərinə nümunə:

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

Ancaq biz onların üzərində daha ətraflı dayanmayacağıq - bütün təfərrüatları burada tapa bilərsiniz kube-apiserver sənədləri.

Artıq qeyd edildiyi kimi, bütün parametrlər api-server konfiqurasiyası ilə manifestdə qurulur (standart olaraq /etc/kubernetes/manifests/kube-apiserver.yaml), bölməsində command. Gəlin 3 tələb olunan parametrə qayıdaq və onları təhlil edək:

1. audit-policy-file — audit siyasətini təsvir edən YAML faylına gedən yol. Onun məzmununa daha sonra qayıdacağıq, lakin hələlik qeyd edim ki, fayl api-server prosesi tərəfindən oxunaqlı olmalıdır. Buna görə də, onu konteynerin içərisinə quraşdırmaq lazımdır, bunun üçün konfiqurasiyanın müvafiq bölmələrinə aşağıdakı kodu əlavə edə bilərsiniz:

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

2. audit-log-path — log faylına gedən yol. Yol həmçinin api-server prosesi üçün əlçatan olmalıdır, ona görə də onun quraşdırılmasını eyni şəkildə təsvir edirik:

     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 — audit jurnalının formatı. Defoltdur json, lakin köhnə mətn formatı da mövcuddur (legacy).

Audit Siyasəti

İndi giriş siyasətini təsvir edən qeyd olunan fayl haqqında. Audit siyasətinin ilk konsepsiyası belədir level, giriş səviyyəsi. Onlar aşağıdakılardır:

• None - qeydiyyatdan keçməyin;
• Metadata — sorğunun metadatasını qeyd edin: istifadəçi, sorğu vaxtı, hədəf resurs (pod, ad sahəsi və s.), fəaliyyət növü (fel) və s.;
• Request — log metadata və sorğu orqanı;
• RequestResponse — log metadata, sorğu orqanı və cavab orqanı.

Son iki səviyyə (Request и RequestResponse) resurslara daxil olmayan sorğuları daxil etməyin (resurs olmayan URL-lərə giriş).

Həm də bütün sorğular keçir bir neçə mərhələdə:

• RequestReceived — sorğunun prosessor tərəfindən qəbul edildiyi və prosessorlar zənciri üzrə hələ də ötürülmədiyi mərhələ;
• ResponseStarted — cavab başlıqları göndərilir, lakin cavab orqanı göndərilməzdən əvvəl. Uzun müddət davam edən sorğular üçün yaradılmışdır (məsələn, watch);
• ResponseComplete — cavab orqanı göndərilib, artıq məlumat göndərilməyəcək;
• Panic — hadisələr anormal vəziyyət aşkar edildikdə yaranır.

İstifadə edə biləcəyiniz addımları atlamaq üçün omitStages.

Siyasət faylında biz müxtəlif qeyd səviyyələri olan bir neçə bölməni təsvir edə bilərik. Siyasət təsvirində tapılan ilk uyğunluq qaydası tətbiq olunacaq.

Kubelet demonu api-server konfiqurasiyası ilə manifestdəki dəyişiklikləri izləyir və aşkar edilərsə, konteyneri api-server ilə yenidən işə salır. Ancaq vacib bir detal var: siyasət faylındakı dəyişikliklər onun tərəfindən nəzərə alınmayacaq. Siyasət faylında dəyişikliklər etdikdən sonra api-serverini əl ilə yenidən başlatmalısınız. api-server kimi işə salındığından statik pod, komanda kubectl delete yenidən başlamasına səbəb olmayacaq. Bunu əl ilə etməli olacaqsınız docker stop audit siyasətinin dəyişdirildiyi kube-masterlərdə:

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

Auditi aktivləşdirərkən bunu yadda saxlamaq vacibdir kube-apiserverə yük artır. Xüsusilə, sorğu kontekstini saxlamaq üçün yaddaş istehlakı artır. Giriş yalnız cavab başlığı göndərildikdən sonra başlayır. Yük həmçinin audit siyasətinin konfiqurasiyasından asılıdır.

Siyasət nümunələri

Nümunələrdən istifadə edərək siyasət fayllarının strukturuna baxaq.

Budur sadə bir fayl policyhər şeyi səviyyədə qeyd etmək Metadata:

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

Siyasətdə istifadəçilərin siyahısını müəyyən edə bilərsiniz (Users и ServiceAccounts) və istifadəçi qrupları. Məsələn, bu şəkildə sistem istifadəçilərini nəzərə almayacağıq, lakin hər şeyi səviyyədə qeyd edəcəyik 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

Hədəfləri də təsvir etmək olar:

• ad boşluqları (namespaces);
• Fe'llər (fe'llər: get, update, delete və qeyriləri);
• resursları (resurslarıKimi aşağıdakılardır: pod, configmaps və s.) və resurs qrupları (apiGroups).

Diqqət edin! Resurslar və resurs qrupları (API qrupları, yəni apiGroups), həmçinin onların klasterdə quraşdırılmış versiyaları əmrlərdən istifadə etməklə əldə edilə bilər:

kubectl api-resources
kubectl api-versions

Aşağıdakı audit siyasəti ən yaxşı təcrübələrin nümayişi kimi təqdim olunur Alibaba Cloud sənədləri:

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

Audit siyasətinin başqa bir yaxşı nümunəsidir GCE-də istifadə olunan profil.

Audit hadisələrinə tez reaksiya vermək mümkündür webhook təsvir edin. Bu məsələ əhatə olunur rəsmi sənədlər, bu məqalənin əhatə dairəsindən kənarda buraxacağam.

Nəticələri

Məqalə Kubernetes klasterlərində fərdiləşdirilmiş istifadəçi hesabları yaratmağa, onların hüquqlarını ayırmağa və hərəkətlərini qeyd etməyə imkan verən əsas təhlükəsizlik mexanizmlərinin icmalı təqdim edir. Ümid edirəm ki, nəzəri və ya praktiki olaraq belə problemlərlə üzləşənlər üçün faydalı olar. "PS"-də verilən Kubernetes-də təhlükəsizlik mövzusunda digər materialların siyahısını oxumağı da tövsiyə edirəm - bəlkə də onların arasında sizə aid olan problemlər haqqında lazımi təfərrüatları tapa bilərsiniz.

PS

Bloqumuzda da oxuyun:

• «33+ Kubernetes təhlükəsizlik alətləri";
• «Təhlükəsizlik Peşəkarları üçün Kubernetes Şəbəkə Siyasətlərinə Giriş";
• «Kubernetes-də RBAC-ı başa düşmək";
• «9 Kubernetes Təhlükəsizlik Ən Yaxşı Təcrübələri";
• «Kubernetes-də sındırılmağın 11 yolu.

Mənbə: www.habr.com