Preview – Zabezpečte svůj cluster pomocí zásad zabezpečení v Azure Kubernetes Service (AKS).

Upozornění

Funkce popsaná v tomto dokumentu, pod zásadou zabezpečení (Preview), zahájí zastaralost s Kubernetes verze 1,21 s jejím odebráním ve verzi 1,25. Vzhledem k Kubernetesm přístupů k tomuto milníku bude komunita Kubernetes fungovat tak, aby dokumentoval životaschopné alternativy. Předchozí oznámení o vyřazení bylo provedeno v době, protože pro zákazníky neexistovala možnost životaschopnosti. Teď, když komunita Kubernetes pracuje na alternativním řešení, už nebudete muset vyřadit před Kubernetes.

Po použití zásady zabezpečení (Preview) je zastaralá. tuto funkci je třeba zakázat na všech stávajících clusterech pomocí zastaralé funkce, aby se prováděly budoucí upgrady clusteru a zůstaly v rámci podpory Azure.

Chcete-li zlepšit zabezpečení clusteru AKS, můžete omezit, které části je možné naplánovat. Lusky, které vyžadují prostředky, které nepovolíte, nejde spustit v clusteru AKS. Tento přístup definujete pomocí zásad zabezpečení pod. V tomto článku se dozvíte, jak používat zásady zabezpečení pod k omezení nasazení lusků v AKS.

Důležité

Funkce AKS ve verzi Preview jsou k dispozici na základě samoobslužných možností. Verze Preview se poskytují "tak, jak jsou" a "jak jsou k dispozici" a jsou vyloučené ze smluv o úrovni služeb a omezené záruky. Verze Preview služby AKS částečně pokryje zákaznická podpora na základě maximálního úsilí. Proto nejsou tyto funkce určeny pro použití v produkčním prostředí. Další informace najdete v následujících článcích podpory:

Než začnete

V tomto článku se předpokládá, že máte existující cluster AKS. Pokud potřebujete cluster AKS, přečtěte si rychlý Start AKS a použijte Azure CLI nebo Azure Portal.

Potřebujete nainstalovanou a nakonfigurovanou verzi Azure CLI 2.0.61 nebo novější. Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.

Instalace rozšíření rozhraní příkazového řádku aks-preview

Pokud chcete použít zásady zabezpečení pod, potřebujete rozšíření AKS-Preview CLI verze 0.4.1 nebo vyšší. Nainstalujte rozšíření Azure CLI AKS-Preview pomocí příkazu AZ Extension Add a potom zkontrolujte, jestli nejsou dostupné aktualizace, pomocí příkazu AZ Extension Update :

# Install the aks-preview extension
az extension add --name aks-preview

# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

Registrace pod poskytovatelem funkcí zásad zabezpečení

Tento dokument a funkce se nastavují pro vyřazení 15. října 2020.

Pokud chcete vytvořit nebo aktualizovat cluster AKS pro použití zásad zabezpečení pod, nejdřív Povolte ve svém předplatném příznak funkce. Chcete-li zaregistrovat příznak funkce PodSecurityPolicyPreview , použijte příkaz AZ Feature Register , jak je znázorněno v následujícím příkladu:

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

Zobrazení stavu v registraci trvá několik minut. Stav registrace můžete zjistit pomocí příkazu AZ Feature list :

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSecurityPolicyPreview')].{Name:name,State:properties.state}"

Až budete připraveni, aktualizujte registraci poskytovatele prostředků Microsoft. ContainerService pomocí příkazu AZ Provider Register :

az provider register --namespace Microsoft.ContainerService

Přehled zásad zabezpečení pod

V clusteru Kubernetes se k zachycení požadavků na server rozhraní API používá řadič pro přístup, když se prostředek vytvoří. Řadič pro přijímání pak může ověřit požadavek prostředku na základě sady pravidel nebo podle prostředku změnit parametry nasazení.

