Schützen Ihres Clusters mittels Podsicherheitsrichtlinie in Azure Kubernetes Service (AKS) (Vorschau)

  • Artikel

Wichtig

Das Feature für Podsicherheitsrichtlinien wurde am 1. August 2023 als veraltet festgelegt und aus den AKS-Versionen 1.25 und höher entfernt.

Es empfiehlt sich, zum Podsicherheits-Zugangscontroller oder zu Azure Policy zu migrieren, um weiterhin Azure-Support zu erhalten. Pod Security Admission ist eine integrierte Richtlinie für die Implementierung einzelner Cluster. Wenn Sie nach einer Unternehmensrichtlinie suchen, ist Azure Policy eine bessere Wahl.

Voraussetzungen

  • In diesem Artikel wird vorausgesetzt, dass Sie über einen AKS-Cluster verfügen. Wenn Sie einen AKS-Cluster benötigen, erstellen Sie einen mithilfe der Azure CLI, von Azure PowerShell oder des Azure-Portals.
  • Azure CLI-Version 2.0.61 oder höher muss installiert und konfiguriert sein. Führen Sie az --version aus, um die Version zu ermitteln. Wenn Sie die CLI installieren oder aktualisieren müssen, finden Sie die entsprechende Anleitung unter Installieren der Azure CLI.

Installieren der Azure CLI-Erweiterung aks-preview

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von den Vereinbarungen zum Service Level und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

  1. Installieren Sie die Erweiterung „aks-preview“ mithilfe des Befehls az extension add.

    az extension add --name aks-preview

  2. Führen Sie mit dem Befehl az extension update ein Update auf die neueste Version der Erweiterung aus.

    az extension update --name aks-preview

Registrieren des PodSecurityPolicyPreview-Featureflags

  1. Registrieren Sie das Featureflag PodSecurityPolicyPreview mithilfe des Befehls az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

    Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird.

  2. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

  3. Wenn der Zustand Registered (Registriert) lautet, aktualisieren Sie die Registrierung des Ressourcenanbieters Microsoft.ContainerService mithilfe des Befehls az provider register.

    az provider register --namespace Microsoft.ContainerService

Übersicht über Podsicherheitsrichtlinien

Kubernetes-Cluster verwenden Zugangscontroller, um an den API-Server gerichtete Anforderungen abzufangen, wenn eine Ressource erstellt werden soll. Die Zugangssteuerung kann dann die Ressourcenanforderung anhand einer Reihe von Regeln überprüfen oder die Ressource mutieren, um die Bereitstellungsparameter zu ändern.

PodSecurityPolicy ist eine Zugangssteuerung, die überprüft, ob eine Podspezifikation die von Ihnen definierten Anforderungen erfüllt. Diese Anforderungen schränken möglicherweise die Verwendung privilegierter Container, den Zugriff auf bestimmte Arten von Speicher oder die Benutzer/Gruppen ein, als die der Container ausgeführt werden kann. Wenn Sie versuchen, eine Ressource bereitzustellen, bei der die Podspezifikationen nicht die in der Podsicherheitsrichtlinie beschriebenen Anforderungen erfüllen, wird die Anforderung abgelehnt. Die Möglichkeit zu steuern, welche Pods im AKS-Cluster geplant werden können, beugt einigen möglichen Sicherheitsrisiken und Rechteausweitungen vor.

Wenn Sie Podsicherheitsrichtlinien in einem AKS-Cluster aktivieren, werden einige Standardrichtlinien angewendet. Diese Richtlinien sind sofort einsatzbereit und definieren, welche Pods geplant werden können. Es kann jedoch zu Problemen bei der Podbereitstellung kommen, solange Sie nicht Ihre eigenen Richtlinien definieren. Empfohlene Vorgehensweise:

  1. Erstellen Sie einen AKS-Cluster.
  2. Definieren Ihrer eigenen Podsicherheitsrichtlinien.
  3. Aktivieren Sie das Feature „Podsicherheitsrichtlinie“.

