Najlepsze rozwiązania dotyczące zabezpieczeń i uaktualnień klastra w usłudze Azure Kubernetes Service (AKS)

Podczas zarządzania klastrami w usłudze Azure Kubernetes Service (AKS) kluczowe znaczenie ma obciążenie i zabezpieczenia danych. W przypadku uruchamiania klastrów wielodostępnych przy użyciu izolacji logicznej należy szczególnie zabezpieczyć dostęp do zasobów i obciążeń. Zminimalizuj ryzyko ataku, stosując najnowsze aktualizacje zabezpieczeń platformy Kubernetes i węzła systemu operacyjnego.

W tym artykule opisano sposób zabezpieczania klastra usługi AKS. Dowiedz się, jak odbywa się:

  • Aby zabezpieczyć dostęp do serwera interfejsu API, użyj identyfikatora Microsoft Entra i kontroli dostępu opartej na rolach platformy Kubernetes (Kubernetes RBAC).
  • Zabezpieczanie dostępu kontenera do zasobów węzłów.
  • Uaktualnij klaster usługi AKS do najnowszej wersji rozwiązania Kubernetes.
  • Aktualizuj węzły i automatycznie stosuj poprawki zabezpieczeń.

Możesz również zapoznać się z najlepszymi rozwiązaniami dotyczącymi zarządzania obrazami kontenerów i zabezpieczeniami zasobników.

Włączanie ochrony przed zagrożeniami

Wskazówki dotyczące najlepszych rozwiązań

Możesz włączyć usługę Defender for Containers , aby ułatwić zabezpieczanie kontenerów. Usługa Defender for Containers może oceniać konfiguracje klastra i udostępniać zalecenia dotyczące zabezpieczeń, uruchamiać skanowania luk w zabezpieczeniach oraz zapewniać ochronę i alerty w czasie rzeczywistym dla węzłów i klastrów Kubernetes.

Bezpieczny dostęp do serwera interfejsu API i węzłów klastra

Wskazówki dotyczące najlepszych rozwiązań

Jednym z najważniejszych sposobów zabezpieczenia klastra jest zabezpieczenie dostępu do serwera interfejsu API Kubernetes. Aby kontrolować dostęp do serwera interfejsu API, zintegruj kontrolę dostępu na podstawie ról platformy Kubernetes z identyfikatorem Entra firmy Microsoft. Dzięki tym kontrolkom zabezpieczasz usługę AKS w taki sam sposób, jak w przypadku zabezpieczania dostępu do subskrypcji platformy Azure.

Serwer interfejsu API Kubernetes udostępnia pojedynczy punkt połączenia dla żądań wykonywania akcji w klastrze. Aby zabezpieczyć i przeprowadzić inspekcję dostępu do serwera interfejsu API, ogranicz dostęp i zapewnij najniższe możliwe poziomy uprawnień. Chociaż takie podejście nie jest unikatowe dla platformy Kubernetes, jest to szczególnie ważne, gdy klaster usługi AKS został logicznie odizolowany do użytku z wieloma dzierżawami.

Microsoft Entra ID udostępnia rozwiązanie do zarządzania tożsamościami gotowymi do użycia w przedsiębiorstwie, które integruje się z klastrami usługi AKS. Ponieważ platforma Kubernetes nie zapewnia rozwiązania do zarządzania tożsamościami, możesz być mocno naciskany w celu szczegółowego ograniczenia dostępu do serwera interfejsu API. W przypadku klastrów zintegrowanych firmy Microsoft w usłudze AKS używasz istniejących kont użytkowników i grup do uwierzytelniania użytkowników na serwerze interfejsu API.

Microsoft Entra integration for AKS clusters

