Azure Container Registry で Docker コンテンツ信頼を使用して署名済みイメージを管理する

Azure Container Registry では、 Docker Content Trust (DCT) モデルを実装して、署名されたイメージのプッシュとプルを有効にします。 この記事では、コンテナー レジストリで DCT を有効にする方法について説明します。 DCT は、コンテナー レジストリの Premium サービス レベル の機能です。

制限事項

リポジトリ スコープのアクセス許可を持つトークンは、現在、署名されたイメージの Docker プッシュとプルをサポートしていません。

DCT のしくみ

セキュリティを念頭に置いて設計された分散システムにとって重要なのは、システムに入る データのソース と 整合性 の両方を検証することです。 データのコンシューマーは、データの発行元 (ソース) を確認し、データが公開された後に変更されなかったことを確認する必要があります (整合性)。

イメージ発行元は、DCT を使用して、レジストリにプッシュするイメージに署名できます。 イメージのコンシューマー (レジストリからイメージをプルするユーザーまたはシステム) は、署名されたイメージのみをプルするようにクライアントを構成できます。 署名済みのイメージをそのコンシューマーがプルすると、Docker クライアントによってイメージの整合性が確認されます。 このモデルでは、コンシューマーは、あなたによって署名されたイメージがレジストリに発行され、発行後に変更が行われていないことが保証されます。

信頼済みのイメージ

DCT はリポジトリ内のタグと連携します。 イメージ リポジトリには、署名付きタグと署名されていないタグの両方を持つイメージを含めることができます。 たとえば、署名の対象を myimage:stable と myimage:latest のイメージに限定し、myimage:dev には署名しないといったことが考えられます。

署名キー

DCT は、暗号化署名キーのセットを使用して管理します。 これらのキーは、レジストリ内の特定のリポジトリ関連付けられます。

Docker クライアントとご利用のレジストリがリポジトリ内のタグに対する信頼を管理する際に使用する署名キーには、いくつかの種類があります。 DCT を有効にし、コンテナーの発行と使用のためにパイプラインに統合する場合は、これらのキーを慎重に管理する必要があります。 詳細については、この記事の後半の 「キーの管理 」および Docker ドキュメントの コンテンツ信頼のキーの管理 を参照してください。

レジストリの DCT を有効にする

最初の手順では、レジストリ レベルで DCT を有効にします。 DCT を有効にすると、クライアント (ユーザーまたはサービス) が署名済みイメージをレジストリにプッシュできるようになります。

レジストリに対して DCT を有効にしても、DCT が有効になっているコンシューマーのみにレジストリの使用が制限されることはありません。 DCT が有効になっていないコンシューマーは、通常どおりレジストリを引き続き使用できます。 ただし、クライアントで DCT を有効にしたコンシューマーは、レジストリ内の署名済みイメージ のみを 表示できます。

Azure portal を使用してレジストリの DCT を有効にするには、レジストリに移動します。 ポリシーで、コンテンツの信頼>有効化>、保存を選択します。 また、Azure CLI で az acr config content-trust update コマンドを使用することもできます。

クライアントの DCT を有効にする

信頼されたイメージを操作するには、イメージの発行元とコンシューマーの両方で、Docker クライアントに対して DCT を有効にする必要があります。 パブリッシャーは、DCT 対応レジストリにプッシュするイメージに署名を行うことができます。 コンシューマーとして DCT を有効にすると、レジストリのビューが署名付きイメージのみに制限されます。 Docker クライアントでは DCT は既定で無効になっていますが、シェル セッションごとまたはコマンドごとに有効にすることができます。

シェル セッションに対して DCT を有効にするには、 DOCKER_CONTENT_TRUST 環境変数を 1 に設定します。 たとえば、Bash シェルでは、次のコードを使用します。

# Enable DCT for a shell session
export DOCKER_CONTENT_TRUST=1

1 つのコマンドに対して DCT を有効または無効にする場合、複数の Docker コマンドで --disable-content-trust 引数がサポートされます。

1 つのコマンドに対して DCT を有効にするには、次のコードを使用します。

# Enable DCT for a single command
docker build --disable-content-trust=false -t myacr.azurecr.io/myimage:v1 .

