Ověřování Spring Cloud v Azure

Tento článek se vztahuje na:✅ verze 4.19.0 ✅ verze 5.20.1

Tento článek popisuje všechny metody ověřování Azure Spring Cloud.

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

S ID Microsoft Entra můžete pomocí řízení přístupu na základě role v Azure (Azure RBAC) udělit oprávnění k 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 prostředku Azure, například k prostředku služby Event Hubs, musí být požadavek autorizovaný. S ID Microsoft Entra je přístup k prostředku dvoustupňový proces:

1. Nejprve se ověří identita objektu zabezpečení a vrátí se token OAuth 2.0.
2. Dále se token předá jako součást požadavku službě Azure za účelem autorizace přístupu k zadanému prostředku.

Typy přihlašovacích údajů

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

DefaultAzureCredential

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

DefaultAzureCredential je určená ke zjednodušení práce se sadou 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, měli byste použít jiné typy přihlašovacích údajů.

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

• Prostředí – DefaultAzureCredential se pokusí 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 se pokusí ověřit pomocí daného účtu.
• Identita úlohy – Pokud je aplikace nasazená na virtuální počítače, DefaultAzureCredential se pokusí ověřit pomocí daného účtu.
• Sdílená mezipaměť tokenů – Pokud jste se ověřili prostřednictvím sady Visual Studio, DefaultAzureCredential se pokusí ověřit pomocí daného účtu.
• IntelliJ – Pokud jste se ověřili prostřednictvím sady Azure Toolkit for IntelliJ, DefaultAzureCredential se pokusí ověřit pomocí daného účtu.
• Azure CLI – Pokud jste účet ověřili pomocí příkazu Azure CLI az login, DefaultAzureCredential se pokusíte ověřit pomocí daného účtu.
• Azure PowerShell – Pokud jste se ověřili přes Azure PowerShell, DefaultAzureCredential se pokusí ověřit pomocí daného účtu.
• Azure Developer CLI – Pokud jste se ověřili prostřednictvím Azure Developer CLI, DefaultAzureCredential se pokusí 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 mohou použít spravovanou identitu k získání tokenů Microsoft Entra. 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ě.

Doporučujeme používat spravovanou identitu místo připojovacího řetězce 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 takovém případě by DefaultAzureCredential mohl lépe sloužit scénáři vývoje místně pomocí informací o účtu uložených místně a pak nasadit aplikaci do Cloudu Azure a použít spravovanou identitu.

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ří se identita v Microsoft Entra, která je svázaná s životním cyklem této instance služby. Takže když se prostředek odstraní, 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 se identita spravuje odděleně od prostředků, které ji používají.

Poznámka

Při použití spravované identity přiřazené uživatelem můžete zadat 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 DefaultAzureCredentialnebo výchozí nastavení váš scénář nepodporuje, měli byste použít 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, můžete nastavit 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
id klienta	ID klienta, které se má použít při ověřování instančního objektu v Azure.
tajný klíč klienta	Tajný klíč klienta, který se má použít při ověřování instančního objektu v Azure.
cesta k certifikátu klienta	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.
uživatelské jméno	Uživatelské jméno, které se má použít při ověřování pomocí uživatelského jména a hesla v Azure.
heslo	Heslo, které se má použít při ověřování pomocí uživatelského jména a hesla v Azure.
spravovaná identita s povolenou identitou	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á továrna pro tvůrce klienta Azure SDK přijímá vlastní bean typu TokenCredential nejprve v případě, že je zadaná vlastnost token-credential-bean-name, a vrátí se k použití DefaultAzureCredential, pokud nejsou nakonfigurované žádné 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 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ěřování pomocí instančního objektu s klientským certifikátem

Následující příklad ukazuje, jak ověřit 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ěření 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í jiných přihlašovacích údajů od ostatních

Následující příklad ukazuje, jak se ověřit ve službě 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, aby k objektu zabezpečení byla přiřazena jedna nebo více rolí Azure. Role přiřazené k 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

Při použití Spring Cloud Azure Resource Manageru k získání připojovacích řetězců pro Službu Event Hubs, Service Bus a Fronta úložiště nebo vlastností Cache for Redis přiřaďte předdefinované role 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 ke službě 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 tajnými klíči, klíči a certifikáty služby Key Vault. Zásady přístupu můžete přiřadit pomocí webu Azure Portal, Azure CLI nebo Azure PowerShellu. 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 je vlastnost, která se má nakonfigurovat. Použijte například spring.cloud.azure.storage.blob.sas-token k ověření ve službě Storage Blob Service.

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

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