A fürtök védelme az Azure Kubernetes Service (AKS) pod biztonsági házirendjeinek használatával (előnézet)

Fontos

A pod biztonsági szabályzat funkcióját 2023. augusztus 1-jén elavulták, és eltávolították az AKS 1.25-ös és újabb verzióiból.

Javasoljuk, hogy migráljon a pod biztonsági beléptető vezérlőre vagy az Azure-szabályzatra, hogy a Azure-támogatás belül maradjon. A Pod security Admission egy beépített szabályzatmegoldás egyetlen fürt implementációihoz. Ha nagyvállalati szintű szabályzatot keres, akkor az Azure Policy jobb választás.

Előkészületek

• Ez a cikk feltételezi, hogy van egy meglévő AKS-fürtje. Ha AKS-fürtre van szüksége, hozzon létre egyet az Azure CLI, az Azure PowerShell vagy az Azure Portal használatával.
• Telepítenie és konfigurálnia kell az Azure CLI 2.0.61-es vagy újabb verzióját. A verzió azonosításához futtassa a következőt: az --version. Ha telepítenie vagy frissítenie kell, tekintse meg az Azure CLI telepítését.

Az aks-preview Azure CLI-bővítmény telepítése

Fontos

Az AKS előzetes verziójú funkciói önkiszolgáló, opt-in alapon érhetők el. Az előzetes verziókat "ahogy van" és "rendelkezésre állóként" biztosítjuk, és a szolgáltatási szerződésekből és a korlátozott jótállásból kizárjuk őket. Az AKS előzetes verzióit részben az ügyfélszolgálat fedezi a legjobb munkamennyiség alapján. Ezért ezek a funkciók nem éles használatra vannak szánva. További információkért tekintse meg az alábbi támogatási cikkeket:

• AKS támogatási politikák
• Azure-támogatás gyakori kérdések

1. Telepítse az aks-preview bővítményt a az extension add paranccsal.

   az extension add --name aks-preview
   

2. Frissítsen a bővítmény legújabb verziójára a az extension update paranccsal.

   az extension update --name aks-preview
   

A funkciójelző regisztrálása PodSecurityPolicyPreview

1. Regisztrálja a PodSecurityPolicyPreview funkciójelzőt a az feature register paranccsal.

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

   Néhány percig tart, amíg az állapot megjelenik a Regisztrált állapotban.

2. Ellenőrizze a regisztrációs állapotot a az feature show paranccsal.

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

3. Ha az állapot a Regisztrált állapotot tükrözi, frissítse a Microsoft.ContainerService erőforrás-szolgáltató regisztrációját a az provider register paranccsal.

   az provider register --namespace Microsoft.ContainerService
   

Podbiztonsági szabályzatok áttekintése

A Kubernetes-fürtök beléptető vezérlőkkel elfogják az API-kiszolgálóra irányuló kéréseket, amikor létrejön egy erőforrás. A beléptető vezérlő ezután érvényesítheti az erőforrás-kérést egy szabálykészleten, vagy az erőforrást mutációval módosíthatja az üzembehelyezési paramétereket.

PodSecurityPolicy egy olyan beléptető vezérlő, amely ellenőrzi, hogy a pod specifikációja megfelel-e a megadott követelményeknek. Ezek a követelmények korlátozhatják a kiemelt tárolók használatát, bizonyos típusú tárolókhoz való hozzáférést, illetve azt a felhasználót vagy csoportot, amelyként a tároló futhat. Ha olyan erőforrást próbál üzembe helyezni, amelynél a pod specifikációi nem felelnek meg a pod biztonsági szabályzatában ismertetett követelményeknek, a rendszer megtagadja a kérést. Az AKS-fürtben ütemezhető podok szabályozásának képessége megakadályozza a biztonsági rések vagy jogosultságok eszkalálását.

Ha engedélyezi a podbiztonsági szabályzatot egy AKS-fürtben, a rendszer néhány alapértelmezett házirendet alkalmaz. Ezek a szabályzatok beépített felületet biztosítanak annak meghatározásához, hogy mely podok ütemezhetők. Előfordulhat azonban, hogy problémákba ütközik a podok üzembe helyezésekor, amíg meg nem határozza a saját szabályzatait. A javasolt megközelítés a következő:

