Uwierzytelnianie platformy Azure w usłudze Spring Cloud

Ten artykuł dotyczy: ✔️ wersja 4.14.0 ✔️ w wersji 5.8.0

W tym artykule opisano wszystkie metody uwierzytelniania platformy Azure spring Cloud.

Wartość domyślnaAzureCredential

Jest DefaultAzureCredential to odpowiednie w przypadku większości scenariuszy, w których aplikacja ma być uruchamiana w chmurze platformy Azure. Jest to spowodowane tym, że DefaultAzureCredential łączy poświadczenia często używane do uwierzytelniania podczas wdrażania przy użyciu poświadczeń używanych do uwierzytelniania w środowisku projektowym.

Uwaga

DefaultAzureCredential Ma na celu uproszczenie rozpoczynania pracy z zestawem SDK przez obsługę typowych scenariuszy z rozsądnymi zachowaniami domyślnymi. Jeśli chcesz mieć większą kontrolę lub scenariusz nie jest obsługiwany przez ustawienia domyślne, należy użyć innych typów poświadczeń.

Element DefaultAzureCredential podejmie próbę uwierzytelnienia za pośrednictwem następujących mechanizmów w kolejności:

• Środowisko — element DefaultAzureCredential odczyta informacje o koncie określone za pomocą zmiennych środowiskowych i użyje ich do uwierzytelniania.
• Tożsamość zarządzana — jeśli aplikacja jest wdrażana na hoście platformy Azure z włączoną tożsamością zarządzaną, element DefaultAzureCredential przeprowadzi uwierzytelnianie za pomocą tego konta.
• IntelliJ — jeśli uwierzytelniono się za pomocą zestawu narzędzi Azure Toolkit for IntelliJ, DefaultAzureCredential zostanie uwierzytelnione przy użyciu tego konta.
• Visual Studio Code — jeśli uwierzytelniono się za pośrednictwem wtyczki konta platformy Azure programu Visual Studio Code, DefaultAzureCredential narzędzie zostanie uwierzytelnione przy użyciu tego konta.
• Interfejs wiersza polecenia platformy Azure — jeśli konto zostało uwierzytelnione za pomocą polecenia interfejsu wiersza polecenia az login platformy Azure, DefaultAzureCredential zostanie uwierzytelnione przy użyciu tego konta.

Napiwek

Upewnij się, że podmiot zabezpieczeń otrzymał wystarczające uprawnienia dostępu do zasobu platformy Azure. Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu za pomocą identyfikatora Entra firmy Microsoft.

Uwaga

Ponieważ platforma Spring Cloud Azure AutoConfigure 4.1.0, ThreadPoolTaskExecutor nazwa fasoli springCloudAzureCredentialTaskExecutor zostanie automatycznie zarejestrowana i będzie zarządzać wszystkimi wątkami utworzonymi przez usługę Azure Identity. Nazwa każdego wątku zarządzanego przez tę pulę wątków ma prefiks az-identity-. Fasola ta ThreadPoolTaskExecutor jest niezależna od fasoli Executor dostarczonej przez spring boot.

Tożsamości zarządzane

Typowym wyzwaniem jest zarządzanie wpisami tajnymi i poświadczeniami używanymi do zabezpieczania komunikacji między różnymi składnikami tworzącymi rozwiązanie. Tożsamości zarządzane eliminują potrzebę zarządzania poświadczeniami. Tożsamości zarządzane zapewniają tożsamość aplikacji do użycia podczas nawiązywania połączenia z zasobami obsługującymi uwierzytelnianie firmy Microsoft Entra. Aplikacje mogą używać tożsamości zarządzanej do uzyskiwania tokenów firmy Microsoft Entra. Na przykład aplikacja może używać tożsamości zarządzanej do uzyskiwania dostępu do zasobów, takich jak usługa Azure Key Vault, w której można przechowywać poświadczenia w bezpieczny sposób lub uzyskiwać dostęp do kont magazynu.

Zachęcamy do korzystania z tożsamości zarządzanej zamiast używania parametry połączenia lub klucza w aplikacji, ponieważ jest ona bezpieczniejsza i pozwoli zaoszczędzić problemy z zarządzaniem wpisami tajnymi i poświadczeniami. W takim przypadku DefaultAzureCredential może lepiej służyć scenariuszowi tworzenia lokalnego przy użyciu informacji o koncie przechowywanych lokalnie, a następnie wdrażania aplikacji w chmurze platformy Azure i używania tożsamości zarządzanej.

