Azure SDK for Go を使用して Azure サービスに対して Go アプリを認証する
アプリケーションが Azure Storage、Azure Key Vault、Azure AI サービスなどの Azure リソースにアクセスする必要がある場合は、アプリケーションを Azure に対して認証する必要があります。 この要件は、Azure にデプロイされているか、オンプレミスにデプロイされているか、ローカルの開発者ワークステーションで開発中であるかに関係なく、すべてのアプリケーションに当てはまります。 この記事では、Azure SDK for Go を使用するときに Azure に対してアプリを認証するための推奨される方法について説明します。
推奨されるアプリ認証方法
アプリが Azure リソースに対して認証を行うときは、接続文字列ではなくトークンベースの認証を使用します。 Azure SDK for Go には、トークンベースの認証をサポートするメカニズムが用意されています。 アプリがローカルで開発されているか、Azure にデプロイされているか、オンプレミス サーバーにデプロイされているかに関係なく、アプリは Azure リソースに対してシームレスに認証できます。
アプリが Azure リソースに対する認証に使用するトークン ベースの認証の特定の種類は、アプリの実行場所によって異なります。 トークン ベースの認証の種類を次の図に示します。
- 開発者がローカル開発時にアプリを実行している場合: アプリは、ローカル開発用のアプリケーション サービス プリンシパルまたは開発者の Azure 資格情報を使用して Azure に対して認証を行います。 これらのオプションについては、「ローカル開発時の認証
」セクションで説明します。 - アプリが Azure でホストされている場合: アプリはマネージド ID を使用して Azure リソースに対して認証を行います。 このオプションについては、「サーバー環境での認証
」セクションで説明します。 - アプリがオンプレミスでホストおよびデプロイされている場合: アプリケーション サービス プリンシパルを使用してアプリが Azure リソースに対して認証されます。 このオプションについては、「サーバー環境での認証
」セクションで説明します。
DefaultAzureCredential
Azure SDK によって提供される DefaultAzureCredential の種類を使用すると、アプリは実行環境に応じて異なる認証方法を使用できます。 これにより、コードを変更することなく、アプリをローカル開発からテスト環境から運用環境に昇格させることができます。
環境ごとに適切な認証方法を構成し、DefaultAzureCredential はその認証方法を自動的に検出して使用します。 条件付きロジックまたは機能フラグを手動でコーディングして、異なる環境で異なる認証方法を使用するよりも、DefaultAzureCredential を使用することをお勧めします。
トークン ベースの認証の利点
Azure 用アプリをビルドするときに接続文字列を使用する代わりに、トークンベースの認証を使用します。 トークンベースの認証は、接続文字列を使用した認証よりも次の利点を提供します。
- この記事で説明するトークン ベースの認証方法を使用すると、Azure リソースでアプリに必要な特定のアクセス許可を確立できます。 このプラクティスは、最小特権の
原則に従います。 これに対し、接続文字列は Azure リソースに対する完全な権限を付与します。 - 接続文字列を持つすべてのユーザーまたはアプリは Azure リソースに接続できますが、トークンベースの認証方法では、リソースへのアクセスを、リソースにアクセスすることを意図したアプリのみにスコープを設定します。
- マネージド ID では、格納するアプリケーション シークレットはありません。 侵害される可能性のある接続文字列やアプリケーション シークレットがないため、アプリの安全性が高くなります。
- Azure SDK の azidentity パッケージは、バックグラウンドでトークンを管理します。 マネージド トークンを使用すると、接続文字列と同じくらい簡単にトークンベースの認証を使用できます。
接続文字列の使用を、運用環境や機密データにアクセスしない初期の概念実証アプリまたは開発プロトタイプに制限します。 それ以外の場合は、Azure リソースに対する認証時に、Azure SDK で使用できるトークン ベースの認証が常に優先されます。
サーバー環境での認証
サーバー環境でホストしている場合、各アプリケーションには、アプリケーションが実行される環境ごとに一意の アプリケーション ID が割り当てられます。 Azure では、アプリ ID は サービス プリンシパルによって表されます。 この特殊な種類のセキュリティ プリンシパルは、Azure に対してアプリを識別して認証します。 アプリに使用するサービス プリンシパルの種類は、アプリが実行されている場所によって異なります。
| 認証方法 | 説明 |
|---|---|
| Azure でホストされているアプリ | Azure でホストされているアプリでは、マネージド ID サービス プリンシパルを使用する必要があります。 マネージド ID は、Azure でホストされているアプリの ID を表すように設計されており、Azure でホストされているアプリでのみ使用できます。 たとえば、Azure Container Apps でホストされている Gin Web アプリには、マネージド ID が割り当てられます。 アプリに割り当てられたマネージド ID は、他の Azure サービスに対するアプリの認証に使用されます。 Azure Kubernetes Service (AKS) で実行されているアプリでは、ワークロード ID 資格情報を使用できます。 この資格情報は、AKS サービス アカウントとの信頼関係を持つマネージド ID に基づいています。 |
| Azure の外部でホストされているアプリ (たとえば、オンプレミス のアプリ) |
Azure サービスに接続する必要がある Azure の外部でホストされているアプリ (オンプレミス アプリなど) では、アプリケーション サービス プリンシパルを使用する必要があります。 アプリケーション サービス プリンシパルは、Azure のアプリの ID を表し、アプリケーション登録プロセスを通じて作成されます。 たとえば、Azure Blob Storage を利用するオンプレミスでホストされている Gin Web アプリについて考えてみましょう。 アプリの登録プロセスを使用して、アプリのアプリケーション サービス プリンシパルを作成します。 AZURE_CLIENT_ID、AZURE_TENANT_ID、および AZURE_CLIENT_SECRET はすべて、実行時にアプリケーションが読み取る環境変数として格納され、アプリケーション サービス プリンシパルを使用してアプリが Azure に対して認証できるようにします。Azure の外部でホストされているアプリからの認証について説明します |
ローカル開発時の認証
ローカル開発中に開発者のワークステーションでアプリケーションを実行する場合でも、アプリで使用されるすべての Azure サービスに対して認証を行う必要があります。 ローカル開発時に Azure に対してアプリを認証するには、主に次の 2 つの戦略があります。
| 認証方法 | 説明 |
|---|---|
| ローカル開発時に使用する専用のアプリケーション サービス プリンシパル オブジェクトを作成します。 | この方法では、専用の アプリケーション サービス プリンシパル オブジェクトを、ローカル開発時に使用するアプリ登録プロセスを使用して設定します。 その後、サービス プリンシパルの ID は、アプリがローカル開発で実行されるときにアクセスする環境変数として格納されます。 このメソッドを使用すると、ローカル開発時に開発者が使用するサービス プリンシパル オブジェクトに、アプリで必要な特定のリソースアクセス許可を割り当てることができます。 この方法により、アプリケーションは必要な特定のリソースにのみアクセスでき、アプリが運用環境で持つアクセス許可がレプリケートされます。 このアプローチの欠点は、アプリケーションで作業する開発者ごとに個別のサービス プリンシパル オブジェクトを作成する必要がある点です。 |
| ローカル開発時に開発者の資格情報を使用して、Azure に対してアプリを認証します。 | この方法では、開発者はローカル ワークステーションで Azure CLI または Azure Developer CLI から Azure にサインインする必要があります。 その後、アプリケーションは資格情報ストアから開発者の資格情報にアクセスし、それらの資格情報を使用してアプリから Azure リソースにアクセスできます。 開発者は前述の開発者ツールのいずれかを使用して自分の Azure アカウントにサインインするだけで済むため、この方法ではセットアップが簡単になるという利点があります。 この方法の欠点は、開発者のアカウントに、アプリケーションで必要とされるよりも多くのアクセス許可があることです。 その結果、アプリケーションは運用環境で実行されるアクセス許可を正確にレプリケートしません。 |
アプリケーションで DefaultAzureCredential を使用する
DefaultAzureCredential は、Microsoft Entra ID に対する認証のための、堅牢な順序付けられた一連のメカニズムです。 各認証メカニズムは、TokenCredential インターフェイスを実装するクラスであり、資格情報と呼ばれます。 実行時に、DefaultAzureCredential は最初の資格情報を使用して認証を試みます。 その資格情報がアクセス トークンの取得に失敗した場合は、アクセス トークンが正常に取得されるまで、シーケンス内の次の資格情報が試行されます。 これにより、アプリは環境固有のコードを記述することなく、異なる環境で異なる資格情報を使用できます。
Go アプリ DefaultAzureCredential を使用するには、azidentity パッケージをアプリケーションに追加します。
go get github.com/Azure/azure-sdk-for-go/sdk/azidentity
次のコード例は、DefaultAzureCredentialを使用して Azure SDK クライアントのインスタンスを作成する方法を示しています。 この場合は、Azure Blob Storage へのアクセスに使用 azblob クライアントです。
import (
"context"
"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)
const (
account = "https://<replace_with_your_storage_account_name>.blob.core.windows.net/"
containerName = "sample-container"
blobName = "sample-blob"
sampleFile = "path/to/sample/file"
)
func main() {
// create a credential
cred, err := azidentity.NewDefaultAzureCredential(nil)
if err != nil {
// TODO: handle error
}
// create a client for the specified storage account
client, err := azblob.NewClient(account, cred, nil)
if err != nil {
// TODO: handle error
}
// TODO: perform some action with the azblob Client
// _, err = client.DownloadFile(context.TODO(), <containerName>, <blobName>, <target_file>, <DownloadFileOptions>)
}
上記のコードがローカル開発ワークステーションで実行されている場合、アプリケーション サービス プリンシパルの環境変数、または Azure CLI などのローカルにインストールされた開発者ツールで、開発者資格情報のセットが検索されます。 どちらの方法も、ローカル開発中に Azure リソースに対してアプリを認証するために使用できます。
Azure にデプロイすると、この同じコードで Azure リソースに対してアプリを認証することもできます。 DefaultAzureCredential は、Azure サービスに対して自動的に認証する環境設定とマネージド ID 構成を取得できます。