Korzystając z kontroli dostępu opartej na rolach platformy Kubernetes i integracji identyfikatora Entra firmy Microsoft, można zabezpieczyć serwer interfejsu API i zapewnić minimalne uprawnienia wymagane do zestawu zasobów o określonym zakresie, na przykład w jednej przestrzeni nazw. Możesz przyznać różnym użytkownikom lub grupom różnych ról platformy Kubernetes firmy Microsoft. Dzięki szczegółowym uprawnieniam można ograniczyć dostęp do serwera interfejsu API i zapewnić jasny dziennik inspekcji wykonanych akcji.

Zalecanym najlepszym rozwiązaniem jest użycie grup w celu zapewnienia dostępu do plików i folderów zamiast poszczególnych tożsamości. Na przykład należy użyć członkostwa w grupie Microsoft Entra ID, aby powiązać użytkowników z rolami kubernetes, a nie poszczególnymi użytkownikami. W miarę zmiany członkostwa w grupie użytkownika uprawnienia dostępu do klastra usługi AKS zmieniają się odpowiednio.

Załóżmy, że użytkownik jest powiązany bezpośrednio z rolą, a ich funkcja zadania zmienia się. Podczas aktualizacji członkostwa w grupach firmy Microsoft Entra ich uprawnienia w klastrze usługi AKS nie byłyby. W tym scenariuszu użytkownik kończy się większą większa większa niż wymaga.

Aby uzyskać więcej informacji na temat integracji z firmą Microsoft Entra, kontroli dostępu opartej na rolach platformy Kubernetes i kontroli dostępu opartej na rolach platformy Azure, zobacz Najlepsze rozwiązania dotyczące uwierzytelniania i autoryzacji w usłudze AKS.

Ograniczanie dostępu do interfejsu API metadanych wystąpienia

Wskazówki dotyczące najlepszych rozwiązań

Dodaj zasady sieciowe we wszystkich przestrzeniach nazw użytkowników, aby zablokować ruch wychodzący zasobnika do punktu końcowego metadanych.

Uwaga

Aby zaimplementować zasady sieciowe, dołącz atrybut --network-policy azure podczas tworzenia klastra usługi AKS. Użyj następującego polecenia, aby utworzyć klaster: az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity --network-plugin azure --network-policy azure

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Zabezpieczanie dostępu kontenera do zasobów

Wskazówki dotyczące najlepszych rozwiązań

Ogranicz dostęp do akcji, które mogą wykonywać kontenery. Podaj najmniejszą liczbę uprawnień i unikaj korzystania z dostępu głównego lub uprzywilejowanej eskalacji.

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.

Na przykład ustaw allowPrivilegeEscalation: false w manifeście zasobnika. Te wbudowane konteksty zabezpieczeń zasobnika Kubernetes umożliwiają definiowanie dodatkowych uprawnień, takich jak użytkownik lub grupa do uruchomienia jako, lub możliwości systemu Linux do uwidocznienia. Aby uzyskać więcej najlepszych rozwiązań, zobacz Bezpieczny dostęp zasobnika do zasobów.

Aby uzyskać jeszcze bardziej szczegółową kontrolę nad akcjami kontenera, możesz również użyć wbudowanych funkcji zabezpieczeń systemu Linux, takich jak AppArmor i seccomp.

  1. Zdefiniuj funkcje zabezpieczeń systemu Linux na poziomie węzła.
  2. Implementowanie funkcji za pośrednictwem manifestu zasobnika.

Wbudowane funkcje zabezpieczeń systemu Linux są dostępne tylko w węzłach i zasobnikach systemu Linux.

Uwaga

Obecnie środowiska Kubernetes nie są całkowicie bezpieczne w przypadku wrogiego użycia wielu dzierżaw. Dodatkowe funkcje zabezpieczeń, takie jak Microsoft Defender for ContainersAppArmor, seccomp,Pod Security Admission lub Kubernetes RBAC dla węzłów, skutecznie blokują luki w zabezpieczeniach.

W przypadku prawdziwych zabezpieczeń podczas uruchamiania wrogich obciążeń wielodostępnych ufaj tylko funkcji hypervisor. Domena zabezpieczeń dla platformy Kubernetes staje się całym klastrem, a nie pojedynczym węzłem.