Verhaltensänderungen zwischen der Podsicherheitsrichtlinie und Azure Policy

Szenario Podsicherheitsrichtlinie Azure Policy
Installation Aktivieren des Podsicherheitsrichtlinien-Features Aktivieren des Azure Policy-Add-Ons
Bereitstellen von Richtlinien Bereitstellen der Podsicherheitsrichtlinien-Ressource Weisen Sie Azure-Richtlinien dem Abonnement- oder Ressourcengruppenbereich zu. Das Azure Policy-Add-On ist für Kubernetes-Ressourcenanwendungen erforderlich.
Standardrichtlinien Wenn die Podsicherheitsrichtlinie in AKS aktiviert ist, werden standardmäßig die Richtlinien „Privilegiert“ (Privileged) und „Uneingeschränkt“ (Unrestricted) angewendet. Durch die Aktivierung des Azure Policy-Add-Ons werden keine Standardrichtlinien angewendet. Sie müssen Richtlinien in Azure Policy explizit aktivieren.
Wer kann Richtlinien erstellen und zuweisen? Der Clusteradministrator erstellt eine Ressource für Podsicherheitsrichtlinien. Benutzer müssen in der AKS-Clusterressourcengruppe mindestens die Berechtigungen „Besitzer“ oder „Ressourcenrichtlinienmitwirkender“ aufweisen. – Über die API können Benutzer Richtlinien im Bereich der AKS-Clusterressourcen zuweisen. Der Benutzer sollte mindestens die Berechtigungen „Besitzer“ oder „Ressourcenrichtlinienmitwirkender" für die AKS-Clusterressource aufweisen. – Im Azure-Portal können Richtlinien auf Verwaltungsgruppen-, Abonnement- oder Ressourcengruppenebene angewendet werden.
Autorisierungsrichtlinien Benutzer und Dienstkonten benötigen explizite Berechtigungen zur Verwendung von Podsicherheitsrichtlinien. Für die Autorisierung von Richtlinien ist keine zusätzliche Zuweisung erforderlich. Nachdem Richtlinien in Azure zugewiesen wurden, können alle Clusterbenutzer diese Richtlinien verwenden.
Anwendbarkeit von Richtlinien Der Administratorbenutzer umgeht die Erzwingung von Podsicherheitsrichtlinien. Alle Benutzer (Administrator und Nicht-Administrator) sehen die gleichen Richtlinien. Es gibt keine spezielle Schreibweise auf der Basis von Benutzern. Die Anwendung von Richtlinien kann auf der Namespaceebene ausgeschlossen werden.
Geltungsbereich der Richtlinie Podsicherheitsrichtlinien sind keinem Namespace zugeordnet. Die von Azure Policy verwendeten Einschränkungsvorlagen sind keinem Namespace zugeordnet.
Deny/Audit/Mutation (Aktion) Podsicherheitsrichtlinien unterstützen nur Aktionen vom Typ „deny“. Die Mutation kann mit Standardwerten bei Erstellungsanforderungen erfolgen. Die Validierung kann während der Aktualisierungsanforderungen durchgeführt werden. Azure Policy unterstützt sowohl Aktionen vom Typ „audit“ als auch vom Typ „deny“. Mutationen werden noch nicht unterstützt.
Compliance von Sicherheitsrichtlinien Es gibt keine Transparenz hinsichtlich der Compliance von Pods, die vor der Aktivierung der Podsicherheitsrichtlinien existierten. Nicht konforme Pods, die nach der Aktivierung von Podsicherheitsrichtlinien erstellt wurden, werden verweigert. Nicht konforme Pods, die vor der Anwendung von Azure-Richtlinien existierten, würden in Richtlinienverletzungen angezeigt werden. Nicht konforme Pods, die nach der Aktivierung von Azure-Richtlinien erstellt wurden, werden verweigert, wenn Richtlinien mit einer Auswirkung vom Typ „deny“ festgelegt werden.
Anzeigen von Richtlinien für den Cluster kubectl get psp kubectl get constrainttemplate – Alle Richtlinien werden zurückgegeben.
Podsicherheitsrichtlinie (Standard): Privilegiert Beim Aktivieren des Features wird standardmäßig eine Sicherheitsrichtlinienressource für privilegierte Pods erstellt. Der privilegierte Modus impliziert keine Einschränkung, daher ist er gleichbedeutend mit keiner Azure Policy-Zuweisung.
Podsicherheitsrichtlinie (Standard): Baseline/Standard Der Benutzer installiert eine Baseline-Ressource der Podsicherheitsrichtlinie. Azure Policy bietet eine integrierte Baseline-Initiative, die sich an der Baseline-Richtlinie für Pods orientiert.
Podsicherheitsrichtlinie (Standard): Eingeschränkt Der Benutzer installiert eine eingeschränkte Ressource der Podsicherheitsrichtlinie. Azure Policy bietet eine integrierte eingeschränkte Initiative, die der eingeschränkten Podsicherheitsrichtlinie zugeordnet ist.

