Sicherheitsgrundlagen in Kubernetes: Authentifizierung, Autorisierung, Audit

Früher oder später stellt sich bei der Verwendung eines jeden Systems die Frage nach der Sicherheit: Gewährleistung der Authentifizierung, Trennung von Rechten, Audit und anderen Aufgaben. Für Kubernetes gibt es bereits eine Vielzahl von Lösungen, die es ermöglichen, die Standards sogar in sehr anspruchsvollen Umgebungen einzuhalten… Dieses Material befasst sich mit den grundlegenden Aspekten der Sicherheit, die im Rahmen der integrierten Mechanismen von K8s umgesetzt sind. Es ist in erster Linie für diejenigen nützlich, die mit Kubernetes beginnen – als Ausgangspunkt für die Erarbeitung sicherheitsrelevanter Fragen.

Authentifizierung

In Kubernetes gibt es zwei Arten von Benutzern:

• Service Accounts – Konten, die über die Kubernetes API verwaltet werden;
• Users – „normale“ Benutzer, die von externen, unabhängigen Diensten verwaltet werden.

Der Hauptunterschied zwischen diesen Typen besteht darin, dass es für Service Accounts spezielle Objekte in der Kubernetes API gibt (sie heißen genau so – ServiceAccounts), die an einen Namensraum und ein Set von Authentifizierungsdaten gebunden sind, die im Cluster in Objekten vom Typ Secrets gespeichert sind. Solche Benutzer (Service Accounts) sind hauptsächlich für die Verwaltung der Zugriffsrechte für Prozesse, die im Kubernetes-Cluster laufen, bestimmt.

Reguläre Users haben keine Einträge in der Kubernetes API: Ihre Verwaltung muss über externe Mechanismen erfolgen. Sie sind für Menschen oder Prozesse gedacht, die außerhalb des Clusters leben.

Jede Anfrage an die API ist entweder an ein Service Account, an einen User oder anonym.

Die Authentifizierungsdaten eines Benutzers umfassen:

• Benutzername – Benutzername (unterscheidet zwischen Groß- und Kleinschreibung!);
• UID – ein maschinenlesbarer Identifikationsstring, der "konsistenter und einzigartiger ist als der Benutzername";
• Gruppen – eine Liste von Gruppen, zu denen der Benutzer gehört;
• Extra – zusätzliche Felder, die von dem Autorisierungsmechanismus verwendet werden können.

Kubernetes kann eine Vielzahl von Authentifizierungsmechanismen nutzen: X509-Zertifikate, Bearer-Tokens, authentifizierende Proxys, HTTP Basic Auth. Mit diesen Mechanismen lassen sich zahlreiche Autorisierungsschemata realisieren: von einer statischen Datei mit Passwörtern bis hin zu OpenID OAuth2.

Darüber hinaus ist die gleichzeitige Nutzung mehrerer Autorisierungsschemata zulässig. Standardmäßig werden im Cluster verwendet:

• Service Account-Tokens – für Service Accounts;
• X509 – für Users.

Die Frage zur Verwaltung von ServiceAccounts geht über den Rahmen dieses Artikels hinaus. Ich empfehle Interessierten, die offiziellen Dokumentationsseite zu konsultieren, um mehr über dieses Thema zu erfahren. offiziellen Dokumentation. Wir werden die Funktionsweise von X.509-Zertifikaten näher untersuchen.

Zertifikate für Benutzer (X.509)

Die klassische Vorgehensweise bei der Arbeit mit Zertifikaten beinhaltet:

• Generierung eines Schlüssels:

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

• Generierung einer Zertifikatsanforderung:

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

