Den ABC vu Sécherheet zu Kubernetes: Authentifikatioun, Autorisatioun, Audit

Fréier oder spéider, an der Operatioun vun all System, entsteet d'Fro vun der Sécherheet: Authentifikatioun garantéieren, Trennung vu Rechter, Audit an aner Aufgaben. Scho fir Kubernetes erstallt vill Léisungen, déi Iech erlaben d'Konformitéit mat Normen och a ganz erfuerderlechen Ëmfeld z'erreechen ... Datselwecht Material ass gewidmet fir d'Basis Aspekter vun der Sécherheet, déi an den agebaute Mechanismen vun de K8s ëmgesat ginn. Als éischt wäert et nëtzlech sinn fir déi, déi ufänken mat Kubernetes kennen ze léieren - als Ausgangspunkt fir Sécherheetsproblemer ze studéieren.

Authentifikatioun

Et ginn zwou Zorte vu Benotzer a Kubernetes:

• Service Konten - Konte geréiert vun der Kubernetes API;
• Benotzer - "normale" Benotzer, déi vun externen, onofhängege Servicer geréiert ginn.

Den Haaptunterschied tëscht dësen Typen ass datt fir Servicekonten et speziell Objekter an der Kubernetes API sinn (si ginn dat genannt - ServiceAccounts), déi un engem Nummraum an enger Rei vun Autorisatiounsdaten gebonnen sinn, déi am Cluster an Objekter vum Secrets-Typ gespäichert sinn. Esou Benotzer (Service Accounts) sinn haaptsächlech geduecht fir Zougangsrechter op d'Kubernetes API vu Prozesser ze managen déi am Kubernetes Cluster lafen.

Gewéinlech Benotzer hunn keng Entréen an der Kubernetes API: si mussen duerch extern Mechanismen geréiert ginn. Si si geduecht fir Leit oder Prozesser, déi ausserhalb vum Cluster liewen.

All API Ufro ass mat engem Service Account, engem Benotzer verbonnen oder gëtt als anonym ugesinn.

Benotzer Authentifikatioun Daten enthalen:

• Benotzernumm - Benotzernumm (case sensibel!);
• UID - eng Maschinn liesbar Benotzer Identifikatioun String déi "méi konsequent an eenzegaarteg ass wéi de Benotzernumm";
• Gruppen - Lëscht vun de Gruppen zu deenen de Benotzer gehéiert;
• extra - zousätzlech Felder déi vum Autorisatiounsmechanismus benotzt kënne ginn.

Kubernetes kënnen eng grouss Unzuel vun Authentifikatiounsmechanismen benotzen: X509 Certificaten, Bearer Tokens, Authentifikatiounsproxy, HTTP Basic Auth. Mat dëse Mechanismen kënnt Dir eng grouss Zuel vun Autorisatiounsschemaen ëmsetzen: vun enger statesch Datei mat Passwuert op OpenID OAuth2.

Ausserdeem ass et méiglech verschidde Autorisatiounsschemaen gläichzäiteg ze benotzen. Par défaut benotzt de Cluster:

• Service Kont Tokens - fir Service Konten;
• X509 - fir Benotzer.

D'Fro iwwer d'Gestioun vun ServiceAccounts ass iwwer den Ëmfang vun dësem Artikel, awer fir déi, déi sech mat dësem Thema méi detailléiert vertraut wëllen, recommandéieren ech mat offiziell Dokumentatioun Säiten. Mir wäerten e méi enk kucken op d'Fro wéi X509 Certificaten funktionnéieren.

Certificaten fir Benotzer (X.509)

De klassesche Wee fir mat Certificaten ze schaffen ëmfaasst:

• Schlëssel Generatioun:

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

• eng Zertifika Ufro generéieren:

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

• d'Veraarbechtung vun enger Zertifika Ufro mat de Kubernetes Cluster CA Schlësselen, e Benotzerzertifika ze kréien (fir e Certificat ze kréien, musst Dir e Kont benotzen deen Zougang zum Kubernetes Cluster CA Schlëssel huet, deen par défaut an /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