PodSecurityPolicy je řadič pro přijímání, který ověřuje specifikaci pod, splňuje vaše definované požadavky. Tyto požadavky mohou omezit použití privilegovaných kontejnerů, přístup k určitým typům úložiště nebo uživatele nebo skupiny, ve kterých může být kontejner spuštěn. Když se pokusíte nasadit prostředek, u kterého specifikace pod nesplňují požadavky uvedené v zásadách zabezpečení pod, požadavek se odepře. Tato možnost určuje, které lusky se můžou naplánovat v clusteru AKS, brání určitým možným chybám zabezpečení nebo zvýšení úrovně oprávnění.

Když v clusteru AKS zapnete zásadu zabezpečení pod, uplatní se některé výchozí zásady. Tyto výchozí zásady poskytují předem připravené možnosti, které definují, jaké lusky je možné naplánovat. Nicméně uživatelé clusteru můžou narazit na problémy s nasazováním lusků, dokud nedefinujete vlastní zásady. Doporučený postup je:

  • Vytvoření clusteru AKS
  • Definovat vlastní zásady zabezpečení pod
  • Povolení funkce zásady zabezpečení pod

Pokud chcete zobrazit, jak výchozí zásady omezují podle nasazení, v tomto článku nejdřív povolíte funkci zásady zabezpečení pod a pak vytvoříte vlastní zásadu.

Změny chování mezi zásadami zabezpečení a Azure Policy

Níže je souhrn změn chování mezi zásadami zabezpečení a Azure Policy.

Scenario Zásady zabezpečení pod Azure Policy
Instalace Funkce zásady zabezpečení Povolit pod Povolit Azure Policy doplněk
Nasadit zásady Prostředek nasazení pod zásadou zabezpečení Přiřaďte zásady Azure k oboru skupiny prostředků nebo předplatnému. Pro aplikace prostředků Kubernetes je vyžadován doplněk Azure Policy.
Výchozí zásady Když je v AKS povolené zásady zabezpečení, aplikují se výchozí privilegované a neomezená zásada. Povolením doplňku Azure Policy nepoužijete žádné výchozí zásady. Zásady musíte explicitně povolit v Azure Policy.
Kdo může vytvářet a přiřazovat zásady Správce clusteru vytvoří prostředek zásad zabezpečení pod. Uživatelé musí mít ve skupině prostředků clusteru AKS minimální roli oprávnění "vlastník" nebo "Přispěvatel zásad prostředků". -Prostřednictvím rozhraní API můžou uživatelé přiřazovat zásady v oboru prostředků clusteru AKS. Uživatel by měl mít minimálně oprávnění "vlastník" nebo "Přispěvatel zásad prostředků" na prostředku clusteru AKS. -V Azure Portal lze zásady přiřadit na úrovni skupiny pro správu nebo předplatného nebo skupiny prostředků.
Autorizace zásad Uživatelé a účty služeb vyžadují explicitní oprávnění k používání zásad zabezpečení pod. K autorizaci zásad není nutné žádné další přiřazení. Až se zásady přiřadí v Azure, můžou tyto zásady používat všichni uživatelé clusteru.
Použitelnost zásad Uživatel s rolí správce obchází vynucování zásad zabezpečení pod. Všichni uživatelé (Správci & nepoužívají správce) uvidí stejné zásady. Na základě uživatelů neexistují žádná speciální velká písmena. Aplikaci zásad lze vyloučit na úrovni oboru názvů.
Rozsah zásad Zásady zabezpečení pod oborem názvů nejsou. Šablony omezení používané Azure Policy nejsou obor názvů.
Akce odepřít/audit/mutace Zásady zabezpečení pod podporují jenom akce Deny. Mutace se dají udělat s výchozími hodnotami pro žádosti o vytvoření. Ověřování lze provést během požadavků na aktualizaci. Azure Policy podporuje akce zakázat &. Mutace se ještě nepodporují, ale byly plánované.
Dodržování předpisů zásad zabezpečení pod Neexistují žádné informace o dodržování předpisů lusky, které existovaly před povolením zásad zabezpečení. Neodpovídající lusky vytvořené po povolení zásad zabezpečení v případě odepření. Neodpovídající lusky, které existovaly před použitím zásad Azure, se budou zobrazovat v porušení zásad. Neodpovídající lusky vytvořené po povolení zásad Azure se odepře, pokud jsou zásady nastavené s použitím efektu odepření.
Postup zobrazení zásad v clusteru kubectl get psp kubectl get constrainttemplate – Vrátí se všechny zásady.
Pod standardem zásady zabezpečení – privilegované Při povolení této funkce se ve výchozím nastavení vytvoří prostředek zásad zabezpečení s oprávněním pod. Privilegovaný režim nezahrnuje žádné omezení. Výsledkem je, že nemusíte mít žádné Azure Policy přiřazení.
Standard zásad zabezpečení/Standardní – Standardní hodnota Uživatel nainstaluje základní zdroj zásad zabezpečení. Azure Policy poskytuje integrovanou iniciativu podle směrného plánu , která se mapuje na základní zásady zabezpečení podle směrného plánu.
V případě zásad zabezpečení s omezením úrovně Standard Uživatel nainstaluje prostředek pod omezením zásad zabezpečení. Azure Policy poskytuje integrovaný s omezenou iniciativou , která se mapuje na zásadu zabezpečení s omezením pod.

