Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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
- 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.
Przed rozpoczęciem potrzebne są następujące zasoby zainstalowane i skonfigurowane:
- 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.
- Program Terraform w wersji 1.6.0 lub nowszej.
- Azure CLI w wersji 2.47.0 lub nowszej. Aby zainstalować lub zaktualizować Azure CLI, zobacz Zainstaluj Azure CLI.
- Narzędzie Kubectl zostało 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:
- Przejdź do usługi Azure Policy w portalu Azure o nazwie Zasady.
- W okienku po lewej stronie usługi 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ę standardów bazowych zabezpieczeń zasobników klastra Kubernetes dla obciążeń bazujących na systemie Linux.
- Wybierz Przypisz.
- Ustaw Zakres na grupę zasobów klastra AKS, z włączonym dodatkiem Azure Policy.
- Wybierz stronę Parametry i zaktualizuj efekt od
auditdodeny, 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. - 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
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
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.
Utwórz plik o nazwie
nginx-privileged.yamli 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: trueUtwórz zasobnik za pomocą polecenia
kubectl applyi podaj nazwę manifestu YAML.kubectl apply -f nginx-privileged.yamlNie 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.
Utwórz plik o nazwie
nginx-unprivileged.yamli 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-alpineUtwórz zasobnik za pomocą polecenia
kubectl applyi podaj nazwę manifestu YAML.kubectl apply -f nginx-unprivileged.yamlSprawdź stan poda za pomocą polecenia
kubectl get pods.kubectl get podsDane 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 18sW tym przykładzie pokazano inicjatywę bazową wpływającą tylko na wdrożenia naruszające zasady w zbiorze. Dozwolone wdrożenia nadal działają.
Usuń
NGINXnieuprzywilejowany pod za pomocą poleceniakubectl deletei 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_nameaks_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:
- Przejdź do okienka Zasady w portalu Azure.
- Wybierz Przypisania.
- Wybierz wielokropek (
...) na końcu wiersza dla inicjatywy standardów bazowych zabezpieczeń zasobników klastra Kubernetes dotyczących obciążeń opartych na systemie Linux. - 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: