Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Zabezpieczenia kontenerowe chronią kompletny potok od kompilacji do obciążeń aplikacji uruchamianych w usłudze Azure Kubernetes Service (AKS).
Łańcuch bezpiecznych dostaw obejmuje środowisko kompilacji i rejestr.
Platforma Kubernetes obejmuje składniki zabezpieczeń, takie jak standardy zabezpieczeń podów i tajemnice. Platforma Azure obejmuje składniki, takie jak Active Directory, Microsoft Defender for Containers, Azure Policy, Azure Key Vault, sieciowe grupy zabezpieczeń i aranżowane uaktualnienia klastrów. Usługa AKS łączy te składniki zabezpieczeń w następujące elementy:
- Podaj pełny scenariusz uwierzytelniania i autoryzacji.
- Zastosuj wbudowaną usługę Azure Policy w usłudze AKS, aby zabezpieczyć aplikacje.
- Kompleksowe szczegółowe informacje z kompilacji za pośrednictwem aplikacji za pomocą usługi Microsoft Defender for Containers.
- Zachowaj klaster usługi AKS z najnowszymi aktualizacjami zabezpieczeń systemu operacyjnego i wydaniami rozwiązania Kubernetes.
- Zapewnij bezpieczny ruch zasobników i dostęp do poufnych poświadczeń.
W tym artykule przedstawiono podstawowe koncepcje, które zabezpieczają aplikacje w usłudze AKS.
Ważne
Od 30 listopada 2025 r. usługa Azure Kubernetes Service (AKS) nie obsługuje już ani nie zapewnia aktualizacji zabezpieczeń dla systemu Azure Linux 2.0. Obraz węzła systemu Linux 2.0 platformy Azure został zamrożony w wersji 202512.06.0. Od 31 marca 2026 r. obrazy węzłów zostaną usunięte i nie będzie można skalować pul węzłów. Przeprowadź migrację do obsługiwanej wersji systemu Linux platformy Azure, uaktualniając pule węzłów do obsługiwanej wersji rozwiązania Kubernetes lub migrując do systemu osSku AzureLinux3. Aby uzyskać więcej informacji, zobacz [Wycofywanie] pul węzłów Azure Linux 2.0 w usłudze AKS.
Budowanie bezpieczeństwa
Jako punkt wejścia dla łańcucha dostaw ważne jest przeprowadzenie statycznej analizy kompilacji obrazów przed podwyższeniem poziomu potoku. Obejmuje to ocenę luk w zabezpieczeniach i zgodności. Nie chodzi o niepowodzenie kompilacji z powodu luki w zabezpieczeniach, ponieważ to zakłóca proces programowania. Chodzi o zapoznanie się ze stanem dostawcy w celu segmentacji na podstawie luk w zabezpieczeniach, którymi mogą się zająć zespoły programistyczne. Ponadto używaj okresów prolongaty, aby umożliwić deweloperom czas korygowania zidentyfikowanych problemów.
Zabezpieczenia rejestru
Ocena stanu podatności obrazu w rejestrze wykrywa odchylenia oraz identyfikuje obrazy, które nie pochodzą ze środowiska kompilacji. Użyj Notary V2, aby zakładać podpisy na obrazy i upewnij się, że wdrożenia pochodzą z zaufanej lokalizacji.
Zabezpieczenia klastra
W usłudze AKS składniki główne platformy Kubernetes są częścią usługi zarządzanej, zarządzanej i obsługiwanej przez firmę Microsoft. Każdy klaster usługi AKS ma własny, jedynodzierżawowy, dedykowany serwer główny Kubernetes, który zapewnia serwer interfejsu API, harmonogram itp. Aby uzyskać więcej informacji, zobacz Zarządzanie lukami w zabezpieczeniach dla usługi Azure Kubernetes Service.
Domyślnie serwer interfejsu API Kubernetes używa publicznego adresu IP i w pełni kwalifikowanej nazwy domeny (FQDN). Dostęp do punktu końcowego serwera interfejsu API można ograniczyć przy użyciu autoryzowanych zakresów adresów IP. Możesz również utworzyć w pełni prywatny klaster , aby ograniczyć dostęp serwera interfejsu API do sieci wirtualnej.
Dostęp do serwera interfejsu API można kontrolować przy użyciu kontroli dostępu opartej na rolach platformy Kubernetes (Kubernetes RBAC) i kontroli dostępu na podstawie ról platformy Azure. Aby uzyskać więcej informacji, zobacz Microsoft Entra integration with AKS (Integracja firmy Microsoft z usługą AKS).
Zabezpieczenia węzłów
Węzły usługi AKS to maszyny wirtualne platformy Azure, którymi zarządzasz i obsługujesz.
- Węzły systemu Linux uruchamiają zoptymalizowane wersje systemu Ubuntu lub Azure Linux.
- Węzły systemu Windows Server uruchamiają zoptymalizowaną wersję systemu Windows Server przy użyciu środowiska uruchomieniowego kontenera
containerd.
Po utworzeniu lub skalowaniu klastra usługi AKS węzły są automatycznie wdrażane przy użyciu najnowszych aktualizacji i konfiguracji zabezpieczeń systemu operacyjnego.
Uwaga
Działające klastry AKS:
- Kubernetes w wersji 1.19 i nowsze — pule węzłów systemu Linux używają
containerdjako środowisko wykonawcze kontenerów. Pule węzłów Windows Server 2019 i Windows Server 2022 używającontainerdjako środowisko uruchomieniowe kontenera. Aby uzyskać więcej informacji, zobacz Dodawanie puli węzłów systemu Windows Server za pomocącontainerd. - Platforma Kubernetes w wersji 1.19 lub starszej — pule węzłów systemu Linux używają platformy Docker jako środowiska uruchomieniowego kontenera.
Aby uzyskać więcej informacji na temat procesu uaktualniania zabezpieczeń dla węzłów roboczych systemu Linux i Windows, zobacz Węzły stosowania poprawek zabezpieczeń.
Klastry AKS uruchamiane na maszynach wirtualnych Azure generacji 2 obejmują obsługę zaufanego uruchamiania. Ta funkcja chroni przed zaawansowanymi i trwałymi technikami ataków, łącząc technologie, które można włączyć niezależnie, na przykład bezpieczny rozruch i zwirtualizowaną wersję modułu zaufanej platformy (vTPM). Administratorzy mogą wdrażać węzły robocze usługi AKS ze zweryfikowanymi i podpisanymi modułami ładujących, jądrami systemu operacyjnego i sterownikami, aby zapewnić integralność całego łańcucha rozruchu podstawowej maszyny wirtualnej.
Opcje systemu operacyjnego zoptymalizowane pod kątem kontenera i zabezpieczeń
Usługa AKS wydała obsługę dwóch nowych zoptymalizowanych opcji systemu operacyjnego Linux. Funkcja Azure Linux OS Guard (wersja zapoznawcza) jest tworzona i zoptymalizowana pod kątem platformy Azure. Funkcja OS Guard jest oparta na systemie Azure Linux z wyspecjalizowaną konfiguracją do obsługi konteneryzowanych obciążeń z optymalizacjami zabezpieczeń. Flatcar Container Linux for AKS (wersja zapoznawcza) to oparty na standardach CNCF i niezależny od dostawcy niezmienny system operacyjny zoptymalizowany pod kątem kontenerów, który najlepiej nadaje się do uruchamiania w środowiskach wielochmurowych i lokalnych. Te opcje systemu operacyjnego zapewniają większe bezpieczeństwo w porównaniu z innymi opcjami systemu operacyjnego Linux, takimi jak:
- Zarówno Azure Linux OS Guard, jak i Flatcar Container Linux dla usługi AKS mają niezmienny system operacyjny, którego nie można modyfikować w trakcie działania. Wszystkie pliki binarne systemu operacyjnego, biblioteki i konfiguracja statyczna są tylko do odczytu, a integralność bitów dla bitów jest często chroniona kryptograficznie. Te systemy operacyjne specjalnego przeznaczenia są dostarczane jako samodzielne obrazy i nie zawierają żadnego rodzaju zarządzania pakietami ani innych tradycyjnych sposobów zmiany systemu operacyjnego. Obciążenia użytkowników są uruchamiane w środowiskach izolowanych, takich jak kontenery, odizolowane od systemu operacyjnego.
- Zarówno usługa Azure Linux OS Guard, jak i flatcar Container Linux dla usługi AKS używają narzędzia SELinux do obowiązkowej kontroli dostępu.
- Funkcja Azure Linux OS Guard wymusza włączenie standardu FIPS i zaufanego uruchamiania , zapewniając lepszą zgodność i ochronę przed zaawansowanymi i trwałymi atakami dzięki połączeniu bezpiecznego rozruchu i zwirtualizowanej wersji zaufanego modułu platformy (vTPM).
Podczas podejmowania decyzji o tym, które opcje systemu operacyjnego zoptymalizowane pod kątem kontenera mają być używane, usługa AKS zaleca następujące kwestie:
- Użyj usługi Flatcar Container Linux dla usługi AKS (wersja zapoznawcza), jeśli szukasz neutralnego dla dostawcy niezmiennego systemu operacyjnego z obsługą wielu chmur.
- Użyj funkcji Azure Linux OS Guard (wersja zapoznawcza), jeśli szukasz niezmiennego systemu operacyjnego gotowego do użycia w przedsiębiorstwie, zalecanego przez firmę Microsoft.
- Użyj systemu Ubuntu , jeśli szukasz neutralnego dla dostawcy systemu operacyjnego ogólnego przeznaczenia z obsługą wielu chmur.
- Użyj platformy Azure w systemie Linux , jeśli szukasz systemu operacyjnego ogólnego przeznaczenia gotowego do użycia w przedsiębiorstwie, zalecanego przez firmę Microsoft.
Autoryzacja węzła
Autoryzacja węzła to tryb autoryzacji specjalnego przeznaczenia, który specjalnie autoryzuje żądania interfejsu API kubelet do ochrony przed atakami na Wschód-Zachód. Autoryzacja węzła jest domyślnie włączona w klastrach AKS 1.24 i wyższych.
Wdrażanie węzła
Węzły są wdrażane w podsieci prywatnej sieci wirtualnej bez przypisanych publicznych adresów IP. Na potrzeby rozwiązywania problemów i zarządzania protokół SSH jest domyślnie włączony i dostępny tylko przy użyciu wewnętrznego adresu IP. Wyłączenie protokołu SSH podczas tworzenia klastrów i pul węzłów lub dla istniejących klastrów lub pul węzłów jest w wersji próbnej. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem za pomocą protokołu SSH.
Przechowywanie węzłów
Aby zapewnić przechowywanie, węzły używają Dysków zarządzanych Azure. W przypadku większości rozmiarów węzłów maszyn wirtualnych (VM) Azure Dyski Zarządzane są dyskami warstwy Premium zasilane przez dyski SSD o wysokiej wydajności. Dane przechowywane na dyskach zarządzanych są automatycznie szyfrowane w spoczynku na platformie Azure. Aby poprawić redundancję, usługa Azure Managed Disks jest bezpiecznie replikowana w centrum danych Azure.
Nieprzyjazne obciążenia wielotenantowe
Obecnie środowiska Kubernetes nie są bezpieczne w przypadku wrogiego użycia wielodostępu. Dodatkowe funkcje zabezpieczeń, takie jak Zasady bezpieczeństwa dla kontenerów lub kontrola RBAC platformy Kubernetes dla węzłów, skutecznie blokują wykorzystania luk. W celu zapewnienia prawdziwego bezpieczeństwa podczas uruchamiania wrogich obciążeń w środowisku wielodostępnym, należy ufać jedynie hiperwizorowi. Domena zabezpieczeń dla platformy Kubernetes staje się całym klastrem, a nie pojedynczym węzłem.
W przypadku tego rodzaju konfliktowych obciążeń wielodostępnych należy używać klastrów odizolowanych fizycznie. Aby uzyskać więcej informacji na temat sposobów izolowania obciążeń, zobacz Najlepsze praktyki dotyczące izolacji klastra w usłudze AKS.
Izolacja środowiska obliczeniowego
Ze względu na wymagania dotyczące zgodności lub przepisów niektóre obciążenia mogą wymagać wysokiego stopnia izolacji od innych obciążeń klientów. W przypadku tych obciążeń platforma Azure zapewnia następujące możliwości:
- Kontenery izolowane przez jądro do użycia jako węzły agentów w klastrze AKS. Te kontenery są całkowicie odizolowane od określonego typu sprzętu i odizolowane od sieci szkieletowej usługi Azure Host, systemu operacyjnego hosta i funkcji hypervisor. Są one przeznaczone dla jednego klienta. Wybierz jeden z izolowanych rozmiarów maszyn wirtualnych jako rozmiar węzła podczas tworzenia klastra usługi AKS lub dodawania puli węzłów.
- Poufne Kontenery (wersja zapoznawcza), również oparte na Kata Confidential Containers, szyfrują pamięć kontenera i uniemożliwiają, aby dane w pamięci podczas obliczeń były w postaci zwykłego tekstu, w czytelnym formacie i podatnym na manipulacje. Pomaga odizolować kontenery od innych grup kontenerów/zasobników i jądra systemu operacyjnego węzła maszyny wirtualnej. Kontenery poufne (wersja zapoznawcza) korzystają z szyfrowania pamięci opartego na sprzęcie (SEV-SNP).
- Pod Sandboxing (wersja zapoznawcza) zapewnia warstwę izolacji między aplikacją kontenera a współdzielonym jądrem i zasobami CPU, pamięci i sieci hosta kontenera.
Bezpieczeństwo sieci
W przypadku łączności i zabezpieczeń z sieciami lokalnymi można wdrożyć klaster usługi AKS w istniejących podsieciach sieci wirtualnej platformy Azure. Te sieci wirtualne łączą się z powrotem z siecią lokalną przy użyciu sieci VPN typu lokacja-lokacja platformy Azure lub usługi Express Route. Zdefiniuj kontrolery ruchu przychodzącego Kubernetes z prywatnymi, wewnętrznymi adresami IP, aby ograniczyć dostęp usług do wewnętrznego połączenia sieciowego.
Sieciowe grupy zabezpieczeń platformy Azure
Aby filtrować przepływ ruchu w sieci wirtualnej, platforma Azure używa reguł sieciowej grupy zabezpieczeń. Te reguły definiują źródłowe i docelowe zakresy adresów IP, porty i protokoły dozwolone lub odmawiane dostępu do zasobów. Domyślne reguły są tworzone, aby zezwolić na ruch TLS do serwera interfejsu API Kubernetes. Usługi są tworzone za pomocą modułów równoważenia obciążenia, mapowań portów lub tras ruchu przychodzącego. AKS automatycznie modyfikuje grupę zabezpieczeń sieci dla przepływu ruchu.
Jeśli udostępnisz własną podsieć dla klastra AKS (niezależnie od tego, czy używasz usługi Azure CNI, czy Kubenet), nie należy modyfikować grupy zabezpieczeń sieciowych na poziomie kart sieciowych zarządzanych przez AKS. Zamiast tego utwórz więcej sieciowych grup zabezpieczeń na poziomie podsieci, aby zmodyfikować przepływ ruchu. Upewnij się, że nie zakłócają one niezbędnego ruchu zarządzającego klastrem, takiego jak dostęp do modułu równoważenia obciążenia, komunikacja z płaszczyzną sterowania lub ruch wychodzący.
Zasady sieciowe platformy Kubernetes
Aby ograniczyć ruch sieciowy między zasobnikami w klastrze, AKS oferuje obsługę zasad sieciowych Kubernetes. Dzięki zasadom sieci można zezwalać na określone ścieżki sieciowe w klastrze lub blokować je na podstawie przestrzeni nazw i selektorów etykiet.
Bezpieczeństwo aplikacji
Aby chronić zasobniki działające w usłudze AKS, rozważ usługę Microsoft Defender for Containers , aby wykrywać i ograniczać ataki cybernetyczne na aplikacje działające w zasobnikach. Uruchom ciągłe skanowanie w celu wykrycia dryfu w stanie luk w zabezpieczeniach aplikacji i zaimplementuj proces "niebieski/zielony/kanary", aby zastosować poprawki i zastąpić obrazy podatne na zagrożenia.
Zabezpieczanie dostępu kontenera do zasobów
W taki sam sposób, jak należy przyznać użytkownikom lub grupom wymagane minimalne uprawnienia, należy również ograniczyć kontenery tylko do niezbędnych akcji i procesów. Aby zminimalizować ryzyko ataku, należy unikać konfigurowania aplikacji i kontenerów, które wymagają eskalowanych uprawnień lub dostępu głównego. Wbudowane funkcje zabezpieczeń systemu Linux, takie jak AppArmor i seccomp , są zalecane jako najlepsze rozwiązania w zakresie [zabezpieczania dostępu kontenera do zasobów][secure-container-access].
Sekrety systemu Kubernetes
Sekret Kubernetes umożliwia wstrzykiwanie poufnych danych do podów, takich jak poświadczenia dostępu lub klucze.
- Utwórz Sekret przy użyciu API Kubernetes.
- Zdefiniuj zasobnik lub wdrożenie i zażądaj określonego wpisu tajnego.
- Tajne dane są udostępniane tylko węzłom, które mają zaplanowany pod, który ich wymaga.
- Tajemnica jest przechowywana w tmpfs, a nie na dysku.
- Usunięcie ostatniego zasobnika na węźle, który wymaga wpisu tajnego, spowoduje usunięcie wpisu tajnego z tmpfs węzła.
- Wpisy tajne są przechowywane w danej przestrzeni nazw i są dostępne tylko z zasobników w tej samej przestrzeni nazw.
Użycie sekretów redukuje ilość informacji poufnych zdefiniowanych w manifeście YAML zasobnika lub usługi. Zamiast tego żądasz tajemnicy przechowywanej na serwerze API Kubernetes w ramach manifestu YAML. Takie podejście zapewnia tylko określony dostęp zasobnika do wpisu tajnego.
Uwaga
Surowe pliki manifestu tajne zawierają dane tajne w formacie base64. Aby uzyskać więcej informacji, zobacz oficjalną dokumentację. Traktuj te pliki jako poufne informacje i nigdy nie zatwierdzaj ich do kontroli źródła.
Tajemnice Kubernetes są przechowywane w etcd, rozproszonym magazynie klucz-wartość. Usługa AKS umożliwia szyfrowanie magazynowanych wpisów tajnych itp. przy użyciu kluczy zarządzanych przez klienta.
Następne kroki
Aby rozpocząć zabezpieczanie klastrów usługi AKS, zobacz Uaktualnij klaster usługi AKS.
Aby uzyskać informacje dotyczące skojarzonych najlepszych praktyk, zobacz Najlepsze praktyki dotyczące zabezpieczeń i uaktualnień klastra w usłudze AKS oraz Najlepsze praktyki dotyczące zabezpieczeń zasobników w usłudze AKS.
Aby uzyskać więcej informacji na temat podstawowych pojęć związanych z platformą Kubernetes i usługą AKS, zobacz: