Zabezpečení clusterů Azure Kubernetes Service (AKS) pomocí Azure Policy

Pomocí Azure Policy můžete použít a vynutit integrované zásady zabezpečení v clusterech Azure Kubernetes Service (AKS). Azure Policy pomáhá vynucovat standardy organizace a vyhodnocovat dodržování předpisů ve velkém. Po instalaci doplňku Azure Policy pro AKS můžete do clusteru použít jednotlivé definice zásad nebo skupiny definic zásad označované jako iniciativy (někdy označované jako sady zásad). Úplný seznam definic zásad a iniciativ AKS najdete v tématu Azure Policy předdefinovaných definic pro AKS.

V tomto článku se dozvíte, jak u clusteru použít definice zásad a ověřit, že se tato přiřazení vynucují.

Požadavky

• Tento článek předpokládá, že máte existující cluster AKS. Pokud potřebujete cluster AKS, můžete ho vytvořit pomocí Azure CLI, Azure PowerShell nebo Azure Portal.
• V clusteru AKS musíte mít nainstalovaný doplněk Azure Policy pro AKS.

Přiřazení předdefinované definice zásad nebo iniciativy

Definici zásad nebo iniciativu můžete použít v Azure Portal pomocí následujícího postupu:

1. Přejděte do služby Azure Policy v Azure Portal s názvem Zásady.
2. V levém podokně stránky Azure Policy vyberte Definice.
3. V části Kategorie vyberte Kubernetes.
4. Zvolte definici zásady nebo iniciativu, kterou chcete použít. V tomto příkladu vyberte iniciativu Standardní standardy zabezpečení podů clusteru Kubernetes pro úlohy založené na Linuxu .
5. Vyberte Přiřadit.
6. Nastavte Obor na skupinu prostředků clusteru AKS s povoleným doplňkem Azure Policy.
7. Vyberte stránku Parametry a aktualizujte efekt od audit na , deny aby blokovala nová nasazení, která porušují iniciativu směrného plánu. Můžete také přidat další obory názvů, které se z vyhodnocení vyloučí. V tomto příkladu ponechte výchozí hodnoty.
8. Výběrem možnosti Zkontrolovat a vytvořit>vytvořit odešlete přiřazení zásady.

Vytvoření a přiřazení vlastní definice zásad

Vlastní zásady umožňují definovat pravidla pro používání Azure. Můžete například vynutit následující typy pravidel:

• Postupy zabezpečení
• Správa nákladů
• Pravidla specifická pro organizaci (například pro pojmenování nebo umístění)

Před vytvořením vlastní zásady si projděte seznam běžných vzorů a ukázek a zjistěte, jestli váš případ už není pokrytý.

Definice vlastních zásad se zapisují ve formátu JSON. Další informace o vytváření vlastních zásad najdete v tématech Azure Policy struktury definic a Vytvoření vlastní definice zásady.

Poznámka

Azure Policy nyní využívá novou vlastnost označovanou jako templateInfo, která umožňuje definovat typ zdroje pro šablonu omezení. Když v definicích zásad definujete templateInfo , nemusíte definovat vlastnosti constraintTemplate nebo constraint . Stále je potřeba definovat apiGroups a druhy. Další informace najdete v tématu Vysvětlení efektů Azure Policy.

Jakmile vytvoříte vlastní definici zásad, projděte si téma Přiřazení definice zásady , kde najdete podrobný návod k přiřazení zásad ke clusteru Kubernetes.

Ověření spuštění Azure Policy

• Pomocí následujícího kubectl get příkazu ověřte, že se přiřazení zásad používají pro váš cluster.

  kubectl get constrainttemplates
  

  Poznámka

  Synchronizace přiřazení zásad do každého clusteru může trvat až 20 minut .

  Výstup by se měl podobat následujícímu příkladu:

  NAME                                     AGE
  k8sazureallowedcapabilities              23m
  k8sazureallowedusersgroups               23m
  k8sazureblockhostnamespace               23m
  k8sazurecontainerallowedimages           23m
  k8sazurecontainerallowedports            23m
  k8sazurecontainerlimits                  23m
  k8sazurecontainernoprivilege             23m
  k8sazurecontainernoprivilegeescalation   23m
  k8sazureenforceapparmor                  23m
  k8sazurehostfilesystem                   23m
  k8sazurehostnetworkingports              23m
  k8sazurereadonlyrootfilesystem           23m
  k8sazureserviceallowedports              23m
  

Ověření zamítnutí privilegovaného podu

Nejprve otestujeme, co se stane, když naplánujete pod s kontextem privileged: truezabezpečení . Tento kontext zabezpečení eskaluje oprávnění podu. Iniciativa zakáže privilegované pody, takže požadavek se odmítne, což má za následek zamítnutí nasazení.

1. Vytvořte soubor s názvem nginx-privileged.yaml a vložte do 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.15.5-alpine
         securityContext:
           privileged: true
   

2. Vytvořte pod příkazem kubectl apply a zadejte název manifestu YAML.

   kubectl apply -f nginx-privileged.yaml
   

   Podle očekávání se pod nepodaří naplánovat, jak je znázorněno v následujícím příkladu výstupu:

   Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}
   

   Pod se nedostane do fáze plánování, takže před tím, než budete pokračovat, nejsou k dispozici žádné prostředky, které by bylo potřeba odstranit.

Testovací vytvoření neprivilegovaného podu

V předchozím příkladu se image kontejneru automaticky pokusila použít root k vytvoření vazby NGINX na port 80. Iniciativa zásad tento požadavek odmítne, takže se pod nespustí. Teď zkusíme spustit stejný pod NGINX bez privilegovaného přístupu.

1. Vytvořte soubor s názvem nginx-unprivileged.yaml a vložte do 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.15.5-alpine
   

2. Vytvořte pod příkazem kubectl apply a zadejte název manifestu YAML.

   kubectl apply -f nginx-unprivileged.yaml
   

3. Pomocí příkazu zkontrolujte stav podu kubectl get pods .

   kubectl get pods
   

   Výstup by se měl podobat následujícímu příkladu, který ukazuje, že pod je úspěšně naplánovaný a má stav Spuštěno:

   NAME                 READY   STATUS    RESTARTS   AGE
   nginx-unprivileged   1/1     Running   0          18s
   

   Tento příklad ukazuje iniciativu směrného plánu, která ovlivňuje pouze nasazení, která porušují zásady v kolekci. Povolená nasazení budou dál fungovat.

4. Odstraňte neprivilegovaný pod NGINX pomocí kubectl delete příkazu a zadejte název manifestu YAML.

   kubectl delete -f nginx-unprivileged.yaml
   

Zakázání zásady nebo iniciativy

Základní iniciativu v Azure Portal můžete odebrat pomocí následujícího postupu:

1. Na Azure Portal přejděte do podokna Zásady.
2. Vyberte Zadání.
3. Vyberte tlačítko ... vedle standardních standardů zabezpečení podů clusteru Kubernetes pro iniciativu úloh založených na Linuxu .
4. Vyberte Odstranit zadání.

Další kroky

Další informace o tom, jak Azure Policy fungují, najdete v následujících článcích:

• Přehled služby Azure Policy
• Azure Policy iniciativ a zásad pro AKS
• Odeberte doplněk Azure Policy.