Zabezpieczanie klastrów Azure Kubernetes Service (AKS) przy użyciu Azure Policy

Artykuł
06/21/2023

Możesz stosować i wymuszać wbudowane zasady zabezpieczeń w klastrach Azure Kubernetes Service (AKS) przy użyciu Azure Policy. Azure Policy pomaga wymuszać standardy organizacyjne i oceniać zgodność na dużą skalę. Po zainstalowaniu dodatku 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 Azure Policy wbudowane definicje 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 usługi AKS. Jeśli potrzebujesz klastra usługi AKS, możesz go utworzyć przy użyciu interfejsu wiersza polecenia platformy Azure, Azure PowerShell lub Azure Portal.
Potrzebujesz dodatku Azure Policy dla usługi AKS zainstalowanego w klastrze usługi AKS.

Przypisywanie wbudowanej definicji lub inicjatywy zasad

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

Przejdź do usługi Azure Policy w Azure Portal o nazwie Zasady.
W lewym okienku strony Azure Policy wybierz pozycję Definicje.
W obszarze Kategorie wybierz pozycję Kubernetes.
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 .
Wybierz opcję Przypisz.
Ustaw pozycję Zakres na grupę zasobów klastra usługi AKS z włączonym dodatkiem Azure Policy.
Wybierz stronę Parametry i zaktualizuj efekt od audit , aby deny 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.
Wybierz pozycję Przejrzyj i utwórz,> aby przesłać przypisanie zasad.

Tworzenie i przypisywanie niestandardowej definicji zasad

Zasady niestandardowe umożliwiają definiowanie reguł na potrzeby 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 twój przypadek jest już uwzględniony.

Definicje zasad niestandardowych są zapisywane w formacie JSON. Aby dowiedzieć się więcej na temat tworzenia zasad niestandardowych, zobacz Azure Policy struktura definicji i Tworzenie niestandardowej definicji zasad.

Uwaga

Azure Policy teraz korzysta 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 irodzaje. Aby uzyskać więcej informacji na ten temat, zobacz Understanding Azure Policy effects (Opis efektów 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 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.

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

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.

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

Utwórz zasobnik przy użyciu kubectl apply polecenia i określ nazwę manifestu YAML.
```
kubectl apply -f nginx-unprivileged.yaml
```
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ę odniesienia mającą wpływ tylko na wdrożenia naruszające zasady w kolekcji. Dozwolone wdrożenia nadal działają.
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 Azure Portal, wykonując następujące kroki:

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

Następne kroki

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