Udostępnij przez


Stosowanie zabezpieczeń wdrażania w celu wymuszenia najlepszych rozwiązań w usłudze Azure Kubernetes Service (AKS)

W tym artykule pokazano, jak za pomocą zabezpieczeń wdrożenia wymusić najlepsze rozwiązania w klastrze usługi Azure Kubernetes Service (AKS).

Przegląd

Uwaga / Notatka

Zabezpieczenia wdrożenia są domyślnie włączone w usłudze AKS Automatic.

W całym cyklu projektowania często występują błędy, problemy i inne problemy, jeśli początkowe wdrożenie zasobów Kubernetes obejmuje błędy konfiguracji. Aby złagodzić obciążenie związane z programowaniem na platformie Kubernetes, usługa Azure Kubernetes Service (AKS) oferuje zabezpieczenia wdrożenia. Zabezpieczenia wdrożenia wymuszają najlepsze rozwiązania dotyczące rozwiązania Kubernetes w klastrze usługi AKS za pomocą kontrolek usługi Azure Policy.

Zabezpieczenia wdrożenia oferują dwa poziomy konfiguracji:

  • Warn: Wyświetla komunikaty ostrzegawcze w terminalu kodu, aby powiadomić o wszelkich niezgodnych konfiguracjach klastra, ale nadal zezwala na wykonywanie żądania.
  • Enforce: wymusza zgodne konfiguracje, odmawiając i modyfikując wdrożenia, jeśli nie są zgodne z najlepszymi rozwiązaniami.

Po skonfigurowaniu zabezpieczeń wdrożenia dla opcji "Ostrzegaj" lub "Wymuszaj" zabezpieczenia wdrożenia programowo oceniają zasoby Kubernetes przy tworzeniu lub aktualizowaniu pod kątem zgodności. Zabezpieczenia wdrożenia zawierają również zagregowane informacje o zgodności w obciążeniach na poziomie poszczególnych zasobów za pośrednictwem pulpitu nawigacyjnego zgodności usługi Azure Policy w witrynie Azure Portal lub w interfejsie wiersza polecenia lub terminalu. Uruchomienie niezgodnego obciążenia wskazuje, że klaster nie jest zgodny z najlepszymi praktykami i że obciążenia na twoim klastrze są narażone na problemy spowodowane konfiguracją klastra.

Wymagania wstępne

Uwaga / Notatka

Administratorzy klastra nie potrzebują uprawnień usługi Azure Policy, aby włączyć lub wyłączyć zabezpieczenia wdrożenia. Wymagane jest jednak zainstalowanie dodatku usługi Azure Policy.

Zasady zabezpieczeń wdrożenia

W poniższej tabeli wymieniono zasady, które stają się aktywne, oraz docelowe zasoby kubernetes po włączeniu zabezpieczeń wdrożenia. Obecnie dostępne zabezpieczenia wdrożenia można wyświetlić w witrynie Azure Portal jako definicję usługi Azure Policy lub w artykule Wbudowane definicje usługi Azure Policy dla usługi Azure Kubernetes Service. Celem tej kolekcji jest utworzenie wspólnej i ogólnej listy najlepszych rozwiązań mających zastosowanie do większości użytkowników i przypadków użycia.

Zasady zabezpieczeń wdrożenia Wynik mutacji, jeśli jest dostępny
Nie można edytować poszczególnych węzłów N/A
Limity zasobów procesora CPU i pamięci kontenerów klastra Kubernetes nie powinny przekraczać określonych limitów Ustawia limity zasobów procesora na 500m, jeśli nie są ustawione, i ustawia limity pamięci na 500Mi, jeśli nie ma ścieżki.
Musi mieć reguły koligacji przeciw koligacji lub topologięSpreadConstraintsSet N/A
Brak etykiet specyficznych dla usługi AKS N/A
Kontenery klastra Kubernetes powinny używać tylko dozwolonych obrazów N/A
Zarezerwowane defekty puli systemu Usuwa CriticalAddonsOnly defekt z puli węzłów użytkownika, jeśli nie został ustawiony. AKS używa znacznika CriticalAddonsOnly, aby utrzymać zasobniki klientów z dala od puli systemu. Ta konfiguracja zapewnia wyraźne rozdzielenie składników usługi AKS i zasobników klientów oraz zapobiega eksmisji zasobników klientów, które nie tolerują zanieczyszczenia CriticalAddonsOnly.
Upewnij się, że kontenery klastra mają skonfigurowane sondy gotowości lub żywotności. N/A
Klastry Kubernetes powinny używać sterownika Container Storage Interface (CSI) StorageClass N/A
Usługi klastra Kubernetes powinny używać unikatowych selektorów N/A
Obrazy kontenerów klastra Kubernetes nie powinny zawierać najnowszego tagu obrazu N/A

