Konfigurowanie danych na żywo w usłudze Container Insights

Artykuł
10/15/2024

Aby wyświetlić dane na żywo za pomocą usługi Container Insights z klastrów usługi Azure Kubernetes Service (AKS), skonfiguruj uwierzytelnianie w celu udzielenia uprawnień dostępu do danych kubernetes. Ta konfiguracja zabezpieczeń umożliwia dostęp w czasie rzeczywistym do danych za pośrednictwem interfejsu API Kubernetes bezpośrednio w witrynie Azure Portal.

Ta funkcja obsługuje następujące metody kontrolowania dostępu do dzienników, zdarzeń i metryk:

Usługa AKS bez włączonej autoryzacji kontroli dostępu opartej na rolach (RBAC) platformy Kubernetes
Usługa AKS włączona z autoryzacją RBAC na platformie Kubernetes
- Usługa AKS skonfigurowana za pomocą klastra powiązania roli klastraMonitoringUser
Usługa AKS włączona przy użyciu logowania jednokrotnego opartego na protokole SAML firmy Microsoft

Te instrukcje wymagają dostępu administracyjnego do klastra Kubernetes. Jeśli konfigurujesz korzystanie z identyfikatora Entra firmy Microsoft na potrzeby uwierzytelniania użytkowników, potrzebujesz również dostępu administracyjnego do identyfikatora Entra firmy Microsoft.

W tym artykule wyjaśniono, jak skonfigurować uwierzytelnianie w celu kontrolowania dostępu do funkcji Danych na żywo z klastra:

Klaster usługi AKS z obsługą kontroli dostępu opartej na rolach platformy Kubernetes
Microsoft Entra integrated AKS cluster (Zintegrowany klaster AKS firmy Microsoft)

Model uwierzytelniania

Funkcja Live Data używa interfejsu API Kubernetes, który jest identyczny z narzędziem kubectl wiersza polecenia. Punkty końcowe interfejsu API platformy Kubernetes używają certyfikatu z podpisem własnym, którego przeglądarka nie będzie mogła zweryfikować. Ta funkcja używa wewnętrznego serwera proxy do weryfikowania certyfikatu z usługą AKS, zapewniając, że ruch jest zaufany.

W witrynie Azure Portal zostanie wyświetlony monit o zweryfikowanie poświadczeń logowania dla klastra Microsoft Entra ID. Spowoduje to przekierowanie do konfiguracji rejestracji klienta podczas tworzenia klastra (i ponowne skonfigurowanie w tym artykule). To zachowanie jest podobne do procesu uwierzytelniania wymaganego przez kubectlprogram .

Uwaga

Autoryzacja do klastra jest zarządzana przez platformę Kubernetes i skonfigurowany model zabezpieczeń. Użytkownicy, którzy uzyskują dostęp do tej funkcji, wymagają uprawnień do pobierania konfiguracji platformy Kubernetes (kubeconfig), która jest podobna do uruchomionej .az aks get-credentials -n {your cluster name} -g {your resource group}

Ten plik konfiguracji zawiera token autoryzacji i uwierzytelniania dla roli użytkownika klastra usługi Azure Kubernetes Service, w przypadku klastrów RBAC platformy Azure i klastrów AKS bez włączonej autoryzacji RBAC platformy Kubernetes. Zawiera on informacje o identyfikatorze Entra firmy Microsoft i szczegółach rejestracji klienta, gdy usługa AKS jest włączona za pomocą logowania jednokrotnego opartego na protokole SAML firmy Microsoft.

Użytkownicy tej funkcji wymagają roli użytkownika klastra Usługi Azure Kubernetes w celu uzyskania dostępu do klastra kubeconfig w celu pobrania funkcji i użycia tej funkcji. Użytkownicy nie wymagają dostępu współautora do klastra w celu korzystania z tej funkcji.

Używanie klastraMonitoringUser z klastrami z obsługą kontroli dostępu opartej na rolach Platformy Kubernetes

Aby wyeliminować konieczność zastosowania większej liczby zmian konfiguracji w celu umożliwienia klastrowi powiązania roli użytkownika KubernetesDostęp użytkownika do funkcji Live Data po włączeniu autoryzacji RBAC platformy Kubernetes usługa AKS dodała nowe powiązanie roli klastra Kubernetes o nazwie clusterMonitoringUser. To powiązanie roli klastra ma wszystkie niezbędne uprawnienia gotowe do uzyskania dostępu do interfejsu API Kubernetes i punktów końcowych na potrzeby korzystania z funkcji Live Data.

