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

Możesz stosować i wymuszać wbudowane zasady zabezpieczeń w klastrach Azure Kubernetes Service (AKS) przy użyciu Azure Policy. 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). Aby uzyskać pełną listę definicji zasad i inicjatyw usługi AKS, zobacz wbudowane definicje Azure Policy dla usługi AKS.

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

Wymagania wstępne

Przed rozpoczęciem potrzebne są następujące zasoby zainstalowane i skonfigurowane:

Przypisywanie wbudowanej definicji zasad lub inicjatywy

Definicję zasad lub inicjatywę można zastosować w portalu Azure, wykonując następujące czynności:

  1. Przejdź do usługi Azure Policy w portalu Azure 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 od audit do deny , aby zablokować nowe wdrożenia naruszające inicjatywę punktu odniesienia. 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.

Utwórz katalog dla konfiguracji narzędzia Terraform.

mkdir aks-use-azure-policy
cd aks-use-azure-policy

Tworzenie konfiguracji narzędzia Terraform

Utwórz plik main.tf i skopiuj do niego następującą przetestowaną przykładową konfigurację. Przykład jest przechowywany w repozytorium GitHub Azure Terraform. Konfiguracja:

  • Konfiguruje dostawcę Azure dla programu Terraform (azurerm).
  • Definiuje zmienne wejściowe dla istniejącej grupy zasobów i klastra AKS.
  • Pobiera istniejącą grupę zasobów i wbudowaną bazową inicjatywę zabezpieczeń podów.
  • Przypisuje inicjatywę do grupy zasobów przy ustawieniu efektu zasad na Deny.
terraform {
  required_version = ">= 1.6.0"
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}
provider "azurerm" {
  features {}
}
variable "resource_group_name" {
  description = "Name of the resource group that contains the existing AKS cluster."
  type = string
}
variable "aks_cluster_name" {
  description = "Name of the existing AKS cluster."
  type = string
}
data "azurerm_resource_group" "aks" {
  name = var.resource_group_name
}
data "azurerm_policy_set_definition" "aks_pod_security_baseline" {
  display_name = "Kubernetes cluster pod security baseline standards for Linux-based workloads"
}
resource "azurerm_resource_group_policy_assignment" "aks_pod_security_baseline" {
  name = "aks-pod-security-baseline"
  display_name = "Kubernetes cluster pod security baseline standards for Linux-based workloads"
  resource_group_id = data.azurerm_resource_group.aks.id
  policy_definition_id = data.azurerm_policy_set_definition.aks_pod_security_baseline.id
  parameters = jsonencode({
    effect = {
      value = "Deny"
    }
  })
}
output "aks_cluster_name" {
  description = "Name of the AKS cluster targeted by this policy assignment."
  value = var.aks_cluster_name
}

Opcjonalnie: Tworzenie i przypisywanie niestandardowej definicji zasad

Sekcja definicji zasad niestandardowych jest informacyjna i znajduje się poza zakresem tego artykułu. 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 dotyczące zabezpieczeń.
  • Zarządzanie kosztami.
  • Reguły specyficzne dla organizacji, takie jak konwencje nazewnictwa lub lokalizacje.

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

Azure Policy używa właściwości o nazwie templateInfo, której można użyć do zdefiniowania typu źródłowego szablonu ograniczenia. Podczas definiowania templateInfo w definicjach zasad nie można używać właściwości constraintTemplate ani constraint. Nadal musisz zdefiniować apiGroups i kinds. Aby uzyskać więcej informacji, zobacz Understanding Azure Policy effects (Opis efektów Azure Policy).

Po utworzeniu niestandardowej definicji zasad zobacz temat Przypisywanie definicji zasad, aby uzyskać instrukcję krok po kroku, jak przypisać zasadę do klastra.

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

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