Aktivieren von Podsicherheitsrichtlinien für einen AKS-Cluster

Hinweis

In der Praxis sollte die Podsicherheitsrichtlinie erst aktiviert werden, nachdem Sie Ihre eigenen benutzerdefinierten Richtlinien definiert haben. In diesem Artikel wird die Podsicherheitsrichtlinie im ersten Schritt aktiviert, um zu zeigen, wie Podbereitstellungen durch die Standardrichtlinien eingeschränkt werden.

  • Aktivieren Sie die Podsicherheitsrichtlinie mit dem Befehl „az aks update“.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-pod-security-policy

AKS-Standardrichtlinien

Wenn Sie Podsicherheitsrichtlinien aktivieren, erstellt AKS eine Standardrichtlinie mit dem Namen privileged (Privilegiert). Die Standardrichtlinie darf nicht bearbeitet oder entfernt werden. Erstellen Sie stattdessen Ihre eigenen Richtlinien, um die Einstellungen zu definieren, die Sie steuern möchten. Befassen wir uns zunächst mit den Standardrichtlinien und ihren Auswirkungen auf Podbereitstellungen.

  1. Zeigen Sie die verfügbaren Richtlinien mit dem Befehl „kubectl get psp“ an.

    kubectl get psp

    Ihre Ausgabe ähnelt der folgenden Beispielausgabe:

    NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

    Die Podsicherheitsrichtlinie privileged gilt für alle authentifizierten Benutzer im AKS-Cluster. Diese Zuweisung wird von ClusterRoles und ClusterRoleBindings gesteuert.

  2. Suchen Sie mit dem Befehl „kubectl get rolebindings“ nach der Bindung default:privileged: im Namespace kube-system.

    kubectl get rolebindings default:privileged -n kube-system -o yaml

    Die folgende gekürzte Beispielausgabe zeigt, dass psp:privilegedClusterRole allen Benutzern vom Typ system:authenticated zugewiesen ist. Diese Funktionalität bietet eine einfache Berechtigungsebene, ohne dass Sie eigene Richtlinien definiert haben.

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  [...]
  name: default:privileged
  [...]
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:privileged
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

Es ist wichtig zu verstehen, wie diese Standardrichtlinien mit den Benutzeranforderungen für die Podplanung interagieren, bevor Sie mit der Erstellung Ihrer eigenen Podsicherheitsrichtlinien beginnen. In den nächsten Abschnitten werden einige Pods geplant, um die Auswirkungen der Standardrichtlinien zu veranschaulichen.

Erstellen eines Testbenutzers in einem AKS-Cluster

Wenn Sie den Befehl „az aks get-credentials“ verwenden, werden die Administratoranmeldeinformationen für den AKS-Cluster Ihrer kubectl-Konfiguration hinzugefügt. Der Administratorbenutzer umgeht die Erzwingung von Podsicherheitsrichtlinien. Wenn Sie für Ihre AKS-Cluster die Microsoft Entra-Integration verwenden, können Sie sich mit den Anmeldeinformationen eines Benutzers bzw. einer Benutzerin ohne Administratorrechte anmelden, um die Erzwingung von Richtlinien in Aktion zu sehen.

  1. Erstellen Sie mithilfe des Befehls kubectl create namespace einen Beispielnamespace namens psp-aks für Testressourcen.

    kubectl create namespace psp-aks

  2. Erstellen Sie mithilfe des Befehls „kubectl create serviceaccount ein Dienstkonto namens nonadmin-user.

    kubectl create serviceaccount --namespace psp-aks nonadmin-user

  3. Erstellen Sie mithilfe des Befehls „kubectl create rolebinding“ eine Rollenbindung für nonadmin-user, um grundlegende Aktionen im Namespace ausführen zu können.

    kubectl create rolebinding \
    --namespace psp-aks \
    psp-aks-editor \
    --clusterrole=edit \
    --serviceaccount=psp-aks:nonadmin-user

Erstellen von Aliasbefehlen für Administratorbenutzer und Benutzer ohne Administratorrechte

Wenn Sie kubectl verwenden, können Sie die Unterschiede zwischen dem regulären Administratorbenutzer und dem Nicht-Administratorbenutzer hervorheben, indem Sie zwei Befehlszeilenaliase erstellen:

  1. Der Alias kubectl-admin für den regulären Administratorbenutzer, der auf den Namespace psp-aks ausgerichtet ist.
  2. Der Alias kubectl-nonadminuser für den im vorherigen Schritt erstellten Benutzer ohne Administratorrechte (nonadmin-user), der auf den Namespace psp-aks ausgerichtet ist.

  • Erstellen Sie die beiden Aliase mit den folgenden Befehlen.

    alias kubectl-admin='kubectl --namespace psp-aks'
alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'

Testen der Erstellung eines privilegierten Pods

Testen Sie, was passiert, wenn Sie einen Pod mit dem Sicherheitskontext „privileged: true“ planen. Dieser Sicherheitskontext weitet die Podberechtigungen aus. Die AKS-Sicherheitsrichtlinie Standardberechtigungen sollte diese Anforderung ablehnen.

  1. Erstellen Sie eine Datei mit dem Namen „nginx-privileged.yaml“, und fügen Sie die Inhalte des folgenden YAML-Manifests ein.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged
spec:
  containers:
    - name: nginx-privileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        privileged: true

  2. Erstellen Sie den Pod mit dem Befehl „kubectl apply“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl-nonadminuser apply -f nginx-privileged.yaml

    Die folgende Beispielausgabe zeigt, dass der Pod nicht geplant werden konnte:

    Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []

    Da der Pod die Planungsphase nicht erreicht, müssen keine Ressourcen gelöscht werden, bevor Sie fortfahren.

Testen der Erstellung eines nicht privilegierten Pods

Im vorherigen Beispiel wurde durch die Podspezifikation eine Rechteausweitung angefordert. Diese Anforderung wird durch die standardmäßige Podsicherheitsrichtlinie privilege abgelehnt, sodass der Pod nicht geplant werden kann. Versuchen Sie, denselben NGINX-Pod ohne Anforderung der Rechteausweitung auszuführen.

  1. Erstellen Sie eine Datei mit dem Namen „nginx-unprivileged.yaml“, und fügen Sie die Inhalte des folgenden YAML-Manifests ein.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine

  2. Erstellen Sie den Pod mit dem Befehl „kubectl apply“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

    Die folgende Beispielausgabe zeigt, dass der Pod nicht geplant werden konnte:

    Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []

    Da der Pod die Planungsphase nicht erreicht, müssen keine Ressourcen gelöscht werden, bevor Sie fortfahren.

Testen der Erstellung eines Pods mit einem spezifischen Benutzerkontext

