Zabezpieczanie klastrów usługi Azure Kubernetes Service (AKS) za pomocą usługi Azure Policy

Za pomocą usługi Azure Policy można stosować i wymuszać wbudowane zasady zabezpieczeń w klastrach usługi Azure Kubernetes Service (AKS). Usługa Azure Policy pomaga wymuszać standardy organizacyjne i oceniać zgodność na dużą skalę. Po zainstalowaniu dodatku usługi Azure Policy dla usługi AKS można zastosować do klastra poszczególne definicje zasad lub grupy definicji zasad nazywanych inicjatywami (czasami nazywanymi zestawami zasad). Zobacz Wbudowane definicje usługi Azure Policy dla usługi AKS , aby uzyskać pełną listę definicji zasad i inicjatyw usługi AKS.

W tym artykule pokazano, jak zastosować definicje zasad do klastra i sprawdzić, czy te przypisania są wymuszane.

Wymagania wstępne

• W tym artykule założono, że masz istniejący klaster AKS. Jeśli potrzebujesz klastra usługi AKS, możesz go utworzyć przy użyciu interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub witryny Azure Portal.
• Musisz zainstalować dodatek Azure Policy dla AKS na swoim klastrze AKS.

Przypisywanie wbudowanej definicji zasad lub inicjatywy

Definicję lub inicjatywę zasad można zastosować w witrynie Azure Portal, wykonując następujące kroki:

1. Przejdź do usługi Azure Policy w witrynie Azure Portal o nazwie Zasady.
2. W okienku po lewej stronie usługi Azure Policy wybierz pozycję Definicje.
3. W obszarze Kategorie wybierz pozycję Kubernetes.
4. Wybierz definicję zasad lub inicjatywę, którą chcesz zastosować. W tym przykładzie wybierz inicjatywę standardów bazowych zabezpieczeń zasobników klastra Kubernetes dla obciążeń bazujących na systemie Linux.
5. Wybierz Przypisz.
6. Ustaw Zakres na grupę zasobów klastra AKS, z włączonym dodatkiem Azure Policy.
7. Wybierz stronę Parametry i zaktualizuj Efekt z audit na deny, aby zablokować nowe wdrożenia naruszające inicjatywę bazową. Możesz również dodać przestrzenie nazw, które mają być wykluczone z oceny. W tym przykładzie zachowaj wartości domyślne.
8. Wybierz pozycję Przejrzyj + utwórz>Utwórz, aby przesłać przypisanie zasad.

Tworzenie i przypisywanie niestandardowej definicji zasad

Zasady niestandardowe umożliwiają definiowanie reguł dotyczących korzystania z platformy Azure. Można na przykład wymusić następujące typy reguł:

• Rozwiązania z zakresu bezpieczeństwa
• Zarządzanie kosztami
• Reguły specyficzne dla organizacji (np. dotyczące nazewnictwa lub lokalizacji)

Przed utworzeniem zasad niestandardowych sprawdź listę typowych wzorców i przykładów , aby sprawdzić, czy sprawa jest już uwzględniona.

Definicje zasad niestandardowych są zapisywane w formacie JSON. Aby dowiedzieć się więcej na temat tworzenia zasad niestandardowych, zobacz Azure Policy definition structure (Struktura definicji usługi Azure Policy) i Create a custom policy definition (Tworzenie niestandardowej definicji zasad).

Uwaga

Usługa Azure Policy korzysta teraz z nowej właściwości znanej jako templateInfo , która umożliwia zdefiniowanie typu źródła dla szablonu ograniczenia. Podczas definiowania templateInfo w definicjach zasad nie trzeba definiować constraintTemplate ani constraint. Nadal musisz zdefiniować apiGroups i kinds. Aby uzyskać więcej informacji na ten temat, zobacz Omówienie efektów usługi Azure Policy.

Po utworzeniu niestandardowej definicji zasad zobacz Przypisywanie definicji zasad, aby zapoznać się z przewodnikiem krok po kroku dotyczącym przypisywania zasad do klastra Kubernetes.

Sprawdzanie, czy usługa Azure Policy jest uruchomiona

• Upewnij się, że przypisania zasad są stosowane do klastra przy użyciu następującego kubectl get polecenia.

  kubectl get constrainttemplates
  

  Uwaga

  Synchronizacja przypisań zasad z każdym klastrem może potrwać do 20 minut.

  Dane wyjściowe powinny być podobne do następujących przykładowych danych wyjściowych:

  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
  

Weryfikowanie odrzucenia uprzywilejowanego zasobnika

Najpierw przetestujmy, co się stanie, gdy zaplanujesz zasobnik z kontekstem zabezpieczeń privileged: true. Ten kontekst zabezpieczeń eskaluje uprawnienia zasobnika. Inicjatywa nie zezwala na uprzywilejowane kontenery, więc żądanie jest odrzucane, co powoduje, że wdrożenie zostaje odrzucone.

1. Utwórz plik o nazwie nginx-privileged.yaml i wklej następujący manifest 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. Utwórz pod za pomocą polecenia kubectl apply i określ nazwę manifestu YAML.

   kubectl apply -f nginx-privileged.yaml
   

   Nie można zaplanować podu, jak pokazano poniżej, zgodnie z oczekiwaniami.

   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 nie osiąga etapu planowania, więc zanim przejdziesz dalej, nie ma żadnych zasobów do usunięcia.

Testowanie tworzenia nieuprzywilejowanego zasobnika

W poprzednim przykładzie obraz kontenera automatycznie próbował użyć katalogu głównego do powiązania serwera NGINX z portem 80. Inicjatywa polityki odrzuca to żądanie, więc pod nie uruchamia się. Teraz spróbujmy uruchomić ten sam pod NGINX bez uprzywilejowanego dostępu.

1. Utwórz plik o nazwie nginx-unprivileged.yaml i wklej następujący manifest 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. Utwórz Pod za pomocą polecenia kubectl apply i określ nazwę swojego manifestu YAML.

   kubectl apply -f nginx-unprivileged.yaml
   

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

   kubectl get pods
   

   Dane wyjściowe powinny być podobne do następujących przykładowych danych wyjściowych, które pokazują, że pod został pomyślnie zaplanowany i ma stan Running:

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

   W tym przykładzie pokazano inicjatywę bazową wpływającą tylko na wdrożenia naruszające zasady w zbiorze. Dozwolone wdrożenia nadal działają.

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

   kubectl delete -f nginx-unprivileged.yaml
   

Wyłącz zasady lub inicjatywę

Podstawową inicjatywę można usunąć w portalu Azure, wykonując następujące kroki:

1. Przejdź do okienka Zasady w witrynie Azure Portal.
2. Wybierz Przypisania.
3. Wybierz przycisk ... obok standardów podstawowych zabezpieczeń zasobników klastra Kubernetes dla obciążeń opartych na systemie Linux.
4. Wybierz opcję Usuń przypisanie.

Następne kroki

Aby uzyskać więcej informacji na temat działania usługi Azure Policy, zobacz następujące artykuły:

• Omówienie zasad platformy Azure
• Inicjatywy i zasady usługi Azure Policy dla usługi AKS
• Usuń dodatek usługi Azure Policy.