Omówienie zabezpieczeń usługi Azure Kubernetes Application Network (wersja zapoznawcza)

Usługa Azure Kubernetes Application Network zabezpiecza komunikację między usługami w połączonych klastrach usługi Azure Kubernetes Service (AKS) za pośrednictwem automatycznego wzajemnego protokołu TLS (mTLS) i autoryzacji opartej na tożsamościach. Nadaje tożsamości dla obciążeń roboczych i zarządza wystawianiem, rotacją i walidacją certyfikatów, aby umożliwić zaszyfrowaną, uwierzytelnioną i jawnie autoryzowaną komunikację między usługami bez ręcznej konfiguracji, z szyfrowaniem zgodnym ze standardem FIPS podczas przesyłania.

Ten artykuł zawiera omówienie funkcji zabezpieczeń w usłudze Azure Kubernetes Application Network, w tym mTLS, tożsamości obciążeń, zarządzania certyfikatami i zasad autoryzacji. Zawiera on również opis ograniczeń i następnych kroków dotyczących implementowania bezpiecznej komunikacji w środowisku sieci aplikacji platformy Azure Kubernetes.

Ograniczenia

• Certyfikaty są obecnie wystawiane przez urząd certyfikacji zarządzany przez usługę Azure Kubernetes Application Network i nie są powiązane z publicznym urzędem certyfikacji.

mTLS

Application Network używa mTLS do zapewnienia zaszyfrowanej komunikacji opartej na tożsamości między obciążeniami. Każda usługa w klastrze połączonym z siecią aplikacji automatycznie otrzymuje certyfikat, który pozwala mu udowodnić swoją tożsamość i ustanowić zaufane, zaszyfrowane połączenia z innymi usługami w tej samej sieci aplikacji. Szyfrowanie podczas przesyłania używa kryptografii zgodnej ze standardem FIPS.

Strategia migracji mTLS

Usługa Application Network obecnie umożliwia zarówno zaszyfrowany, jak i niezaszyfrowany ruch. Takie podejście zapewnia, że istniejące obciążenia będą nadal działać normalnie, podczas gdy nowe lub zaktualizowane obciążenia automatycznie używają biblioteki mTLS do bezpiecznej komunikacji. Oznacza to, że można wdrożyć mTLS w celu zapewnienia bezpiecznej komunikacji między operacjami bez przestojów. Po zakończeniu migracji można zmienić tryb na ścisły, tak aby uwierzytelnianie było wymuszane.

Zalety mTLS w sieci aplikacji Azure Kubernetes

mTLS w Azure Kubernetes Application Network pomaga Ci:

• Ochrona danych podczas przesyłania: cały ruch typu usługa-usługa może być szyfrowany automatycznie (zgodny ze standardem FIPS).
• Weryfikowanie tożsamości usługi: każde obciążenie ma unikatowy certyfikat główny i pośredni zarządzany przez sieć aplikacji.
• Upraszczanie operacji: usługa Application Network obsługuje wystawianie, rotację i odwoływanie certyfikatów dla użytkowników.

Zarządzanie certyfikatami

Usługa Azure Kubernetes Application Network zapewnia zarządzanie certyfikatami wspierane przez usługę Azure Key Vault, która wystawia i utrzymuje certyfikaty używane w usłudze mTLS. Ta usługa ustanawia wspólną granicę zaufania we wszystkich klastrach usługi AKS połączonych z tym samym zasobem usługi Application Network.

Usługa Application Network automatycznie zarządza całym cyklem życia certyfikatów dla certyfikatów głównych i pośrednich, w tym aprowizowania, odnawiania i rotacji. Dzięki temu identyfikatory obciążeń pozostaną prawidłowe, a komunikacja z biegiem czasu będzie bezpieczna. Nie trzeba tworzyć, przechowywać ani obracać certyfikatów ręcznie.

Na poniższym diagramie przedstawiono hierarchię certyfikatów w usłudze Application Network, pokazując, jak główny urząd certyfikacji, pośrednie urzędy certyfikacji i certyfikaty obciążeń mają strukturę w celu ustanowienia zaufania między połączonymi klastrami:

Hierarchia certyfikatów i cykl życia

Po utworzeniu zasobu sieci aplikacji, główny urząd certyfikacji jest aprowizowany jako punkt zaufania dla sieci aplikacji. Gdy klaster usługi AKS dołącza do sieci aplikacji jako element członkowski, usługa Application Network wystawia certyfikat pośredni dla tego elementu członkowskiego podpisanego przez główny urząd certyfikacji usługi Application Network. Każdy połączony klaster usługi AKS używa certyfikatu pośredniego zarządzanego przez sieć aplikacji do wystawiania krótkotrwałych certyfikatów obciążeń dla obciążeń w tym klastrze.

