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

  • Artykuł

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

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ę Punkt odniesienia zabezpieczeń zasobnika klastra Kubernetes dla inicjatywy obciążeń opartych na systemie Linux.
  5. Zaznacz Przypisz.
  6. Ustaw pozycję Zakres na grupę zasobów klastra usługi AKS z włączonym dodatkiem usługi Azure Policy.
  7. Wybierz stronę Parametry i zaktualizuj efekt od audit dodeny, aby zablokować nowe wdrożenia naruszające inicjatywę punktu odniesienia. Możesz również dodać dodatkowe przestrzenie nazw do wykluczenia z oceny. W tym przykładzie zachowaj wartości domyślne.
  8. Wybierz pozycję Przejrzyj i 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 właściwości templateInfo w definicjach zasad nie trzeba definiować właściwości ograniczeń ani ograniczeń . Nadal musisz zdefiniować grupy apiGroup i rodzaje. 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 planujesz zasobnik z kontekstem zabezpieczeń privileged: true. Ten kontekst zabezpieczeń eskaluje uprawnienia zasobnika. Inicjatywa nie zezwala na uprzywilejowane zasobniki, więc żądanie jest odrzucane, co powoduje odrzucenie wdrożenia.

  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 zasobnik przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

    kubectl apply -f nginx-privileged.yaml

    Zgodnie z oczekiwaniami nie można zaplanować zasobnika, jak pokazano w następujących przykładowych danych wyjściowych:

    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}

    Zasobnik nie osiąga etapu planowania, dlatego przed przejściem 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 zasad odrzuca to żądanie, więc nie można uruchomić zasobnika. Teraz spróbujmy uruchomić ten sam zasobnik 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 zasobnik przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.

    kubectl apply -f nginx-unprivileged.yaml

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

    kubectl get pods

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

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

    W tym przykładzie pokazano inicjatywę punktu odniesienia wpływającą tylko na wdrożenia naruszające zasady w kolekcji. 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łączanie zasad lub inicjatywy

Inicjatywę punktu odniesienia można usunąć w witrynie Azure Portal, wykonując następujące kroki:

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

Następne kroki

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