Ověřování Spring Cloud v Azure

  • Platí pro: ✅ Version 4.20.0, ✅ Version 5.25.0, ✅ Version 6.5.0, ✅ Version 7.4.0

Tento článek vysvětluje metody ověřování Spring Cloud Azure a pomáhá zvolit správný typ přihlašovacích údajů pro zabezpečení přístupu k prostředkům Azure.

Ověřování a autorizace pomocí Microsoft Entra ID

Při použití Microsoft Entra ID můžete pomocí řízení přístupu na základě rolí v Azure (Azure RBAC) udělit oprávnění objektu zabezpečení, kterým může být uživatel nebo instanční objekt aplikace. Když se objekt zabezpečení (uživatel nebo aplikace) pokusí získat přístup k prostředku Azure, jako je prostředek služby Event Hubs, musí být požadavek autorizován. Pomocí Microsoft Entra ID je přístup k prostředku dvoustupňový proces:

  1. Nejprve ověřte identitu objektu zabezpečení a vraťte token OAuth 2.0.
  2. V dalším kroku předejte token jako součást požadavku službě Azure k autorizaci přístupu k zadanému prostředku.

Typy přihlašovacích údajů

Spring Cloud Azure umožňuje konfigurovat různé typy přihlašovacích údajů pro ověřování, včetně DefaultAzureCredential, WorkloadIdentityCredential, ManagedIdentityCredential, ClientSecretCredential, AzureCliCredentiala dalších.

VýchozíAzureCredential

DefaultAzureCredential je vhodné pro většinu scénářů, ve kterých má aplikace běžet v Cloudu Azure, protože kombinuje následující přihlašovací údaje:

  • Přihlašovací údaje, které se běžně používají k ověření při nasazení.
  • Přihlašovací údaje používané k ověření ve vývojovém prostředí.

Poznámka

DefaultAzureCredentialzjednodušuje zahájení práce s Azure SDK tím, že zpracovává běžné scénáře s rozumným výchozím chováním. Pokud chcete mít větší kontrolu nebo výchozí nastavení váš scénář nepodporuje, použijte jiné typy přihlašovacích údajů.

DefaultAzureCredential se pokusí ověřit pomocí následujících mechanismů v pořadí:

Snímek obrazovky s tokem ověřování DefaultAzureCredential a pořadím přihlašovacích údajů

  • Prostředí – DefaultAzureCredential se pokouší načíst informace o účtu zadané prostřednictvím proměnných prostředí a použít je k ověření identity.
  • Spravovaná identita – Pokud je aplikace nasazená na hostitele Azure s povolenou spravovanou identitou, DefaultAzureCredential pokusí se ověřit pomocí daného účtu.
  • Identita úlohy – Pokud je aplikace nasazená na virtuální počítač, DefaultAzureCredential pokusí se ověřit pomocí daného účtu.
  • Mezipaměť sdílených tokenů – Pokud jste se ověřili prostřednictvím Visual Studio, DefaultAzureCredential pokusí se ověřit pomocí daného účtu.
  • IntelliJ – Pokud jste se ověřili prostřednictvím sady Azure Toolkit for IntelliJ, DefaultAzureCredential pokusí se ověřit pomocí daného účtu.
  • Azure CLI – Pokud jste účet ověřili pomocí příkazu Azure CLIaz login, DefaultAzureCredential pokusí se ověřit pomocí daného účtu.
  • Azure PowerShell – pokud jste se ověřili prostřednictvím Azure PowerShell, DefaultAzureCredential pokusí se ověřit pomocí daného účtu.
  • Azure Developer CLI - Pokud jste se přihlásili prostřednictvím Azure Developer CLI, DefaultAzureCredential se pokusí ověřit pomocí tohoto účtu.

Tip

Ujistěte se, že objekt zabezpečení má dostatečná oprávnění k přístupu k prostředku Azure. Další informace naleznete v tématu Autorizace přístupu pomocí microsoft Entra ID.

Poznámka