シェル セッションに対して DCT を有効にし、1 つのコマンドに対して DCT を無効にする場合は、次のコードを使用します。

# Disable DCT for a single command
docker build --disable-content-trust -t myacr.azurecr.io/myimage:v1 .

イメージに署名するためのアクセス許可を与える

アクセス許可を付与するユーザーまたはシステムのみが、信頼できるイメージをレジストリにプッシュできます。 このプッシュアクセス許可をユーザー (またはサービス プリンシパルを使用してシステム) に付与するには、 AcrImageSigner ロールをユーザーの Microsoft Entra ID に割り当てます。 このアクセス許可は、レジストリにイメージをプッシュするために必要な AcrPush (または同等の) ロールに加えて行います。 詳細については、「 Azure Container Registry のアクセス許可とロールの割り当ての概要」を参照してください。

2021 年 7 月の時点で、 AcrImageSigner ロールには、 Microsoft.ContainerRegistry/registries/sign/write アクションと Microsoft.ContainerRegistry/registries/trustedCollections/write データ アクションの両方が含まれています。

Azure portal

Azure portal を使用して AcrImageSigner ロールを付与するには:

1. [アクセス制御 (IAM)] を選択します。

2. [ 追加>ロールの割り当ての追加 ] を選択して、[ ロールの割り当ての追加] ウィンドウを開きます。

3. 次のロールを割り当てます。 この例では、ロールが個々のユーザーに割り当てられます。 詳細な手順については、 Azure portal を使用した Azure ロールの割り当てに関するページを参照してください。

   設定	値
   役割	AcrImageSigner
   アクセスを割り当てる	User
   メンバー	アラン

   

Azure CLI

Azure CLI を使用してユーザーに署名アクセス許可を付与するには、レジストリをスコープとする AcrImageSigner ロールをユーザーに割り当てます。 コマンドの形式は次のとおりです。

az role assignment create --scope <registry ID> --role AcrImageSigner --assignee <user name>

たとえば、管理者以外のユーザーにロールを割り当てるには、認証された Azure CLI セッションで次のコマンドを実行できます。 REGISTRY の値は、実際の Azure Container Registry の名前に合わせて変更してください。

# Grant signing permissions to an authenticated Azure CLI user
REGISTRY=myregistry
REGISTRY_ID=$(az acr show --name $REGISTRY --query id --output tsv)

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee azureuser@contoso.com

信頼済みのイメージをレジストリにプッシュするための権限をサービス プリンシパルに与えることもできます。 サービス プリンシパルは、信頼済みのイメージをレジストリにプッシュする必要のある無人のシステム (ビルド システムなど) で使用できます。 形式はユーザーアクセス許可の付与に似ていますが、 --assignee 値にサービス プリンシパル ID を指定します。

az role assignment create --scope $REGISTRY_ID --role AcrImageSigner --assignee <service principal ID>

<service principal ID>値には、サービス プリンシパルのappId値、objectId値、またはそのservicePrincipalNames値のいずれかを指定できます。 サービス プリンシパルと Azure Container Registry の取り扱いについて詳しくは、「サービス プリンシパルによる Azure Container Registry 認証」をご覧ください。

信頼済みのイメージをプッシュする

信頼されたイメージ タグをコンテナー レジストリにプッシュするには、DCT を有効にして、 docker pushを使用します。 署名付きタグを使用してプッシュを初めて完了すると、ルート署名キーとリポジトリ署名キーの両方のパスフレーズを作成するように求められます。 ルート キーとリポジトリ キーは、どちらもマシンのローカルで生成されて格納されます。

$ docker push myregistry.azurecr.io/myimage:v1
[...]
The push refers to repository [myregistry.azurecr.io/myimage]
ee83fc5847cb: Pushed
v1: digest: sha256:aca41a608e5eb015f1ec6755f490f3be26b48010b178e78c00eac21ffbe246f1 size: 524
Signing and pushing trust metadata
You are about to create a new root signing key passphrase. This passphrase
will be used to protect the most sensitive key in your signing system. Please
choose a long, complex passphrase and be careful to keep the password and the
key file itself secure and backed up. It is highly recommended that you use a
password manager to generate the passphrase and keep it safe. There will be no
way to recover this key. You can find the key in your config directory.
Enter passphrase for new root key with ID 4c6c56a:
Repeat passphrase for new root key with ID 4c6c56a:
Enter passphrase for new repository key with ID bcd6d98:
Repeat passphrase for new repository key with ID bcd6d98:
Finished initializing "myregistry.azurecr.io/myimage"
Successfully signed myregistry.azurecr.io/myimage:v1