• Verarbeitung der Zertifikatsanforderung mit den CA-Schlüsseln des Kubernetes-Clusters, um ein Benutzerzertifikat zu erhalten (zum Erhalt des Zertifikats muss ein Konto verwendet werden, das Zugriff auf den Schlüssel der Zertifizierungsstelle des Kubernetes-Clusters hat, der sich standardmäßig in /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/mynewuser.crt -days 500

• Erstellung einer Konfigurationsdatei:
  • Beschreibung des Clusters (geben Sie die Adresse und den Speicherort der CA-Zertifikatsdatei der jeweiligen Clusterinstallation an):

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

  • oder — als nichtempfohlene Variante — es kann der Root-Zertifikat nicht angegeben werden (in diesem Fall wird kubectl die Genauigkeit des API-Servers des Clusters nicht überprüfen):

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

  • Hinzufügen eines Benutzers zur Konfigurationsdatei:

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

  • Hinzufügen eines Kontexts:

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

  • Festlegung des Standardkontexts:

    kubectl config use-context mynewuser-context

Nach den oben beschriebenen Vorgängen wird die Konfigurationsdatei folgende Form haben: .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

Um den Transfer der Konfiguration zwischen Konten und Servern zu erleichtern, ist es sinnvoll, die Werte der folgenden Schlüssel zu bearbeiten:

certificate-authority

• client-certificate
• client-key
• Zu diesem Zweck können die angegebenen Dateien mit base64 kodiert und in die Konfiguration eingetragen werden, indem Sie dem Schlüsselname das Suffix

-data hinzufügen, d.h. erhaltencertificate-authority-data usw. Zertifikate mit kubeadm

Mit der Version

Kubernetes 1.15 Kubernetes 1.15 Die Arbeit mit Zertifikaten ist dank der Alpha-Version ihrer Unterstützung in dem Tool kubeadm. Zum Beispiel könnte die Generierung einer Konfigurationsdatei mit Benutzerschlüsseln jetzt so aussehen:

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

NB: Erforderliche Werbung Adresse kann in der Konfiguration des API-Servers eingesehen werden, die standardmäßig unter /etc/kubernetes/manifests/kube-apiserver.yaml.

Der resultierende Konfig wird in stdout ausgegeben. Er muss in ~/.kube/config dem Benutzerkonto oder in der Datei, die in der Umgebungsvariable KUBECONFIG.

Tiefer graben

Für diejenigen, die sich eingehender mit den beschriebenen Fragen beschäftigen möchten:

• einen eigenen Artikel zur Arbeit mit Zertifikaten in der offiziellen Kubernetes-Dokumentation;
• ein guter Artikel von Bitnami, in dem das Thema der Zertifikate aus praktischer Sicht behandelt wird.
• allgemeine Dokumentation zur Authentifizierung in Kubernetes.

Autorisierung

Das autorisierte Konto hat standardmäßig keine Berechtigungen für Aktionen im Cluster. Um Berechtigungen in Kubernetes zu erteilen, wurde ein Autorisierungsmechanismus implementiert.

Bis zur Version 1.6 wurde in Kubernetes ein Autorisierungstyp namens ABAC (Attributbasierte Zugriffskontrolle) verwendet. Details dazu finden Sie in offiziellen Dokumentation. Momentan wird dieser Ansatz als veraltet (legacy) angesehen, jedoch können Sie ihn immer noch zusammen mit anderen Autorisierungstypen verwenden.

Der aktuelle (und flexiblere) Ansatz zur Aufteilung von Zugriffsrechten im Cluster heißt RBAC (Rollenbasierte Zugriffskontrolle). Er wurde mit der Version Kubernetes 1.8stabil erklärt. RBAC implementiert ein Berechtigungsmodell, in dem alles, was nicht ausdrücklich erlaubt ist, verboten ist.
Um RBAC zu aktivieren, müssen Sie den Kubernetes API-Server mit dem Parameter --authorization-mode=RBACstarten. Die Parameter werden im Manifest des API-Servers festgelegt, das standardmäßig unter dem Pfad /etc/kubernetes/manifests/kube-apiserver.yamlin der Sektion command. Übrigens ist RBAC standardmäßig bereits aktiviert, daher müssen Sie sich wahrscheinlich keine Sorgen darüber machen: Sie können sich über den Wert authorization-mode (in der bereits erwähnten kube-apiserver.yaml). Übrigens können unter seinen Werten auch andere Autorisierungstypen auftauchen (node, webhook, always allow), aber die Betrachtung dieser lassen wir im Rahmen des Materials zurück.

Übrigens haben wir bereits veröffentlicht einen Artikel mit einem recht detaillierten Bericht über die Prinzipien und Merkmale der Arbeit mit RBAC, daher beschränke ich mich im Folgenden auf eine kurze Aufzählung der Grundlagen und Beispiele.

Für die Verwaltung des Zugriffs in Kubernetes über RBAC werden die folgenden API-Entitäten verwendet:

• Rolle und Clusterrolle – Rollen, die zur Beschreibung von Zugriffsrechten dienen:
• Rolle erlaubt es, Rechte innerhalb eines Namensraums zu beschreiben;
• Clusterrolle – im Rahmen eines Clusters, einschließlich cluster-spezifischer Objekte wie Knoten, non-resources URLs (d.h. nicht mit Kubernetes-Ressourcen verbunden – beispielsweise, /version, /logs, /api*);
• RoleBinding und ClusterRoleBinding – dient zur Bindung Rolle und Clusterrolle an einen Benutzer, eine Benutzergruppe oder ein ServiceAccount.

Die Entitäten Role und RoleBinding sind namespacespezifisch, d.h. sie müssen innerhalb eines Namensraums liegen. RoleBinding kann jedoch auf ClusterRole verweisen, was es ermöglicht, eine Menge Standardberechtigungen zu erstellen und den Zugriff damit zu verwalten.

Rollen beschreiben Rechte mithilfe von Regel-Sets, die Folgendes enthalten:

• API-Gruppen – siehe offizielle Dokumentation zu apiGroups und Ausgabe kubectl api-resources;
• Ressourcen (resources: Pod, Namespace, deployment usw.);
• Verben (verbs: set, update usw.).
• Ressourcennamen (resourceNames) – für den Fall, dass Zugriff auf eine bestimmte Ressource gewährt werden soll, und nicht auf alle Ressourcen dieses Typs.

Eine detailliertere Analyse der Autorisierung in Kubernetes finden Sie auf der Seite offiziellen Dokumentation. Stattdessen (oder besser gesagt – zusätzlich dazu) gebe ich Beispiele, die ihre Funktionsweise veranschaulichen.

Beispiele für RBAC-Entitäten

Einfach Rolle, die es ermöglicht, eine Liste von Pods und ihren Status im Namespace zu erhalten und sie zu überwachen 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"]

Beispiel Clusterrolle, was es ermöglicht, eine Liste von Pods und ihren Status im gesamten Cluster zu erhalten und sie zu überwachen:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # die Sektion "namespace" fehlt, da ClusterRole den gesamten Cluster nutzt
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Beispiel RoleBinding, was es dem Benutzer ermöglicht, mynewuser „Pods“ im Namespace zu „lesen“ my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # Benutzername ist von der Groß- und Kleinschreibung abhängig!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # hier muss „Role“ oder „ClusterRole“ stehen
  name: pod-reader # Name der Role, die im selben Namespace liegt,
                   # oder Name der ClusterRole, deren Nutzung
                   # wir dem Benutzer erlauben möchten
  apiGroup: rbac.authorization.k8s.io

Ereignisprüfung

Die Architektur von Kubernetes kann schematisch wie folgt dargestellt werden:

Die zentrale Komponente von Kubernetes, die für die Bearbeitung von Anfragen zuständig ist – api-server. Alle Operationen am Cluster erfolgen über ihn. Mehr über diese internen Mechanismen findet man in dem Artikel „Was passiert in Kubernetes, wenn kubectl run ausgeführt wird?».

Das Auditing-System ist eine interessante Funktion in Kubernetes, die standardmäßig deaktiviert ist. Es ermöglicht das Protokollieren aller Anfragen an die Kubernetes-API. Wie man sich leicht denken kann, werden über diese API alle Aktionen zur Überwachung und Änderung des Zustands des Clusters durchgeführt. Eine gute Beschreibung ihrer Möglichkeiten findet man (wie immer) in offiziellen Dokumentation K8s. Im Folgenden werde ich versuchen, das Thema einfacher zu erklären.

Also, Um das Auditing zu aktivieren,müssen wir dem Container im API-Server drei erforderliche Parameter übergeben, die weiter unten erläutert werden:

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

Neben diesen drei notwendigen Parametern gibt es viele zusätzliche Einstellungen, die sich auf das Auditing beziehen: von der Protokollrotation bis hin zu Beschreibungen für Webhooks. Beispiel für Protokollrotationsparameter:

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

Aber wir wollen nicht näher darauf eingehen – alle Details können in der Dokumentation zum kube-apiserver.

Wie bereits erwähnt, werden alle Parameter im Manifest mit der Konfiguration des API-Servers festgelegt (standardmäßig /etc/kubernetes/manifests/kube-apiserver.yaml), im Abschnitt command. Kommen wir zurück zu den drei erforderlichen Parametern und betrachten wir diese genauer:

1. audit-policy-file – der Pfad zur YAML-Datei mit der Beschreibung der Audit-Policy. Auf den Inhalt werden wir später zurückkommen, aber zunächst sei darauf hingewiesen, dass die Datei für den Prozess des API-Servers lesbar sein muss. Daher muss sie in den Container gemountet werden, wofür folgender Code in die entsprechenden Abschnitte der Konfiguration eingefügt werden kann:

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

2. audit-log-path – der Pfad zur Protokolldatei. Der Pfad muss auch für den Prozess des API-Servers verfügbar sein, daher beschreiben wir ähnlich das Mounting:

     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 – das Format des Audit-Logs. Standardmäßig ist dies json, aber es ist auch ein veraltetes Textformat verfügbar (legacy).

Audit-Policy

Jetzt zu der erwähnten Datei mit der Beschreibung der Protokollierungsrichtlinien. Der erste Begriff der Audit-Policy ist das level, Protokollierungsniveau. Es gibt folgende Möglichkeiten:

• None – nicht protokollieren;
• Metadata – Metadaten der Anfrage protokollieren: Benutzer, Anfragetime, Zielressource (Pod, Namespace usw.), Aktionstyp (Verb) usw.;
• Request – Metadaten und den Inhalt der Anfrage protokollieren;
• RequestResponse — Metadaten, Anfrageinhalt und Antwortinhalt protokollieren.

Die letzten beiden Ebenen (Request und RequestResponse) protokollieren keine Anfragen, die sich nicht an Ressourcen gewandt haben (Zugriffe auf sogenannte Non-Resource-URLs).

Alle Anfragen durchlaufen auch mehrere Phasen:

• RequestReceived — Die Phase, in der die Anfrage vom Handler empfangen wird und noch nicht an die nächste Stage weitergegeben wurde;
• ResponseStarted — Die Antwort-Header wurden gesendet, aber bevor der Antwortinhalt gesendet wird. Wird für lang laufende Anfragen erzeugt (z.B. beobachten);
• ResponseComplete — Der Antwortinhalt wurde gesendet, es werden keine weiteren Informationen gesendet;
• Panic — Ereignisse werden generiert, wenn eine Ausnahme auftritt.

Um bestimmte Phasen auszuschließen, kann man omitStages.

In der Richtlinien-Datei können wir mehrere Abschnitte mit unterschiedlichen Protokollierungsebenen beschreiben. Es wird die erste passende Regel angewendet, die in der Beschreibung der Richtlinie gefunden wird.

Der Kubelet-Daemon überwacht Änderungen am Manifest mit der api-server-Konfiguration und startet den Container mit api-server neu, wenn solche entdeckt werden. Es gibt jedoch eine wichtige Einzelheit: Änderungen in der Richtlinie werden dabei ignoriert. Nach Änderungen an der Richtlinien-Datei muss der api-server manuell neu gestartet werden. Da der api-server als statisches Podgestartet wird, wird der Befehl kubectl delete nicht zu einem Neustart führen. Man muss manuell docker stop auf den Kube-Mastern durchführen, auf denen die Audit-Richtlinie geändert wurde:

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

Beim Aktivieren des Audits ist es wichtig zu beachten, dass die Last auf dem kube-apiserver steigt. Insbesondere steigt der Speicherverbrauch zur Speicherung des Anfragekontextes. Das Protokollieren beginnt erst nach dem Senden des Antwort-Headers. Auch die Last hängt von der Konfiguration der Auditrichtlinie ab.

Beispiele für Richtlinien

Lassen Sie uns die Struktur der Richtlinien-Dateien anhand von Beispielen betrachten.

Hier ist eine einfache Datei, um alles auf der Ebene zu protokollieren policy, Metadata:

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

In der Richtlinie kann eine Liste von Benutzern (Users und ServiceAccounts) und Benutzergruppen angegeben werden. Zum Beispiel werden wir in dieser Weise systemeigene Benutzer ignorieren, aber alles andere auf der Ebene protokollieren. 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

Es gibt auch die Möglichkeit, Ziel:

• Namensräume (namespaces);
• Verben (verbs: get, update, delete und andere);
• Ressourcen (resources, nämlich: Pod, configmaps usw.) und Ressourcengruppen (apiGroups).

Bitte beachten Sie! Ressourcen und Ressourcengruppen (API-Gruppen, d.h. apiGroups) sowie deren Versionen, die im Cluster installiert sind, können mit den folgenden Befehlen abgerufen werden:

kubectl api-resources
kubectl api-versions

Die folgende Audit-Policy dient als Demonstration bewährter Praktiken in der Dokumentation von Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Nicht das Stadium RequestReceived protokollieren
omitStages:
  - "RequestReceived"
rules:
  # Nicht protokollieren von Ereignissen, die als unwesentlich und ungefährlich gelten:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # dies ist die API-Gruppe mit leerem Namen, zu der gehören
                  # die Basismittel von Kubernetes, die „core“ genannt werden
        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"]
  # Nicht protokollieren von Zugriffen auf read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Nicht protokollieren von Meldungen, die sich auf Ressourcen vom Typ „Ereignisse“ beziehen:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ressourcen vom Typ Secret, ConfigMap und TokenReview können geheime Daten enthalten,
  # daher protokollieren wir nur die Metadaten der zugehörigen Anfragen
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Aktionen wie get, list und watch können ressourcenintensiv sein; wir protokollieren sie nicht
  - 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"
  # Standardprotokollierungsniveau für Standard-API-Ressourcen
  - 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"
  # Standardprotokollierungsniveau für alle anderen Anfragen
  - level: Metadata

Ein weiteres gutes Beispiel für eine Audit-Policy ist das Profil, das in GCE verwendet wird.

Um auf Ereignisse im Audit schnell zu reagieren, besteht die Möglichkeit einen Webhook zu beschreiben. Dieses Thema wird behandelt in offiziellen Dokumentation, ich lasse es außerhalb dieses Artikels.

Ergebnisse

Der Artikel bietet einen Überblick über die Mechanismen der grundlegenden Sicherheitsanforderungen in Kubernetes-Clustern, die es ermöglichen, personalisierte Benutzerkonten zu erstellen, ihre Berechtigungen zu trennen und ihre Handlungen zu protokollieren. Ich hoffe, es ist hilfreich für diejenigen, die mit solchen Fragen in der Theorie oder bereits in der Praxis konfrontiert wurden. Ich empfehle auch, sich die Liste anderer Materialien zum Thema Sicherheit in Kubernetes anzusehen, die in „P.S.“ aufgeführt ist – möglicherweise findet sich darunter das, was Sie für Ihre aktuellen Probleme benötigen.

P.S.

Lesen Sie auch in unserem Blog:

• «33+ Tools für die Sicherheit von Kubernetes»;
• «Einführung in die Netzwerkrichtlinien von Kubernetes für Sicherheitsexperten»;
• «RBAC in Kubernetes verstehen»;
• «9 beste Praktiken für die Sicherheit in Kubernetes»;
• «11 Wege, wie man (nicht) Opfer eines Hacks in Kubernetes wird».

Quelle: habr.com