Uwierzytelnianie platformy Azure w usłudze Spring Cloud

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

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.

Typy poświadczeń

Platforma Spring Cloud Azure umożliwia konfigurowanie różnych typów poświadczeń na potrzeby uwierzytelniania, w tym DefaultAzureCredential, WorkloadIdentityCredential, ManagedIdentityCredential, ClientSecretCredential, AzureCliCredentialitd.

Wartość domyślnaAzureCredential

DefaultAzureCredential jest odpowiednia w przypadku większości scenariuszy, w których aplikacja ma być uruchamiana w chmurze platformy Azure, ponieważ łączy następujące poświadczenia:

• Poświadczenia są często używane do uwierzytelniania podczas wdrażania.
• Poświadczenia używane do uwierzytelniania w środowisku projektowym.

Nuta

DefaultAzureCredential ma uprościć rozpoczęcie pracy z zestawem Azure SDK, obsługując typowe scenariusze z rozsądnymi zachowaniami domyślnymi. Jeśli chcesz mieć większą kontrolę lub ustawienia domyślne nie obsługują twojego scenariusza, należy użyć innych typów poświadczeń.

DefaultAzureCredential próbuje uwierzytelnić się za pomocą następujących mechanizmów w następującej kolejności:

• Środowisko — DefaultAzureCredential próbuje odczytać informacje o koncie określone za pomocą zmiennych środowiskowych i użyć ich do uwierzytelnienia.
• Tożsamość zarządzana — jeśli aplikacja jest wdrożona na hoście platformy Azure z włączoną tożsamością zarządzaną, DefaultAzureCredential próbuje uwierzytelnić się przy użyciu tego konta.
• Tożsamość obciążenia — jeśli aplikacja jest wdrażana na maszynach wirtualnych, DefaultAzureCredential próbuje uwierzytelnić się przy użyciu tego konta.
• Udostępniona pamięć podręczna tokenów — jeśli uwierzytelnisz się za pośrednictwem programu Visual Studio, DefaultAzureCredential spróbuje uwierzytelnić się przy użyciu tego konta.
• IntelliJ — jeśli uwierzytelnisz się za pośrednictwem zestawu narzędzi Azure Toolkit for IntelliJ, DefaultAzureCredential spróbuje uwierzytelnić się przy użyciu tego konta.
• Interfejs wiersza polecenia platformy Azure — w przypadku uwierzytelnienia konta za pomocą polecenia interfejsu wiersza polecenia platformy Azure az loginDefaultAzureCredential próbuje się uwierzytelnić przy użyciu tego konta.
• Azure PowerShell — w przypadku uwierzytelnienia za pomocą programu Azure PowerShell DefaultAzureCredential próbuje uwierzytelnić się przy użyciu tego konta.
• Interfejs wiersza polecenia dla deweloperów platformy Azure — jeśli uwierzytelnisz się za pośrednictwem interfejsu wiersza polecenia dla deweloperów platformy Azure, DefaultAzureCredential próbuje uwierzytelnić się przy użyciu tego konta.

Napiwek

Upewnij się, że podmiot zabezpieczeń ma wystarczające uprawnienia dostępu do zasobu platformy Azure. Aby uzyskać więcej informacji, zobacz Authorize access with Microsoft Entra ID.

Nuta

Ponieważ rozwiązanie Spring Cloud Azure AutoConfigure 4.1.0 wymaga zarejestrowania ThreadPoolTaskExecutor fasoli o nazwie springCloudAzureCredentialTaskExecutor w celu zarządzania 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-. Ten fasola ThreadPoolTaskExecutor jest niezależna od fasoli Executor dostarczanej przez platformę 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ą konieczność 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 parametrów połączenia lub klucza w aplikacji, ponieważ jest ona bezpieczniejsza i pozwala 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 usunie tożsamość. Zgodnie z projektem tylko ten zasób platformy Azure może używać tej tożsamości do żądania tokenów z identyfikatora Entra firmy Microsoft.
• 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ą.

Nuta

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

Napiwek

Aby uzyskać dostęp do zasobu platformy Azure, upewnij się, że podmiot zabezpieczeń ma wystarczające uprawnienia. Aby uzyskać więcej informacji, zobacz Authorize access with Microsoft Entra ID.

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ę niż to, co jest udostępniane przez DefaultAzureCredential, lub ustawienia domyślne nie obsługują twojego scenariusza, należy użyć innych typów poświadczeń.