DCT を有効にした最初の docker push アクションの後、Docker クライアントは後続のプッシュに同じルート キーを使用します。 それ以降は、同じリポジトリに対してプッシュするたびに、リポジトリ キーのみが求められます。 信頼済みイメージのプッシュ先となるリポジトリが変わると、その都度、新しいリポジトリ キーのパスフレーズを入力するよう求められます。

信頼済みのイメージをプルする

信頼されたイメージをプルするには、DCT を有効にして、通常どおり docker pull コマンドを実行します。 通常のユーザーが信頼済みのイメージをプルするには、AcrPull ロールがあれば十分です。 追加のロール ( AcrImageSigner ロールなど) は必要ありません。 DCT が有効になっているコンシューマーは、署名付きタグを持つイメージのみをプルできます。 以下に示したのは、署名済みのタグをプルする例です。

$ docker pull myregistry.azurecr.io/myimage:signed
Pull (1 of 1): myregistry.azurecr.io/myimage:signed@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b: Pulling from myimage
8e3ba11ec2a2: Pull complete
Digest: sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Status: Downloaded newer image for myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b
Tagging myregistry.azurecr.io/myimage@sha256:0800d17e37fb4f8194495b1a188f121e5b54efb52b5d93dc9e0ed97fce49564b as myregistry.azurecr.io/myimage:signed

DCT が有効になっているクライアントが署名されていないタグをプルしようとすると、次の例のようなエラーで操作が失敗します。

$ docker pull myregistry.azurecr.io/myimage:unsigned
Error: remote trust data does not exist

バックグラウンド処理

docker pullを実行すると、Docker クライアントは Notary CLI と同じライブラリを使用して、プルするタグのタグ対 SHA-256 ダイジェスト マッピングを要求します。 クライアントは信頼データの署名を検証した後、Docker エンジンに "ダイジェストによるプル" を実行するように指示します。プル中、エンジンはコンテンツ アドレスとして SHA-256 チェックサムを使用して、Azure コンテナー レジストリからイメージ マニフェストを要求および検証します。

キーの管理

信頼済みのイメージを初めてプッシュするときの docker push 出力に記載されているように、ルート キーはきわめて機微な情報です。 ルート キーは必ずバックアップを作成して、安全な場所に保管してください。

~/.docker/trust/private

ルートキーとリポジトリキーをアーカイブに圧縮し、アーカイブを安全な場所に保存してバックアップします。 たとえば、Bash で次のコマンドを使用します。

umask 077; tar -zcvf docker_private_keys_backup.tar.gz ~/.docker/trust/private; umask 022

コンテナー レジストリは、ローカルで生成されたルート キーとリポジトリ キーと共に、信頼されたイメージをプッシュするときに、他のいくつかのキーを生成して格納します。 管理ガイダンスなど、DCT 実装のさまざまなキーの詳細については、Docker ドキュメントの コンテンツ信頼のキーの管理 に関するページを参照してください。

ルート キーの紛失

ルート キーへのアクセス権が失われると、そのキーが署名されたタグを持つリポジトリ内の署名済みタグにアクセスできなくなります。 Container Registry は、紛失したルート キーで署名されたイメージ タグへのアクセスを復元できません。 レジストリのすべての信頼データ (署名) を削除するには、レジストリの DCT を無効にしてから再度有効にします。

レジストリの DCT を無効にするには、Azure portal でレジストリに移動します。 [ポリシー] で、 [コンテンツの信頼]>[無効]>[保存] の順に選択します。 レジストリ内の署名がすべて失われるという警告が表示されます。 そのレジストリ内のすべての署名を完全に削除する場合は、 [OK] を選択してください。

関連コンテンツ

• docker trust コマンドや信頼委任など、DCT の詳細については、「Docker でのコンテンツの信頼」を参照してください。
• Docker イメージをビルドしてプッシュするときに DCT を使用する例については、 Azure Pipelines のドキュメントを参照してください。