Przetestuj, co się stanie, gdy zaplanujesz pod z kontekstem bezpieczeństwa 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 zasobnik za pomocą polecenia kubectl apply i podaj 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 NGINX z portem 80. Inicjatywa polityki odrzuca to żądanie, więc pod nie uruchamia się. Teraz spróbuj uruchomić ten sam NGINX zasobnik bez uprzywilejowanego dostępu.

  1. Utwórz plik o nazwie nginx-unprivileged.yaml i wklej do niego 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 za pomocą polecenia kubectl apply i podaj nazwę manifestu YAML.

    kubectl apply -f nginx-unprivileged.yaml
    
  3. Sprawdź stan poda za pomocą 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ń NGINX nieuprzywilejowany pod za pomocą polecenia kubectl delete i podaj nazwę manifestu YAML.

    kubectl delete -f nginx-unprivileged.yaml
    

Wykonaj poniższe kroki, aby przypisać wbudowaną inicjatywę Azure Policy do klastra usługi AKS przy użyciu narzędzia Terraform.

Pokazana wcześniej konfiguracja Terraform pobiera wbudowaną inicjatywę i przypisuje ją do grupy zasobów, w której znajduje się klaster AKS.

Inicjowanie konfiguracji narzędzia Terraform

Uruchom polecenie terraform init , aby zainicjować katalog roboczy programu Terraform i pobrać wymagane wtyczki dostawcy.

terraform init

Formatuj i zweryfikuj konfigurację

Uruchom polecenie terraform fmt , aby sformatować konfigurację programu Terraform.

terraform fmt

Uruchom polecenie terraform validate , aby zweryfikować składnię konfiguracji narzędzia Terraform.

terraform validate

Stosowanie konfiguracji narzędzia Terraform

Przed wdrożeniem konfiguracji podaj wartości dla następujących zmiennych:

  • resource_group_name
  • aks_cluster_name

Uruchom polecenie terraform apply , aby wdrożyć przypisanie Azure Policy.

terraform apply

Po wyświetleniu monitu wprowadź polecenie yes , aby potwierdzić wdrożenie.

Weryfikowanie instalacji Azure Policy

Po zakończeniu wdrażania sprawdź, czy składniki Azure Policy są uruchomione w klastrze usługi AKS.

kubectl get pods -n kube-system

Sprawdź, czy szablony ograniczeń usługi Gatekeeper zostały pomyślnie zainstalowane.

kubectl get constrainttemplates

Testowanie przypisania Azure Policy

Utwórz plik o nazwie privileged-pod.yaml.

apiVersion: v1
kind: Pod
metadata:
 name: privileged-pod
spec:
 containers:
 - name: nginx
   image: nginx
   securityContext:
     privileged: true

Zastosuj manifest w klastrze.

kubectl apply -f privileged-pod.yaml

Wdrożenie kończy się niepowodzeniem, ponieważ przypisanie zasad usługi Azure Policy blokuje uprzywilejowane kontenery naruszające skonfigurowane podstawowe standardy zabezpieczeń podów.

Wyłącz zasady lub inicjatywę

Usuń inicjatywę bazową w portalu Azure, wykonując następujące kroki:

  1. Przejdź do okienka Zasady w portalu Azure.
  2. Wybierz Przypisania.
  3. Wybierz wielokropek (...) na końcu wiersza dla inicjatywy standardów bazowych zabezpieczeń zasobników klastra Kubernetes dotyczących obciążeń opartych na systemie Linux.
  4. Wybierz opcję Usuń przypisanie.

Aby usunąć dodatek Azure Policy z klastra usługi AKS, zobacz Usuwanie dodatku.

Wyłącz zasady lub inicjatywę

Uruchom polecenie terraform destroy z katalogu zawierającego konfigurację narzędzia Terraform, aby usunąć przypisanie zasad utworzone przez ten przykład.

terraform destroy

Aby usunąć dodatek Azure Policy z klastra usługi AKS, zobacz Usuwanie dodatku.

Następne kroki

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