Azure SDK for Python を使用して Azure サービスに対して Python アプリを認証する方法

[アーティクル]
03/01/2024

アプリケーションがAzure Storage、Azure Key Vault、またはAzure AIサービスのようなAzureリソースにアクセスする必要がある場合、アプリケーションはAzureに対して認証される必要があります。この要件は、Azure にデプロイされているか、オンプレミスにデプロイされているか、ローカルの開発者ワークステーションで開発中であるかに関係なく、すべてのアプリケーションに当てはまります。この記事では、Azure SDK for Python を使用するときに Azure に対してアプリを認証するための推奨される方法について説明します。

推奨されるアプリの認証方法

アプリで Azure リソースに対して認証を行うときは、接続文字列ではなくトークンベースの認証を使用します。 Azure SDK for Python には、トークンベースの認証をサポートするクラスが用意されています。アプリがローカル開発中であるか、Azure にデプロイされているか、オンプレミスサーバーにデプロイされているかにかかわらず、アプリを Azure リソースに対してシームレスに認証できます。

アプリで Azure リソースに対する認証に使用するトークンベース認証の特定の種類は、アプリが実行される場所によって異なります。トークンベースの認証の種類を次の図に示します。

A diagram that shows the recommended token-based authentication strategies for an app depending on where it's running.

開発者がローカルでの開発時にアプリを実行している場合: アプリで、ローカル開発用のアプリケーションサービスプリンシパルまたは開発者の Azure 資格情報を使用して、Azure に対して認証を行うことができます。これらのオプションについては、「ローカル開発時の認証」セクションで説明します。
アプリが Azure でホストされている場合: アプリでマネージド ID を使用して Azure リソースに対して認証を行います。このオプションについては、「サーバー環境での認証」セクションで説明します。
アプリがオンプレミスでホストされデプロイされている場合: アプリでサービスプリンシパルを使用して Azure リソースに対して認証を行います。このオプションについては、「サーバー環境での認証」セクションで説明します。

DefaultAzureCredential

Azure SDK に提供されている DefaultAzureCredential クラスを使用すると、アプリが実行されている環境に応じて異なる認証方法を使用できます。そうすることで、コードを変更せずに、ローカル開発からテスト環境、運用環境へアプリを昇格できます。

環境ごとに適切な認証方法を構成すると、DefaultAzureCredential によりその認証方法が自動的に検出されて使用されます。さまざまな環境で異なる認証方法を使用するには、条件付きロジックや機能フラグを手動でコーディングするよりも、DefaultAzureCredential を使用することをお勧めします。

DefaultAzureCredential クラスの使用の詳細については、「アプリケーションで DefaultAzureCredential を使用する」セクションで説明します。

トークンベースの認証の利点

Azure 用アプリをビルドするときには、接続文字列を使用するのではなくトークンベースの認証を使用します。トークンベースの認証には、接続文字列を使用した認証に比べて次のような利点があります。

この記事で説明しているトークンベースの認証方法を使用すると、Azure リソースに対してアプリが必要とする特定のアクセス許可を確立できます。この方法は、最小限の特権の原則に従ったものです。これに対し、接続文字列では Azure リソースに対する完全な権限が付与されます。
接続文字列を使用するとすべてのユーザーまたはアプリが Azure リソースに接続できるのに対し、トークンベースの認証方法では、リソースへのアクセスのスコープは、リソースへのアクセスを意図しているアプリのみに設定されます。
マネージド ID の場合、保存するアプリケーションシークレットはありません。侵害される可能性がある接続文字列やアプリケーションシークレットが存在しないため、アプリの安全性が高くなります。
Azure SDK の azure.identity パッケージでは、バックグラウンドでトークンを管理します。マネージドトークンにより、トークンベースの認証を接続文字列のように簡単に使用できるようになります。