Aby korzystać z funkcji Dane na żywo z tym nowym użytkownikiem, musisz być członkiem roli użytkownika lub współautora klastra usługi Azure Kubernetes Service w zasobie klastra usługi AKS. Usługa Container Insights po włączeniu jest domyślnie skonfigurowana do uwierzytelniania przy użyciu polecenia clusterMonitoringUser . clusterMonitoringUser Jeśli powiązanie roli nie istnieje w klastrze, klasterUżytkownik jest używany do uwierzytelniania. Współautor zapewnia dostęp ( clusterMonitoringUser jeśli istnieje), a użytkownik klastra usługi Azure Kubernetes Service zapewnia dostęp do klastraUżytkownik. Każda z tych dwóch ról zapewnia wystarczający dostęp do korzystania z tej funkcji.

Usługa AKS wydała to nowe powiązanie roli w styczniu 2020 r., więc klastry utworzone przed styczniem 2020 r. nie mają tego powiązania. Jeśli masz klaster, który został utworzony przed styczniem 2020 r., nowy klasterMonitoringUser można dodać do istniejącego klastra, wykonując operację PUT w klastrze. Możesz też wykonać dowolną inną operację w klastrze, która wykonuje operację PUT w klastrze, taką jak aktualizowanie wersji klastra.

Klaster Kubernetes bez włączonej kontroli dostępu opartej na rolach platformy Kubernetes

Jeśli masz klaster Kubernetes, który nie jest skonfigurowany z autoryzacją RBAC platformy Kubernetes lub zintegrowany z logowaniem jednokrotnym firmy Microsoft Entra, nie musisz wykonywać tych kroków. Masz już uprawnienia administracyjne domyślnie w konfiguracji innej niż RBAC.

Konfigurowanie autoryzacji RBAC platformy Kubernetes

Po włączeniu autoryzacji RBAC na platformie Kubernetes klasterUżytkownik i klasterAdmin są używane do uzyskiwania dostępu do interfejsu API Kubernetes. Ta konfiguracja jest podobna do uruchamiania az aks get-credentials -n {cluster_name} -g {rg_name} bez opcji administracyjnej. Z tego powodu klasterUser musi mieć dostęp do punktów końcowych w interfejsie API platformy Kubernetes.

W poniższych przykładowych krokach pokazano, jak skonfigurować powiązanie roli klastra z tego szablonu konfiguracji YAML.

Skopiuj i wklej plik YAML i zapisz go jako Plik LogReaderRBAC.yaml.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
   name: containerHealth-log-reader
rules:
    - apiGroups: ["", "metrics.k8s.io", "extensions", "apps"]
      resources:
         - "pods/log"
         - "events"
         - "nodes"
         - "pods"
         - "deployments"
         - "replicasets"
      verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
   name: containerHealth-read-logs-global
roleRef:
   kind: ClusterRole
   name: containerHealth-log-reader
   apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: clusterUser
  apiGroup: rbac.authorization.k8s.io

Aby zaktualizować konfigurację, uruchom polecenie kubectl apply -f LogReaderRBAC.yaml.

Uwaga

Jeśli do klastra zastosowano poprzednią wersję pliku LogReaderRBAC.yaml , zaktualizuj go, kopiując i wklejając nowy kod pokazany w kroku 1. Następnie uruchom polecenie pokazane w kroku 2, aby zastosować je do klastra.

Konfigurowanie zintegrowanego uwierzytelniania firmy Microsoft

Klaster usługi AKS skonfigurowany do używania identyfikatora Entra firmy Microsoft do uwierzytelniania użytkownika używa poświadczeń logowania osoby, która uzyskuje dostęp do tej funkcji. W tej konfiguracji możesz zalogować się do klastra usługi AKS przy użyciu tokenu uwierzytelniania entra firmy Microsoft.

Aby umożliwić witrynie Azure Portal przekierowywanie stron autoryzacji jako zaufany adres URL przekierowania, należy ponownie skonfigurować rejestrację klienta firmy Microsoft Entra. Użytkownicy z identyfikatora Entra firmy Microsoft uzyskują dostęp bezpośrednio do tych samych punktów końcowych interfejsu API Kubernetes za pośrednictwem elementów ClusterRoles i ClusterRoleBindings.