1. AKS-fürt létrehozása.
2. Saját podbiztonsági szabályzatok definiálása.
3. Engedélyezze a pod biztonsági szabályzat funkcióját.

A pod biztonsági szabályzata és az Azure Policy közötti viselkedésváltozások

Eset	Pod biztonsági szabályzata	Azure Policy
Installation	Pod biztonsági szabályzat funkció engedélyezése	Az Azure Policy bővítmény engedélyezése
Szabályzatok üzembe helyezése	Pod biztonsági szabályzat erőforrásának üzembe helyezése	Azure-szabályzatok hozzárendelése az előfizetéshez vagy az erőforráscsoport hatóköréhez. A Kubernetes-erőforrásalkalmazásokhoz az Azure Policy bővítményre van szükség.
Alapértelmezett szabályzatok	Ha a pod biztonsági szabályzata engedélyezve van az AKS-ben, az alapértelmezett privileged és unrestricted szabályzatok lesznek alkalmazva.	Az Azure Policy bővítmény engedélyezésével a rendszer nem alkalmaz alapértelmezett szabályzatokat. Explicit módon engedélyeznie kell a szabályzatokat az Azure Policyban.
Ki hozhat létre és rendelhet hozzá szabályzatokat?	A fürtgazdák podbiztonsági házirend-erőforrást hoznak létre	A felhasználóknak legalább tulajdonosi vagy erőforrásházirend-közreműködői engedélyekkel kell rendelkezniük az AKS-fürt erőforráscsoportján. – Az API-n keresztül a felhasználók szabályzatokat rendelhetnek az AKS-fürt erőforrás-hatóköréhez. A felhasználónak legalább tulajdonosi vagy erőforrásházirend-közreműködői engedélyekkel kell rendelkeznie az AKS-fürterőforráson. – Az Azure Portalon a szabályzatok a felügyeleti csoport/előfizetés/erőforráscsoport szintjén rendelhetők hozzá.
Szabályzatok engedélyezése	A felhasználók és a szolgáltatásfiókok kifejezett engedélyeket igényelnek a podbiztonsági szabályzatok használatához.	A szabályzatok engedélyezéséhez nincs szükség további hozzárendelésre. Miután hozzárendelte a szabályzatokat az Azure-ban, a fürt összes felhasználója használhatja ezeket a szabályzatokat.
Szabályzat alkalmazhatósága	A rendszergazdai felhasználó végrehajtja a pod biztonsági szabályzatainak érvényesítését.	Minden felhasználó (rendszergazda és nem rendszergazda) ugyanazokat a házirendeket látja. A felhasználókon alapuló speciális burkolatok nem léteznek. A szabályzatalkalmazás a névtér szintjén kizárható.
Szabályzat hatóköre	A pod biztonsági szabályzatai nincsenek névtérben	Az Azure Policy által használt kényszersablonok nincsenek névtérben.
Megtagadási/naplózási/mutációs művelet	A pod biztonsági szabályzatai csak a megtagadási műveleteket támogatják. A mutáció a létrehozási kérelmek alapértelmezett értékeivel is elvégezhető. Az ellenőrzés a frissítési kérelmek során végezhető el.	Az Azure Policy mindkét naplózási és megtagadási műveletet támogatja. A mutáció még nem támogatott.
Pod biztonsági szabályzatának megfelelősége	A podok biztonsági szabályzatának engedélyezése előtt nem látható a podok megfelelősége. A podbiztonsági szabályzatok engedélyezése után létrehozott nem megfelelő podok elutasítása.	Az Azure-szabályzatok alkalmazása előtt meglévő nem megfelelő podok szabályzatsértésekben jelennek meg. Az Azure-szabályzatok engedélyezése után létrehozott nem megfelelő podokat a rendszer megtagadja, ha a szabályzatok elutasítási hatással vannak beállítva.
Szabályzatok megtekintése a fürtön	kubectl get psp	kubectl get constrainttemplate - Minden szabályzat vissza lesz adva.
Pod biztonsági szabályzat szabványa – Privileged	A szolgáltatás engedélyezésekor alapértelmezés szerint létrejön egy emelt szintű podbiztonsági házirend-erőforrás.	A kiemelt mód nem jelent korlátozást, ezért egyenértékű azzal, hogy nem rendelkezik Azure Policy-hozzárendeléssel.
Pod biztonsági szabályzatának szabványa – Alapterv/alapértelmezett	A felhasználó telepíti a pod biztonsági szabályzatának alapkonfigurációs erőforrását.	Az Azure Policy egy beépített alapszintű kezdeményezést biztosít, amely megfelel az alapkonfiguráció podbiztonsági szabályzatának.
Pod biztonsági szabályzat szabványa – Korlátozott	A felhasználó podbiztonsági szabályzattal korlátozott erőforrást telepít.	Az Azure Policy egy beépített korlátozott kezdeményezést biztosít, amely megfelel a korlátozott pod biztonsági szabályzatának.