Od verze Spring Cloud Azure AutoConfigure 4.1.0 musíte zaregistrovat komponentu ThreadPoolTaskExecutor bean s názvem springCloudAzureCredentialTaskExecutor, která bude spravovat všechna vlákna vytvořená službou Azure Identity. Název každého vlákna spravovaného tímto fondem vláken má předponu az-identity-. Tento ThreadPoolTaskExecutor bean je nezávislý na Executor beanu, který poskytuje Spring Boot.

Spravované identity

Běžným problémem je správa tajných kódů a přihlašovacích údajů používaných k zabezpečení komunikace mezi různými komponentami, které tvoří řešení. Spravované identity eliminují potřebu správy přihlašovacích údajů. Spravované identity poskytují identitu pro aplikace, které se mají použít při připojování k prostředkům, které podporují ověřování Microsoft Entra. Aplikace můžou spravovanou identitu použít k získání Microsoft Entra tokenů. Aplikace může například použít spravovanou identitu pro přístup k prostředkům, jako je Azure Key Vault, kde můžete přihlašovací údaje ukládat zabezpečeným způsobem nebo přistupovat k účtům úložiště.

Spravovanou identitu používejte místo připojovací řetězec nebo klíče ve vaší aplikaci, protože je bezpečnější a šetří potíže se správou tajných kódů a přihlašovacích údajů. V tomto případě DefaultAzureCredential lépe vyhovuje scénáři místního vývoje s využitím lokálně uložených informací o účtu a následného nasazení aplikace do cloudu Azure s využitím spravované identity.

Typy spravovaných identit

Existují dva typy spravovaných identit:

  • systémově přiřazené – Některé služby Azure umožňují povolit spravovanou identitu přímo v instanci služby. Když povolíte spravovanou identitu přiřazenou systémem, vytvoříte identitu v Microsoft Entra, která je svázaná s životním cyklem této instance služby. Když tedy prostředek odstraníte, Azure automaticky odstraní identitu za vás. Na základě návrhu může tuto identitu použít pouze prostředek Azure k vyžádání tokenů z ID Microsoft Entra.
  • Přiřazená uživatelem – Spravovanou identitu můžete vytvořit také jako samostatný prostředek Azure. Spravovanou identitu přiřazenou uživatelem můžete vytvořit a přiřadit ji k jedné nebo více instancím služby Azure. U spravovaných identit přiřazených uživatelem spravujete identitu odděleně od prostředků, které ji používají.

Poznámka

Při použití spravované identity přiřazené uživatelem zadejte ID klienta prostřednictvím spring.cloud.azure.credential.client-id nebo spring.cloud.azure.<azure-service>.credential.client-id. Konfiguraci přihlašovacích údajů nepotřebujete, pokud používáte spravovanou identitu přiřazenou systémem.

Tip

Abyste získali přístup k prostředku Azure, ujistěte se, že zabezpečovací objekt má dostatečná oprávnění. Další informace naleznete v tématu Autorizace přístupu pomocí microsoft Entra ID.

Další informace o spravované identitě najdete v tématu Co jsou spravované identity pro prostředky Azure?.

Jiné typy přihlašovacích údajů

Pokud chcete mít větší kontrolu nad tím, co poskytuje DefaultAzureCredential, nebo výchozí nastavení váš scénář nepodporuje, použijte jiné typy přihlašovacích údajů.

Ověřování pomocí ID Microsoft Entra

Pokud chcete připojit aplikace k prostředkům, které podporují ověřování Microsoft Entra, nastavte následující konfigurace s předponou spring.cloud.azure.credential nebo spring.cloud.azure.<azure-service>.credential.

Následující tabulka uvádí vlastnosti ověřování:

Vlastnost Popis
client-id ID klienta, které se má použít při ověřování instančního objektu v Azure.
client-secret Tajný klíč klienta, který se má použít při ověřování instančního objektu v Azure.
client-certificate-path Cesta k souboru certifikátu PEM, který se má použít při ověřování instančního objektu v Azure
client-certificate-password Heslo souboru certifikátu.
username Uživatelské jméno, které se má použít při ověřování pomocí uživatelského jména a hesla v Azure.
password Heslo, které se má použít při ověřování pomocí uživatelského jména a hesla v Azure.
managed-identity-enabled Určuje, jestli chcete povolit spravovanou identitu.
token-credential-bean-name Název beanu typu TokenCredential, který se má použít při ověřování pomocí Azure.

Tip

Seznam všech vlastností konfigurace Azure Spring Cloud najdete v tématu Vlastnosti konfigurace Spring Cloud Azure.

Aplikace hledá na několika místech dostupné přihlašovací údaje. Každá továrna pro vytváření klientů Azure SDK nejprve použije vlastní bean typu TokenCredential, pokud zadáte vlastnost token-credential-bean-name, a pokud vlastnosti přihlašovacích údajů nenakonfigurujete, použije místo toho DefaultAzureCredential.

Ověřování pomocí vlastního objektu bean TokenCredential

Následující příklad ukazuje, jak definovat vlastní TokenCredential bean k provedení ověřování:

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

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

Ověřování pomocí spravované identity přiřazené systémem

Následující příklad ukazuje, jak se ověřit pomocí spravované identity přiřazené systémem:

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

Ověřování pomocí spravované identity přiřazené uživatelem

Následující příklad ukazuje, jak se ověřit pomocí spravované identity přiřazené uživatelem:

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

Ověřování pomocí instančního objektu služby s tajným klíčem klienta

Následující příklad ukazuje, jak se ověřit pomocí instančního objektu s tajným klíčem klienta:

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

Poznámka

Hodnoty povolené pro tenant-id jsou: common, organizations, consumersnebo ID tenanta. Další informace o těchto hodnotách najdete v části Použití nesprávného koncového bodu (osobních a organizačních účtů) části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity vtenanta neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod jednoklientských aplikací na víceklienta vMicrosoft Entra ID .

Ověřte se pomocí instančního objektu a klientského certifikátu

Následující příklad ukazuje, jak se ověřit pomocí instančního objektu služby s klientským certifikátem 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>

Poznámka

Hodnoty povolené pro tenant-id jsou: common, organizations, consumersnebo ID tenanta. Další informace o těchto hodnotách najdete v části Použití nesprávného koncového bodu (osobních a organizačních účtů) části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity vtenanta neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod jednoklientských aplikací na víceklienta vMicrosoft Entra ID .

Následující příklad ukazuje, jak se ověřit pomocí instančního objektu služby s klientským certifikátem PEM:

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

Poznámka

Hodnoty povolené pro tenant-id jsou: common, organizations, consumersnebo ID tenanta. Další informace o těchto hodnotách najdete v části Použití nesprávného koncového bodu (osobních a organizačních účtů) části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity vtenanta neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod jednoklientských aplikací na víceklienta vMicrosoft Entra ID .

Ověřování pomocí přihlašovacích údajů uživatele

Následující příklad ukazuje, jak se ověřit pomocí přihlašovacích údajů uživatele:

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

Ověřte službu pomocí jiného přihlašovacího údaje než ostatní.

Následující příklad ukazuje, jak ověřit svou identitu ve službě Key Vault pomocí jiného instančního objektu služby. Tento příklad nakonfiguruje aplikaci pomocí dvou přihlašovacích údajů: jedné spravované identity přiřazené systémem a jednoho instančního objektu služby. Klient pro tajné kódy služby Key Vault používá instanční objekt služby, ale všechny ostatní komponenty místo toho používají spravovanou identitu.

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>

Poznámka

Hodnoty povolené pro tenant-id jsou: common, organizations, consumersnebo ID tenanta. Další informace o těchto hodnotách najdete v části Použití nesprávného koncového bodu (osobních a organizačních účtů) části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity vtenanta neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod jednoklientských aplikací na víceklienta vMicrosoft Entra ID .

Autorizace přístupu pomocí Microsoft Entra ID