Aby uzyskać więcej informacji na temat zaawansowanej konfiguracji zabezpieczeń na platformie Kubernetes, zapoznaj się z dokumentacją rozwiązania Kubernetes.

Uwaga

Jeśli tworzysz nowy klaster z włączoną kontrolą dostępu opartą na rolach Kubernetes, zobacz Integrowanie identyfikatora entra firmy Microsoft z usługą Azure Kubernetes Service i wykonaj kroki konfigurowania uwierzytelniania firmy Microsoft Entra. Podczas kroków tworzenia aplikacji klienckiej w tej sekcji wyróżniono dwa adresy URL przekierowania, które należy utworzyć dla szczegółowych informacji o kontenerze pasujących do tych określonych w kroku 3.

Ponowna konfiguracja rejestracji klienta

Znajdź rejestrację klienta dla klastra Kubernetes w obszarze Microsoft Entra ID w obszarze Microsoft Entra ID> Rejestracje aplikacji w witrynie Azure Portal.
W okienku po lewej stronie wybierz pozycję Uwierzytelnianie.
Dodaj dwa adresy URL przekierowania do tej listy jako typy aplikacji internetowych . Pierwszą podstawową wartością adresu URL powinna być https://afd.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. Druga podstawowa wartość adresu URL powinna mieć wartość https://monitoring.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.

Uwaga

Jeśli używasz tej funkcji na platformie Microsoft Azure obsługiwanej przez firmę 21Vianet, pierwszą podstawową wartością adresu URL powinna być https://afd.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. Druga podstawowa wartość adresu URL powinna mieć wartość https://monitoring.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.
Po zarejestrowaniu adresów URL przekierowania w obszarze Niejawne udzielanie wybierz opcje Tokeny dostępu i tokeny identyfikatorów. Następnie zapisz zmiany.

Uwierzytelnianie można skonfigurować za pomocą identyfikatora Microsoft Entra ID tylko do logowania jednokrotnego podczas początkowego wdrażania nowego klastra usługi AKS. Nie można skonfigurować logowania jednokrotnego dla klastra usługi AKS, który został już wdrożony.

Ważne

Jeśli ponownie skonfigurowano identyfikator Entra firmy Microsoft na potrzeby uwierzytelniania użytkownika przy użyciu zaktualizowanego identyfikatora URI, wyczyść pamięć podręczną przeglądarki, aby upewnić się, że zaktualizowany token uwierzytelniania zostanie pobrany i zastosowany.

Udzielanie uprawnień

Każde konto Microsoft Entra musi mieć uprawnienie do odpowiednich interfejsów API na platformie Kubernetes w celu uzyskania dostępu do funkcji Live Data. Kroki udzielania konta Microsoft Entra są podobne do kroków opisanych w sekcji Uwierzytelnianie RBAC platformy Kubernetes. Przed zastosowaniem szablonu konfiguracji YAML do klastra zastąp element clusterUser w obszarze ClusterRoleBinding żądanym użytkownikiem.

Ważne

Jeśli użytkownik, dla którego przyznano powiązanie RBAC platformy Kubernetes, znajduje się w tej samej dzierżawie firmy Microsoft Entra, przypisz uprawnienia na userPrincipalNamepodstawie elementu . Jeśli użytkownik znajduje się w innej dzierżawie firmy Microsoft Entra, wykonaj zapytanie dotyczące właściwości i użyj jej objectId .

Aby uzyskać więcej pomocy w konfigurowaniu klastra usługi AKS ClusterRoleBinding, zobacz Create Kubernetes RBAC binding (Tworzenie powiązania RBAC platformy Kubernetes).

Następne kroki

Po skonfigurowaniu uwierzytelniania możesz wyświetlać metryki i zdarzenia oraz dzienniki w czasie rzeczywistym z klastra.

Udostępnij za pośrednictwem

Konfigurowanie danych na żywo w usłudze Container Insights

Model uwierzytelniania

Używanie klastraMonitoringUser z klastrami z obsługą kontroli dostępu opartej na rolach Platformy Kubernetes

Klaster Kubernetes bez włączonej kontroli dostępu opartej na rolach platformy Kubernetes

Konfigurowanie autoryzacji RBAC platformy Kubernetes

Konfigurowanie zintegrowanego uwierzytelniania firmy Microsoft

Ponowna konfiguracja rejestracji klienta

Udzielanie uprawnień

Następne kroki

Opinia

Dodatkowe zasoby