Podbiztonsági szabályzat engedélyezése AKS-fürtön

Megjegyzés:

Valós használat esetén ne engedélyezze a pod biztonsági szabályzatát, amíg meg nem határozza saját egyéni szabályzatait. Ebben a cikkben első lépésként engedélyezzük a pod biztonsági szabályzatát, hogy lássuk, az alapértelmezett házirendek hogyan korlátozzák a podtelepítéseket.

• Engedélyezze a pod biztonsági szabályzatát a az aks update paranccsal.

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

Alapértelmezett AKS-szabályzatok

A pod biztonsági szabályzatának engedélyezésekor az AKS létrehoz egy jogosultsággal ellátott alapértelmezett házirendet. Ne szerkessze vagy távolítsa el az alapértelmezett szabályzatot. Ehelyett hozzon létre saját szabályzatokat, amelyek meghatározzák a szabályozni kívánt beállításokat. Először nézzük meg, hogy ezek az alapértelmezett szabályzatok milyen hatással vannak a podok üzembe helyezésére.

1. Tekintse meg az elérhető szabályzatokat a kubectl get psp paranccsal.

   kubectl get psp
   

   A kimenet a következő példakimenethez hasonlóan fog kinézni:

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

   A rendszer a kiemelt pod biztonsági szabályzatát alkalmazza az AKS-fürt bármely hitelesített felhasználója esetében. Ezt a hozzárendelést ClusterRoles az and ClusterRoleBindings.

2. Keresse meg az alapértelmezett:privileged: kötést a kube-system névtérben a kubectl get rolebindings paranccsal.

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

   Az alábbi tömörített példakimenet azt mutatja, hogy a psp:privilegedClusterRole bármely rendszer:hitelesített felhasználóhoz van rendelve. Ez a képesség alapvető jogosultsági szintet biztosít a saját szabályzatok definiálása nélkül.

   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
   

Fontos tisztában lenni azzal, hogy ezek az alapértelmezett szabályzatok hogyan működnek együtt a podok ütemezésére irányuló felhasználói kérésekkel, mielőtt saját podbiztonsági szabályzatokat hoz létre. A következő néhány szakaszban ütemezünk néhány podot az alapértelmezett szabályzatok működés közbeni megtekintéséhez.

Tesztfelhasználó létrehozása AKS-fürtben

A parancs használatakor a az aks get-credentials rendszer alapértelmezés szerint hozzáadja az AKS-fürt rendszergazdai hitelesítő adatait a kubectl konfigurációhoz. A rendszergazdai felhasználó végrehajtja a pod biztonsági szabályzatainak érvényesítését. Ha Microsoft Entra-integrációt használ az AKS-fürtökhöz, bejelentkezhet egy nem rendszergazdai felhasználó hitelesítő adataival a szabályzatok működés közbeni érvényesítésének megtekintéséhez.

1. Hozzon létre egy psp-aks nevű mintanévteret az erőforrások teszteléséhez a kubectl create namespace parancs használatával.

   kubectl create namespace psp-aks
   

2. Hozzon létre egy nem felhasználó nevű szolgáltatásfiókot a kubectl create serviceaccount parancs használatával.

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

3. Hozzon létre egy RoleBinding-műveletet a nem a felhasználó számára, hogy alapvető műveleteket hajthasson végre a névtérben a kubectl create rolebinding paranccsal.

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