W przypadku tych typów wrogich obciążeń wielodostępnych należy używać klastrów odizolowanych fizycznie.

Ochrona aplikacji

Aby ograniczyć akcje kontenera, możesz użyć modułu zabezpieczeń jądra systemu Linux AppArmor . Aplikacja AppArmor jest dostępna w ramach bazowego systemu operacyjnego węzła usługi AKS i jest domyślnie włączona. Tworzone są profile AppArmor, które ograniczają akcje odczytu, zapisu lub wykonywania albo funkcje systemowe, takie jak instalowanie systemów plików. Domyślne profile AppArmor ograniczają dostęp do różnych lokalizacji /proc i /sys i zapewniają środki do logicznego odizolowania kontenerów od węzła bazowego. Aplikacja AppArmor działa w przypadku każdej aplikacji działającej w systemie Linux, a nie tylko zasobników Kubernetes.

AppArmor profiles in use in an AKS cluster to limit container actions

Aby zobaczyć działanie appArmor, poniższy przykład tworzy profil, który uniemożliwia zapisywanie w plikach.

  1. Połączenie SSH z węzłem usługi AKS.

  2. Utwórz plik o nazwie deny-write.profile.

  3. Skopiuj i wklej następującą zawartość:

    #include <tunables/global>
    profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
      #include <abstractions/base>
    
      file,
      # Deny all file writes.
      deny /** w,
    }
    

Profile AppArmor są dodawane przy użyciu apparmor_parser polecenia .

  1. Dodaj profil do aplikacji AppArmor.

  2. Określ nazwę profilu utworzonego w poprzednim kroku:

    sudo apparmor_parser deny-write.profile
    

    Jeśli profil jest poprawnie przeanalizowany i zastosowany do aplikacji AppArmor, nie zobaczysz żadnych danych wyjściowych i nastąpi powrót do wiersza polecenia.

  3. Na komputerze lokalnym utwórz manifest zasobnika o nazwie aks-apparmor.yaml. Ten manifest:

    • Definiuje adnotację dla elementu container.apparmor.security.beta.kubernetes.
    • Odwołuje się do profilu deny-write utworzonego w poprzednich krokach.
    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-apparmor
      annotations:
        container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
    spec:
      containers:
      - name: hello
        image: mcr.microsoft.com/dotnet/runtime-deps:6.0
        command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
    
  4. Po wdrożeniu zasobnika uruchom następujące polecenie i sprawdź, czy zasobnik hello-apparmor ma stan Uruchomione :

    kubectl get pods
    
    NAME             READY   STATUS    RESTARTS   AGE
    aks-ssh          1/1     Running   0          4m2s
    hello-apparmor   0/1     Running   0          50s
    

Aby uzyskać więcej informacji na temat aplikacji AppArmor, zobacz Profile AppArmor na platformie Kubernetes.

Bezpieczne przetwarzanie

Podczas gdy aplikacja AppArmor działa dla dowolnej aplikacji systemu Linux, seccomp (secure computing) działa na poziomie procesu. Seccomp jest również modułem zabezpieczeń jądra systemu Linux i jest natywnie obsługiwany przez środowisko uruchomieniowe platformy Docker używane przez węzły usługi AKS. Za pomocą funkcji seccomp można ograniczyć wywołania procesów kontenera. Dopasuj do najlepszych rozwiązań w zakresie udzielania kontenerowi minimalnych uprawnień tylko do uruchamiania przez:

  • Definiowanie za pomocą filtrów, jakie akcje mają zezwalać lub odrzucać.
  • Dodawanie adnotacji w manifeście YAML zasobnika do skojarzenia z filtrem seccomp.

Aby wyświetlić skompilację w działaniu, utwórz filtr, który uniemożliwia zmianę uprawnień w pliku.

  1. Połączenie SSH z węzłem usługi AKS.

  2. Utwórz filtr seccomp o nazwie /var/lib/kubelet/seccomp/prevent-chmod.

  3. Skopiuj i wklej następującą zawartość:

    {
      "defaultAction": "SCMP_ACT_ALLOW",
      "syscalls": [
        {
          "name": "chmod",
          "action": "SCMP_ACT_ERRNO"
        },
        {
          "name": "fchmodat",
          "action": "SCMP_ACT_ERRNO"
        },
        {
          "name": "chmodat",
          "action": "SCMP_ACT_ERRNO"
        }
      ]
    }
    

    W wersji 1.19 lub nowszej należy skonfigurować następujące elementy:

    {
      "defaultAction": "SCMP_ACT_ALLOW",
      "syscalls": [
        {
          "names": ["chmod","fchmodat","chmodat"],
          "action": "SCMP_ACT_ERRNO"
        }
      ]
    }
    
  4. Na komputerze lokalnym utwórz manifest zasobnika o nazwie aks-seccomp.yaml i wklej następującą zawartość. Ten manifest:

    • Definiuje adnotację dla elementu seccomp.security.alpha.kubernetes.io.
    • Odwołuje się do filtru prevent-chmod utworzonego w poprzednim kroku.
    apiVersion: v1
    kind: Pod
    metadata:
      name: chmod-prevented
      annotations:
        seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
    spec:
      containers:
      - name: chmod
        image: mcr.microsoft.com/dotnet/runtime-deps:6.0
        command:
          - "chmod"
        args:
         - "777"
         - /etc/hostname
      restartPolicy: Never
    

    W wersji 1.19 lub nowszej należy skonfigurować następujące elementy:

    apiVersion: v1
    kind: Pod
    metadata:
      name: chmod-prevented
    spec:
      securityContext:
        seccompProfile:
          type: Localhost
          localhostProfile: prevent-chmod
      containers:
      - name: chmod
        image: mcr.microsoft.com/dotnet/runtime-deps:6.0
        command:
          - "chmod"
        args:
         - "777"
         - /etc/hostname
      restartPolicy: Never
    
  5. Wdróż przykładowy zasobnik przy użyciu polecenia kubectl apply :

    kubectl apply -f ./aks-seccomp.yaml
    
  6. Wyświetl stan zasobnika za pomocą polecenia kubectl get pods .

    • Zasobnik zgłasza błąd.
    • Polecenie chmod jest blokowane przez filtr seccomp, jak pokazano w następujących przykładowych danych wyjściowych:
    kubectl get pods
    
    NAME                      READY     STATUS    RESTARTS   AGE
    chmod-prevented           0/1       Error     0          7s
    

Aby uzyskać więcej informacji na temat dostępnych filtrów, zobacz Seccomp security profiles for Docker (Profile zabezpieczeń skompiluj dla platformy Docker).

Regularnie aktualizuj do najnowszej wersji rozwiązania Kubernetes

Wskazówki dotyczące najlepszych rozwiązań

Aby być na bieżąco z nowymi funkcjami i poprawkami błędów, regularnie uaktualnij wersję rozwiązania Kubernetes w klastrze usługi AKS.

Platforma Kubernetes udostępnia nowe funkcje w szybszym tempie niż w przypadku bardziej tradycyjnych platform infrastruktury. Aktualizacje platformy Kubernetes obejmują:

  • Nowe funkcje
  • Poprawki błędów lub zabezpieczeń

Nowe funkcje zwykle przechodzą przez stan alfa i beta , zanim staną się stabilne. Gdy jest stabilna, są ogólnie dostępne i zalecane do użytku produkcyjnego. Cykl wydania nowej funkcji platformy Kubernetes umożliwia aktualizowanie platformy Kubernetes bez regularnego napotykania zmian powodujących niezgodność lub dostosowywania wdrożeń i szablonów.

Usługa AKS obsługuje trzy wersje pomocnicze platformy Kubernetes. Po wprowadzeniu nowej wersji poprawki pomocniczej najstarsza obsługiwana wersja pomocnicza i wersje poprawek zostaną wycofane. Aktualizacje pomocnicze platformy Kubernetes są wykonywane okresowo. Aby pozostać w ramach pomocy technicznej, upewnij się, że masz proces zapewniania ładu w celu sprawdzenia niezbędnych uaktualnień. Aby uzyskać więcej informacji, zobacz Obsługiwane wersje platformy Kubernetes w usłudze AKS.

Aby sprawdzić wersje dostępne dla klastra, użyj polecenia az aks get-upgrades , jak pokazano w poniższym przykładzie:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Następnie możesz uaktualnić klaster usługi AKS przy użyciu polecenia az aks upgrade . Proces uaktualniania jest bezpieczny:

  • Cordony i opróżniają jeden węzeł naraz.
  • Planuje zasobniki na pozostałych węzłach.
  • Wdraża nowy węzeł z najnowszymi wersjami systemu operacyjnego i platformy Kubernetes.

Ważne

Przetestuj nowe wersje pomocnicze w środowisku testowym deweloperskim i sprawdź, czy obciążenie pozostaje w dobrej kondycji przy użyciu nowej wersji platformy Kubernetes.

Platforma Kubernetes może przestarzać interfejsy API (na przykład w wersji 1.16), na których polegają obciążenia. W przypadku wprowadzenia nowych wersji do środowiska produkcyjnego rozważ użycie wielu pul węzłów w osobnych wersjach i uaktualnienie poszczególnych pul pojedynczo, aby stopniowo wdrażać aktualizację w klastrze. W przypadku uruchamiania wielu klastrów uaktualnij jeden klaster jednocześnie, aby stopniowo monitorować wpływ lub zmiany.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Aby uzyskać więcej informacji na temat uaktualnień w usłudze AKS, zobacz Obsługiwane wersje rozwiązania Kubernetes w usłudze AKS i Uaktualnianie klastra usługi AKS.

Przetwarzanie aktualizacji węzła systemu Linux

Każdego wieczoru węzły systemu Linux w usłudze AKS uzyskują poprawki zabezpieczeń za pośrednictwem kanału aktualizacji dystrybucji. To zachowanie jest konfigurowane automatycznie, gdy węzły są wdrażane w klastrze usługi AKS. Aby zminimalizować zakłócenia i potencjalny wpływ na uruchamianie obciążeń, węzły nie są automatycznie uruchamiane, jeśli wymagana jest poprawka zabezpieczeń lub aktualizacja jądra. Aby uzyskać więcej informacji na temat obsługi ponownych rozruchów węzłów, zobacz Stosowanie aktualizacji zabezpieczeń i jądra do węzłów w usłudze AKS.

Uaktualnienia obrazu węzła

Nienadzorowane uaktualnienia stosują aktualizacje do systemu operacyjnego węzła systemu Linux, ale obraz używany do tworzenia węzłów dla klastra pozostaje niezmieniony. Jeśli nowy węzeł systemu Linux zostanie dodany do klastra, oryginalny obraz zostanie użyty do utworzenia węzła. Ten nowy węzeł będzie otrzymywać wszystkie aktualizacje zabezpieczeń i jądra dostępne podczas automatycznego sprawdzania każdej nocy, ale pozostaną niezapieczętowane do momentu zakończenia wszystkich kontroli i ponownych uruchomień. Możesz użyć uaktualnienia obrazu węzła, aby sprawdzić i zaktualizować obrazy węzłów używane przez klaster. Aby uzyskać więcej informacji na temat uaktualniania obrazu węzła, zobacz Uaktualnianie obrazu węzła usługi Azure Kubernetes Service (AKS).

Przetwarzanie aktualizacji węzłów systemu Windows Server

W przypadku węzłów systemu Windows Server regularnie przeprowadzaj operację uaktualniania obrazu węzła, aby bezpiecznie kordonować i opróżniać zasobniki oraz wdrażać zaktualizowane węzły.