Udostępnij za pośrednictwem

Zabezpieczanie klastra za pomocą zasad zabezpieczeń zasobników w usłudze Azure Kubernetes Service (AKS) (wersja zapoznawcza)

  • Artykuł

Ważne

Funkcja zasad zabezpieczeń zasobnika została wycofana 1 sierpnia 2023 r. i usunięta z usługi AKS w wersji 1.25 lub nowszej.

Zalecamy przeprowadzenie migracji do kontrolera zabezpieczeń zabezpieczeń zasobnika lub zasad platformy Azure, aby pozostać w pomoc techniczna platformy Azure. Przyjęcie zabezpieczeń zasobnika to wbudowane rozwiązanie zasad dla implementacji pojedynczego klastra. Jeśli szukasz zasad klasy korporacyjnej, zasady platformy Azure są lepszym wyborem.

Zanim rozpoczniesz

  • W tym artykule założono, że masz istniejący klaster usługi AKS. Jeśli potrzebujesz klastra usługi AKS, utwórz go przy użyciu interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub witryny Azure Portal.
  • Potrzebny jest interfejs wiersza polecenia platformy Azure w wersji 2.0.61 lub nowszej, zainstalowany i skonfigurowany. Uruchom polecenie az --version, aby dowiedzieć się, jaka wersja jest używana. Jeśli musisz zainstalować lub uaktualnić, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

Instalowanie rozszerzenia interfejsu wiersza polecenia platformy aks-preview Azure

Ważne

Funkcje usługi AKS w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze usługi AKS są częściowo objęte pomocą techniczną dla klientów. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego. Aby uzyskać więcej informacji, zobacz następujące artykuły pomocy technicznej:

  1. Zainstaluj rozszerzenie aks-preview przy użyciu az extension add polecenia .

    az extension add --name aks-preview

  2. Przeprowadź aktualizację do najnowszej wersji rozszerzenia przy użyciu az extension update polecenia .

    az extension update --name aks-preview

Rejestrowanie flagi PodSecurityPolicyPreview funkcji

  1. Zarejestruj flagę PodSecurityPolicyPreview funkcji przy użyciu az feature register polecenia .

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

    Wyświetlenie stanu Zarejestrowane trwa kilka minut.

  2. Sprawdź stan rejestracji przy użyciu az feature show polecenia .

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

  3. Gdy stan będzie odzwierciedlał wartość Zarejestrowano, odśwież rejestrację dostawcy zasobów Microsoft.ContainerService przy użyciu az provider register polecenia .

    az provider register --namespace Microsoft.ContainerService

Omówienie zasad zabezpieczeń zasobnika

Klastry Kubernetes używają kontrolerów przyjęć do przechwytywania żądań do serwera interfejsu API, gdy zostanie utworzony zasób. Kontroler wpływu danych może następnie zweryfikować żądanie zasobu względem zestawu reguł lub zmodyfikować zasób w celu zmiany parametrów wdrożenia.

PodSecurityPolicy jest kontrolerem wpływu, który weryfikuje specyfikację zasobnika spełniającą zdefiniowane wymagania. Te wymagania mogą ograniczać użycie uprzywilejowanych kontenerów, dostęp do niektórych typów magazynu lub użytkownika lub grupy, w których kontener może działać jako. Podczas próby wdrożenia zasobu, w którym specyfikacje zasobnika nie spełniają wymagań opisanych w zasadach zabezpieczeń zasobnika, żądanie zostanie odrzucone. Ta możliwość kontrolowania, jakie zasobniki można zaplanować w klastrze usługi AKS, zapobiega niektórym możliwym lukom w zabezpieczeniach lub eskalacjom uprawnień.

Po włączeniu zasad zabezpieczeń zasobników w klastrze usługi AKS są stosowane niektóre domyślne zasady. Te zasady zapewniają gotowe do użycia środowisko umożliwiające zdefiniowanie zaplanowanych zasobników. Jednak mogą wystąpić problemy z wdrażaniem zasobników, dopóki nie zdefiniujesz własnych zasad. Zalecanym podejściem jest:

  1. Utwórz klaster usługi AKS.
  2. Zdefiniuj własne zasady zabezpieczeń zasobnika.
  3. Włącz funkcję zasad zabezpieczeń zasobnika.

