Uwierzytelnianie platformy Azure w usłudze Spring Cloud

W tym artykule opisano metody uwierzytelniania usługi Spring Cloud Azure i ułatwia wybranie odpowiedniego typu poświadczeń w celu zabezpieczenia dostępu do Azure zasobów.

Uwierzytelnianie i autoryzacja przy użyciu identyfikatora Entra firmy Microsoft

Za pomocą Microsoft Entra ID można użyć Azure kontroli dostępu opartej na rolach (Azure kontroli dostępu opartej na rolach) w celu udzielenia 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 Azure, takiego jak zasób usługi Event Hubs, żądanie musi być autoryzowane. Przy użyciu Microsoft Entra ID dostęp do zasobu jest procesem dwuetapowym:

1. Najpierw uwierzytelnij tożsamość podmiotu zabezpieczeń i zwróć token OAuth 2.0.
2. Następnie przekaż token w ramach żądania do usługi Azure, aby autoryzować dostęp do określonego zasobu.

Typy poświadczeń

Usługa Spring Cloud Azure umożliwia konfigurowanie różnych typów poświadczeń na potrzeby uwierzytelniania, w tym DefaultAzureCredential, , WorkloadIdentityCredentialManagedIdentityCredential, ClientSecretCredential, AzureCliCredentiali innych.

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

DefaultAzureCredentialUpraszcza rozpoczęcie pracy z Azure SDK przez obsługę typowych scenariuszy z rozsądnymi zachowaniami domyślnymi. Jeśli chcesz mieć większą kontrolę lub ustawienia domyślne nie obsługują twojego scenariusza, użyj 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 zostanie wdrożona na hoście Azure z włączoną tożsamością zarządzaną, DefaultAzureCredential spróbuje uwierzytelnić się przy użyciu tego konta.
• Tożsamość obciążenia — jeśli aplikacja jest wdrożona na maszynie wirtualnej, DefaultAzureCredential spróbuje przeprowadzić uwierzytelnianie przy użyciu tego konta.
• Udostępniona pamięć podręczna tokenów — jeśli uwierzytelnisz się za pośrednictwem Visual Studio, DefaultAzureCredential spróbuje uwierzytelnić się przy użyciu tego konta.
• IntelliJ — jeśli uwierzytelnisz się za pomocą zestawu narzędzi Azure Toolkit for IntelliJ, DefaultAzureCredential spróbuje uwierzytelnić się przy użyciu tego konta.
• Azure CLI — w przypadku uwierzytelnienia konta za pomocą polecenia DefaultAzureCredential Azure CLI az login próbuje się uwierzytelnić przy użyciu tego konta.
• Azure PowerShell — w przypadku uwierzytelnienia za pośrednictwem Azure PowerShell DefaultAzureCredential próba uwierzytelnienia przy użyciu tego konta.
• Azure interfejs wiersza polecenia dewelopera — w przypadku uwierzytelnienia za pomocą interfejsu wiersza polecenia DefaultAzureCredential dewelopera Azure próbuje się uwierzytelnić 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 Microsoft Entra tokenów. Na przykład aplikacja może używać tożsamości zarządzanej do uzyskiwania dostępu do zasobów, takich jak Azure Key Vault, gdzie można przechowywać poświadczenia w bezpieczny sposób lub uzyskiwać dostęp do kont magazynu.

Użyj tożsamości zarządzanej zamiast używania parametry 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 lepiej obsługuje scenariusz tworzenia lokalnego przy użyciu informacji o koncie przechowywanych lokalnie, a następnie wdrażania aplikacji w chmurze 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 należy utworzyć tożsamość w Microsoft Entra powiązanym z cyklem życia tego wystąpienia usługi. Dlatego, gdy usuniesz zasób, platforma Azure automatycznie usuwa przypisaną tożsamość za Ciebie. 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żna również utworzyć tożsamość zarządzaną jako autonomiczny zasób 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. Dzięki tożsamościom zarządzanym przypisanym przez użytkownika zarządzasz tożsamością oddzielnie od zasobów, które go używają.

Nuta

W przypadku korzystania z tożsamości zarządzanej przypisanej przez użytkownika określ identyfikator klienta za pośrednictwem 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 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 DefaultAzureCredentialprogram , lub ustawienia domyślne nie obsługują twojego scenariusza, użyj innych typów poświadczeń.

Uwierzytelnianie przy użyciu identyfikatora Entra firmy Microsoft

Aby połączyć aplikacje z zasobami obsługującymi uwierzytelnianie Microsoft Entra, ustaw 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.
client-secret	Klucz tajny klienta używany podczas przeprowadzania uwierzytelniania jednostki usługi za pomocą platformy Azure.
client-certificate-path	Ścieżka pliku certyfikatu PEM do użycia podczas przeprowadzania uwierzytelniania jednostki usługi na platformie Azure.
client-certificate-password	Hasło pliku certyfikatu.
username	Nazwa użytkownika używana podczas przeprowadzania uwierzytelniania nazwy użytkownika/hasła na platformie Azure.
password	Hasło do użycia podczas uwierzytelniania nazwy użytkownika/hasła na platformie Azure.
managed-identity-enabled	Czy włączyć tożsamość zarządzaną.
token-credential-bean-name	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 Azure SDK fabryka konstruktora klienta przyjmuje najpierw niestandardową fasolę typuTokenCredential, jeśli określisz właściwość token-credential-bean-namei powrócisz do użyciaDefaultAzureCredential, jeśli nie skonfigurujesz właściwości poświadczeń.

Uwierzytelnianie przy użyciu dostosowanej fasoli TokenCredential

W poniższym przykładzie pokazano, jak zdefiniować niestandardową TokenCredential fasolę 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 z kluczem tajnym 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ę przy użyciu 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 Azure ról 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

Jeśli używasz usługi Spring Cloud Azure Resource Manager do pobierania parametrów połączenia dla usługi Event Hubs, Service Bus i kolejki magazynu lub właściwości pamięci podręcznej Cache for Redis, przypisz wbudowaną rolę ContributorAzure . 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 Key Vault określają, czy dany podmiot zabezpieczeń, czyli użytkownik, aplikacja lub grupa użytkowników, może wykonywać różne operacje na Key Vault wpisach tajnych, kluczach i certyfikatach. Zasady dostępu można przypisywać przy użyciu portalu Azure, Azure CLI lub 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

Usługi do uwierzytelniania można również skonfigurować przy użyciu sygnatury dostępu współdzielonego (SAS). spring.cloud.azure.<azure-service>.sas-token Użyj właściwości , aby skonfigurować to uwierzytelnianie. Na przykład użyj polecenia spring.cloud.azure.storage.blob.sas-token , aby uwierzytelnić się w usłudze Blob Storage.

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

Niektóre usługi Azure obsługują parametry połączenia w celu dostarczenia informacji o połączeniu i poświadczeń. Aby nawiązać połączenie z tymi usługami Azure przy użyciu parametrów połączenia, skonfiguruj usługę 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.