接続文字列の使用は、運用環境や機密データにアクセスしない初期の概念実証アプリまたは開発プロトタイプに限定してください。それ以外の場合、Azure リソースに対する認証時に、Azure SDK で使用できるトークンベースの認証クラスが常に優先されます。

サーバー環境での認証

サーバー環境でホストする場合、各アプリケーションには、アプリケーションが実行されている環境ごとに一意の "アプリケーション ID" が割り当てられます。 Azure では、アプリ ID はサービスプリンシパルによって表されます。この特殊な種類のセキュリティプリンシパルにより、アプリが Azure に対して識別されて認証されます。アプリに使用するサービスプリンシパルの種類は、アプリが実行されている場所によって異なります。

認証方法説明

Azure でホストされているアプリ

認証方法	説明
Azure でホストされているアプリ	Azure でホストされているアプリでは、"マネージド ID サービスプリンシパル" を使用する必要があります。マネージド ID は、Azure でホストされているアプリの ID を表すように設計されており、Azure でホストされているアプリでのみ使用できます。たとえば、Azure App Service でホストされている Django Web アプリにはマネージド ID が割り当てられます。アプリに割り当てられたマネージド ID は、他の Azure サービスに対するアプリの認証に使用されます。 Azure Kubernetes Service（AKS）で実行されているアプリは、ワークロードIDクレデンシャルを使用できます。このクレデンシャルは、AKSサービスアカウントと信頼関係のある管理IDに基づいています。 , Azure でホストされているアプリからの認証について学習する
Azure の外部でホストされているアプリ (オンプレミスアプリなど)	Azure サービスに接続する必要がある Azure の外部でホストされているアプリ (オンプレミスアプリなど) では、"アプリケーションサービスプリンシパル" を使用する必要があります。アプリケーションサービスプリンシパルは Azure のアプリの ID を表し、アプリケーション登録プロセスを通じて作成されます。たとえば、Azure Blob Storage を利用するオンプレミスでホストされている Django Web アプリがあるとします。アプリの登録プロセスを使用して、アプリのアプリケーションサービスプリンシパルを作成します。 `AZURE_CLIENT_ID`、`AZURE_TENANT_ID`、`AZURE_CLIENT_SECRET` はすべて環境変数として保存され、実行時にアプリケーションによって読み取られます。これにより、アプリでアプリケーションサービスプリンシパルを使用して Azure に対して認証を行うことができます。 Azure の外部でホストされているアプリからの認証について学習する

Azure でホストされているアプリでは、"マネージド ID サービスプリンシパル" を使用する必要があります。マネージド ID は、Azure でホストされているアプリの ID を表すように設計されており、Azure でホストされているアプリでのみ使用できます。

たとえば、Azure App Service でホストされている Django Web アプリにはマネージド ID が割り当てられます。アプリに割り当てられたマネージド ID は、他の Azure サービスに対するアプリの認証に使用されます。

Azure Kubernetes Service（AKS）で実行されているアプリは、ワークロードIDクレデンシャルを使用できます。このクレデンシャルは、AKSサービスアカウントと信頼関係のある管理IDに基づいています。
,

Azure でホストされているアプリからの認証について学習する

Azure の外部でホストされているアプリ
(オンプレミスアプリなど)

Azure サービスに接続する必要がある Azure の外部でホストされているアプリ (オンプレミスアプリなど) では、"アプリケーションサービスプリンシパル" を使用する必要があります。アプリケーションサービスプリンシパルは Azure のアプリの ID を表し、アプリケーション登録プロセスを通じて作成されます。

たとえば、Azure Blob Storage を利用するオンプレミスでホストされている Django Web アプリがあるとします。アプリの登録プロセスを使用して、アプリのアプリケーションサービスプリンシパルを作成します。 AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET はすべて環境変数として保存され、実行時にアプリケーションによって読み取られます。これにより、アプリでアプリケーションサービスプリンシパルを使用して Azure に対して認証を行うことができます。