Zmiany zachowania między zasadami zabezpieczeń zasobnika i usługą Azure Policy

Scenariusz Zasady zabezpieczeń zasobnika Azure Policy
Instalacja Włączanie funkcji zasad zabezpieczeń zasobnika Włączanie dodatku usługi Azure Policy
Wdrażanie zasad Wdrażanie zasobu zasad zabezpieczeń zasobnika Przypisz zasady platformy Azure do zakresu subskrypcji lub grupy zasobów. Dodatek usługi Azure Policy jest wymagany dla aplikacji zasobów platformy Kubernetes.
Domyślne zasady Po włączeniu zasad zabezpieczeń zasobnika w usłudze AKS są stosowane domyślne zasady uprzywilejowane i nieograniczone. Nie są stosowane żadne domyślne zasady, włączając dodatek usługi Azure Policy. Należy jawnie włączyć zasady w usłudze Azure Policy.
Kto może tworzyć i przypisywać zasady Administrator klastra tworzy zasób zasad zabezpieczeń zasobnika Użytkownicy muszą mieć minimalną rolę uprawnień "właściciel" lub "Współautor zasad zasobów" w grupie zasobów klastra usługi AKS. — Za pośrednictwem interfejsu API użytkownicy mogą przypisywać zasady w zakresie zasobów klastra usługi AKS. Użytkownik powinien mieć co najmniej uprawnienia "właściciel" lub "Współautor zasad zasobów" w zasobie klastra usługi AKS. — W witrynie Azure Portal zasady można przypisać na poziomie grupy zarządzania/subskrypcji/grupy zasobów.
Autoryzowanie zasad Użytkownicy i konta usług wymagają jawnych uprawnień do korzystania z zasad zabezpieczeń zasobnika. Do autoryzowania zasad nie jest wymagane żadne dodatkowe przypisanie. Po przypisaniu zasad na platformie Azure wszyscy użytkownicy klastra mogą używać tych zasad.
Możliwość stosowania zasad Administrator pomija wymuszanie zasad zabezpieczeń zasobnika. Wszyscy użytkownicy (administratorzy i użytkownicy niebędący administratorami) widzą te same zasady. Nie ma specjalnej wielkości liter na podstawie użytkowników. Aplikację zasad można wykluczyć na poziomie przestrzeni nazw.
Zakresy zasad Zasady zabezpieczeń zasobnika nie są przestrzenią nazw Szablony ograniczeń używane przez usługę Azure Policy nie są przestrzenią nazw.
Akcja Odmów/Inspekcja/Mutacja Zasady zabezpieczeń zasobnika obsługują tylko akcje odmowy. Mutację można wykonać przy użyciu wartości domyślnych podczas tworzenia żądań. Podczas żądań aktualizacji można przeprowadzić walidację. Usługa Azure Policy obsługuje zarówno akcje inspekcji, jak i odmowy. Mutacja nie jest jeszcze obsługiwana.
Zgodność z zasadami zabezpieczeń zasobnika Nie ma wglądu w zgodność zasobników, które istniały przed włączeniem zasad zabezpieczeń zasobnika. Niezgodne zasobniki utworzone po włączeniu zasad zabezpieczeń zasobnika są odrzucane. Niezgodne zasobniki, które istniały przed zastosowaniem zasad platformy Azure, będą wyświetlane w naruszeniach zasad. Niezgodne zasobniki utworzone po włączeniu zasad platformy Azure są odrzucane, jeśli zasady są ustawione z efektem odmowy.
Jak wyświetlić zasady w klastrze kubectl get psp kubectl get constrainttemplate — Zwracane są wszystkie zasady.
Standard zasad zabezpieczeń zasobnika — uprzywilejowane Uprzywilejowany zasób zasad zabezpieczeń zasobnika jest tworzony domyślnie podczas włączania funkcji. Tryb uprzywilejowany nie oznacza żadnych ograniczeń, w wyniku czego nie ma żadnego przypisania usługi Azure Policy.
Standard zasad zabezpieczeń zasobnika — punkt odniesienia/wartość domyślna Użytkownik instaluje zasób punktu odniesienia zasad zabezpieczeń zasobnika. Usługa Azure Policy udostępnia wbudowaną inicjatywę punktu odniesienia, która mapuje je na podstawowe zasady zabezpieczeń zasobników.
Standard zasad zabezpieczeń zasobnika — ograniczony Użytkownik instaluje zasób z ograniczeniami zasad zabezpieczeń zasobnika. Usługa Azure Policy udostępnia wbudowaną inicjatywę z ograniczeniami, która jest mapowana na zasady zabezpieczeń ograniczonych zasobników.

