正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

GitLabチャート使用時のAzure Workload Identity

チャートでの外部オブジェクトストレージのデフォルト設定では、シークレットキーを使用します。Azure Workload Identityを使用すると、有効期間の短いtokenを使用して、Kubernetes clusteringにObject storageへのアクセス権を付与できます。Azure Kubernetes Service（AKS）クラスターでワークロードIDをデプロイおよび設定する方法に関するMicrosoftのドキュメントをお読みください。

要件

Object storageでworkload identityを使用するには、以下が必要です:

  1. OpenID Connect Issuer（OIDC）Issuerが有効になっているAKS clustering。
  2. Storage Blob Data ContributorロールがassignられたAzureマネージドID。
  3. 注釈azure.workload.identity/client-id: <CLIENT ID>が指定された、マネージドIDに関連付けられたKubernetes service account。

workload identityをアクティブ化するには、各podにラベルazure.workload.identity/use: "true"が必要です。これはpodのラベルであり、注釈ではありません。

チャートの設定

レジストリ

レジストリに対するworkload identityサポートはベータ版です。podのラベルを設定することで、workload identityを有効にできます:

--set registry.podLabels."azure\.workload\.identity/use"=true

registry-storage.yamlシークレットを作成する際は、以下を行う必要があります:

  1. azure_v2 storageの設定を使用します。
  2. credentialstypeをdefault_credentialsに設定します。

例:

azure_v2:
  accountname: accountname
  container: containername
  credentialstype: default_credentials
  realm: core.windows.net

azure_v2 storage driverはworkload identityをサポートしていますが、azure driverはサポートしていません。現在azure driverを使用している場合にworkload identityを使用する場合は、azure_v2 driverに移行します。詳細については、azure_v2のドキュメントを参照してください。

LFS、artifacts、uploads、パッケージ

LFS、artifacts、uploads、パッケージの場合、IAMロールは、webservice、sidekiq、およびtoolbox設定のアノテーションキーを介して指定できます:

--set gitlab.sidekiq.podLabels."azure\.workload\.identity/use"="true"
--set gitlab.webservice.podLabels."azure\.workload\.identity/use"="true"
--set gitlab.toolbox.podLabels."azure\.workload\.identity/use"="true"

object-storage.yamlシークレットの場合は、azure_storage_access_keyを省略します:

provider: AzureRM
azure_storage_account_name: YOUR_AZURE_STORAGE_ACCOUNT_NAME
azure_storage_domain: blob.core.windows.net

バックアップ

Toolbox設定を使用すると、podのラベルを設定できます:

--set gitlab.toolbox.podLabels."azure\.workload\.identity/use"="true"

gitlab.toolbox.backups.objectStorage.config.secretシークレットに保存されているazure-backup-conf.yamlの場合は、azure_storage_access_keyを省略します:

# azure-backup-conf.yaml
azure_storage_account_name: <storage account>
azure_storage_domain: blob.core.windows.net # optional

トラブルシューティング

Azure workload identityが正しく設定されていること、およびGitLabがtoolbox podにログインしてAzure Blob Storageにアクセスしていることをテストできます（<namespace>をGitLabがあるnamespaceに置き換えます）:

kubectl exec -ti $(kubectl get pod -n <namespace> -lapp=toolbox -o jsonpath='{.items[0].metadata.name}') -n <namespace> -- bash

まず、必要なenvironment variableが存在するかどうかを確認します:

  • AZURE_TENANT_ID
  • AZURE_FEDERATED_TOKEN_FILE
  • AZURE_CLIENT_ID

たとえば、次のように表示されます:

$ env | grep AZURE
AZURE_TENANT_ID=abcdefghi-c2c5-43d6-b426-1d8c9e8e7ad1
AZURE_FEDERATED_TOKEN_FILE=/var/run/secrets/azure/tokens/azure-identity-token
AZURE_AUTHORITY_HOST=https://login.microsoftonline.com/
AZURE_CLIENT_ID=123456789-abcd-12ab-89ca-cb379118f978

次に、azcopyを使用してblob container内のファイルを一覧表示します:

export AZCOPY_AUTO_LOGIN_TYPE=workload
azcopy --log-level debug list https://<YOUR STORAGE ACCOUNT NAME>.blob.core.windows.net/<YOUR AZURE BLOB CONTAINER NAME>

認証に成功した場合は、blob containerの内容とともに、次のメッセージが表示されます:

INFO: Login with Workload Identity succeeded
INFO: Authenticating to source using Azure AD

401または403エラーが表示される場合は、マネージドIDの設定を確認してください。一般的なエラーを以下に示します:

  1. Azure storageアカウントとblob containerの名前のスペルを確認します。
  2. kubectl describe pod <pod>を使用して、podに正しいKubernetes service accountとazure.workload.identity/use: "true" podラベルがあることを確認します。
  3. マネージドIDの場合は、フェデレーション認証情報の設定に、正しいIssuer URL、namespace、および関連付けられているKubernetes service accountがあることを確認してください。これは、Azureポータルで確認するか、command-line interfaceazを使用して確認できます。
  4. マネージドIDにblob storage containerのStorage Blob Data Contributorがあることを確認します。