Typy tożsamości zarządzanych

Istnieją dwa typy tożsamości zarządzanych:

• Przypisane przez system — niektóre usługi platformy Azure umożliwiają włączenie tożsamości zarządzanej bezpośrednio w wystąpieniu usługi. Po włączeniu tożsamości zarządzanej przypisanej przez system tożsamość jest tworzona w usłudze Microsoft Entra, która jest powiązana z cyklem życia tego wystąpienia usługi. Dlatego po usunięciu zasobu platforma Azure automatycznie usuwa tożsamość. Zgodnie z projektem tylko ten zasób platformy Azure może używać tej tożsamości do żądania tokenów z usługi Microsoft Entra ID.
• Przypisane przez użytkownika — możesz również utworzyć tożsamość zarządzaną jako autonomiczny zasób platformy Azure. Możesz utworzyć tożsamość zarządzaną przypisaną przez użytkownika i przypisać ją do co najmniej jednego wystąpienia usługi platformy Azure. W przypadku tożsamości zarządzanych przypisanych przez użytkownika tożsamość jest zarządzana oddzielnie od zasobów, które go używają.

Uwaga

W przypadku korzystania z tożsamości zarządzanej przypisanej przez użytkownika można określić identyfikator klienta za pośrednictwem adresu spring.cloud.azure.credential.managed-identity-client-id lub spring.cloud.azure.<azure-service>.credential.managed-identity-client-id. Nie potrzebujesz konfiguracji poświadczeń, jeśli używasz tożsamości zarządzanej przypisanej przez system.

Napiwek

Upewnij się, że podmiot zabezpieczeń otrzymał wystarczające uprawnienia dostępu do zasobu platformy Azure. Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu za pomocą identyfikatora Entra firmy Microsoft.

Aby uzyskać więcej informacji na temat tożsamości zarządzanej, zobacz Co to są tożsamości zarządzane dla zasobów platformy Azure?.

Inne typy poświadczeń

Jeśli chcesz mieć większą kontrolę lub twój scenariusz nie jest obsługiwany przez DefaultAzureCredential ustawienia domyślne lub, należy użyć innych typów poświadczeń.

Uwierzytelnianie i autoryzacja przy użyciu identyfikatora Entra firmy Microsoft

Za pomocą identyfikatora Entra firmy Microsoft możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień jednostce zabezpieczeń, która może być użytkownikiem lub jednostką usługi aplikacji. Gdy podmiot zabezpieczeń (użytkownik lub aplikacja) próbuje uzyskać dostęp do zasobu platformy Azure, na przykład zasób usługi Event Hubs, żądanie musi być autoryzowane. W przypadku identyfikatora Entra firmy Microsoft dostęp do zasobu jest procesem dwuetapowym:

1. Najpierw tożsamość podmiotu zabezpieczeń jest uwierzytelniana, a token OAuth 2.0 jest zwracany.
2. Następnie token jest przekazywany jako część żądania do usługi platformy Azure w celu autoryzowania dostępu do określonego zasobu.

Uwierzytelnianie przy użyciu usługi Microsoft Entra ID

Aby połączyć aplikacje z zasobami obsługującymi uwierzytelnianie firmy Microsoft Entra, możesz ustawić następujące konfiguracje z prefiksem spring.cloud.azure.credential lub spring.cloud.azure.<azure-service>.credential

W poniższej tabeli wymieniono właściwości uwierzytelniania:

Właściwości	opis
client-id	Identyfikator klienta do użycia podczas przeprowadzania uwierzytelniania jednostki usługi na platformie Azure.
client-secret	Klucz tajny klienta używany podczas przeprowadzania uwierzytelniania jednostki usługi za pomocą platformy Azure.
ścieżka klienta-certyfikatu	Ścieżka pliku certyfikatu PEM do użycia podczas przeprowadzania uwierzytelniania jednostki usługi na platformie Azure.
client-certificate-password	Hasło pliku certyfikatu.
nazwa użytkownika	Nazwa użytkownika używana podczas przeprowadzania uwierzytelniania nazwy użytkownika/hasła na platformie Azure.
hasło	Hasło do użycia podczas uwierzytelniania nazwy użytkownika/hasła na platformie Azure.
tożsamość zarządzana włączona	Czy włączyć tożsamość zarządzaną.