Włączanie zasad zabezpieczeń zasobników w klastrze usługi AKS

Uwaga

W przypadku rzeczywistego użycia nie włączaj zasad zabezpieczeń zasobników, dopóki nie zdefiniujesz własnych zasad niestandardowych. W tym artykule włączymy zasady zabezpieczeń zasobnika jako pierwszy krok, aby zobaczyć, jak domyślne zasady ograniczają wdrożenia zasobników.

  • Włącz zasady zabezpieczeń zasobnika za pomocą az aks update polecenia .

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

Domyślne zasady usługi AKS

Po włączeniu zasad zabezpieczeń zasobnika usługa AKS tworzy jedną domyślną zasadę o nazwie privileged. Nie edytuj ani nie usuwaj zasad domyślnych. Zamiast tego utwórz własne zasady, które definiują ustawienia, które chcesz kontrolować. Najpierw przyjrzyjmy się tym, jak te domyślne zasady wpływają na wdrożenia zasobników.

  1. Wyświetl dostępne zasady przy użyciu kubectl get psp polecenia .

    kubectl get psp

    Dane wyjściowe będą wyglądać podobnie do następujących przykładowych danych wyjściowych:

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

    Uprzywilejowane zasady zabezpieczeń zasobników są stosowane do dowolnego uwierzytelnionego użytkownika w klastrze usługi AKS. To przypisanie jest kontrolowane przez jednostki ClusterRoles i ClusterRoleBindings.

  2. Wyszukaj wartość default:privileged: binding w przestrzeni nazw kube-system przy użyciu kubectl get rolebindings polecenia .

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

    Następujące skrócone przykładowe dane wyjściowe pokazują, że psp:privileged ClusterRole jest przypisywany do dowolnego systemu:uwierzytelnionych użytkowników. Ta możliwość zapewnia podstawowy poziom uprawnień bez definiowania własnych zasad.

    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

Przed rozpoczęciem tworzenia własnych zasad zabezpieczeń zasobników ważne jest, aby zrozumieć, jak te zasady domyślne wchodzą w interakcje z żądaniami użytkowników. W kilku następnych sekcjach zaplanowaliśmy niektóre zasobniki, aby zobaczyć domyślne zasady w działaniu.

Tworzenie użytkownika testowego w klastrze usługi AKS

Gdy używasz az aks get-credentials polecenia, poświadczenia administratora klastra usługi AKS są domyślnie dodawane do kubectl konfiguracji. Administrator pomija wymuszanie zasad zabezpieczeń zasobnika. Jeśli używasz integracji firmy Microsoft Entra dla klastrów usługi AKS, możesz zalogować się przy użyciu poświadczeń użytkownika niebędącego administratorem, aby zobaczyć wymuszanie zasad w działaniu.

  1. Utwórz przykładową przestrzeń nazw o nazwie psp-aks dla zasobów testowych przy użyciu kubectl create namespace polecenia .

    kubectl create namespace psp-aks

  2. Utwórz konto usługi o nazwie nonadmin-user przy użyciu kubectl create serviceaccount polecenia .

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

  3. Utwórz element RoleBinding dla użytkownika niebędącego administratorem, aby wykonać podstawowe akcje w przestrzeni nazw przy użyciu kubectl create rolebinding polecenia .

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

Tworzenie poleceń aliasu dla administratora i użytkownika niebędącego administratorem

W przypadku korzystania z programu kubectlmożna wyróżnić różnice między zwykłym użytkownikiem administratora a użytkownikiem niebędącym administratorem, tworząc dwa aliasy wiersza polecenia:

  1. Alias kubectl-admin dla zwykłego użytkownika administratora, który ma zakres dla przestrzeni nazw psp-aks .
  2. Alias kubectl-nonadminuser dla użytkownika niebędącego administratorem utworzonym w poprzednim kroku, który jest zakresem przestrzeni nazw psp-aks.

  • Utwórz dwa aliasy przy użyciu następujących poleceń.

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

Testowanie tworzenia uprzywilejowanego zasobnika

Przetestujmy, co się stanie, gdy planujesz zasobnik z kontekstem zabezpieczeń privileged: true. Ten kontekst zabezpieczeń eskaluje uprawnienia zasobnika. Domyślne zasady zabezpieczeń usługi AKS powinny odrzucać to żądanie.

  1. Utwórz plik o nazwie nginx-privileged.yaml i wklej zawartość następującego manifestu YAML.

    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. Utwórz zasobnik przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

    kubectl-nonadminuser apply -f nginx-privileged.yaml

    Następujące przykładowe dane wyjściowe pokazują, że nie można zaplanować zasobnika:

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

    Ponieważ zasobnik nie osiąga etapu planowania, przed przejściem nie ma żadnych zasobów do usunięcia.

Testowanie tworzenia nieuprzywilejowanego zasobnika

W poprzednim przykładzie specyfikacja zasobnika zażądała uprzywilejowanej eskalacji. To żądanie jest odrzucane przez domyślne zasady zabezpieczeń zasobnika uprawnień , więc nie można zaplanować zasobnika. Spróbujmy uruchomić ten sam zasobnik NGINX bez żądania eskalacji uprawnień.

  1. Utwórz plik o nazwie nginx-unprivileged.yaml i wklej zawartość następującego manifestu YAML.

    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. Utwórz zasobnik przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

    Następujące przykładowe dane wyjściowe pokazują, że nie można zaplanować zasobnika:

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

    Ponieważ zasobnik nie osiąga etapu planowania, przed przejściem nie ma żadnych zasobów do usunięcia.

Testowanie tworzenia zasobnika z określonym kontekstem użytkownika

W poprzednim przykładzie obraz kontenera automatycznie próbował użyć katalogu głównego do powiązania serwera NGINX z portem 80. To żądanie zostało odrzucone przez domyślne zasady zabezpieczeń zasobnika uprawnień , więc nie można uruchomić zasobnika. Spróbujmy uruchomić ten sam zasobnik NGINX z określonym kontekstem użytkownika, takim jak runAsUser: 2000.

  1. Utwórz plik o nazwie nginx-unprivileged-nonroot.yaml i wklej następujący manifest YAML.

    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. Utwórz zasobnik przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

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

    Następujące przykładowe dane wyjściowe pokazują, że nie można zaplanować zasobnika:

    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: []

    Ponieważ zasobnik nie osiąga etapu planowania, przed przejściem nie ma żadnych zasobów do usunięcia.

Tworzenie niestandardowych zasad zabezpieczeń zasobnika

Teraz, gdy już znasz zachowanie domyślnych zasad zabezpieczeń zasobnika, zapewnijmy użytkownikowi innego użytkownika sposób na pomyślne zaplanowanie zasobników.

Utworzymy zasady odrzucające zasobniki, które żądają uprzywilejowanego dostępu. Inne opcje, takie jak runAsUser lub dozwolone woluminy, nie są jawnie ograniczone. Ten typ zasad odrzuca żądanie dostępu uprzywilejowanego, ale umożliwia klastrowi uruchamianie żądanych zasobników.

  1. Utwórz plik o nazwie psp-deny-privileged.yaml i wklej następujący manifest YAML.

    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. Utwórz zasady przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

    kubectl apply -f psp-deny-privileged.yaml

  3. Wyświetl dostępne zasady przy użyciu kubectl get psp polecenia .

    kubectl get psp

    W poniższych przykładowych danych wyjściowych porównaj zasady psp-deny-privileged z domyślnymi zasadami uprawnień , które zostały wymuszone w poprzednich przykładach, aby utworzyć zasobnik. Zasady nie korzystają tylko z eskalacji PRIV . Nie ma żadnych ograniczeń dotyczących użytkownika lub grupy dla zasad psp-deny-privileged .

    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            *

Zezwalaj kontu użytkownika na używanie niestandardowych zasad zabezpieczeń zasobników