Aliasparancsok létrehozása rendszergazdai és nem rendszergazdai felhasználók számára

A használat során kubectlkét parancssori alias létrehozásával kiemelheti a normál rendszergazdai és a nem rendszergazdai felhasználó közötti különbségeket:

1. A normál rendszergazdai felhasználó kubectl-admin aliasa, amely a psp-aks névtérre terjed ki.
2. Az előző lépésben létrehozott nem felhasználó kubectl-nonadminuser aliasa, amely a psp-aks névtérre terjed ki.

• Hozza létre a két aliast az alábbi parancsokkal.

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

Emelt szintű pod létrehozásának tesztelése

Teszteljük, mi történik, ha egy podot a biztonsági környezettel privileged: trueütemez. Ez a biztonsági környezet eszkalálja a pod jogosultságait. Az alapértelmezett jogosultsági AKS biztonsági szabályzatnak meg kell tagadnia ezt a kérést.

1. Hozzon létre egy elnevezett nginx-privileged.yaml fájlt, és illessze be a következő YAML-jegyzék tartalmát.

   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. Hozza létre a podot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

   kubectl-nonadminuser apply -f nginx-privileged.yaml
   

   Az alábbi példakimenet azt mutatja, hogy a podot nem sikerült ütemezni:

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

   Mivel a pod nem éri el az ütemezési szakaszt, a továbblépés előtt nincs törölni kívánt erőforrás.

Nem emelt szintű pod létrehozásának tesztelése

Az előző példában a pod specifikációja emelt szintű eszkalációt kért. Ezt a kérést az alapértelmezett jogosultsági pod biztonsági szabályzata elutasítja, ezért a pod nem lesz ütemezve. Próbálja meg futtatni ugyanazt az NGINX-podot a jogosultságeszkalációs kérés nélkül.

1. Hozzon létre egy fájlt, nginx-unprivileged.yaml és illessze be a következő YAML-jegyzék tartalmát.

   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. Hozza létre a podot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

   Az alábbi példakimenet azt mutatja, hogy a podot nem sikerült ütemezni:

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

   Mivel a pod nem éri el az ütemezési szakaszt, a továbblépés előtt nincs törölni kívánt erőforrás.

Pod létrehozásának tesztelése adott felhasználói környezettel

Az előző példában a tárolórendszerkép automatikusan a gyökér használatával próbálta meg az NGINX-et a 80-s porthoz kötni. Ezt a kérést az alapértelmezett jogosultsági pod biztonsági szabályzata elutasította, ezért a pod nem indul el. Próbáljuk meg futtatni ugyanazt az NGINX-podot egy adott felhasználói környezettel, például runAsUser: 2000.

1. Hozzon létre egy fájlt, nginx-unprivileged-nonroot.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a podot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

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

   Az alábbi példakimenet azt mutatja, hogy a podot nem sikerült ütemezni:

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

   Mivel a pod nem éri el az ütemezési szakaszt, a továbblépés előtt nincs törölni kívánt erőforrás.

Egyéni podbiztonsági szabályzat létrehozása

Most, hogy megismerte az alapértelmezett podbiztonsági szabályzatok viselkedését, biztosítsunk módot a nem felhasználó számára a podok sikeres ütemezésére.

Létrehozunk egy szabályzatot, amely elutasítja a kiemelt hozzáférést kérő podokat. Más beállítások, például a runAsUser vagy az engedélyezett kötetek nincsenek explicit módon korlátozva. Az ilyen típusú szabályzat tagadja a kiemelt hozzáférésre vonatkozó kérést, de lehetővé teszi a fürt számára a kért podok futtatását.

1. Hozzon létre egy fájlt, psp-deny-privileged.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a szabályzatot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

   kubectl apply -f psp-deny-privileged.yaml
   

3. Tekintse meg az elérhető szabályzatokat a kubectl get psp paranccsal.

   kubectl get psp
   

   A következő példakimenetben hasonlítsa össze a psp-deny-privileged házirendet az előző példákban kényszerített alapértelmezett jogosultsági szabályzattal pod létrehozásához. A házirend csak a PRIV eszkaláció használatát tagadja meg. A psp-deny-privileged szabályzathoz nincs korlátozás a felhasználóra vagy csoportra vonatkozóan.

   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            *          
   

