Zabezpečení clusteru pomocí zásad zabezpečení pro pody v prostředí Azure Kubernetes Service (AKS) (Preview)

Článek
10/24/2023

Důležité

Funkce zásad zabezpečení podů byla vyřazena 1. srpna 2023 a odebrána z AKS verze 1.25 a vyšší.

Doporučujeme migrovat na kontroler přístupu zabezpečení podu nebo zásady Azure, abyste zůstali v podpora Azure. Přístup k zabezpečení podů je integrované řešení zásad pro implementace jednoho clusteru. Pokud hledáte zásady na podnikové úrovni, je lepší volbou služba Azure Policy.

Než začnete

Tento článek předpokládá, že máte existující cluster AKS. Pokud potřebujete cluster AKS, vytvořte ho pomocí Azure CLI, Azure PowerShellu nebo webu 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 nainstalovat nebo upgradovat, přečtěte si téma instalace Azure CLI.

`aks-preview` Instalace rozšíření Azure CLI

Důležité

Funkce AKS ve verzi Preview jsou k dispozici na samoobslužné bázi. Verze Preview jsou poskytovány "tak, jak jsou" a "dostupné", a jsou vyloučené ze smluv o úrovni služeb a omezené záruky. Verze Preview AKS jsou částečně pokryty zákaznickou podporou na základě maximálního úsilí. Proto tyto funkce nejsou určené pro produkční použití. Další informace najdete v následujících článcích podpory:

Nainstalujte rozšíření aks-preview pomocí az extension add příkazu.
```
az extension add --name aks-preview
```
Pomocí příkazu aktualizujte na nejnovější verzi rozšíření az extension update .
```
az extension update --name aks-preview
```

Registrace příznaku `PodSecurityPolicyPreview` funkce

PodSecurityPolicyPreview Pomocí příkazu zaregistrujte příznak az feature register funkce.
```
az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
```
Zobrazení stavu Zaregistrované trvá několik minut.

Pomocí příkazu ověřte stav az feature show registrace.

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

Jakmile se stav projeví jako zaregistrovaný, aktualizujte registraci poskytovatele prostředků Microsoft.ContainerService pomocí az provider register příkazu.
```
az provider register --namespace Microsoft.ContainerService
```

Přehled zásad zabezpečení podů

Clustery Kubernetes používají kontrolery přístupu k zachycení požadavků na server rozhraní API při vytváření prostředku. Kontroler přístupu pak může ověřit požadavek na prostředek proti sadě pravidel nebo ztlumit prostředek a změnit parametry nasazení.

PodSecurityPolicy je kontroler přístupu, který ověřuje specifikaci podu, která 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živatel nebo skupina, které může kontejner spustit jako. Když se pokusíte nasadit prostředek, ve kterém specifikace podů nesplňují požadavky uvedené v zásadách zabezpečení podů, požadavek se odepře. Tato schopnost řídit, jaké pody je možné naplánovat v clusteru AKS, brání některým možným ohrožením zabezpečení nebo eskalací oprávnění.

Když povolíte zásady zabezpečení podů v clusteru AKS, použijí se některé výchozí zásady. Tyto zásady poskytují předdefinované prostředí, které definuje, jaké pody je možné naplánovat. Můžete ale narazit na problémy s nasazením podů, dokud nedefinujete vlastní zásady. Doporučeným přístupem je:

Vytvořte cluster AKS.
Definujte vlastní zásady zabezpečení podů.
Povolte funkci zásad zabezpečení podů.

Změny chování mezi zásadami zabezpečení podů a službou Azure Policy