Jeśli chcesz przesłać pomysł lub żądanie dotyczące zabezpieczeń wdrożenia, otwórz problem w repozytorium GitHub usługi AKS i dodaj [Deployment Safeguards request] go na początku tytułu.

Standardy bezpieczeństwa Podów w ochronie wdrożeń

Uwaga / Notatka

Podstawowe standardy zabezpieczeń zasobników są teraz domyślnie włączone w usłudze AKS w trybie automatycznym. Nie można wyłączyć podstawowych standardów zabezpieczeń Pod w AKS Automatic.

Zabezpieczenia wdrożenia obsługują również możliwość włączania standardów zabezpieczeń zasobników: Bazowego, Ograniczonego oraz Uprzywilejowanego. Aby zapewnić pomyślne wdrożenie obciążeń, upewnij się, że każdy manifest jest zgodny z wymaganiami Pod Security Baseline lub Restricted. Domyślnie usługa Azure Kubernetes Service używa uprzywilejowanych Standardów Bezpieczeństwa Podów.

Policy Komunikat o błędzie Napraw.
AppArmor AppArmor annotation values must be undefined/nil, runtime/default, or localhost/* lub AppArmor profile type must be one of: undefined/nil, RuntimeDefault, or Localhost Usuń dowolną specyfikację aplikacji AppArmor. Domyślnie Kubernetes stosuje ustawienia apparmor. "Na obsługiwanych hostach profil RuntimeDefault AppArmor jest stosowany domyślnie".
Przestrzenie nazw hosta Host network namespaces are disallowed: spec.hostNetwork is set to true' lub 'Host PID namespaces are disallowed: spec.hostPID is set to true' lub 'Host IPC namespaces are disallowed: spec.hostIPC is set to true' Ustaw te wartości na wartość false lub usuń określanie pól.
Kontenery uprzywilejowane 'Privileged [ephemeral\|init\|N/A] containers are disallowed: spec.containers[*].securityContext.privileged is set to true' Ustaw odpowiednie pole securityContext.privileged na wartość false lub usuń pole.
Capabilities Komunikat rozpocznie się od 'Disallowed capabilities detected Usuń możliwość wyświetlaną z manifestu kontenera.
Woluminy HostPath HostPath volumes are forbidden under restricted security policy unless containers mounting them are from allowed images Usuń wolumin HostPath i instalację woluminu.
Porty hosta HostPorts są zabronione w ramach podstawowej polityki bezpieczeństwa Usuń specyfikację portu hosta z wadliwego kontenera.
SELinux SELinux type must be one of: undefined/empty, container_t, container_init_t, container_kvm_t, or container_engine_t Ustaw pole securityContext.seLinuxOptions.type kontenera na jedną z dozwolonych wartości.
/proc Typ montowania Element ProcMount musi być niezdefiniowany/zerowy lub domyślny w pliku spec.containers[*].securityContext.procMount Ustaw "* spec.containers[*].securityContext.procMount" na 'Domyślny' lub pozostaw niezdefiniowane.
Seccomp Seccomp profile must not be explicitly set to Unconfined. Allowed values are: undefined/nil, RuntimeDefault, or Localhost Ustaw securityContext.seccompProfile.type na zasobniku lub kontenerach jedną z dozwolonych wartości.
Sysctls Disallowed sysctl detected. Only baseline Kubernetes pod security standard sysctls are permitted Usuń niedozwolone sysctls (zobacz specyfikację OSS dla określonej listy).
Typy woluminów (tylko z ograniczeniami PSS) Only the following volume types are allowed under restricted policy: configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret Usuń wszystkie woluminy, które nie są jednym z dozwolonych typów.
Eskalacja uprawnień (tylko z ograniczeniami PSS) Privilege escalation must be set to false under restricted policy * spec.containers[*].securityContext.allowPrivilegeEscalation" musi być jawnie ustawiona na wartość false dla każdego kontenera, kontenera inicjalizującego i kontenera tymczasowego.
Uruchamianie jako użytkownik bez uprawnień głównego użytkownika (dotyczy wyłącznie ograniczeń PSS) Containers must not run as root user in spec.containers[*].securityContext.runAsNonRoot spec.containers[*].securityContext.runAsNonRoot musi być jawnie ustawiona na wartość false dla każdego kontenera, initContainer i efemerycznego kontenera.
Uruchom jako użytkownik niebędący użytkownikiem głównym (tylko z ograniczeniami PSS) 'Containers must not run as root user: spec.securityContext.runAsUser is set to 0' Ustaw wartość securityContext.runAsUser na wartość inną niż zero lub pozostaw ją niezdefiniowaną dla poziomu poda, a każdy kontener, initContainer i ephemeralContainer.
Seccomp (tylko z ograniczeniami PSS) Seccomp profile must be "RuntimeDefault" or "Localhost" under restricted policy Ustaw securityContext.seccompProfile.type na zasobniku lub kontenerach jedną z dozwolonych wartości. Różni się to od punktu odniesienia, ponieważ zasady z ograniczeniami nie zezwalają na niezdefiniowaną wartość.
Możliwości (tylko z ograniczeniami PSS) All containers must drop ALL capabilities under restricted policy lub Only NET_BIND_SERVICE may be added to capabilities under restricted policy Wszystkie kontenery muszą usuwać możliwości "ALL" i mogą dodawać tylko "NET_BIND_SERVICE".

Włączanie zabezpieczeń wdrożenia

Uwaga / Notatka

Użycie poziomu zabezpieczeń Enforce wdrożenia oznacza, że decydujesz się na blokowanie i wyciszanie wdrożeń. Przed włączeniem Enforce, rozważ, jak te zasady mogą współdziałać z klastrem usługi AKS.

Włączanie zabezpieczeń wdrożenia w istniejącym klastrze

Włącz zabezpieczenia wdrożenia w istniejącym klastrze z włączonym dodatkiem usługi Azure Policy za pomocą az aks safeguard create polecenia z flagą --level . Jeśli chcesz otrzymywać ostrzeżenia o niezgodności, ustaw --level na Warn. Jeśli chcesz zablokować lub zmutować wszystkie niezgodne wdrożenia, ustaw to na Enforce.

az aks safeguards create --resource-group <resource-group-name> --name <cluster-name> --level Enforce 

Można również włączyć zabezpieczenia wdrożenia przy użyciu --cluster flagi i określenia identyfikatora zasobu klastra.

az aks safeguards create --cluster <ID> --level Enforce

Jeśli chcesz zaktualizować poziom zabezpieczeń wdrożenia istniejącego klastra, uruchom następujące polecenie z nową wartością .--level

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn 

Wykluczanie przestrzeni nazw

Można również wykluczyć niektóre przestrzenie nazw z obszaru Zabezpieczenia wdrożenia. Jeśli wykluczysz przestrzeń nazw, działanie w tej przestrzeni nazw nie ma wpływu na ostrzeżenia lub wymuszanie zabezpieczeń wdrożenia.

Aby na przykład wykluczyć przestrzenie ns1 nazw i ns2, użyj rozdzielonej spacją listy przestrzeni nazw z flagą --excluded-ns , jak pokazano w poniższym przykładzie:

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --excluded-ns ns1 ns2 

Włączanie standardów zabezpieczeń Podów

Uwaga / Notatka

Usługa Azure Kubernetes Service (AKS) domyślnie używa Privileged standardów zabezpieczeń Pod. Jeśli chcesz przywrócić domyślną konfigurację, ustaw flagę --pss-level na Privileged.

Aby włączyć standardy zabezpieczeń podów w zabezpieczeniach wdrożenia, użyj flagi --pss-level i wybierz jeden z następujących poziomów: Baseline, Restricted lub Privileged.

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --pss-level <Baseline|Restricted|Privileged>

Aktualizowanie wersji zabezpieczeń wdrożenia

Zabezpieczenia wdrożenia są zgodne ze schematem przechowywania wersji dodatków usługi AKS. Każda nowa wersja zabezpieczeń wdrożenia zostanie wydana jako nowa wersja pomocnicza w usłudze AKS. Te aktualizacje będą przekazywane za pośrednictwem informacji o wersji usługi GitHub usługi AKS i zostaną odzwierciedlone w tabeli "Zasady zabezpieczeń wdrożenia" w naszej dokumentacji.

Aby dowiedzieć się więcej na temat przechowywania wersji i dodatków usługi AKS, zapoznaj się z następującą dokumentacją: aks-component-versions i aks-versioning-for-addons.

Weryfikowanie zgodności między klastrami

Po wdrożeniu manifestu platformy Kubernetes w interfejsie wiersza polecenia lub terminalu zostaną wyświetlone ostrzeżenia lub potencjalny komunikat odmowy, jeśli klaster nie jest zgodny z zabezpieczeniami wdrożenia, jak pokazano w poniższych przykładach:

ostrzegaj

$ kubectl apply -f deployment.yaml
Warning: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
deployment.apps/simple-web created

wymuszanie

Dzięki mutacjom zabezpieczeń wdrożenia poziom Enforce modyfikuje zasoby Kubernetes, gdy ma to zastosowanie. Jednak zasoby Kubernetes nadal muszą przejść wszystkie zabezpieczenia, aby zostać pomyślnie wdrożone. Jeśli jakiekolwiek polisy ochrony nie powiodą się, zasób zostanie odrzucony i nie zostanie wdrożony.

$ kubectl apply -f deployment.yaml 
Error from server (Forbidden): error when creating "deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing

Jeśli zasoby Platformy Kubernetes są zgodne z odpowiednimi zabezpieczeniami mutacji i spełniają wszystkie inne wymagania zabezpieczające, zostaną one pomyślnie wdrożone, jak pokazano w poniższym przykładzie:

$ kubectl apply -f deployment.yaml
deployment.apps/simple-web created

Weryfikowanie zgodności między klastrami przy użyciu pulpitu nawigacyjnego usługi Azure Policy

Aby sprawdzić, czy zastosowano zabezpieczenia wdrożenia i sprawdzić zgodność klastra, przejdź do strony witryny Azure Portal dla klastra i wybierz pozycję Zasady, a następnie wybierz pozycję Azure Policy.

Z listy zasad i inicjatyw wybierz inicjatywę skojarzoną z zabezpieczeniami wdrożenia. Widzisz pulpit nawigacyjny pokazujący stan zgodności w całym klastrze usługi AKS.

Uwaga / Notatka

Aby prawidłowo ocenić zgodność w klastrze usługi AKS, inicjatywa usługi Azure Policy musi być ograniczona do grupy zasobów klastra.

Wyłączanie zabezpieczeń wdrożenia

Aby wyłączyć zabezpieczenia wdrożenia w klastrze, użyj delete polecenia .

az aks safeguards delete --resource-group <resource-group-name> --name <cluster-name>

Często zadawane pytania

Czy mogę utworzyć własne mutacje?

Nie. Jeśli masz pomysł na zabezpieczenie, otwórz problem w repozytorium GitHub usługi AKS i dodaj [Deployment Safeguards request] go na początku tytułu.

Czy mogę wybrać, które mutacje chcę w egzekwowaniu?

Nie. Zabezpieczenia wdrożenia to wszystko lub nic. Po włączeniu opcji Ostrzegaj lub Wymuszaj wszystkie zabezpieczenia są aktywne.

Dlaczego mój zasób wdrożeniowy został zaakceptowany, mimo że nie przestrzegał najlepszych praktyk?

Zabezpieczenia wdrożenia wymuszają standardy najlepszych rozwiązań za pomocą mechanizmów kontroli usługi Azure Policy i mają zasady sprawdzające poprawność względem zasobów platformy Kubernetes. Aby ocenić i wymusić składniki klastra, usługa Azure Policy rozszerza usługę Gatekeeper. Wymuszanie mechanizmu typu gatekeeper działa również obecnie w fail-open modelu. Ponieważ nie ma gwarancji, że usługa Gatekeeper reaguje na nasze wywołanie sieciowe, upewniamy się, że w takim przypadku weryfikacja zostanie pominięta, aby odmowa nie blokowała wdrożeń.

Aby dowiedzieć się więcej, zobacz Walidacja obciążenia w usłudze Gatekeeper.

Dalsze kroki