Az egyéni pod biztonsági szabályzatának használatának engedélyezése a felhasználói fiók számára

Az előző lépésben létrehozott egy podbiztonsági szabályzatot, amely elutasítja a kiemelt hozzáférést kérő podokat. A szabályzat használatának engedélyezéséhez létre kell hoznia egy szerepkörtvagy egy ClusterRole-t. Ezután hozzárendelhet egy szerepkört egy RoleBinding vagy ClusterRoleBinding használatával. Ebben a példában létrehozunk egy ClusterRole-t, amely lehetővé teszi az előző lépésben létrehozott psp-deny-privileged szabályzat használatát.

1. Hozzon létre egy fájlt, psp-deny-privileged-clusterrole.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a ClusterRole-t a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

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

3. Hozzon létre egy fájlt, psp-deny-privileged-clusterrolebinding.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a ClusterRoleBinding parancsot, kubectl apply és adja meg a YAML-jegyzék nevét.

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

Megjegyzés:

A cikk első lépésében az AKS-fürtön engedélyezve lett a pod biztonsági házirend funkciója. Az ajánlott eljárás az volt, hogy csak a pod biztonsági szabályzat funkciójának engedélyezése a saját szabályzatok definiálása után. Ez az a szakasz, ahol engedélyezné a pod biztonsági szabályzat funkcióját. Definiáltunk egy vagy több egyéni szabályzatot, és felhasználói fiókok lettek társítva ezekhez a házirendekhez. Mostantól biztonságosan engedélyezheti a pod biztonsági szabályzat funkcióját, és minimalizálhatja az alapértelmezett szabályzatok által okozott problémákat.

Nem emelt szintű pod létrehozásának ismételt tesztelése

Az egyéni pod biztonsági szabályzatának alkalmazásával és a felhasználói fiókhoz tartozó kötéssel hozzon létre újra egy nem emelt szintű podot.

Ez a példa bemutatja, hogyan hozhat létre egyéni podbiztonsági szabályzatokat az AKS-fürthöz való hozzáférés meghatározásához különböző felhasználók vagy csoportok számára. Az alapértelmezett AKS-szabályzatok szigorú vezérlőket biztosítanak a podok futtatásához, ezért hozzon létre saját egyéni szabályzatokat a szükséges korlátozások helyes meghatározásához.

1. A jegyzék használatával nginx-privileged.yaml hozza létre a podot a kubectl apply paranccsal.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

2. Ellenőrizze a pod állapotát a kubectl get pods paranccsal.

   kubectl-nonadminuser get pods
   

   Az alábbi példakimenet azt mutatja, hogy a podot sikeresen ütemezték, és fut:

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

3. Törölje az NGINX nem emelt szintű podot a kubectl delete parancs használatával, és adja meg a YAML-jegyzék nevét.

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

Clean up resources

1. Tiltsa le a pod biztonsági szabályzatát a az aks update paranccsal.

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

2. Törölje a ClusterRole és a ClusterRoleBinding parancsot.kubectl delete

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

3. Törölje a ClusterRoleBinding parancsot.kubectl delete

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

4. Törölje a biztonsági szabályzatot parancs használatával kubectl delete , és adja meg a YAML-jegyzék nevét.

   kubectl delete -f psp-deny-privileged.yaml
   

5. Törölje a psp-aks névteret a kubectl delete paranccsal.

   kubectl delete namespace psp-aks
   

További lépések

Ez a cikk bemutatta, hogyan hozhat létre podbiztonsági szabályzatot a kiemelt hozzáférés használatának megakadályozása érdekében. A szabályzatok számos funkciót kényszeríthetnek ki, például a kötet típusát vagy a futtató felhasználót. A rendelkezésre álló lehetőségekről további információt a Kubernetes pod biztonsági házirendjének dokumentációja tartalmaz.

A podok hálózati forgalmának korlátozásával kapcsolatos további információkért tekintse meg a podok közötti adatforgalom biztonságossá tételét az AKS-ben található hálózati házirendek használatával.