Napiwek

Aby uzyskać listę wszystkich właściwości konfiguracji platformy Azure spring Cloud, zobacz Właściwości konfiguracji platformy Azure spring Cloud.

Aplikacja będzie szukać w kilku miejscach, aby znaleźć dostępne poświadczenia i będzie używana DefaultAzureCredential , jeśli nie skonfigurowano właściwości poświadczeń. Jeśli chcesz użyć określonych poświadczeń, zapoznaj się z poniższymi przykładami, aby uzyskać wskazówki.

W poniższym przykładzie pokazano, jak uwierzytelniać się przy użyciu tożsamości zarządzanej przypisanej przez system:

spring.cloud.azure:
  credential:
    managed-identity-enabled: true

W poniższym przykładzie pokazano, jak uwierzytelniać się przy użyciu tożsamości zarządzanej przypisanej przez użytkownika:

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
    client-id: ${AZURE_CLIENT_ID}

W poniższym przykładzie pokazano, jak uwierzytelniać się przy użyciu jednostki usługi przy użyciu klucza tajnego klienta:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-secret: ${AZURE_CLIENT_SECRET}
  profile:
    tenant-id: <tenant>

Uwaga

Dozwolone tenant-id wartości to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użycie nieprawidłowego punktu końcowego (konta osobiste i konta organizacji) w sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Konwertowanie aplikacji z jedną dzierżawą na wielodostępny w usłudze Microsoft Entra ID.

W poniższym przykładzie pokazano, jak uwierzytelniać się przy użyciu jednostki usługi przy użyciu certyfikatu PFX klienta:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
    client-certificate-password: ${AZURE_CLIENT_CERTIFICATE_PASSWORD}
  profile:
    tenant-id: <tenant>

Uwaga

Dozwolone tenant-id wartości to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użycie nieprawidłowego punktu końcowego (konta osobiste i konta organizacji) w sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Konwertowanie aplikacji z jedną dzierżawą na wielodostępny w usłudze Microsoft Entra ID.

W poniższym przykładzie pokazano, jak uwierzytelniać się przy użyciu jednostki usługi przy użyciu certyfikatu PEM klienta:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    client-certificate-path: ${AZURE_CLIENT_CERTIFICATE_PATH}
  profile:
    tenant-id: <tenant>

Uwaga

Dozwolone tenant-id wartości to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użycie nieprawidłowego punktu końcowego (konta osobiste i konta organizacji) w sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Konwertowanie aplikacji z jedną dzierżawą na wielodostępny w usłudze Microsoft Entra ID.

W poniższym przykładzie pokazano, jak uwierzytelniać się przy użyciu poświadczeń użytkownika:

spring.cloud.azure:
  credential:
    client-id: ${AZURE_CLIENT_ID}
    username: ${AZURE_USER_USERNAME}
    password: ${AZURE_USER_PASSWORD}

W poniższym przykładzie pokazano, jak uwierzytelniać się w usłudze Key Vault przy użyciu innej jednostki usługi. W tym przykładzie aplikacja konfiguruje dwie poświadczenia: jedną tożsamość zarządzaną przypisaną przez system i jedną jednostkę usługi. Klient wpisu tajnego usługi Key Vault będzie używać jednostki usługi, ale wszystkie inne składniki będą używać tożsamości zarządzanej.

spring.cloud.azure:
  credential:
    managed-identity-enabled: true
  keyvault.secret:
    credential:
      client-id: ${AZURE_CLIENT_ID}
      client-secret: ${AZURE_CLIENT_SECRET}
    profile:
      tenant-id: <tenant>

Uwaga

Dozwolone tenant-id wartości to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użycie nieprawidłowego punktu końcowego (konta osobiste i konta organizacji) w sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Konwertowanie aplikacji z jedną dzierżawą na wielodostępny w usłudze Microsoft Entra ID.

Autoryzowanie dostępu za pomocą identyfikatora Entra firmy Microsoft

Krok autoryzacji wymaga przypisania co najmniej jednej roli platformy Azure do podmiotu zabezpieczeń. Role przypisane do podmiotu zabezpieczeń określają uprawnienia, które będzie miał podmiot zabezpieczeń.

