Share via

Ověřování Spring Cloud v Azure

  • Článek

Tento článek se vztahuje na: ✔️ Verze 4.14.0 ✔️ verze 5.8.0

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

DefaultAzureCredential

Je DefaultAzureCredential vhodný pro většinu scénářů, ve kterých je aplikace určená ke spuštění v cloudu Azure. Důvodem je to, že DefaultAzureCredential kombinuje přihlašovací údaje, které se běžně používají k ověření při nasazení s přihlašovacími údaji použitými k ověření ve vývojovém prostředí.

Poznámka:

DefaultAzureCredential účelem je zjednodušit zahájení práce se sadou 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áš scénář není ve výchozím nastavení obsluhován, měli byste použít jiné typy přihlašovacích údajů.

DefaultAzureCredential se pokusí provést ověření pomocí následujících mechanismů v uvedeném pořadí:

Diagram showing the authentication mechanism for `DefaultAzureCredential`.

  • Prostředí – DefaultAzureCredential přečte informace o účtu určené pomocí proměnných prostředí a použije je k ověření.
  • Spravovaná identita – Pokud je aplikace nasazená na hostitele Azure se zapnutou spravovanou identitou, DefaultAzureCredential provede ověření s tímto účtem.
  • IntelliJ – Pokud jste provedli ověření prostřednictvím sady Azure Toolkit for IntelliJ, DefaultAzureCredential provede se ověření u daného účtu.
  • Visual Studio Code – Pokud jste se ověřili prostřednictvím modulu plug-in Azure Account pro Visual Studio Code, DefaultAzureCredential provede se ověření u daného účtu.
  • Azure CLI – Pokud jste účet ověřili pomocí příkazu Azure CLI az login , DefaultAzureCredential provede se ověření s tímto účtem.

Tip

Ujistěte se, že objekt zabezpečení má 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, ThreadPoolTaskExecutor název bean springCloudAzureCredentialTaskExecutor se ve výchozím nastavení automaticky zaregistruje a bude spravovat všechna vlákna vytvořená identitou Azure. 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 poskytované 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 spravovat tyto přihlašovací údaje. 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í řetězec nebo klíče ve vaší aplikaci, protože je bezpečnější a ušetří vám potíže se správou tajných kódů a přihlašovacích údajů. V takovém případě DefaultAzureCredential by mohl lépe sloužit scénář vývoje místně pomocí informací o účtu uložených místně a pak nasadit aplikaci do Azure Cloudu a použít spravovanou identitu.

Typy spravovaných identit

Existují dva typy spravovaných identit:

  • Přiřazené systémem – 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ž je tento prostředek odstraněn, Azure identitu automaticky odstraní. Z podstaty této identity vyplývá, že ji může k vyžadování tokenů z Microsoft Entra ID používat pouze daný prostředek Azure.
  • 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.managed-identity-client-id nebo spring.cloud.azure.<azure-service>.credential.managed-identity-client-id. Konfiguraci přihlašovacích údajů nepotřebujete, pokud používáte spravovanou identitu přiřazenou systémem.

Tip

Ujistěte se, že objekt zabezpečení má 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.

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 nebo váš scénář není obsluhován DefaultAzureCredential výchozím nastavením, měli byste použít jiné typy přihlašovacích údajů.

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.

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

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.
client-secret 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.
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.
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.

Tip

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

Aplikace vyhledá na několika místech dostupné přihlašovací údaje a použije DefaultAzureCredential se, pokud nejsou nakonfigurované žádné vlastnosti přihlašovacích údajů. Pokud chcete použít konkrétní přihlašovací údaje, pokyny najdete v následujících příkladech.

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

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}

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:

Povolené hodnoty 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 účtů a účtů organizace) v části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity v tenantovi neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod aplikace s jedním tenantem na víceklienta na ID Microsoft Entra.

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:

Povolené hodnoty 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 účtů a účtů organizace) v části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity v tenantovi neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod aplikace s jedním tenantem na víceklienta na ID Microsoft Entra.

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:

Povolené hodnoty 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 účtů a účtů organizace) v části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity v tenantovi neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod aplikace s jedním tenantem na víceklienta na ID Microsoft Entra.

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}

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 bude používat instanční objekt, ale všechny ostatní komponenty budou používat 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:

Povolené hodnoty 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 účtů a účtů organizace) v části Chyba AADSTS50020 – Uživatelský účet od zprostředkovatele identity v tenantovi neexistuje. Informace o převodu aplikace s jedním tenantem najdete v tématu Převod aplikace s jedním tenantem na víceklienta na ID Microsoft Entra.

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á bude mít 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.
Čtenář konfiguračních dat aplikace Umožňuje přístup pro čtení ke konfiguračním datům aplikace.
Vlastník 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í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 v objektech 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.
Čtenář dat v objektech blob služby Storage Čtení a výpis kontejnerů a objektů blob Služby Azure Storage
Čtenář dat fronty úložiště Č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í řetězec pro službu Event Hubs, Service Bus a frontu úložiště nebo vlastnosti Cache for Redis, přiřaďte předdefinované role ContributorAzure. Azure Cache for Redis je speciální a můžete také přiřadit Redis Cache Contributor roli 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 váš účet služby Azure Cosmos DB.

Tokeny 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á konfigurovat. Slouží spring.cloud.azure.storage.blob.sas-token například k ověření ve službě Storage Blob Service.

Připojovací řetězce

některé služby Azure podporují řetězec Připojení ion, 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í řetězec, stačí nakonfigurovat spring.cloud.azure.<azure-service>.connection-string. Nakonfigurujte spring.cloud.azure.eventhubs.connection-string například připojení ke službě Event Hubs.