W poprzednim kroku utworzono zasady zabezpieczeń zasobnika, aby odrzucić zasobniki, które żądają dostępu uprzywilejowanego. Aby zezwolić na używanie zasad, należy utworzyć rolę lub klasterRole. Następnie skojarzysz jedną z tych ról przy użyciu funkcji RoleBinding lub ClusterRoleBinding. W tym przykładzie utworzymy klasterRole, który umożliwia użycie zasad psp-deny-privileged utworzonych w poprzednim kroku.

  1. Utwórz plik o nazwie psp-deny-privileged-clusterrole.yaml i wklej następujący manifest YAML.

    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. Utwórz klasterRole przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

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

  3. Utwórz plik o nazwie psp-deny-privileged-clusterrolebinding.yaml i wklej następujący manifest YAML.

    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. Utwórz klasterRoleBinding przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

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

Uwaga

W pierwszym kroku tego artykułu funkcja zasad zabezpieczeń zasobnika została włączona w klastrze usługi AKS. Zalecaną praktyką było włączenie funkcji zasad zabezpieczeń zasobnika tylko po zdefiniowaniu własnych zasad. Jest to etap, na którym można włączyć funkcję zasad zabezpieczeń zasobnika. Zdefiniowano co najmniej jedną zasady niestandardowe, a konta użytkowników zostały skojarzone z tymi zasadami. Teraz możesz bezpiecznie włączyć funkcję zasad zabezpieczeń zasobnika i zminimalizować problemy spowodowane przez domyślne zasady.

Ponownie przetestuj tworzenie nieuprzywilejowanego zasobnika

Po zastosowaniu niestandardowych zasad zabezpieczeń zasobnika i powiązaniu dla konta użytkownika w celu korzystania z zasad spróbujmy ponownie utworzyć nieuprzywilejowany zasobnik.

W tym przykładzie pokazano, jak utworzyć niestandardowe zasady zabezpieczeń zasobników w celu zdefiniowania dostępu do klastra usługi AKS dla różnych użytkowników lub grup. Domyślne zasady usługi AKS zapewniają ścisłe mechanizmy kontroli nad tym, które zasobniki mogą być uruchamiane, więc utwórz własne zasady niestandardowe, aby następnie poprawnie zdefiniować potrzebne ograniczenia.

  1. Użyj manifestu nginx-privileged.yaml , aby utworzyć zasobnik przy użyciu kubectl apply polecenia .

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

  2. Sprawdź stan zasobnika przy użyciu kubectl get pods polecenia .

    kubectl-nonadminuser get pods

    Następujące przykładowe dane wyjściowe pokazują, że zasobnik został pomyślnie zaplanowany i działa:

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

  3. Usuń nieuprzywilejowany zasobnik NGINX przy użyciu kubectl delete polecenia i określ nazwę manifestu YAML.

    kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Czyszczenie zasobów

  1. Wyłącz zasady zabezpieczeń zasobnika przy użyciu az aks update polecenia .

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

  2. Usuń klasterRole i ClusterRoleBinding przy użyciu kubectl delete polecenia .

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

  3. Usuń klasterRoleBinding przy użyciu kubectl delete polecenia .

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

  4. Usuń zasady zabezpieczeń przy użyciu kubectl delete polecenia i określ nazwę manifestu YAML.

    kubectl delete -f psp-deny-privileged.yaml

  5. Usuń przestrzeń nazw psp-aks przy użyciu kubectl delete polecenia .

    kubectl delete namespace psp-aks

Następne kroki

W tym artykule pokazano, jak utworzyć zasady zabezpieczeń zasobnika, aby uniemożliwić korzystanie z uprzywilejowanego dostępu. Zasady mogą wymuszać wiele funkcji, takich jak typ woluminu lub użytkownik Uruchom jako. Aby uzyskać więcej informacji na temat dostępnych opcji, zobacz dokumentację dotyczącą zasad zabezpieczeń zasobnika platformy Kubernetes.

Aby uzyskać więcej informacji na temat ograniczania ruchu sieciowego zasobnika, zobacz Zabezpieczanie ruchu między zasobnikami przy użyciu zasad sieciowych w usłudze AKS.