Wszystkie certyfikaty dotyczące obciążeń dziedziczą zaufanie z głównego urzędu certyfikacji sieci aplikacyjnej, utrzymując ujednoliconą granicę zaufania w całym zasobie. Rotacja certyfikatów głównych i pośrednich jest obsługiwana w sposób niewidoczny dla użytkowników bez powodowania przestojów ani zakłóceń ruchu. Ta hierarchia zarządzana zapewnia spójne, weryfikowalne zaufanie we wszystkich klastrach w sieci aplikacji przy jednoczesnym automatycznym zachowaniu ważności każdego certyfikatu.

Z dowolnego klastra członkowskiego można pobrać certyfikat głównego urzędu certyfikacji z mapy istio-root-cert konfiguracji w przestrzeni nazw applink-system.

Typy certyfikatów i okresy rotacji

Identyfikacja i autoryzacja obciążenia roboczego

W miarę rozwoju aplikacji usługi często muszą komunikować się bezpiecznie w różnych przestrzeniach nazw i środowiskach w ramach tego samego wdrożenia. Zarządzanie certyfikatami i zapewnienie, że każda usługa może sprawdzić, kto rozmawia z nim, może szybko stać się złożona i podatna na błędy. Usługa Azure Kubernetes Application Network eliminuje to obciążenie przez automatyczne przypisywanie tożsamości obciążeń i zarządzanie nimi.

W środowisku połączonym z siecią aplikacji obciążenia komunikują się bezpiecznie wewnątrz przestrzeni nazw i między nimi. Aby zapewnić, że każda usługa może być zaufana i uwierzytelniona, usługa Application Network przypisuje każdemu obciążeniu weryfikowalną tożsamość reprezentującą jej przestrzeń nazw i konto usługi.

Każde obciążenie aplikacji w sieci automatycznie odbiera unikatową tożsamość w formacie SPIFFE, w którego skład wchodzą przestrzeń nazw i konto usługi. Tożsamość jest formatowana w następujący sposób:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Ta tożsamość jest osadzona w certyfikacie obciążenia i służy do potwierdzenia tożsamości usługi podczas komunikacji z innymi obciążeniami. Usługa Azure Kubernetes Application Network używa tego modelu tożsamości opartego na standardzie SPIFFE z zasadami autoryzacji Istio, dzięki czemu można zdefiniować jasne, spójne reguły, dla których usługi mogą komunikować się.

Definiowanie zasad dostępu

Za pomocą istio AuthorizationPolicies można kontrolować, które obciążenia mogą komunikować się w danym środowisku. Te zasady umożliwiają definiowanie dostępu na podstawie zweryfikowanych tożsamości obciążeń, a nie lokalizacji sieciowych lub adresów IP. Takie podejście pomaga wymusić spójne mechanizmy kontroli dostępu, nawet gdy usługi są skalowane i przenoszone między węzłami. Jak pokazano w poniższym przykładzie, można zezwolić na wywoływanie usługi tylko przez określone bramy lub zadania z zaufanych przestrzeni nazw, odwołując się do ich tożsamości SPIFFE na liście głównych tożsamości polityki.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Wskazówki dotyczące projektowania zasad

Podczas projektowania zasad autoryzacji należy pamiętać o następujących najlepszych rozwiązaniach:

• Zawsze określ zarówno przestrzeń nazw, jak i konto usługi, aby zapobiec niezamierzonym dostępowi między przestrzeniami nazw.
• Użyj głównych tożsamości, aby zdefiniować wyraźne tożsamości obciążenia na potrzeby dostępu o szczegółowej granulacji.
• Użyj przestrzeni nazw , aby w razie potrzeby zdefiniować szersze granice zaufania.
• Unikaj reguł, które dotyczą tylko nazw kont usługowych bez przestrzeni nazw, ponieważ może to umożliwić dostęp w klastrach lub środowiskach.
• Połącz AuthorizationPolicies z Kubernetes NetworkPolicies, aby wymusić zarówno izolację opartą o tożsamość, jak i izolację sieciową.

Łącząc zarządzane przez Azure Kubernetes Application Network tożsamości, certyfikaty i mechanizmy kontroli zasad, można zaimplementować komunikację usługową opartą na tożsamościach i najmniej uprzywilejowanym dostępie, zapewniając uwierzytelniony, zaszyfrowany i jawnie autoryzowany ruch między obciążeniami w klastrach.

Treści powiązane

Aby dowiedzieć się więcej o usłudze Azure Kubernetes Application Network, zobacz następujące artykuły:

• Architektura sieci aplikacji platformy Azure Kubernetes
• Omówienie możliwości obserwowania usługi Azure Kubernetes Application Network