Povolit zásadu zabezpečení pod v clusteru AKS

Pomocí příkazu AZ AKS Update můžete povolit nebo zakázat zásadu zabezpečení pod. Následující příklad povolí zásady zabezpečení pro název clusteru myAKSCluster ve skupině prostředků s názvem myResourceGroup.

Poznámka

Pro reálné použití nepovolujte zásady zabezpečení pod, dokud nedefinujete vlastní zásady. V tomto článku aktivujete zásadu zabezpečení pod prvním krokem, abyste viděli, jak výchozí zásady omezují na pod nasazeními.

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

Výchozí zásady AKS

Když zapnete zásadu zabezpečení pod, AKS vytvoří jednu výchozí zásadu s názvem Privileged. Neupravujte ani neodstraňujte výchozí zásady. Místo toho vytvořte vlastní zásady, které definují nastavení, které chcete ovládat. Nejdřív se podíváme na to, jak tyto výchozí zásady ovlivňují nasazení pod.

Pokud chcete zobrazit dostupné zásady, použijte příkaz kubectl Get PSP , jak je znázorněno v následujícím příkladu.

$ kubectl get psp

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

Zásady zabezpečení Privileged pod se aplikují na každého ověřeného uživatele v clusteru AKS. Toto přiřazení se řídí ClusterRoles a ClusterRoleBindings. Použijte příkaz kubectl Get rolebindings a vyhledejte výchozí: Privileged: Binding v oboru názvů Kube-System :

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

Jak je znázorněno v následujícím zhuštěném výstupu, je režim PSP: Privileged ClusterRole přiřazen všem systémům: ověření uživatelé. Tato možnost poskytuje základní úroveň oprávnění bez definování vlastních zásad.

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

Je důležité porozumět tomu, jak tyto výchozí zásady pracují s požadavky uživatelů na plánování lusků předtím, než začnete vytvářet vlastní zásady zabezpečení pod. V následujících částech plánujeme některé lusky, aby viděli tyto výchozí zásady v akci.

Vytvoření testovacího uživatele v clusteru AKS

Ve výchozím nastavení platí, že když použijete příkaz AZ AKS Get-Credentials , přidají se do konfigurace přihlašovací údaje správce pro cluster AKS kubectl . Uživatel s rolí správce obchází vynucování zásad zabezpečení pod. Pokud pro clustery AKS používáte integraci Azure Active Directory, můžete se přihlásit pomocí přihlašovacích údajů uživatele bez oprávnění správce, aby se zobrazilo vynucování zásad v akci. V tomto článku vytvoříme účet testovacího uživatele v clusteru AKS, který můžete použít.

Vytvořte ukázkový obor názvů s názvem PSP-AKS pro zdroje testu pomocí příkazu kubectl Create Namespace . Pak vytvořte účet služby s názvem neadmin-User pomocí příkazu kubectl Create ServiceAccount :

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

V dalším kroku vytvořte RoleBinding pro uživatele bez správce , aby se v oboru názvů prováděly základní akce pomocí příkazu kubectl Create RoleBinding :

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

Vytváření příkazů aliasu pro správce a uživatele bez role správce