Im vorherigen Beispiel hat das Containerimage automatisch versucht, Stammberechtigungen zu verwenden, um NGINX an den Port 80 zu binden. Diese Anforderung wurde durch die standardmäßige Podsicherheitsrichtlinie privilege abgelehnt, sodass der Pod nicht gestartet werden kann. Versuchen Sie, denselben NGINX-Pod mit einem spezifischen Benutzerkontext (etwa runAsUser: 2000) auszuführen.

  1. Erstellen Sie eine Datei mit dem Namen „nginx-unprivileged-nonroot.yaml“, und fügen Sie das folgende YAML-Manifest ein.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged-nonroot
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        runAsUser: 2000

  2. Erstellen Sie den Pod mit dem Befehl „kubectl apply“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml

    Die folgende Beispielausgabe zeigt, dass der Pod nicht geplant werden konnte:

    Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []

    Da der Pod die Planungsphase nicht erreicht, müssen keine Ressourcen gelöscht werden, bevor Sie fortfahren.

Erstellen einer benutzerdefinierten Podsicherheitsrichtlinie

Nachdem Sie nun mit dem Verhalten der Standard-Podsicherheitsrichtlinien vertraut sind, erfahren Sie als Nächstes, wie Sie dem Benutzer ohne Administratorrechte (nonadmin-user) die erfolgreiche Planung von Pods ermöglichen.

Hierzu erstellen wir eine Richtlinie zur Ablehnung von Pods, die privilegierten Zugriff anfordern. Andere Optionen wie RunAsUser oder zulässige Volumes werden explizit nicht eingeschränkt. Diese Art von Richtlinie lehnt die Anforderung von privilegiertem Zugriff ab, lässt aber die Ausführung der angeforderten Pods durch den Cluster zu.

  1. Erstellen Sie eine Datei mit dem Namen „psp-deny-privileged.yaml“, und fügen Sie das folgende YAML-Manifest ein.

    apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp-deny-privileged
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
 - '*'

  2. Erstellen Sie die Richtlinie mit dem Befehl „kubectl apply“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f psp-deny-privileged.yaml

  3. Zeigen Sie die verfügbaren Richtlinien mit dem Befehl „kubectl get psp“ an.

    kubectl get psp

    Vergleichen Sie in der folgenden Beispielausgabe die Richtlinie psp-deny-privileged mit der Standardrichtlinie privilege, die in den vorherigen Beispielen für die Poderstellung erzwungen wurde. Durch Ihre Richtlinie wird lediglich die Verwendung von PRIV für die Rechteausweitung abgelehnt. Bei der Richtlinie psp-deny-privileged gibt es keinerlei Benutzer- oder Gruppeneinschränkungen.

    NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *

Zulassen der Verwendung der benutzerdefinierten Podsicherheitsrichtlinie durch das Benutzerkonto

Im vorherigen Schritt haben Sie eine Podsicherheitsrichtlinie erstellt, um Pods abzulehnen, die privilegierten Zugriff anfordern. Damit die Richtlinie verwendet werden kann, müssen Sie eine Rolle (Role) oder Clusterrolle (ClusterRole) erstellen. Anschließend müssen Sie eine dieser Rollen mithilfe einer Rollenbindung (RoleBinding) oder Clusterrollenbindung (ClusterRoleBinding) zuordnen. In diesem Beispiel erstellen wir eine Clusterrolle, die es Ihnen ermöglicht, die im vorherigen Schritt erstellte Richtlinie psp-deny-privileged zu verwenden.

  1. Erstellen Sie eine Datei mit dem Namen „psp-deny-privileged-clusterrole.yaml“, und fügen Sie das folgende YAML-Manifest ein.

    kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-deny-privileged-clusterrole
rules:
- apiGroups:
  - extensions
   resources:
  - podsecuritypolicies
   resourceNames:
  - psp-deny-privileged
   verbs:
  - use

  2. Erstellen Sie die Clusterrolle mit dem Befehl „kubectl apply“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f psp-deny-privileged-clusterrole.yaml

  3. Erstellen Sie eine Datei mit dem Namen „psp-deny-privileged-clusterrolebinding.yaml“, und fügen Sie das folgende YAML-Manifest ein.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: psp-deny-privileged-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp-deny-privileged-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts

  4. Erstellen Sie eine Clusterrollenbindung mit dem Befehl „kubectl apply“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml

Hinweis

Im ersten Schritt dieses Artikels wurde das Podsicherheitsrichtlinien-Feature für den AKS-Cluster aktiviert. Laut empfohlener Vorgehensweise sollte das Podsicherheitsrichtlinien-Feature allerdings erst aktiviert werden, nachdem Sie Ihre eigenen Richtlinien definiert haben. Das ist nun die Phase, in der Sie das Podsicherheitsrichtlinien-Feature normalerweise aktivieren würden. Es wurde mindestens eine benutzerdefinierte Richtlinie definiert, und den Richtlinien wurden Benutzerkonten zugeordnet. Nun können Sie problemlos das Feature „Podsicherheitsrichtlinie“ aktivieren und Probleme minimieren, die durch die Standardrichtlinien verursacht werden.

Erneutes Testen der Erstellung eines nicht privilegierten Pods

Versuchen Sie erneut, einen nicht privilegierten Pod zu erstellen, nachdem Sie Ihre benutzerdefinierte Podsicherheitsrichtlinie angewendet haben und über eine Bindung verfügen, damit das Benutzerkonto die Richtlinie verwenden kann.

Dieses Beispiel zeigt, wie Sie benutzerdefinierte Podsicherheitsrichtlinien erstellen, um den Zugriff auf den AKS-Cluster für verschiedene Benutzer oder Gruppen zu definieren. Mit den AKS-Standardrichtlinien wird sehr streng kontrolliert, welche Pods ausgeführt werden können. Erstellen Sie daher Ihre eigenen benutzerdefinierten Richtlinien, um die korrekten Einschränkungen für Ihre Anforderungen zu definieren.

  1. Verwenden Sie zum Erstellen des Pods das Manifest „nginx-privileged.yaml“ und den Befehl „kubectl apply“.

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

  2. Überprüfen Sie mit dem Befehl „kubectl get pods“ den Status des Pods.

    kubectl-nonadminuser get pods

    Die folgende Beispielausgabe zeigt, dass der Pod erfolgreich geplant wurde und ausgeführt wird:

    NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          7m14s

  3. Löschen Sie den nicht privilegierten NGINX-Pod mit dem Befehl „kubectl delete“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Bereinigen von Ressourcen

  1. Deaktivieren Sie die Podsicherheitsrichtlinie mit dem Befehl „az aks update“.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-pod-security-policy

  2. Löschen Sie die Clusterrolle und die Clusterrollenbindung mit dem Befehl „kubectl delete“.

    kubectl delete -f psp-deny-privileged-clusterrole.yaml

  3. Löschen Sie die Clusterrollenbindung mit dem Befehl „kubectl delete“.

    kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml

  4. Löschen Sie die Sicherheitsrichtlinie mit dem Befehl „kubectl delete“, und geben Sie den Namen Ihres YAML-Manifests an.

    kubectl delete -f psp-deny-privileged.yaml

  5. Löschen Sie den Namespace psp-aks mit dem Befehl „kubectl delete“.

    kubectl delete namespace psp-aks

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie eine Podsicherheitsrichtlinie erstellen, um die Verwendung von privilegiertem Zugriff zu verhindern. Richtlinien können eine Vielzahl von Features erzwingen, z. B. den Typ des Volumes oder den RunAs-Benutzer. Weitere Informationen zu den verfügbaren Optionen finden Sie in der Referenzdokumentation zu Kubernetes-Podsicherheitsrichtlinien.

Weitere Informationen zum Einschränken des Netzwerkdatenverkehrs von Pods finden Sie unter Vorschauversion: Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in Azure Kubernetes Service (AKS).