Scénář	Zásady zabezpečení podů	Azure Policy
Instalace	Povolení funkce zásad zabezpečení podů	Povolení doplňku Azure Policy
Nasazení zásad	Nasazení prostředku zásad zabezpečení podu	Přiřaďte zásady Azure k oboru předplatného nebo skupiny prostředků. Doplněk Azure Policy se vyžaduje pro aplikace prostředků Kubernetes.
Výchozí zásady	Pokud jsou v AKS povolené zásady zabezpečení podů, použijí se výchozí zásady privilegovaných a neomezených oprávnění.	Nepoužijí se žádné výchozí zásady povolením doplňku Azure Policy. Zásady musíte explicitně povolit ve službě 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 pro skupinu prostředků clusteru AKS minimální roli vlastníka 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 oprávnění vlastníka nebo Přispěvatel zásad prostředků pro prostředek clusteru AKS. – Na webu Azure Portal je možné zásady přiřadit na úrovni skupiny pro správu, 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 se nevyžaduje žádné další přiřazení. Po přiřazení zásad v Azure můžou tyto zásady používat všichni uživatelé clusteru.
Použitelnost zásad	Uživatel správce obchází vynucení zásad zabezpečení podů.	Všichni uživatelé (správci a nesprávci) vidí stejné zásady. Na základě uživatelů neexistuje žádné speciální velikostí. Aplikaci zásad je možné vyloučit na úrovni oboru názvů.
Rozsah zásad	Zásady zabezpečení podů nejsou oborem názvů	Šablony omezení používané službou Azure Policy nejsou obory názvů.
Odepřít/auditovat/zmutovat akci	Zásady zabezpečení podů podporují pouze akce odepření. K vytvoření požadavků je možné použít výchozí hodnoty. Ověření je možné provést během žádostí o aktualizaci.	Azure Policy podporuje obě akce auditu a zamítnutí. Mutování zatím není podporováno.
Dodržování zásad zabezpečení podů	Před povolením zásad zabezpečení podů neexistuje žádný přehled o dodržování předpisů. Nekompatibilní pody vytvořené po povolení zásad zabezpečení podů jsou odepřeny.	Pody nedodržující předpisy, které existovaly před použitím zásad Azure, se zobrazí v porušení zásad. Pody, které nedodržují předpisy vytvořené po povolení zásad Azure, se zamítnou, pokud jsou zásady nastavené s účinkem zamítnutí.
Zobrazení zásad v clusteru	`kubectl get psp`	`kubectl get constrainttemplate` - Vrátí se všechny zásady.
Standard zásad zabezpečení podů – Privilegované	Prostředek zásad zabezpečení privilegovaného podu se ve výchozím nastavení vytvoří při povolování funkce.	Privilegovaný režim neznamená žádné omezení, proto je ekvivalentní tomu, že nemá žádné přiřazení azure Policy.
Standard zásad zabezpečení podů – standardní hodnoty nebo výchozí hodnoty	Uživatel nainstaluje prostředek standardních hodnot zásad zabezpečení podů.	Azure Policy poskytuje integrovanou základní iniciativu, která se mapuje na základní zásady zabezpečení podů.
Standard zásad zabezpečení podů – Omezené	Uživatel nainstaluje prostředek s omezenými zásadami zabezpečení podů.	Azure Policy poskytuje integrovanou omezenou iniciativu, která se mapuje na zásady zabezpečení omezeného podu.

Povolení zásad zabezpečení podů v clusteru AKS

Poznámka:

Pro skutečné použití nepovolujte zásady zabezpečení podů, dokud nedefinujete vlastní zásady. V tomto článku povolíme zásady zabezpečení podů jako první krok, abychom zjistili, jak výchozí zásady omezují nasazení podů.

Pomocí příkazu povolte zásady zabezpečení podů az aks update .

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

Výchozí zásady AKS

Když povolíte zásady zabezpečení podů, AKS vytvoří jednu výchozí zásadu s názvem privilegované. Neupravujte ani neodebívejte výchozí zásady. Místo toho vytvořte vlastní zásady, které definují nastavení, která chcete řídit. Nejprve se podíváme na to, co tyto výchozí zásady ovlivňují nasazení podů.