V kroku autorizace je nutné přiřadit objektu zabezpečení jednu nebo více rolí Azure. Role, které přiřadíte objektu zabezpečení, určují oprávnění, která má objekt zabezpečení.

Tip

Seznam všech předdefinovaných rolí Azure najdete v tématu předdefinované role Azure.

Následující tabulka uvádí předdefinované role Azure pro autorizaci přístupu ke službám Azure podporovaným v Azure Spring Cloud:

Role Popis
Vlastník dat konfigurace aplikace Umožňuje úplný přístup ke konfiguračním datům aplikace.
čtečka dat konfigurace aplikace Umožňuje přístup pro čtení ke konfiguračním datům aplikace.
Vlastník dat Azure Event Hubs Umožňuje úplný přístup k prostředkům azure Event Hubs.
příjemce dat služby Azure Event Hubs Umožňuje přijímat přístup k prostředkům azure Event Hubs.
Odesílatel dat služby Azure Event Hubs Umožňuje odesílat přístup k prostředkům Azure Event Hubs.
Vlastník dat služby Azure Service Bus Umožňuje úplný přístup k prostředkům služby Azure Service Bus.
příjemce dat služby Azure Service Bus Umožňuje přijímat přístup k prostředkům služby Azure Service Bus.
Odesílatel dat služby Azure Service Bus Umožňuje odesílat přístup k prostředkům služby Azure Service Bus.
Vlastník dat objektů blob služby Storage Poskytuje úplný přístup k kontejnerům objektů blob a datům Azure Storage, včetně přiřazování řízení přístupu POSIX.
čtečka dat objektů blob služby Storage Čtení a výpis kontejnerů a objektů blob Služby Azure Storage
Čtenář dat fronty Storage Queue Čtení a výpis front a zpráv front azure Storage
Přispěvatel Redis Cache Správa mezipamětí Redis

Poznámka

Pokud používáte Spring Cloud Azure Resource Manager k získání připojovacích řetězců pro Event Hubs, Service Bus a Storage Queue nebo vlastností služby Cache for Redis, přiřaďte předdefinovanou roli Azure Contributor. Azure Cache for Redis je speciální a můžete také přiřadit roli Redis Cache Contributor pro získání vlastností Redis.

Poznámka

Zásada přístupu Key Vault určuje, jestli daný objekt zabezpečení, konkrétně uživatel, aplikace nebo skupina uživatelů, může provádět různé operace s Key Vault tajnými klíči, klíči a certifikáty. Zásady přístupu můžete přiřadit pomocí portálu Azure, Azure CLI nebo Azure PowerShell. Další informace najdete v tématu Přiřazení zásad přístupu ke službě Key Vault.

Důležitý

Azure Cosmos DB zveřejňuje dvě předdefinované definice rolí: Cosmos DB Built-in Data Reader a Cosmos DB Built-in Data Contributor. Podpora webu Azure Portal pro správu rolí zatím není dostupná. Další informace o modelu oprávnění, definicích rolí a přiřazení rolí najdete v tématu Konfigurace řízení přístupu na základě role pomocí Microsoft Entra ID pro účet služby Azure Cosmos DB.

Ověřování pomocí tokenů SAS

Můžete také nakonfigurovat služby pro ověřování pomocí sdíleného přístupového podpisu (SAS). spring.cloud.azure.<azure-service>.sas-token Ke konfiguraci tohoto ověřování použijte vlastnost. Například použijte spring.cloud.azure.storage.blob.sas-token k ověřování ke službě Storage Blob service.

Ověřování pomocí připojovacích řetězců

Některé Azure služby podporují připojovací řetězce a poskytují informace o připojení a přihlašovací údaje. Pokud se chcete připojit k těmto službám Azure pomocí připojovacích řetězců, nakonfigurujte spring.cloud.azure.<azure-service>.connection-string. Nakonfigurujte například spring.cloud.azure.eventhubs.connection-string pro připojení ke službě Event Hubs.

  • Poslední aktualizace v