Azure の外部でホストされているアプリからの認証について学習する

ローカル開発時の認証

ローカル開発時に開発者のワークステーションでアプリケーションを実行する場合でも、アプリで使用するすべての Azure サービスに対して認証を行う必要があります。ローカル開発時に Azure に対してアプリを認証するための主な戦略は 2 つあります。

認証方法	説明
ローカル開発時に使用する専用のアプリケーションサービスプリンシパルオブジェクトを作成する。	この方法では、専用の "アプリケーションサービスプリンシパル" オブジェクトが、ローカル開発時に使用するアプリ登録プロセスを使用して設定されます。その後、サービスプリンシパルの ID は、アプリがローカル開発で実行されるときにアクセスする環境変数として保存されます。この方法では、ローカル開発時に開発者が使用するサービスプリンシパルオブジェクトに、アプリで必要な特定のリソースアクセス許可を割り当てることができます。この方法により、アプリケーションで必要な特定のリソースのみにアクセスでき、運用環境でアプリに割り当てられるアクセス許可がレプリケートされます。この方法の欠点は、アプリケーションで作業する開発者ごとに個別のサービスプリンシパルオブジェクトを作成する必要があることです。開発者サービスプリンシパルを使用したauthについて知る
ローカル開発時に開発者の資格情報を使用して Azure に対してアプリを認証する。	この方法では、開発者はローカルワークステーションのAzure CLI、Azure PowerShell、またはAzure Developer CLIからAzureにサインインする必要があります。その後、アプリケーションは資格情報ストアから開発者の資格情報にアクセスし、それらの資格情報を使用してアプリから Azure リソースにアクセスできます。この方法は、開発者が前述の開発者ツールのいずれかを使用してAzureアカウントにサインインするだけで済むため、セットアップが簡単になるという利点があります。この方法の欠点は、開発者のアカウントにアプリケーションで必要とされるよりも多くのアクセス許可が与えられることです。その結果、アプリケーションは運用環境での実行に使用するアクセス許可を正確にレプリケートしません。開発者アカウントを使用したauthについて知る

認証方法

説明

ローカル開発時に使用する専用のアプリケーションサービスプリンシパルオブジェクトを作成する。

この方法では、専用の "アプリケーションサービスプリンシパル" オブジェクトが、ローカル開発時に使用するアプリ登録プロセスを使用して設定されます。その後、サービスプリンシパルの ID は、アプリがローカル開発で実行されるときにアクセスする環境変数として保存されます。

この方法では、ローカル開発時に開発者が使用するサービスプリンシパルオブジェクトに、アプリで必要な特定のリソースアクセス許可を割り当てることができます。この方法により、アプリケーションで必要な特定のリソースのみにアクセスでき、運用環境でアプリに割り当てられるアクセス許可がレプリケートされます。

この方法の欠点は、アプリケーションで作業する開発者ごとに個別のサービスプリンシパルオブジェクトを作成する必要があることです。

開発者サービスプリンシパルを使用したauthについて知る

ローカル開発時に開発者の資格情報を使用して Azure に対してアプリを認証する。

この方法では、開発者はローカルワークステーションのAzure CLI、Azure PowerShell、またはAzure Developer CLIからAzureにサインインする必要があります。その後、アプリケーションは資格情報ストアから開発者の資格情報にアクセスし、それらの資格情報を使用してアプリから Azure リソースにアクセスできます。

この方法は、開発者が前述の開発者ツールのいずれかを使用してAzureアカウントにサインインするだけで済むため、セットアップが簡単になるという利点があります。この方法の欠点は、開発者のアカウントにアプリケーションで必要とされるよりも多くのアクセス許可が与えられることです。その結果、アプリケーションは運用環境での実行に使用するアクセス許可を正確にレプリケートしません。

開発者アカウントを使用したauthについて知る

アプリケーションで DefaultAzureCredential を使用する