Pomocí příkazu zobrazte dostupné zásady kubectl get psp .
```
kubectl get psp
```
Výstup bude vypadat podobně jako v následujícím příkladu výstupu:
```
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í privilegovaného podu se použijí pro všechny ověřené uživatele v clusteru AKS. Toto přiřazení je řízeno ClusterRoles a ClusterRoleBindings.

Pomocí příkazu vyhledejte vazbu default:privileged: v oboru názvů kubectl get rolebindings kube-system.

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

Následující zhuštěný ukázkový výstup ukazuje, že psp:privilegedClusterRole je přiřazen k libovolnému systému:ověřeným uživatelům. Tato schopnost 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

Než začnete vytvářet vlastní zásady zabezpečení podů, je důležité pochopit, jak tyto výchozí zásady komunikují s požadavky uživatelů na plánování podů. V následujících několika částech naplánujeme několik podů, aby se zobrazily výchozí zásady v akci.

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

Při použití az aks get-credentials příkazu se ve výchozím nastavení do konfigurace kubectl přidají přihlašovací údaje správce clusteru AKS. Uživatel správce obchází vynucení zásad zabezpečení podů. Pokud pro clustery AKS používáte integraci Microsoft Entra, můžete se přihlásit pomocí přihlašovacích údajů uživatele, který není správcem, abyste viděli vynucení zásad v akci.

Pomocí příkazu vytvořte ukázkový obor názvů psp-aks pro testovací prostředky kubectl create namespace .
```
kubectl create namespace psp-aks
```
Pomocí příkazu vytvořte účet služby s názvem nonadmin-userkubectl create serviceaccount.
```
kubectl create serviceaccount --namespace psp-aks nonadmin-user
```
Vytvořte vazbu rolí pro uživatele bez oprávnění správce k provádění základních akcí v oboru názvů pomocí kubectl create rolebinding příkazu.
```
kubectl create rolebinding \
    --namespace psp-aks \
    psp-aks-editor \
    --clusterrole=edit \
    --serviceaccount=psp-aks:nonadmin-user
```

Vytvoření příkazů aliasů pro správce a uživatele bez oprávnění správce

Při použití kubectlmůžete zvýraznit rozdíly mezi běžným uživatelem správce a uživatelem, který není správcem, vytvořením dvou aliasů příkazového řádku:

Alias kubectl-admin pro běžného uživatele správce, který je vymezen na obor názvů psp-aks .
Alias kubectl-nonadminuser pro uživatele bez oprávnění správce vytvořeného v předchozím kroku, který je vymezen oborem oboru názvů psp-aks.

Pomocí následujících příkazů vytvořte tyto dva aliasy.

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

Otestování vytvoření privilegovaného podu

Pojďme otestovat, co se stane, když naplánujete pod s kontextem privileged: truezabezpečení . Tento kontext zabezpečení eskaluje oprávnění podu. Výchozí zásady zabezpečení AKS by měly tuto žádost odepřít.

Vytvořte soubor s názvem nginx-privileged.yaml a vložte do něj obsah následujícího 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

Vytvořte pod pomocí kubectl apply příkazu a zadejte název manifestu YAML.
```
kubectl-nonadminuser apply -f nginx-privileged.yaml
```
Následující příklad výstupu ukazuje, že se pod nepodařilo naplánovat:
```
Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []
```
Vzhledem k tomu, že se pod nedosahuje fáze plánování, nejsou před přechodem k dispozici žádné prostředky, které byste měli odstranit.

Vytvoření neprivilegovaného podu

V předchozím příkladu specifikace podu požadovala privilegovanou eskalaci. Tento požadavek je odepřen výchozími zásadami zabezpečení podů oprávnění , takže se pod nepodaří naplánovat. Zkusme spustit stejný pod NGINX bez požadavku na eskalaci oprávnění.

Vytvořte soubor s názvem nginx-unprivileged.yaml a vložte do něj obsah následujícího 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

Vytvořte pod pomocí kubectl apply příkazu a zadejte název manifestu YAML.
```
kubectl-nonadminuser apply -f nginx-unprivileged.yaml
```
Následující příklad výstupu ukazuje, že se pod nepodařilo naplánovat:
```
Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []
```
Vzhledem k tomu, že se pod nedosahuje fáze plánování, nejsou před přechodem k dispozici žádné prostředky, které byste měli odstranit.

Testování vytvoření podu s konkrétním kontextem uživatele

V předchozím příkladu se image kontejneru automaticky pokusila použít kořen k vytvoření vazby NGINX na port 80. Tento požadavek byl odepřen výchozími zásadami zabezpečení podů oprávnění , takže se pod nespustí. Zkusme spustit stejný pod NGINX s konkrétním kontextem uživatele, například runAsUser: 2000.

Vytvořte soubor s názvem nginx-unprivileged-nonroot.yaml a vložte do následujícího manifestu 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

Vytvořte pod pomocí kubectl apply příkazu a zadejte název manifestu YAML.
```
kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml
```
Následující příklad výstupu ukazuje, že se pod nepodařilo naplánovat:
```
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: []
```
Vzhledem k tomu, že se pod nedosahuje fáze plánování, nejsou před přechodem k dispozici žádné prostředky, které byste měli odstranit.

Vytvoření vlastních zásad zabezpečení podů

Teď, když jste viděli chování výchozích zásad zabezpečení podů, poskytneme uživatelům bez oprávnění správce možnost úspěšného plánování podů.

Vytvoříme zásadu, která odmítne pody, které požadují privilegovaný přístup. Jiné možnosti, například runAsUser nebo povolené svazky, nejsou explicitně omezené. Tento typ zásad odmítne požadavek na privilegovaný přístup, ale umožňuje clusteru spouštět požadované pody.

Vytvořte soubor s názvem psp-deny-privileged.yaml a vložte do následujícího manifestu 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:
 - '*'

Vytvořte zásadu kubectl apply pomocí příkazu a zadejte název manifestu YAML.
```
kubectl apply -f psp-deny-privileged.yaml
```
Pomocí příkazu zobrazte dostupné zásady kubectl get psp .
```
kubectl get psp
```
V následujícím příkladu výstupu porovnejte zásadu psp-deny-privileged s výchozí zásadou oprávnění , která byla vynucena v předchozích příkladech k vytvoření podu. Zásady odepře pouze použití eskalace PRIV . Neexistují žádná omezení pro uživatele nebo skupinu zásad psp-odepřít-privilegované .
```
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            *          
```

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

V předchozím kroku jste vytvořili zásadu zabezpečení podu, která odmítne pody, které požadují privilegovaný přístup. Chcete-li povolit použití zásady, vytvořte roli nebo roli clusteru. Potom přidružíte jednu z těchto rolí pomocí roleBinding nebo ClusterRoleBinding. V tomto příkladu vytvoříme role clusteru, která vám umožní 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 do následujícího manifestu 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

Pomocí příkazu vytvořte role clusteru kubectl apply a zadejte název manifestu YAML.
```
kubectl apply -f psp-deny-privileged-clusterrole.yaml
```

Vytvořte soubor s názvem psp-deny-privileged-clusterrolebinding.yaml a vložte do následujícího manifestu 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

Pomocí příkazu vytvořte ClusterRoleBinding kubectl apply a zadejte název manifestu YAML.
```
kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
```

Poznámka:

V prvním kroku tohoto článku byla v clusteru AKS povolená funkce zásad zabezpečení podů. Doporučeným postupem bylo povolit funkci zásad zabezpečení podů jenom po definování vlastních zásad. Toto je fáze, ve které byste povolili funkci zásad zabezpečení podů. Byly definovány některé vlastní zásady a k těmto zásadám byly přidružené uživatelské účty. Teď můžete bezpečně povolit funkci zásad zabezpečení podů a minimalizovat problémy způsobené výchozími zásadami.

Opětovné otestování vytvoření neprivilegovaného podu

Po použití vlastních zásad zabezpečení podů a vazby pro uživatelský účet pro použití zásad zkusíme znovu vytvořit neprivilegovaný pod.

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

Pomocí manifestu nginx-privileged.yaml vytvořte pod pomocí kubectl apply příkazu.
```
kubectl-nonadminuser apply -f nginx-unprivileged.yaml
```
Pomocí příkazu zkontrolujte stav podu kubectl get pods .
```
kubectl-nonadminuser get pods
```
Následující příklad výstupu ukazuje, že pod byl úspěšně naplánován a je spuštěný:
```
NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          7m14s
```
Odstraňte neprivilegovaný pod NGINX pomocí kubectl delete příkazu a zadejte název manifestu YAML.
```
kubectl-nonadminuser delete -f nginx-unprivileged.yaml
```

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

Pomocí příkazu zakažte zásady zabezpečení podů az aks update .

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

Pomocí příkazu odstraňte clusterRole a ClusterRoleBinding kubectl delete .
```
kubectl delete -f psp-deny-privileged-clusterrole.yaml
```

Pomocí příkazu odstraňte clusterRoleBinding kubectl delete .

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

Odstraňte zásady zabezpečení pomocí kubectl delete příkazu a zadejte název manifestu YAML.
```
kubectl delete -f psp-deny-privileged.yaml
```
Odstraňte obor názvů psp-aks pomocí kubectl delete příkazu.
```
kubectl delete namespace psp-aks
```

Další kroky

Tento článek vám ukázal, jak vytvořit zásady zabezpečení podů, které zabrání použití privilegovaného přístupu. Zásady můžou vynucovat spoustu funkcí, jako je typ svazku nebo uživatel Spustit jako. Další informace o dostupných možnostech najdete v dokumentaci k referenčním informacím o zásadách zabezpečení podů Kubernetes.

Další informace o omezení síťového provozu podů najdete v tématu Zabezpečení provozu mezi pody pomocí zásad sítě v AKS.

Share via

Zabezpečení clusteru pomocí zásad zabezpečení pro pody v prostředí Azure Kubernetes Service (AKS) (Preview)

Než začnete

`aks-preview` Instalace rozšíření Azure CLI

Registrace příznaku `PodSecurityPolicyPreview` funkce

Přehled zásad zabezpečení podů

Změny chování mezi zásadami zabezpečení podů a službou Azure Policy

Povolení zásad zabezpečení podů v clusteru AKS

Výchozí zásady AKS

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

Vytvoření příkazů aliasů pro správce a uživatele bez oprávnění správce

Otestování vytvoření privilegovaného podu

Vytvoření neprivilegovaného podu

Testování vytvoření podu s konkrétním kontextem uživatele

Vytvoření vlastních zásad zabezpečení podů

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

Opětovné otestování vytvoření neprivilegovaného podu

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

Další kroky

Další materiály

Share via

Zabezpečení clusteru pomocí zásad zabezpečení pro pody v prostředí Azure Kubernetes Service (AKS) (Preview)

Než začnete

aks-preview Instalace rozšíření Azure CLI

Registrace příznaku PodSecurityPolicyPreview funkce

Přehled zásad zabezpečení podů

Změny chování mezi zásadami zabezpečení podů a službou Azure Policy

Povolení zásad zabezpečení podů v clusteru AKS

Výchozí zásady AKS

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

Vytvoření příkazů aliasů pro správce a uživatele bez oprávnění správce

Otestování vytvoření privilegovaného podu

Vytvoření neprivilegovaného podu

Testování vytvoření podu s konkrétním kontextem uživatele

Vytvoření vlastních zásad zabezpečení podů

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

Opětovné otestování vytvoření neprivilegovaného podu

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

Další kroky

Další materiály

`aks-preview` Instalace rozšíření Azure CLI

Registrace příznaku `PodSecurityPolicyPreview` funkce