Napiwek

Aby uzyskać listę wszystkich wbudowanych ról platformy Azure, zobacz Role wbudowane platformy Azure.

W poniższej tabeli wymieniono wbudowane role platformy Azure służące do autoryzowania dostępu do usług platformy Azure obsługiwanych w usłudze Spring Cloud Azure:

Rola	opis
Właściciel danych konfiguracji aplikacji	Umożliwia pełny dostęp do danych usługi App Configuration.
Czytelnik danych konfiguracji aplikacji	Umożliwia dostęp do odczytu do danych usługi App Configuration.
Właściciel danych usługi Azure Event Hubs	Umożliwia pełny dostęp do zasobów usługi Azure Event Hubs.
Odbiornik danych usługi Azure Event Hubs	Umożliwia odbieranie dostępu do zasobów usługi Azure Event Hubs.
Nadawca danych usługi Azure Event Hubs	Umożliwia wysyłanie dostępu do zasobów usługi Azure Event Hubs.
Właściciel danych usługi Azure Service Bus	Umożliwia pełny dostęp do zasobów usługi Azure Service Bus.
Odbiornik danych usługi Azure Service Bus	Umożliwia odbieranie dostępu do zasobów usługi Azure Service Bus.
Nadawca danych usługi Azure Service Bus	Umożliwia wysyłanie dostępu do zasobów usługi Azure Service Bus.
Właściciel danych obiektu blob usługi Storage	Zapewnia pełny dostęp do kontenerów i danych obiektów blob usługi Azure Storage, w tym przypisywania kontroli dostępu POSIX.
Czytelnik danych obiektu blob usługi Storage	Odczytywanie i wyświetlanie listy kontenerów i obiektów blob usługi Azure Storage.
Czytelnik danych kolejki usługi Storage	Odczytywanie i wyświetlanie listy kolejek i komunikatów usługi Azure Storage.
Współautor pamięci podręcznej Redis Cache	Zarządzanie pamięciami podręcznymi Redis Cache.

Uwaga

W przypadku korzystania z usługi Spring Cloud Azure Resource Manager w celu uzyskania parametry połączenia dla usług Event Hubs, Service Bus i Storage Queue lub właściwości pamięci podręcznej Redis przypisz wbudowaną rolę Contributorplatformy Azure. Usługa Azure Cache for Redis jest specjalna i możesz również przypisać Redis Cache Contributor rolę, aby uzyskać właściwości usługi Redis.

Uwaga

Zasady dostępu usługi Key Vault określają, czy dany podmiot zabezpieczeń, czyli użytkownik, aplikacja lub grupa użytkowników, może wykonywać różne operacje na wpisach tajnych, kluczach i certyfikatach usługi Key Vault. Zasady dostępu można przypisywać przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell. Aby uzyskać więcej informacji, zobacz Przypisywanie zasad dostępu do usługi Key Vault.

Ważne

Usługa Azure Cosmos DB udostępnia dwie wbudowane definicje ról: Cosmos DB Built-in Data Reader i Cosmos DB Built-in Data Contributor. Jednak obsługa witryny Azure Portal na potrzeby zarządzania rolami nie jest jeszcze dostępna. Aby uzyskać więcej informacji na temat modelu uprawnień, definicji ról i przypisywania ról, zobacz Konfigurowanie kontroli dostępu opartej na rolach przy użyciu identyfikatora Entra firmy Microsoft dla konta usługi Azure Cosmos DB.

Tokeny sygnatur dostępu współdzielonego

Możesz również skonfigurować usługi do uwierzytelniania za pomocą sygnatury dostępu współdzielonego (SAS). spring.cloud.azure.<azure-service>.sas-token to właściwość do skonfigurowania. Na przykład użyj polecenia spring.cloud.azure.storage.blob.sas-token , aby uwierzytelnić się w usłudze Blob Storage.

Parametry połączeń

parametry Połączenie ion są obsługiwane przez niektóre usługi platformy Azure w celu dostarczania informacji o połączeniu i poświadczeń. Aby nawiązać połączenie z tymi usługami platformy Azure przy użyciu parametry połączenia, wystarczy skonfigurować usługę spring.cloud.azure.<azure-service>.connection-string. Można na przykład skonfigurować połączenie spring.cloud.azure.eventhubs.connection-string z usługą Event Hubs.