Ověřování Spring Cloud v Azure

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

Pomocí Microsoft Entra ID můžete pomocí Azure řízení přístupu na základě role (Azure RBAC) udělit oprávnění objektu zabezpečení, což může být uživatel nebo instanční objekt aplikace. Když se objekt zabezpečení (uživatel nebo aplikace) pokusí o přístup k Azure prostředku, jako je prostředek služby Event Hubs, musí být požadavek autorizovaný. 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 pokusí se přečíst informace o účtu zadané prostřednictvím proměnných prostředí a použít ho k ověření.
  • 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 rozhraní příkazového řádku pro vývojáře – pokud jste se ověřili prostřednictvím rozhraní příkazového řádku pro vývojáře Azure, DefaultAzureCredential pokusí se ověřit pomocí daného účtu.

Spropitné

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

Poznámka

Vzhledem k tomu, že Spring Cloud Azure AutoConfigure 4.1.0, musíte zaregistrovat ThreadPoolTaskExecutor bean s názvem springCloudAzureCredentialTaskExecutor ke správě všech vláken vytvořených službou Azure Identity. Název každého vlákna spravovaného tímto fondem vláken má předponu az-identity-. Tato ThreadPoolTaskExecutor bean je nezávislá na Executor bean, kterou 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 funguje scénář vývoje místně pomocí informací o účtu uložených místně a pak nasaďte aplikaci do Azure cloudu a pomocí 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.

Spropitné

Pokud chcete získat přístup k prostředku Azure, ujistěte se, že má objekt zabezpečení 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 typu TokenCredential, který se má použít při ověřování v Azure.

Spropitné

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á Azure SDK objekt pro vytváření klientů nejprve přijme vlastní typ bean, TokenCredential pokud zadáte vlastnost token-credential-bean-name, a vrátí se k použitíDefaultAzureCredential, pokud nenakonfigurujete vlastnosti přihlašovacích údajů.

Ověřování pomocí přizpůsobené hodnoty TokenCredential bean

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 s tajným klíčem klienta

Následující příklad ukazuje, jak provést ověření 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ěřování pomocí instančního objektu s klientským certifikátem

Následující příklad ukazuje, jak provést ověření pomocí instančního objektu 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 ověřit pomocí instančního objektu 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ěření služby pomocí různých přihlašovacích údajů od ostatních

Následující příklad ukazuje, jak se ověřit pomocí Key Vault pomocí jiného instančního objektu. Tento příklad nakonfiguruje aplikaci se dvěma přihlašovacími údaji: jednou spravovanou identitou přiřazenou systémem a jedním instančním objektem. Tajný klíč služby Key Vault používá instanční objekt, ale všechny ostatní komponenty 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

Krok autorizace vyžaduje přiřazení jedné nebo více rolí Azure objektu zabezpečení. Role, které přiřadíte objektu zabezpečení, určují oprávnění, která má objekt zabezpečení.

Spropitné

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íka 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íka dat služby 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ílatele dat služby Azure Event Hubs Umožňuje odesílat přístup k prostředkům Azure Event Hubs.
vlastníka 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ílatele dat služby Azure Service Bus Umožňuje odesílat přístup k prostředkům služby Azure Service Bus.
vlastníka 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
čtečky dat fronty služby Storage Čtení a výpis front a zpráv front azure Storage
přispěvatele 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 službu Event Hubs, Service Bus a frontu úložiště nebo vlastnosti Cache for Redis, přiřaďte Azure předdefinované role 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. Slouží spring.cloud.azure.storage.blob.sas-token například k ověření ve 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.