Uwierzytelnianie w Spring Cloud Azure

W tym artykule opisano metody uwierzytelniania w Spring Cloud Azure oraz przedstawiono pomoc w wyborze odpowiedniego typu poświadczeń w celu zabezpieczenia dostępu do zasobów platformy Azure.

Uwierzytelnianie i autoryzacja przy użyciu identyfikatora Entra firmy Microsoft

Korzystając z usługi Microsoft Entra ID, można używać kontroli dostępu opartej na rolach platformy Azure (Azure RBAC) do przyznawania uprawnień podmiotowi zabezpieczeń, którym może być użytkownik lub nazwa główna 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.

Uwaga

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 roboczego — jeśli aplikacja jest wdrożona na maszynie wirtualnej (VM), DefaultAzureCredential spróbuje się uwierzytelnić za pomocą 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 — jeśli uwierzytelniono konto za pomocą polecenia Azure CLI az login, składnik DefaultAzureCredential próbuje uwierzytelnić się przy użyciu tego konta.
• Azure PowerShell — Jeśli uwierzytelniono się za pośrednictwem Azure PowerShell, DefaultAzureCredential próbuje się uwierzytelnić przy użyciu tego konta.
• Azure Developer CLI — jeśli uwierzytelniono się za pomocą Azure Developer CLI, DefaultAzureCredential próbuje uwierzytelnić się przy użyciu tego konta.

Wskazówka

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

Uwaga

Od wersji 4.1.0 Spring Cloud Azure AutoConfigure musisz zarejestrować komponent bean ThreadPoolTaskExecutor o nazwie springCloudAzureCredentialTaskExecutor, aby zarządzać wszystkimi wątkami tworzonymi przez Azure Identity. Nazwa każdego wątku zarządzanego przez tę pulę wątków ma prefiks az-identity-. Ten bean ThreadPoolTaskExecutor jest niezależny od beana Executor dostarczanego przez Spring Boot.

Tożsamości zarządzane

Częstym wyzwaniem jest zarządzanie sekretami i danymi uwierzytelniającymi używanymi do zabezpieczania komunikacji między różnymi komponentami wchodzącymi w skład rozwiązania. Tożsamości zarządzane eliminują konieczność zarządzania poświadczeniami. Tożsamości zarządzane zapewniają aplikacjom tożsamość, której mogą używać podczas łączenia się z zasobami obsługującymi uwierzytelnianie 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 parametrów połączenia lub klucza w aplikacji, ponieważ jest to bezpieczniejsze i pozwala uniknąć kłopotów 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 w usłudze Microsoft Entra jest tworzona tożsamość powiązana z cyklem życia tego wystąpienia usługi. Dlatego, gdy usuniesz zasób, platforma Azure automatycznie usuwa przypisaną tożsamość za Ciebie. Z założenia 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ż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ą.

Uwaga

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.

Wskazówka

Aby uzyskać dostęp do zasobu Azure, upewnij się, że podmiot zabezpieczeń ma wystarczające uprawnienia. Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu za pomocą 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 komponentu bean typu TokenCredential, używanego podczas uwierzytelniania przy użyciu platformy Azure.

Wskazówka

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

Uwierzytelnij się za pomocą niestandardowego beana 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>

Uwaga

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 niewłaściwego punktu końcowego (konta osobiste i organizacyjne) w artykule Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje na temat konwersji aplikacji z jedną dzierżawą na aplikację wielodzierżawną, zobacz Konwertowanie aplikacji z jedną dzierżawą na aplikację wielodzierżawną w usłudze Microsoft Entra ID.

Uwierzytelnianie za pomocą nazwy głównej usługi i certyfikatu klienta

Poniższy przykład pokazuje, jak uwierzytelniać przy użyciu jednostki usługi za pomocą certyfikatu klienta w formacie PFX:

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 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 niewłaściwego punktu końcowego (konta osobiste i organizacyjne) w artykule Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje na temat konwersji aplikacji z jedną dzierżawą na aplikację wielodzierżawną, zobacz Konwertowanie aplikacji z jedną dzierżawą na aplikację wielodzierżawną w usłudze Microsoft Entra ID.

Poniższy przykład pokazuje, jak uwierzytelnić się przy użyciu nazwy głównej usługi za pomocą certyfikatu klienta PEM:

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

Uwaga

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 niewłaściwego punktu końcowego (konta osobiste i organizacyjne) w artykule Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje na temat konwersji aplikacji jednotenantowej, zobacz Konwertowanie aplikacji jednotenantowej na wielotenantową w usłudze 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}

Uwierzytelnij usługę przy użyciu innych poświadczeń niż pozostałe

W poniższym przykładzie pokazano, jak uwierzytelnić się w usłudze Key Vault przy użyciu innej jednostki usługi. W tym przykładzie skonfigurowano aplikację przy użyciu dwóch poświadczeń: jednego poświadczenia w postaci tożsamości zarządzanej przypisanej przez system oraz jednej jednostki usługi. Klient wpisów tajnych usługi Key Vault używa nazwy głównej usługi, ale wszystkie pozostałe składniki używają zamiast tego 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 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 niewłaściwego punktu końcowego (konta osobiste i organizacyjne) w artykule Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie. Aby uzyskać informacje o konwertowaniu aplikacji jednodzierżawowej, zobacz Konwertowanie aplikacji jednodzierżawowej na wielodzierżawową w usłudze Microsoft Entra ID.

Autoryzowanie dostępu za pomocą identyfikatora Entra firmy Microsoft

Etap autoryzacji wymaga przypisania jednej lub większej liczby ról platformy Azure do podmiotu zabezpieczeń. Role, które przypisujesz do podmiotu zabezpieczeń, określają, jakie uprawnienia ma ten podmiot.

Wskazówka

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 usługi 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.
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.
Storage właściciel danych obiektów blob	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 obiektów blob usługi Storage	Odczytywanie i wyświetlanie listy kontenerów i obiektów blob usługi Azure Storage.
Czytnik danych kolejki magazynu	Odczytywanie i wyświetlanie listy kolejek i komunikatów usługi Azure Storage.
Współautor Redis Cache	Zarządzaj pamięciami podręcznymi Redis.

Uwaga

Jeśli używasz 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 usługi Cache for 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.

Uwaga

Zasada dostępu do usługi Key Vault określa, czy dany podmiot zabezpieczeń, a mianowicie użytkownik, aplikacja lub grupa użytkowników, może wykonywać różne operacje na wpisach tajnych, kluczach i certyfikatach w usłudze Key Vault. 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). Użyj właściwości spring.cloud.azure.<azure-service>.sas-token, aby skonfigurować tę metodę uwierzytelniania. 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.