• eng Konfiguratiounsdatei erstellen:
  • Clusterbeschreiwung (spezifizéieren d'Adress an d'Plaz vun der CA Zertifikatdatei fir eng spezifesch Clusterinstallatioun):

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

  • oder wéi Netrecommandéiert Optioun - Dir musst de Root Zertifikat net spezifizéieren (da kontrolléiert kubectl d'Korrektheet vum Api-Server vum Cluster net):

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

  • e Benotzer an d'Konfiguratiounsdatei derbäisetzen:

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

  • Kontext addéieren:

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

  • Standard Kontext Aufgab:

    kubectl config use-context mynewuser-context

No der uewen Manipulatiounen, an der Datei .kube/config eng Configuratioun wéi dës gëtt erstallt:

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

Fir et méi einfach ze maachen d'Konfiguratioun tëscht Konten a Serveren ze transferéieren, ass et nëtzlech d'Wäerter vun de folgende Schlësselen z'änneren:

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

Fir dëst ze maachen, kënnt Dir d'Dateien, déi an hinnen spezifizéiert sinn, mat der Basis64 kodéieren an se an der Configuratioun registréieren, andeems Dir de Suffix zum Numm vun de Schlësselen bäidréit -data, d.h. kritt hunn certificate-authority-data an dergläichen.

Certificaten mat kubeadm

Mat der Verëffentlechung Kubernetes 1.15 mat Certificaten ze schaffen ass vill méi einfach ginn dank der Alpha Versioun vu senger Ënnerstëtzung an kubeadm Utility. Zum Beispill, dëst ass wéi eng Konfiguratiounsdatei mat Benotzerschlëssel generéiere kéint elo ausgesinn:

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

NB: néideg Annonce Adress kann an der api-Server Config fonnt ginn, déi par défaut läit an /etc/kubernetes/manifests/kube-apiserver.yaml.

Déi resultéierend Configuratioun gëtt op stdout erausginn. Et muss gespäichert ginn an ~/.kube/config Benotzerkont oder op eng Datei an enger Ëmfeldvariabel spezifizéiert KUBECONFIG.

Grab méi déif

Fir déi, déi d'Problemer méi grëndlech beschriwwe wëllen verstoen:

• getrennten Artikel op Aarbecht mat Certificaten an der offizieller Kubernetes Dokumentatioun;
• gudden Artikel aus Bitnami, an deem d’Zertifikater aus enger praktescher Perspektiv beréiert ginn.
• allgemeng Dokumentatioun op Authentifikatioun an Kubernetes.

Autorisatioun

De Standard autoriséierte Kont huet keng Rechter fir um Cluster ze bedreiwen. Fir Permissiounen ze ginn, implementéiert Kubernetes en Autorisatiounsmechanismus.

Virun der Versioun 1.6 benotzt Kubernetes en Autorisatiounstyp genannt ABAC (Attributer-baséiert Zougang Kontroll). Detailer doriwwer fannt Dir an offiziell Dokumentatioun. Dës Approche gëtt de Moment als Legacy ugesinn, awer Dir kënnt et nach ëmmer niewent aner Authentifikatiounstypen benotzen.

Déi aktuell (a méi flexibel) Manéier fir Zougangsrechter zu engem Cluster opzedeelen gëtt genannt RBAC (Roll-baséiert Zougangskontroll). Et ass stabil deklaréiert zënter Versioun Kubernetes 1.8. RBAC implementéiert e Rechtermodell an deem alles wat net explizit erlaabt ass verbueden ass.
Fir RBAC z'aktivéieren, Dir musst Kubernetes api-Server mam Parameter starten --authorization-mode=RBAC. D'Parameteren sinn am Manifest mat der api-Server Konfiguratioun gesat, déi par défaut laanscht de Wee läit /etc/kubernetes/manifests/kube-apiserver.yaml, an der Rubrik command. Wéi och ëmmer, RBAC ass scho par défaut aktivéiert, sou datt Dir Iech wahrscheinlech keng Suergen doriwwer maache sollt: Dir kënnt dëst mam Wäert verifizéieren authorization-mode (an der schonn ernimmt kube-apiserver.yaml). Iwwregens, ënner senge Bedeitunge kënnen et aner Aarte vun Autorisatioun ginn (node, webhook, always allow), mä mir wäerten hir Iwwerleeung ausserhalb vum Ëmfang vum Material loossen.

Mir hunn iwwregens schonn publizéiert Artikel mat enger zimlech detailléiert Beschreiwung vun de Prinzipien an Fonctiounen vun schaffen mat RBAC, sou weider wäert ech mech op eng kuerz Oplëschtung vun de Grondlage an Beispiller limitéieren.

Déi folgend API Entitéite gi benotzt fir Zougang zu Kubernetes iwwer RBAC ze kontrolléieren:

• Role и ClusterRole - Rollen déi déngen fir Zougangsrechter ze beschreiwen:
• Role erlaabt Iech Rechter bannent engem Nummraum ze beschreiwen;
• ClusterRole - am Cluster, inklusiv Clusterspezifesch Objekter wéi Noden, Net-Ressource URLen (dh net mat Kubernetes Ressourcen verbonnen - zum Beispill, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - benotzt fir Bindung Role и ClusterRole zu engem Benotzer, Benotzergrupp oder ServiceAccount.

D'Roll an d'RoleBinding Entitéite si limitéiert duerch Nummraum, d.h. muss am selwechte Nummraum sinn. Wéi och ëmmer, e RoleBinding kann e ClusterRole referenzéieren, wat Iech erlaabt eng Rei vu generesche Permissiounen ze kreéieren an den Zougang mat hinnen ze kontrolléieren.

Rollen beschreiwen Rechter mat Sets vu Reegelen déi enthalen:

• API Gruppen - gesinn offiziell Dokumentatioun vun apiGroups an Ausgang kubectl api-resources;
• Ressourcen (Ressourcen: pod, namespace, deployment a sou weider.);
• Verben (Verben: set, update an dergläichen).
• Ressource Nimm (resourceNames) - fir de Fall wou Dir Zougang zu enger spezifescher Ressource muss ubidden, an net op all Ressourcen vun dësem Typ.

Eng méi detailléiert Analyse vun der Autorisatioun an Kubernetes kann op der Säit fonnt ginn offiziell Dokumentatioun. Amplaz (oder éischter, zousätzlech zu dësem), wäert ech Beispiller ginn, déi hir Aarbecht illustréieren.

Beispiller vu RBAC Entitéiten

Einfach Role, wat Iech erlaabt eng Lëscht a Status vu Pods ze kréien an se am Nummraum ze iwwerwaachen 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"]

Beispill: ClusterRole, wat Iech erlaabt eng Lëscht a Status vu Pods ze kréien an se am ganze Cluster ze iwwerwaachen:

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

Beispill: RoleBinding, wat de Benotzer erlaabt mynewuser "liesen" Pods am Nummraum 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

Event Audit

Schematesch kann d'Kubernetes Architektur wéi follegt vertruede sinn:

De Schlëssel Kubernetes Komponent verantwortlech fir d'Veraarbechtung vun Ufroen ass api-Server. All Operatiounen um Cluster ginn duerch. Dir kënnt méi iwwer dës intern Mechanismen am Artikel liesen "Wat geschitt a Kubernetes wann Dir kubectl Run leeft?".

System Audit ass eng interessant Feature a Kubernetes, déi als Standard deaktivéiert ass. Et erlaabt Iech all Uruff un der Kubernetes API ze protokolléieren. Wéi Dir kéint roden, ginn all Aktiounen am Zesummenhang mat der Iwwerwaachung an der Ännerung vum Zoustand vum Cluster duerch dës API duerchgefouert. Eng gutt Beschreiwung vu senge Fäegkeeten kann (wéi gewinnt) fonnt ginn offiziell Dokumentatioun k8s. Als nächst wäert ech probéieren d'Thema an enger méi einfacher Sprooch ze presentéieren.

An dofir, Audit z'erméiglechen, musse mir dräi erfuerderlech Parameteren un de Container am Api-Server passéieren, déi hei ënnen méi detailléiert beschriwwe ginn:

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

Zousätzlech zu dësen dräi noutwendege Parameteren, ginn et vill zousätzlech Astellungen am Zesummenhang mat Audit: vu Logrotatioun bis Webhookbeschreiwungen. Beispill vu Logrotatiounsparameter:

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

Awer mir wäerte se net méi am Detail ophalen - Dir kënnt all Detailer fannen kube-apiserver Dokumentatioun.

Wéi scho gesot, sinn all Parameteren am Manifest mat der API-Server Konfiguratioun gesat (par défaut /etc/kubernetes/manifests/kube-apiserver.yaml), an der Rubrik command. Loosst eis zréck op déi 3 erfuerderlech Parameteren an analyséieren se:

1. audit-policy-file - Wee fir d'YAML Datei déi d'Auditpolitik beschreift. Mir wäerte spéider op säin Inhalt zréckkommen, awer fir de Moment wäert ech feststellen datt d'Datei vum Api-Server-Prozess liesbar muss sinn. Dofir ass et néideg et am Container ze montéieren, fir deen Dir de folgende Code an déi entspriechend Sektioune vun der Konfiguratioun addéiere kënnt:

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

2. audit-log-path - Wee zu der Log Datei. De Wee muss och zougänglech sinn fir den Api-Server Prozess, sou datt mir seng Montage op déiselwecht Manéier beschreiwen:

     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 Log Format. De Standard ass json, awer de legacy Textformat ass och verfügbar (legacy).

Audit Politik

Elo iwwer déi erwähnt Datei déi d'Protokollpolitik beschreift. Dat éischt Konzept vun der Auditpolitik ass level, aloggen Niveau. Si sinn wéi follegt:

• None - net aloggen;
• Metadata - Log Ufro Metadaten: Benotzer, Ufro Zäit, Zilressource (Pod, Nummraum, etc.), Handlungstyp (Verb), asw.;
• Request - Log Metadaten an Ufro Kierper;
• RequestResponse - Log Metadaten, Ufro Kierper an Äntwert Kierper.

Déi lescht zwee Niveauen (Request и RequestResponse) protokolléiert keng Ufroen déi net Zougang zu Ressourcen hunn (Zougäng op sougenannte Net-Ressource URLen).

Och all Ufroe ginn duerch puer Etappen:

• RequestReceived - d'Etapp wou d'Ufro vum Prozessor kritt gëtt an nach net weider an der Kette vun de Prozessoren iwwerdroe gouf;
• ResponseStarted - Äntwert Header ginn geschéckt, awer ier d'Äntwert Kierper geschéckt gëtt. Generéiert fir laang Lafen Ufroen (zum Beispill, watch);
• ResponseComplete - d'Äntwert Kierper gouf geschéckt, keng méi Informatiounen wäert geschéckt ginn;
• Panic - Eventer ginn generéiert wann eng anormal Situatioun festgestallt gëtt.

Fir all Schrëtt ze sprangen déi Dir benotze kënnt omitStages.

An enger Politikdatei kënne mir verschidde Sektioune mat verschiddene Logbicher beschreiwen. Déi éischt passende Regel, déi an der Politikbeschreiwung fonnt gëtt, gëtt applizéiert.

De Kubelet-Daemon iwwerwaacht Ännerungen am Manifest mat der Api-Server Konfiguratioun an, wann iergendeen erkannt ginn, start de Container mat Api-Server. Awer et gëtt e wichtegen Detail: Ännerungen an der Politik Fichier wäert vun et ignoréiert ginn. Nodeems Dir Ännerunge vun der Politikdatei gemaach hutt, musst Dir den API-Server manuell nei starten. Zënter api-Server gëtt als statesch Pod, Equipe kubectl delete wäert et net nei starten. Dir musst et manuell maachen docker stop op Kube-Masters, wou d'Auditpolitik geännert gouf:

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

Wann Dir Audit aktivéiert, ass et wichteg dat ze erënneren d'Laascht op kube-apiserver erhéicht. Besonnesch vergréissert Erënnerung Konsum fir raumen Ufro Kontext. Logging fänkt eréischt no der Äntwert Header geschéckt gëtt. D'Laascht hänkt och vun der Auditpolitik Konfiguratioun of.

Beispiller vu Politik

Loosst eis d'Struktur vu Politikdateien mat Beispiller kucken.

Hei ass eng einfach Datei policyfir alles um Niveau ze protokolléieren Metadata:

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

An der Politik kënnt Dir eng Lëscht vun de Benotzer uginn (Users и ServiceAccounts) a Benotzergruppen. Zum Beispill, dëst ass wéi mir de System Benotzer ignoréieren, awer alles anescht um Niveau aloggen 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

Et ass och méiglech d'Ziler ze beschreiwen:

• Nummraim (namespaces);
• Verben (Verben: get, update, delete an anerer);
• Ressourcen (Ressourcenan nämlech: pod, configmaps etc.) a Ressourcegruppen (apiGroups).

Opgepasst! Ressourcen a Ressourcegruppen (API Gruppen, dh apiGroups), souwéi hir Versiounen, déi am Cluster installéiert sinn, kënne mat de Kommandoen kritt ginn:

kubectl api-resources
kubectl api-versions

Déi folgend Auditpolitik gëtt als Demonstratioun vu beschten Praktiken zur Verfügung gestallt Alibaba Cloud Dokumentatioun:

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

En anert gutt Beispill vun der Auditpolitik ass Profil benotzt am GCE.

Fir séier op Auditevenementer z'äntwerten, ass et méiglech beschreiwen webhook. Dëst Thema ass ofgedeckt offiziell Dokumentatioun, Ech loossen et ausserhalb vum Kader vun dësem Artikel.

Resultater

Den Artikel gëtt en Iwwerbléck iwwer Basis Sécherheetsmechanismen a Kubernetes Cluster, déi Iech erlaben personaliséiert Benotzerkonten ze kreéieren, hir Rechter ze trennen an hir Handlungen opzehuelen. Ech hoffen et wäert nëtzlech sinn fir déi, déi mat esou Themen an der Theorie oder an der Praxis konfrontéiert sinn. Ech recommandéieren och datt Dir d'Lëscht vun anere Materialien iwwer d'Thema Sécherheet am Kubernetes liest, déi am "PS" uginn ass - vläicht ënnert hinnen fannt Dir déi néideg Detailer iwwer d'Problemer déi Iech relevant sinn.

PS

Liest och op eisem Blog:

• «33+ Kubernetes Sécherheetsinstrumenter";
• «Eng Aféierung zu Kubernetes Netzwierkpolitike fir Sécherheetsprofesser";
• «RBAC zu Kubernetes verstoen";
• «9 Beschte Praktiken fir Kubernetes Sécherheet";
• «11 Weeër fir (net) Affer vun engem Kubernetes Hack ze ginn".

Source: will.com