Azure SDK for Python を使用して Azure サービスに対して Python アプリを認証する方法
アプリが Azure Storage、Azure Key Vault、または Azure AI サービスのような Azure ソースにアクセスする必要がある場合、アプリは Azure に対して認証される必要があります。 この要件は、Azure にデプロイされているか、オンプレミスにデプロイされているか、ローカルの開発者ワークステーションで開発中であるかに関係なく、すべてのアプリに当てはまります。 この記事では、Azure SDK for Python を使用するときに Azure に対してアプリを認証するための推奨される方法について説明します。
推奨されるアプリの認証方法
アプリで Azure リソースに対して認証を行うときは、接続文字列ではなくトークンベースの認証を使用します。 Python 用 Azure ID クライアント ライブラリはトークンベースの認証をサポートするクラスを提供し、アプリがローカル開発中か、Azure にデプロイされているか、オンプレミス サーバーにデプロイされているかに関わらず、アプリが Azure リソースに対してシームレスに認証できるようにします。
アプリで Azure リソースに対する認証に使用するトークンベース認証の特定の種類は、アプリが実行される場所によって異なります。 トークンベースの認証の種類を次の図に示します。
- 開発者がローカルでの開発時にアプリを実行している場合: アプリで、ローカル開発用のアプリケーション サービス プリンシパルまたは開発者の Azure 資格情報を使用して、Azure に対して認証を行うことができます。 これらのオプションについては、「ローカル開発時の認証」セクションで説明します。
- アプリが Azure でホストされている場合: アプリでマネージド ID を使用して Azure リソースに対して認証を行います。 このオプションについては、「サーバー環境での認証」セクションで説明します。
- アプリがオンプレミスでホストされデプロイされている場合: アプリでサービス プリンシパルを使用して Azure リソースに対して認証を行います。 このオプションについては、「サーバー環境での認証」セクションで説明します。
DefaultAzureCredential
Azure ID クライアント ライブラリに提供されている DefaultAzureCredential クラスを使用すると、アプリが実行されている環境に応じて異なる認証方法を使用できます。 そうすることで、コードを変更せずに、ローカル開発からテスト環境、運用環境へアプリを昇格できます。
環境ごとに適切な認証方法を構成すると、DefaultAzureCredential によりその認証方法が自動的に検出されて使用されます。 さまざまな環境で異なる認証方法を使用するには、条件付きロジックや機能フラグを手動でコーディングするよりも、DefaultAzureCredential を使用することをお勧めします。
DefaultAzureCredential クラスの使用の詳細については、「アプリケーションで DefaultAzureCredential を使用する」セクションで説明します。
トークンベースの認証の利点
Azure 用アプリをビルドするときには、接続文字列を使用するのではなくトークンベースの認証を使用します。 トークンベースの認証には、接続文字列を使用した認証に比べて次のような利点があります。
- この記事で説明しているトークンベースの認証方法を使用すると、Azure リソースに対してアプリが必要とする特定のアクセス許可を確立できます。 この方法は、最小限の特権の原則に従ったものです。 これに対し、接続文字列では Azure リソースに対する完全な権限が付与されます。
- 接続文字列を使用するとすべてのユーザーまたはアプリが Azure リソースに接続できるのに対し、トークンベースの認証方法では、リソースへのアクセスのスコープは、リソースへのアクセスを意図しているアプリのみに設定されます。
- マネージド ID の場合、保存するアプリケーション シークレットはありません。 侵害される可能性がある接続文字列やアプリケーション シークレットが存在しないため、アプリの安全性が高くなります。
- azure-identity パッケージは、Microsoft Entra トークンを取得して管理します。 これにより、トークンベースの認証を接続文字列として簡単に使用できます。
接続文字列の使用は、運用環境や機密データにアクセスしない初期の概念実証アプリまたは開発プロトタイプに限定してください。 それ以外の場合、Azure リソースに対する認証時に、Azure ID クライアント ライブラリで使用できるトークンベースの認証クラスが常に優先されます。
サーバー環境での認証
サーバー環境でホストする場合、各アプリには、アプリが実行されている環境ごとに一意の "アプリケーション ID" が割り当てられます。 Azure では、アプリケーション ID はサービス プリンシパルによって表されます。 この特殊な種類のセキュリティ プリンシパルにより、アプリが 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 のアプリの ID を表し、アプリケーション登録プロセスを通じて作成されます。 たとえば、Azure Blob Storage を利用するオンプレミスでホストされている Django Web アプリがあるとします。 アプリの登録プロセスを使用して、アプリのアプリケーション サービス プリンシパルを作成します。 AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET はすべて環境変数として保存され、実行時にアプリケーションによって読み取られます。これにより、アプリでアプリケーション サービス プリンシパルを使用して Azure に対して認証を行うことができます。 |
ローカル開発時の認証
ローカル開発時に開発者のワークステーションでアプリを実行する場合でも、アプリで使用するすべての Azure サービスに対して認証を行う必要があります。 ローカル開発時に Azure に対してアプリを認証するための主な戦略は 2 つあります。
| 認証方法 | 説明 |
|---|---|
| ローカル開発時に使用する専用のアプリケーション サービス プリンシパル オブジェクトを作成する。 | この方法では、専用の "アプリケーション サービス プリンシパル" オブジェクトが、ローカル開発時に使用するアプリ登録プロセスを使用して設定されます。 その後、サービス プリンシパルの ID は、アプリがローカル開発で実行されるときにアクセスする環境変数として保存されます。 この方法では、ローカル開発時に開発者が使用するサービス プリンシパル オブジェクトに、アプリで必要な特定のリソース アクセス許可を割り当てることができます。 この方法により、アプリケーションで必要な特定のリソースのみにアクセスでき、運用環境でアプリに割り当てられるアクセス許可がレプリケートされます。 この方法の欠点は、アプリケーションで作業する開発者ごとに個別のサービス プリンシパル オブジェクトを作成する必要があることです。 |
| ローカル開発時に開発者の資格情報を使用して Azure に対してアプリを認証する。 | この方法では、開発者はローカルワークステーションのAzure CLI、Azure PowerShell、またはAzure Developer CLIからAzureにサインインする必要があります。 その後、アプリケーションは資格情報ストアから開発者の資格情報にアクセスし、それらの資格情報を使用してアプリから Azure リソースにアクセスできます。 この方法は、開発者が前述の開発者ツールのいずれかを使用してAzureアカウントにサインインするだけで済むため、セットアップが簡単になるという利点があります。 この方法の欠点は、開発者のアカウントにアプリケーションで必要とされるよりも多くのアクセス許可が与えられることです。 その結果、アプリケーションは運用環境での実行に使用するアクセス許可を正確にレプリケートしません。 |
アプリケーションで DefaultAzureCredential を使用する
DefaultAzureCredential は、Microsoft Entra IDに対する認証のための、堅牢な順序付けられた一連のメカニズムです。 各認証メカニズムは TokenCredential プロトコルを実装するクラスであり、資格情報と呼ばれます。 実行時に、DefaultAzureCredential は最初の資格情報を使用して認証を試みます。 その資格情報がアクセス トークンの取得に失敗した場合は、シーケンス内の次の資格情報が試みられ、正常にアクセス トークンが取得されるまでそれを続けます。 これにより、アプリは環境固有のコードを記述せずに、さまざまな環境でさまざまな資格情報を使用できます。
Python アプリで DefaultAzureCredential を使用するには、azure-identity パッケージをアプリケーションに追加します。
pip install azure-identity
Azure サービスには、さまざまな Azure SDK クライアント ライブラリの特殊なクライアント クラスを使用してアクセスします。 次のコード例で、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)
上記のコードをローカル開発ワークステーションで実行すると、環境変数でアプリケーション サービス プリンシパルが検索されるか、ローカルにインストールされた開発者ツール (Azure CLI など) で開発者の資格情報のセットが検索されます。 どちらのアプローチも、ローカル開発中に Azure リソースに対してアプリを認証するために使用できます。
Azure にデプロイすると、この同じコードで Azure リソースに対してアプリを認証することもできます。 DefaultAzureCredential では、Azure サービスに対して自動的に認証するための環境設定とマネージド ID 構成を取得できます。