Uwierzytelnianie platformy Azure w usłudze Spring Cloud

Ten artykuł dotyczy:✅ w wersji 4.19.0 ✅ w wersji 5.19.0

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

Wartość domyślnaAzureCredential

DefaultAzureCredential jest odpowiednia 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.

Nuta

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ń.

DefaultAzureCredential podejmie próbę uwierzytelnienia za pomocą następujących mechanizmów w następującej kolejności:

• Środowisko — DefaultAzureCredential odczytuje informacje o koncie określone za pośrednictwem zmiennych środowiskowych i używa ich do uwierzytelniania.
• Tożsamość zarządzana — jeśli aplikacja zostanie wdrożona na hoście platformy Azure z włączoną tożsamością zarządzaną, DefaultAzureCredential zostanie uwierzytelniony przy użyciu tego konta.
• IntelliJ — jeśli uwierzytelniono się za pomocą zestawu narzędzi Azure Toolkit for IntelliJ, DefaultAzureCredential uwierzytelni się przy użyciu tego konta.
• Visual Studio Code — jeśli uwierzytelniono się za pośrednictwem wtyczki konta platformy Azure programu Visual Studio Code, DefaultAzureCredential zostanie uwierzytelniony przy użyciu tego konta.
• Interfejs wiersza polecenia platformy Azure — jeśli konto zostało uwierzytelnione za pośrednictwem interfejsu wiersza polecenia platformy Azure az login, DefaultAzureCredential zostanie uwierzytelniony 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 Authorize access with Microsoft Entra ID.

Nuta

Ponieważ spring Cloud Azure AutoConfigure 4.1.0, fasola ThreadPoolTaskExecutor o nazwie 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-. 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 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 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

Upewnij się, że podmiot zabezpieczeń otrzymał wystarczające uprawnienia dostępu do zasobu platformy Azure. 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ę lub scenariusz nie jest obsługiwany przez DefaultAzureCredential lub ustawienia domyślne, 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 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
client-id	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.
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żywać 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>

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 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.

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>

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 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.
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.

Tokeny sygnatury 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 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.

Parametry połączenia

Parametry połączenia 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 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.