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) obciążenie i zabezpieczenia danych są kluczowym czynnikiem. W przypadku uruchamiania klastrów z wieloma dzierżawami 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. Omawiane kwestie:

  • Aby zabezpieczyć dostęp do serwera interfejsu API, użyj usługi Azure Active Directory 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 platformy Kubernetes.
  • Zachowaj aktualność węzłów i automatycznie zastosuj poprawki zabezpieczeń.

Możesz również zapoznać się z najlepszymi rozwiązaniami dotyczącymi zarządzania obrazami kontenera 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, należy zintegrować kontrolę dostępu opartej na rolach platformy Kubernetes z usługą Azure Active Directory (Azure AD). Dzięki tym kontrolkom zabezpieczasz usługę AKS tak samo, jak zabezpieczasz dostęp 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.

Azure AD 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że być mocno naciskany, aby szczegółowo ograniczyć dostęp do serwera interfejsu API. W przypadku klastrów Azure AD zintegrowanych w usłudze AKS można używać istniejących kont użytkowników i grup do uwierzytelniania użytkowników na serwerze interfejsu API.

Integracja usługi Azure Active Directory dla klastrów usługi AKS

Korzystając z kontroli dostępu opartej na rolach platformy Kubernetes i integracji Azure AD, można zabezpieczyć serwer interfejsu API i zapewnić minimalne uprawnienia wymagane do zestawu zasobów o określonym zakresie, na przykład pojedynczej przestrzeni nazw. Możesz udzielić różnych Azure AD użytkownikom lub grupom różnych ról platformy Kubernetes. 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 użyj członkostwa w grupie Azure AD, aby powiązać użytkowników z rolami platformy Kubernetes, a nie poszczególnymi użytkownikami. W miarę zmiany członkostwa w grupie użytkownika ich uprawnienia dostępu do klastra usługi AKS zmieniają się odpowiednio.

W międzyczasie załóżmy, że powiążesz użytkownika bezpośrednio z rolą i zmienisz funkcję zadania. Podczas gdy członkostwo w grupie Azure AD jest aktualizowane, ich uprawnienia w klastrze usługi AKS nie byłyby. W tym scenariuszu użytkownik kończy się większymi uprawnieniami, niż wymagają.

Aby uzyskać więcej informacji na temat integracji Azure AD, 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.

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

Uwaga

Alternatywnie możesz użyć tożsamości zasobnika , chociaż jest to dostępna w publicznej wersji zapoznawczej. Ma zasobnik (NMI), który działa jako demonset w każdym węźle w klastrze usługi AKS. Usługa NMI przechwytuje żądania tokenu zabezpieczającego do usługi Azure Instance Metadata Service w każdym węźle, przekierowuje je do siebie i sprawdza, czy zasobnik ma dostęp do tożsamości, dla której żąda tokenu i pobiera token z dzierżawy Azure AD w imieniu aplikacji.

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 uprzywilejowanego 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ą eskalacji uprawnień lub dostępu głównego.

Na przykład ustaw allowPrivilegeEscalation: false w manifeście zasobnika. Te wbudowane konteksty zabezpieczeń zasobnika Kubernetes umożliwiają zdefiniowanie 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 Zabezpieczanie dostępu zasobnika do zasobów.

Aby uzyskać jeszcze bardziej szczegółową kontrolę nad akcjami kontenera, można 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 pomocą 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 dla kontenerówAppArmor, seccomp,PodSecurity Admission lub Kubernetes RBAC dla węzłów, skutecznie blokują luki w zabezpieczeniach.

W przypadku prawdziwych zabezpieczeń podczas uruchamiania wrogich obciążeń z wieloma dzierżawami 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 fizycznie izolowanych.

Aplikacja Opancerzona

Aby ograniczyć akcje kontenera, możesz użyć modułu zabezpieczeń jądra AppArmor Linux. Aplikacja AppArmor jest dostępna jako część bazowego systemu operacyjnego węzła usługi AKS i jest domyślnie włączona. Można tworzyć 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 /proc lokalizacji i /sys udostępniają środki do logicznego izolowania kontenerów z 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.

Profile AppArmor używane w klastrze usługi AKS w celu ograniczenia akcji kontenera

Aby wyświetlić 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 został 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 container.apparmor.security.beta.kuberneteselementu .
    • 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 sprawdź, czy zasobnik hello-apparmor wyświetla zablokowany stan, uruchamiając następujące polecenie:

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

Aby uzyskać więcej informacji na temat aplikacji AppArmor, zobacz Profile AppArmor w usłudze 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. W przypadku seccomp można ograniczyć wywołania procesów kontenera. Dopasuj do najlepszego rozwiązania w zakresie udzielania minimalnych uprawnień do uruchamiania kontenera tylko przez:

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

Aby wyświetlić akcję skompilowania, 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 seccomp.security.alpha.kubernetes.ioelementu .
    • 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 przy użyciu polecenia kubectl get pods .

    • Zasobnik zgłasza błąd.
    • Nie chmod można uruchomić polecenia za pomocą filtru seccomp, jak pokazano w poniższych 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ń seccomp dla platformy Docker).

Regularnie aktualizuj do najnowszej wersji rozwiązania Kubernetes

Wskazówki dotyczące najlepszych rozwiązań

Aby zachować aktualność nowych funkcji i poprawek błędów, regularnie uaktualnij wersję platformy Kubernetes w klastrze usługi AKS.

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

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

Nowe funkcje zazwyczaj przechodzą przez stan alfa i beta , zanim staną się stabilne. Gdy jest stabilna, są ogólnie dostępne i zalecane do użycia w środowisku produkcyjnym. Nowy cykl wydania 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 wersja pomocnicza i obsługiwane wersje poprawek zostaną wycofane. Drobne aktualizacje 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 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:

  • Kordony i opróżniają jeden węzeł naraz.
  • Planuje zasobniki na pozostałych węzłach.
  • Wdraża nowy węzeł z najnowszą wersją 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. Podczas wprowadzania nowych wersji do środowiska produkcyjnego rozważ użycie wielu pul węzłów w oddzielnych wersjach i uaktualnij poszczególne pule pojedynczo, aby stopniowo wdrażać aktualizację w klastrze. W przypadku uruchamiania wielu klastrów uaktualnij jeden klaster naraz, 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 platformy 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 automatycznie konfigurowane, 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 wymaga tego 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 dotyczą aktualizacji 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ą niezatwierdzone 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 Azure Kubernetes Service (AKS).

Przetwarzanie aktualizacji węzła 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.