Chcete-li zvýraznit rozdíl mezi běžným uživatelem s rolí správce při použití nástroje kubectl a uživatelem bez role správce vytvořeným v předchozích krocích, vytvořte dva aliasy příkazového řádku:

  • Alias kubectl-admin je určen pro obvyklého uživatele správce a je vymezen na obor názvů PSP-AKS .
  • Alias kubectl-nonadminuser je pro uživatele, který není správce vytvořený v předchozím kroku, a má obor názvů PSP-AKS .

Vytvořte tyto dva aliasy, jak je znázorněno v následujících příkazech:

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

Testování vytvoření privilegovaného pod

Pojďme nejdřív otestovat, co se stane, když naplánujete pod, pomocí kontextu zabezpečení privileged: true . Tento kontext zabezpečení přestupňování oprávnění pod. V předchozí části, která ukázala výchozí zásady zabezpečení AKS pod, by měla zásada oprávnění zamítnout tuto žádost.

Vytvořte soubor s názvem nginx-privileged.yaml a vložte následující YAML manifest:

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

Vytvořte pod pomocí příkazu kubectl Applu a zadejte název manifestu YAML:

kubectl-nonadminuser apply -f nginx-privileged.yaml

V části se nezdařila plánovaná, jak je znázorněno v následujícím příkladu výstupu:

$ kubectl-nonadminuser apply -f nginx-privileged.yaml

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

V poli se nedosáhnou fáze plánování, takže před přesunutím na neexistují žádné prostředky, které by bylo možné odstranit.

Vytvoření testu neprivilegovaného pod

V předchozím příkladu specifikace pod požaduje privilegovanou eskalaci. Tento požadavek je odepřený pomocí výchozích zásad zabezpečení Privilege , takže se u něj nepovede naplánovat. Pojďme teď spustit stejný NGINX pod tím, že nebudete mít požadavek na eskalaci oprávnění.

Vytvořte soubor s názvem nginx-unprivileged.yaml a vložte následující YAML manifest:

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

Vytvořte pod pomocí příkazu kubectl Applu a zadejte název manifestu YAML:

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

V části se nezdařila plánovaná, jak je znázorněno v následujícím příkladu výstupu:

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

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

V poli se nedosáhnou fáze plánování, takže před přesunutím na neexistují žádné prostředky, které by bylo možné odstranit.

Vytvoření testu pod s konkrétním kontextem uživatele

V předchozím příkladu se image kontejneru automaticky pokusila použít kořen k navázání NGINX na port 80. Tato žádost byla zamítnutá pomocí výchozích zásad zabezpečení Privilege , takže se na začátku nespustí. Pojďme teď spustit stejný NGINX pod stejným kontextem uživatele, jako je třeba runAsUser: 2000 .

Vytvořte soubor s názvem nginx-unprivileged-nonroot.yaml a vložte následující YAML manifest:

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

Vytvořte pod pomocí příkazu kubectl Applu a zadejte název manifestu YAML:

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

V části se nezdařila plánovaná, jak je znázorněno v následujícím příkladu výstupu:

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

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

V poli se nedosáhnou fáze plánování, takže před přesunutím na neexistují žádné prostředky, které by bylo možné odstranit.

Vytvořit vlastní zásadu zabezpečení pod

Teď, když jste se seznámili s chováním výchozích zásad zabezpečení pod, Pojďme dát nesprávci možnost, aby nedokázali naplánovat lusky.

Pojďme vytvořit zásadu, která odmítne lusky, které požadují privilegovaný přístup. Další možnosti, například runAsUser nebo povolené svazky, nejsou výslovně omezeny. Tento typ zásady odepře požadavek na privilegovaný přístup, ale jinak umožňuje clusteru spustit požadované lusky.

Vytvořte soubor s názvem psp-deny-privileged.yaml a vložte následující YAML manifest:

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:
  - '*'

Vytvořte zásadu pomocí příkazu kubectl Apply a zadejte název manifestu YAML:

kubectl apply -f psp-deny-privileged.yaml

Pokud chcete zobrazit dostupné zásady, použijte příkaz kubectl Get PSP , jak je znázorněno v následujícím příkladu. Porovnejte zásadu PSP-Deny-Privilege s výchozími zásadami oprávnění , které byly vyhodnoceny v předchozích příkladech, a vytvořte pod ní. Zásady zakázaly jenom použití eskalace priv . Pro zásady PSP-Deny-Privilege neexistují žádná omezení pro uživatele nebo skupinu.

$ kubectl get psp

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            *          

Povolí uživatelskému účtu používat vlastní zásady zabezpečení pod.

V předchozím kroku jste vytvořili zásadu zabezpečení pod tím, že odmítnete lusky, které požadují privilegovaný přístup. Pokud chcete, aby se tato zásada použila, vytvořte roli nebo ClusterRole. Pak přidružíte jednu z těchto rolí pomocí RoleBinding nebo ClusterRoleBinding.

V tomto příkladu vytvořte ClusterRole, který umožňuje použít zásadu PSP-Deny-Privileged vytvořenou v předchozím kroku. Vytvořte soubor s názvem psp-deny-privileged-clusterrole.yaml a vložte následující YAML manifest:

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

Vytvořte ClusterRole pomocí příkazu kubectl Apply a zadejte název vašeho manifestu YAML:

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

Nyní vytvořte ClusterRoleBinding pro použití ClusterRole vytvořené v předchozím kroku. Vytvořte soubor s názvem psp-deny-privileged-clusterrolebinding.yaml a vložte následující YAML manifest:

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

Vytvořte ClusterRoleBinding pomocí příkazu kubectl Apply a zadejte název vašeho manifestu YAML:

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

Poznámka

V prvním kroku tohoto článku byla funkce zásady zabezpečení pod povolena v clusteru AKS. Doporučeným postupem bylo povolit funkci zásady zabezpečení pod, jenom když jste definovali vlastní zásady. To je fáze, kde byste povolili funkci zásady zabezpečení pod. Byla definována jedna nebo více vlastních zásad a k těmto zásadám byly přidruženy uživatelské účty. Teď můžete bezpečně povolit funkci zásady zabezpečení pod a minimalizovat problémy způsobené výchozími zásadami.

Otestování opětovného vytvoření neprivilegovaného objektu.

Když použijete vlastní zásadu zabezpečení pod a vytvoříte vazbu pro uživatelský účet, abyste mohli zásady používat, zkusíme znovu vytvořit Neprivilegovaný příkaz. Pomocí stejného nginx-privileged.yaml manifestu vytvořte pod pomocí příkazu kubectl Apply :

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

V části se úspěšně naplánovalo. Když zkontrolujete stav pod, pomocí příkazu kubectl Get lusky je spuštěný:

$ kubectl-nonadminuser get pods

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

Tento příklad ukazuje, jak můžete vytvořit vlastní zásady zabezpečení, které definují přístup ke clusteru AKS pro různé uživatele nebo skupiny. Výchozí zásady AKS poskytují těsné kontroly nad tím, jak se můžou lusky spouštět, takže vytvořte vlastní zásady, které pak správně definují potřebná omezení.

Pomocí příkazu kubectl Delete odstraňte Nginx s neprivilegovaným příkazem a zadejte název vašeho manifestu YAML:

kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Vyčištění prostředků

Pokud chcete zakázat zásadu zabezpečení pod, použijte znovu příkaz AZ AKS Update . Následující příklad zakáže zásady zabezpečení v názvu clusteru myAKSCluster ve skupině prostředků s názvem myResourceGroup:

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

Dále odstraňte ClusterRole a ClusterRoleBinding:

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

Odstraňte zásadu zabezpečení pomocí příkazu kubectl Delete a zadejte název manifestu YAML:

kubectl delete -f psp-deny-privileged.yaml

Nakonec odstraňte obor názvů PSP-AKS :

kubectl delete namespace psp-aks

Další kroky

Tento článek ukazuje, jak vytvořit zásadu zabezpečení pod tím, abyste zabránili použití privilegovaného přístupu. Existuje spousta funkcí, které může zásada vyhovět, jako je například typ svazku nebo uživatel RunAs. Další informace o dostupných možnostech najdete v referenční dokumentaci k zásadám zabezpečení Kubernetes pod.

Další informace o omezování síťového provozu najdete v tématu zabezpečení provozu mezi lusky pomocí zásad sítě v AKS.