Python アプリで DefaultAzureCredential を使用するには、azure.identity パッケージをアプリケーションに追加します。

pip install azure-identity

次のコード例で、DefaultAzureCredential オブジェクトのインスタンスを作成し、それを Azure SDK クライアントクラスと共に使用する方法を示します。この例では、Azure Blob Storage へのアクセスに使用される BlobServiceClient オブジェクトです。

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# Acquire a credential object
credential = DefaultAzureCredential()

blob_service_client = BlobServiceClient(
        account_url="https://<my_account_name>.blob.core.windows.net",
        credential=credential)

DefaultAzureCredential オブジェクトでアプリ用に構成された認証メカニズムを自動的に検出し、Azure に対してアプリを認証するために必要なトークンを取得します。アプリケーションで複数の SDK クライアントを使用する場合は、各 SDK クライアントオブジェクトで同じ資格情報オブジェクトを使用できます。

DefaultAzureCredential を使用するときの認証方法のシーケンス

内部的には、DefaultAzureCredential で Azure リソースに対してアプリケーションを認証するための資格情報プロバイダーのチェーンが実装されます。各資格情報プロバイダーでは、その種類の資格情報がアプリ用に構成されているかどうかを検出できます。 DefaultAzureCredential オブジェクトで各プロバイダーを順番にチェックし、資格情報が構成されている最初のプロバイダーの資格情報を使用します。

次の図と表に、DefaultAzureCredential で資格情報を検索する順序を示します。

資格情報の種類	説明
環境	`DefaultAzureCredential` オブジェクトで、一連の環境変数を読み取り、アプリケーションサービスプリンシパル (アプリケーションユーザー) がアプリに設定されているかどうかを判断します。そうであれば、`DefaultAzureCredential` はこれらの値を使用し、Azure に対してアプリを認証します。この方法は、サーバー環境で最もよく使用されますが、ローカルで開発する場合も使用できます。
ワークロード ID	アプリケーションがAzure Kubernetes Service（AKS）に展開されている場合、`DefaultAzureCredential`はその管理対象 ID を使用してAzureにアプリを認証します。ワークロードIDは、ユーザーが割り当てた管理IDとAKSサービスアカウントの間の信頼関係を表します。ワークロードIDを使用した認証については、AKSの記事「Azure KubernetesサービスでMicrosoft Entra Workload IDを使用する」を参照してください。
マネージド ID	マネージド ID が有効な Azure ホストにアプリケーションがデプロイされている場合、`DefaultAzureCredential` ではそのマネージド ID を使用して、Azure に対してアプリを認証します。マネージド ID を使用した認証については、「サーバー環境での認証」セクションで説明しています。この方法は、Azure App Service、Azure Functions、Azure Virtual Machines などのサービスを使用してアプリケーションが Azure でホストされている場合にのみ使用できます。
Azure CLI	Azure CLI の `az login` コマンドを使用して Azure に対して認証を行った場合は、`DefaultAzureCredential` で、その同じアカウントを使用して Azure に対してアプリを認証します。
Azure PowerShell	Azure PowerShell の `Connect-AzAccount` コマンドレットを使用して Azure に対して認証を行った場合は、`DefaultAzureCredential` で、その同じアカウントを使用して Azure に対してアプリを認証します。
Azure Developer CLI	Azure Developer CLIの`azd auth login`コマンドを使用してAzureに認証した場合、`DefaultAzureCredential`は同じアカウントを使用してAzureにアプリを認証します。
Interactive	有効にした場合は、`DefaultAzureCredential` で、現在のシステムの既定のブラウザーを介して対話形式で認証を行います。既定では、このオプションは無効になっています。

Note

既知の問題により、VisualStudioCodeCredentialはDefaultAzureCredentialトークンチェーンから削除されました。今後のリリースで問題が解決されると、この変更は元に戻ります。詳細については、Azure Identity client library for Pythonを参照してください。