Uwierzytelnianie przy użyciu identyfikatora Entra firmy Microsoft

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łasność	Opis
identyfikator klienta	Identyfikator klienta do użycia podczas przeprowadzania uwierzytelniania jednostki usługi na platformie Azure.
klucz tajny klienta	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.
hasło-certyfikatu-klienta	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ą.
nazwa-bean-tokenu z poświadczeniami	Nazwa fasoli typu TokenCredential do użycia podczas uwierzytelniania za pomocą platformy Azure.

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 szuka w kilku miejscach, aby znaleźć dostępne poświadczenia. Każda fabryka konstruktora klienta zestawu Azure SDK przyjmuje niestandardową fasolę typu TokenCredential najpierw, jeśli właściwość token-credential-bean-name jest określona, i wraca do użycia DefaultAzureCredential, jeśli nie skonfigurowano właściwości poświadczeń.

Uwierzytelnianie przy użyciu dostosowanej fasoli TokenCredential

W poniższym przykładzie pokazano, jak zdefiniować niestandardowy TokenCredential fasoli w celu przeprowadzenia uwierzytelniania:

@Bean
TokenCredential myTokenCredential() {
    // Your concrete TokenCredential instance
}

spring.cloud.azure:
  credential:
    token-credential-bean-name: myTokenCredential

Uwierzytelnianie przy użyciu tożsamości zarządzanej przypisanej przez system

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

Uwierzytelnianie przy użyciu tożsamości zarządzanej przypisanej przez użytkownika

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}

Uwierzytelnianie przy użyciu jednostki usługi z kluczem tajnym klienta

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>

Nuta

Dozwolone wartości dla tenant-id to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użyto nieprawidłowego punktu końcowego (kont osobistych i organizacji) sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje wdzierżawy. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Convert single-tenant app to multitenant on Microsoft Entra ID.

Uwierzytelnianie przy użyciu jednostki usługi z certyfikatem klienta

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>

Nuta

Dozwolone wartości dla tenant-id to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użyto nieprawidłowego punktu końcowego (kont osobistych i organizacji) sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje wdzierżawy. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Convert single-tenant app to multitenant on 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>

Nuta

Dozwolone wartości dla tenant-id to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użyto nieprawidłowego punktu końcowego (kont osobistych i organizacji) sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje wdzierżawy. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Convert single-tenant app to multitenant on Microsoft Entra ID.

Uwierzytelnianie przy użyciu poświadczeń użytkownika

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}

Uwierzytelnianie usługi przy użyciu innych poświadczeń

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 używa jednostki usługi, ale inne składniki używają 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>

Nuta

Dozwolone wartości dla tenant-id to: common, organizations, consumerslub identyfikator dzierżawy. Aby uzyskać więcej informacji na temat tych wartości, zobacz sekcję Użyto nieprawidłowego punktu końcowego (kont osobistych i organizacji) sekcji Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje wdzierżawy. Aby uzyskać informacje na temat konwertowania aplikacji z jedną dzierżawą, zobacz Convert single-tenant app to multitenant on 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 ma 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.
czytnik danych App Configuration	Umożliwia dostęp do odczytu do danych usługi App Configuration.
właścicielem danych usługi Azure Event Hubs	Umożliwia pełny dostęp do zasobów usługi Azure Event Hubs.
odbiornika danych usługi Azure Event Hubs	Umożliwia odbieranie dostępu do zasobów usługi Azure Event Hubs.
nadawcy danych usługi Azure Event Hubs	Umożliwia wysyłanie dostępu do zasobów usługi Azure Event Hubs.
właścicielem danych usługi Azure Service Bus	Umożliwia pełny dostęp do zasobów usługi Azure Service Bus.
odbiornika danych usługi Azure Service Bus	Umożliwia odbieranie dostępu do zasobów usługi Azure Service Bus.
nadawcy danych usługi Azure Service Bus	Umożliwia wysyłanie dostępu do zasobów usługi Azure Service Bus.
właściciela 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.
Czytnik danych obiektów blob usługi Storage	Odczytywanie i wyświetlanie listy kontenerów i obiektów blob usługi Azure Storage.
czytnika 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.

Nuta

W przypadku używania usługi Spring Cloud Azure Resource Manager do pobierania parametrów 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ę platformy Azure Contributor. Usługa Azure Cache for Redis jest specjalna i możesz również przypisać rolę Redis Cache Contributor, aby uzyskać właściwości usługi Redis.

Nuta

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 usługi Key Vault.

Ważny

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 Configure role-based access control with Microsoft Entra ID for your Azure Cosmos DB account.

Uwierzytelnianie przy użyciu tokenów SAS

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

Uwierzytelnianie przy użyciu parametrów połączenia

Niektóre usługi platformy Azure obsługują parametry połączenia w celu udostępnienia informacji o połączeniu i poświadczeń. Aby nawiązać połączenie z tymi usługami platformy Azure przy użyciu parametrów połączenia, wystarczy skonfigurować spring.cloud.azure.<azure-service>.connection-string. Na przykład skonfiguruj spring.cloud.azure.eventhubs.connection-string, aby nawiązać połączenie z usługą Event Hubs.