IBM Cloud Docs
コンテナー・レジストリーへのアクセス

コンテナー・レジストリーへのアクセス

IBM Cloud® Code Engine で使用されるイメージは通常、レジストリーに保管されます。だれでもアクセスできるレジストリー (パブリック・レジストリー) を使用することも、小さなグループのユーザーだけにアクセスを限定したレジストリー (プライベート・レジストリー) をセットアップすることもできます。

コンテナー・レジストリー (レジストリー) は、コンテナー・イメージを保管するサービスです。 例えば、IBM Cloud Container Registryと Docker Hub はコンテナー・レジストリーです。 コンテナー・レジストリーは、パブリックにすることもプライベートにすることもできます。 パブリックであるコンテナー・レジストリーには、アクセスするための資格情報は必要ありません。 これに対して、プライベート・レジストリーへのアクセスには資格情報が必要です。

Code Engineは、以下のアクションを実行するためにコンテナー・レジストリーへのアクセスを必要とします。

  • アプリまたはジョブを実行するためにコンテナー・イメージを取得 (または「プル」) する
  • 新しく作成したコンテナー・イメージをイメージ・ビルドの出力として保管する
  • ビルドがローカル・ソースから実行されるときにローカル・ファイルを保管および取得する

Code Engine は、システムとレジストリーの間の対話の基礎となる詳細の多くを処理します。

イメージをレジストリーからプルするために、Code Engine は、imagePullSecret という特別なタイプの Kubernetes シークレットを使用します。 このイメージ・プル・シークレットには、コンテナー・レジストリーにアクセスするための資格情報が保管されます。 イメージをプルするために Code Engine を使用してコンテナー・レジストリーへのアクセス権限を追加すると、イメージ・プル・シークレットが作成されます。 イメージ・プル・シークレットについて詳しくは、 Kubernetes の資料を参照してください。

イメージ・レジストリーのタイプ

イメージは通常、レジストリーに保管されます。だれでもアクセスできるレジストリー (パブリック・レジストリー) を使用することも、小さなグループのユーザーだけにアクセスを限定したレジストリー (プライベート・レジストリー) をセットアップすることもできます。

パブリック Docker Hub などのパブリック・レジストリーは、Docker と Code Engine の取り掛かりとして、最初のアプリケーションまたはジョブを作成するために使用できます。 しかし、エンタープライズ・ワークロードに関しては、無許可ユーザーによるイメージの使用から保護するために、IBM Cloud Container Registryで提供されているようなプライベート・レジストリーを使用してください。 プライベート・レジストリーの場合は、レジストリー・シークレットを使用して、資格情報がプライベート・レジストリーにアクセスできるようにします。

表 1. パブリックおよびプライベートのイメージ・レジストリー・タイプ
Registry 説明
IBM Cloud Container Registry

このタイプのレジストリーでは、 IBM Cloud Container Registry に独自の保護されたイメージ・リポジトリーをセットアップして、ユーザー間でイメージを安全に保管および共有することができます。
IBM Cloud Container Registryを使用すると、
-アカウント内のイメージへのアクセスを管理できます。

  • IBM 提供のイメージおよびサンプル・アプリケーション ( IBM Liberty など) を基本イメージとして使用し、独自のアプリ・コードを追加できます。
他のすべてのプライベート・レジストリー アクセスを追加して、既存のプライベート・レジストリーを Code Engine に接続します。 アクセスを追加すると、レジストリーの URL と資格情報が Kubernetes シークレットに安全に保存されます。
プライベート・レジストリーでは、
-ソース (Docker Hub、組織が所有するレジストリー、またはその他のプライベート・クラウド・レジストリー) に関係なく、既存のプライベート・レジストリーを使用できます。
パブリック Docker Hub このタイプのレジストリーを使用して、 Docker Hub から Code Engine アプリケーションまたはジョブ

に既存のパブリック・イメージを直接プルします。 重要
-このレジストリー・タイプは、アクセス管理、脆弱性スキャン、アプリ・プライバシーなど、組織のセキュリティー要件を満たしていない可能性があります。

  • Code Engine内のアプリまたはジョブで使用するために Docker Hub からイメージをプルする場合は、無料プランの Docker レート制限 に注意してください。 プル・レート制限に達したことを示す 429 エラーを受け取った場合、プル制限が発生する可能性があります。 レート制限を増やすには、アカウントを Docker Pro または Team サブスクリプションにアップグレードします。

パブリック Docker Hub では、以下を行うことができます。
-これらのイメージは、アプリまたはジョブの作成時に直接参照できます。追加のセットアップは不要です。
-さまざまなオープン・ソース・アプリケーションが含まれています。

レジストリー・シークレットのタイプ

レジストリー内のイメージにアクセスするために、 Code Engine は、以下のいずれかのタイプのレジストリー・シークレットを使用します。

  • Code Engine 管理対象シークレット-レジストリーでアカウント内の IBM Cloud Container Registry 名前空間を使用する場合は、 Code Engine に作成させることができます。 コンソールでは、自動的に作成されたこのレジストリー・シークレットは Code Engine managed secret と呼ばれます。 CLI では、自動的に作成されるレジストリー・シークレットの名前の形式は ce-auto-icr-private-<region> です。
  • ユーザー管理シークレット - これは、ユーザーが作成および管理するシークレットです。 選択したコンテナー・レジストリー (Docker Hub など) のアクセス・トークンを API キーを使用してアカウントからイメージにアクセスするまたは使用できます。 この場合、コンソールにリストされるレジストリー・シークレットは、レジストリー・シークレットの名前です。

レジストリーがパブリックであり、資格情報を必要としない場合 (例えば、 icr.io/codeengine または Docker Hub パブリックの Code Engine サンプル・イメージ)、レジストリー・シークレットは必要ありません。 この場合、コンソールにリストされるレジストリー・シークレットは None です。

イメージ・レジストリーに対する権限の設定

レジストリーがパブリックの場合は、イメージをプルするための権限をセットアップする必要はありません。 Code Engineの開始時にパブリック・レジストリーからイメージをプルすることは許容されることに注意してください。 エンタープライズ・ワークロードに関しては、プライベート・レジストリーを使用してください。

どのような権限が必要ですか?

必要な権限を判別するには、以下のケースを考慮してください。

  • アプリをデプロイしたりジョブを実行したりすると、Code Engine は、自分のアカウントにあるイメージに自動的にアクセスできます。

  • 共有アカウント、他の IBM Cloud アカウント、またはプライベート Docker アカウントからイメージにアクセスするには、適切なアクセス権限が割り当てられている必要があります。

  • アプリをデプロイしたりジョブを実行したりするときに、ご使用のアカウントに含まれている IBM Cloud Container Registry 名前空間をレジストリーが使用する場合は、アカウントに必要な権限があれば、 Code Engine が自動的にレジストリー・シークレットを作成して管理するようにすることができます。

    • コンソールでは、このレジストリー・シークレットは Code Engine managed secret と呼ばれます。 このオプションは、Code Engineを使用してイメージをビルドするためにイメージの構成ワークフローまたはビルド詳細の指定ワークフローを使用する場合に使用できます。
    • CLI では、このレジストリー・シークレットの形式は ce-auto-icr-private-<region> です。 このレジストリー・シークレットは、 --build-source オプションを指定したが、 app createapp updatejob create、または job update コマンドで --registry-secret オプションを指定しなかった場合に自動的に作成されます。
表 2. イメージ・レジストリーのアクセス権限
アクション IAM サービス・アクセス権限 説明
イメージのプル Reader サービス・アクセス イメージをアプリケーションまたはジョブとしてデプロイするときは、そのイメージをレジストリーからプルする必要があります。 イメージをプルするには、読み取りアクセス権限が必要です。 レジストリーがパブリックの場合は、イメージに対する読み取り権限が既にあります。 レジストリーがプライベートの場合は、レジストリー・シークレットが必要です。
イメージのプッシュ ReaderおよびWriterサービスのアクセス権限 ソース・コードをビルドするときは、イメージをレジストリーにプッシュする必要があります。 イメージをレジストリーにプッシュするには、読み取り権限と書き込み権限が必要です。また、レジストリー・シークレットが必要です。
名前空間を作成します。 ReaderWriter、およびManagerサービスのアクセス権限 このアクションは、IBM Cloud Container Registry でのみサポートされます。
Code Engine 自動的に作成されるレジストリー・シークレット Administratorプラットフォーム・アクセス
ReaderWriter、およびManagerサービス・アクセス
このアクションは、IBM Cloud Container Registry でのみサポートされます。

サービス ID を使用できますか?

はい、サービス ID を作成し、それに権限を割り当てることができます。 Code Engine へのアクセス権限が自動的に作成される時点で、サービス ID も IBM Cloud Container Registry UI によって自動的に作成されることに注意してください。 このサービス ID は削除しないでください。レジストリー内のイメージへのアクセスが失われます。

別のレジストリー内のイメージにアクセスできますか?

そのとおりです! その方法は、こちらです

特定のリージョン・レジストリーまたは単一の名前空間へのプル・アクセスを制限できますか?

はい。サービス ID の既存の IAM ポリシーを編集して、リーダーのサービス・アクセス役割をそのリージョン・レジストリーまたはレジストリー・リソース (名前空間など) に制限できます。 レジストリーの IAM ポリシーをカスタマイズする前に IBM Cloud で IBM Cloud Container Registry IAM ポリシーを有効にしておく必要があります。

パブリック・アカウントからイメージへのアクセス

イメージがパブリック・リポジトリー (パブリック Docker Hub など) に保管されている場合は、アプリケーションをデプロイしたりジョブを実行したりする際に、単純にそのイメージを直接参照することができます。 アプリケーションやジョブの使用を開始するにあたってパブリック・レジストリーにイメージを保管することは問題ありませんが、エンタープライズ・イメージはプライベート・レジストリーに保管してください。

自分のアカウントにあるイメージへのコンソールからのアクセス

所有または管理しているアカウントからCode Engineにアクセスする場合、コンソールからアプリ、ジョブ、またはビルドを作成または更新するときに、Code Engineは、アカウント内のIBM Cloud Container Registry名前空間との間でイメージを自動的にプッシュおよびプルできます。Code Engineは、イメージをプッシュするときに名前空間を作成することもできます。 詳しくは、以下のトピックを参照してください。

自分のアカウントからの API キーを使用したイメージへのアクセス

CLI を使用して Code Engine にアクセスしている場合は、まず IAM API キーを作成し、IAM API キーをレジストリー・アクセス権限として Code Engine に保存する必要があります。

以下のステップでは、ユーザー ID の資格情報を保管する API キーを作成します。 ユーザー ID を使用する代わりに、IBM Cloud に対する IBM Cloud Container Registry IAM サービス・アクセス・ポリシーを割り当てたサービス ID の API キーを作成することもできます。 ユーザー ID を認証することを選択する場合は、そのユーザー ID は機能 ID にしてください。あるいは、その特定のユーザーがいなくなっても Code Engine が引き続きレジストリーにアクセスできるように計画しておいてください。

コンソールからの API キーの作成

コンソールから IBM Cloud IAM の API キーを作成するには、以下の手順を実行します。

  1. アクセス (IAM) の概要を起動します。

  2. **「API キー」**を選択します。

  3. **「IBM Cloud API キーの作成」**をクリックします。

  4. API キーの名前と説明 (オプション) を入力して**「作成」**をクリックします。

  5. API キーをコピーするか、「ダウンロード」をクリックして保存します。

    この API キーは再表示できないため、必ず安全な場所に記録してください。

これで API キーを作成できたので、それをレジストリー・アクセス権限として保存します

CLI を使用した API キーの作成

CLI で IBM Cloud IAM API キーを作成するには、iam api-key-create コマンドを実行します。 例えば、「My CLI API key」という説明を使用して cliapikey という API キーを作成し、それを key_file というファイルに保存するには、以下のコマンドを実行します。

ibmcloud iam api-key-create cliapikey -d "My CLI API key" --file key_file

キーをファイルに保存しないことを選択した場合は、作成時に表示される API キーを記録する必要があります。 後で取得することはできません。

これで API キーを作成できたので、それをレジストリー・アクセス権限として保存します

共有アカウントにあるイメージへのアクセス

共有アカウントでIBM Cloud Container Registryからイメージにアクセスするには、適切な権限が割り当てられていなければなりません。

共有アカウントからのアプリケーションのデプロイとジョブの実行を計画している場合、Code Engine は、アプリケーションをデプロイまたはジョブを作成するときに、自動的にイメージをプルまたはプッシュすることができます。

共有アカウントから自分のアカウントにイメージをプルする場合は、IBM Cloud Container Registry にアクセスする権限を持っている必要があります。

異なるアカウントにあるイメージへのアクセス

IBM Cloud の IAM アクセス・ポリシーをユーザーまたはサービス ID に割り当てて、特定のレジストリー・イメージ名前空間または操作 (push や pull など) にアクセス権を制限できます。 それから、API キーを作成して、これらのレジストリー資格情報を Code Engine に保管します。

例えば、他の IBM Cloud アカウント内のイメージにアクセスするには、そのアカウント内のユーザーまたはサービス ID の IBM Cloud Container Registry 資格情報を保管する API キーを作成します。 その後、Code Engine で、そのキーを使用して自分のアカウント内にアクセス権限を作成します。

プライベート Docker Hub アカウントにあるイメージへのアクセス

プライベート Docker Hub アカウントにあるイメージにアクセスするには、自分のパスワードまたはアクセス・トークンを提供することでレジストリー・アクセス権限を作成します。 アクセス・トークンを使用すると、パスワードを変更することなく、より簡単に Docker Hub アカウントへのアクセス権限を付与したり、取り消したりすることができます。 アクセス・トークンおよび Docker Hub について詳しくは、 アクセス・トークンの管理を参照してください。

パスワードを直接使用するか、アクセス・トークンを作成するかを決めた後、レジストリー・アクセス権限を作成します。

Code Engine へのレジストリー・アクセス権限の追加

IBM Cloud Container Registry へのアクセス権限を異なる IBM Cloud アカウント内にセットアップしたり、プライベート Docker Hub アカウントからイメージをプルしたり、Code Engine CLI を使用してイメージをプルまたはプッシュしたりするには、IBM API キーまたは Docker Hub パスワードまたはアクセス・トークンを使用して Code Engine 経由でレジストリー・アクセス権限を作成し、認証キーまたはトークンを自動的に保管することができます。

コンソールを使用したレジストリー・アクセス権限の追加

始めに、プロジェクトを作成します

  1. プロジェクトの状況が 「アクティブ」 になったら、 Code Engine 「プロジェクト」ページでプロジェクトの名前をクリックします。
  2. 「コンポーネント」ページで、**「シークレットおよび構成マップ (Secrets and configmaps)」**をクリックします。
  3. 「シークレットおよび構成マップ (Secrets and configmaps)」ページで**「作成」**をクリックして、シークレットを作成します。
  4. 「シークレットまたは構成マップの作成 (Create secret or configmap)」ページで、以下の手順を実行します。
    1. 「レジストリー・シークレット」 を選択し、 「次へ」 をクリックします。
    2. 名前を指定します (例: mysecret-registry)。
    3. このシークレットのターゲット・レジストリー ( IBM Cloud Container Registry や Docker Hub など) を指定します。
    4. レジストリーの場所を指定します。
    5. ユーザー名を指定します。 このシークレットが IBM Cloud Container Registry用である場合、ユーザー名は iamapikey です。 このシークレットが Docker Hub 用の場合は、 Docker ID です。
    6. ユーザー名の資格情報を入力します。 IBM Cloud Container Registryでは、IAM API キーを使用します。 Docker Hub の場合は、ご使用の Docker Hub パスワードかアクセス・トークンを使用できます。 その他のターゲット・レジストリーの場合は、ユーザー名のパスワードまたは API キーを指定します。
    7. **「作成」**をクリックして、シークレットを作成します。

これで、コンソールからシークレットが作成されたので、「シークレットと構成マップ (Secrets and configmaps)」ページに移動して、定義されているシークレットと構成マップのリストを表示します。 必要に応じて、フィルターを適用してリストをカスタマイズすることができます。

コンテナー・レジストリーへのアクセス権限は、アプリケーションまたはジョブを作成するとき、またはイメージを作成するときに追加できます。 イメージの構成をクリックし、実行するコンテナー・イメージを指定します。これには、イメージが保管されているレジストリーと、イメージの取得に使用するレジストリー・アクセスが含まれます。

CLI を使用したレジストリー・アクセス権限の追加

CLI バージョン 1.42.0以降、CLI でのシークレットの定義と操作は、 secret コマンド・グループの下で統一されています。 ibmcloud ce secret コマンドを参照してください。 秘密のカテゴリー ( basic_authgenericsshtlsregistry など) を指定するには、 --format オプションを使用します。 registry コマンド・グループは引き続き使用できますが、統一された secret コマンド・グループを活用してください。 コンテナー・レジストリーにアクセスするためのシークレットを作成するには、 ibmcloud ce secret create --format registry コマンドを使用します。 Code Engineでのシークレットの処理について詳しくは、 シークレットの処理 を参照してください。

CLI で IBM Cloud Container Registry または Docker Hub アクセスを追加するには、 secret create --format registry コマンドを使用します。 このコマンドには、レジストリー・シークレットの名前、レジストリー・サーバーの URL、およびレジストリー・サーバーにアクセスするためのユーザー名とパスワードの情報が必要です。また、他のオプションの引数も使用できます。 オプションの完全なリストについては、 ibmcloud ce secret create コマンドを参照してください。

例えば、以下のコマンドは、 us.icr.io レジストリー・サーバー上にある myregistry という IBM Cloud Container Registry インスタンスへのレジストリー・アクセスを作成します。

ibmcloud ce secret create --format registry --name myregistry --server us.icr.io --username iamapikey --password API_KEY

出力例

Creating registry secret 'myregistry'...
OK

以下の表は、この例の secret create --format registry コマンドで使用されるオプションを要約しています。 コマンドとそのオプションについて詳しくは、 ibmcloud ce secret create コマンドを参照してください。

表 3. コマンドの説明
オプション 説明
--name

レジストリー・シークレットの名前。 プロジェクト内で固有の名前を使用します。 この値は必須です。

  • 名前の先頭と末尾は小文字の英数字でなければなりません。
  • 名前は 253 文字以下でなければならず、小文字、数字、ピリオド (.)、およびハイフン (-) を使用できます。
--server レジストリー・サーバーの URL を入力します。 Container Registryの場合、サーバー名は<region>.icr.ioです。 例えば、us.icr.io です。 Docker Hub の場合、値は https://index.docker.io/v1/ です。
--username レジストリー・サーバーにアクセスするためのユーザー名を入力します。 Container Registry の場合は iamapikey です。 Docker Hub の場合は、ご使用の Docker ID です。
--password パスワードを入力します。 Container Registry の場合、パスワードは、ご使用の API キーです。 Docker Hub の場合は、ご使用の Docker Hub パスワードかアクセス・トークンを使用できます。

サービス ID を使用した Container Registry へのアクセス権限の付与

異なるアカウント内のサービス ID へのアクセス権限を追加する前に、まずサービス ID に対するアクセス権限を付与する必要があります。

サービス ID を作成するときに、リージョンの IBM Cloud Container Registry や、その IBM Cloud Container Registry アカウント内の特定の名前空間にアクセスを制限できます。

コンソールからのサービス ID を使用した Container Registry へのアクセス権限の付与

IBM Cloud Container Registryとの間でイメージをプルまたはプッシュするには、サービス ID を作成し、サービス ID のアクセス・ポリシーを作成してから、資格情報を保管するための API キーを作成しなければなりません。

ステップ 1 サービス ID を作成または識別し、それを IBM Cloud Container Registry サービスに対して許可します。

  1. アクセス (IAM) の概要を起動します。
  2. **「サービス ID」**を選択します。
  3. 使用するサービス ID がある場合は、それを選択します。 使用するサービス ID がない場合は、**「作成」を選択し、名前と説明を入力して、「作成」**をクリックします。
  4. 「サービス ID」ページの 「アクセス・ポリシー」 セクションで、 「アクセス権限の割り当て」 を選択します。
  5. **「サービス ID への追加のアクセス権限の割り当て」**セクションで、以下の手順を実行します。
    1. アクセス権限のタイプに、**「コンテナー・レジストリー」**を選択します。 **「次へ」**をクリックします。
    2. アクセスのタイプとして、 「すべてのリソース」 または 「特定のリソース」 を選択します。 「特定のリソース」 を指定すると、リソース・グループ、地域、地域、リソース・タイプ、リソース ID、またはリソース名に基づいて属性を追加し、アクセスをさらに制限することができます。 特定のリソース・グループを選択する場合は、 「リソース・グループ」 アクセスに対して 「ビューアー」 アクセスを選択するようにしてください。 「次へ」 をクリックします。
    3. 「役割とアクション」 セクションで、付与するアクセス権限のタイプを選択します。 アプリケーションとジョブでイメージのみを使用する計画の場合は、**「リーダー」**を選択します。 ソース・コードとイメージを Container Registryにプッシュする場合は、 「ライター」 も選択します。 確認 をクリックします。
    4. **「追加」をクリックしてから「割り当て」**をクリックします。

ステップ 2 Container Registry ディスカバリーの有効化

Code Engine コンソールがコンテナー・レジストリーを自動的にディスカバーできるようにするには、 IAM Identity Serviceに対してサービス ID を認証する必要があります。

  1. 「サービス ID」ページの 「アクセス・ポリシー」 セクションで、 「アクセス権限の割り当て」 を選択します。
  2. **「サービス ID への追加のアクセス権限の割り当て」**セクションで、以下の手順を実行します。
    1. アクセスのタイプとして IAM Identity Service を選択します。 **「次へ」**をクリックします。
    2. リソース・スコープとして 「特定のリソース」 を選択します。 属性タイプとして 「リソース・タイプ」 を選択し、演算子として string equals を保持し、値として serviceid を入力します。 **「条件の追加」**をクリックします。
    3. 属性タイプとして 「リソース ID」 を選択し、演算子として string equals を保持し、サービス ID の ID を入力します。 サービス ID は、サービス ID の 「詳細」 ページ、またはサービス ID の構成時にブラウザーの URL で確認できます。 次へ をクリックします。
    4. 「役割とアクション」 セクションで、プラットフォームの 「オペレーター」 アクセス権限を選択します。 「レビュー」 をクリックします
    5. **「追加」をクリックしてから「割り当て」**をクリックします。

ステップ 3: サービス ID の API キーを作成する

サービス ID の API キーを作成します。

  1. 「サービス ID」ページで**「API キー」を選択してから、「作成」**を選択します。

  2. API キーの名前と説明 (オプション) を入力して**「作成」**をクリックします。

  3. API キーをコピーするか、「ダウンロード」をクリックして保存します。

    この API キーは再表示できないため、必ず安全な場所に記録してください。

これで、サービス ID と API キーのアクセス・ポリシーが設定され、コンテナー・レジストリーからイメージをプルするCode Engineへのアクセス権限の追加ができます。

CLI を使用した Container Registry へのアクセス権限の付与

別のアカウントでIBM Cloud Container Registryからイメージをプルするには、サービス ID を作成し、そのサービス ID のアクセス・ポリシーを作成してから、資格情報を保管するための API キーを作成しなければなりません。

  1. iam service-id-create コマンドを使用して、イメージ・プル・シークレットの IAM ポリシーと API キー資格情報のために使用するプロジェクトの IBM Cloud IAM サービス ID を作成します。 必ず、後でサービス ID を思い出せるように、プロジェクト名などを含む説明を付けてください。 iam service-id-create コマンドとそのオプションの全リストについては、ibmcloud iam service-id-create コマンドを参照してください。

    例えば、次のコマンドは、codeengine-myproject-id という名前のサービス ID を Service ID for IBM Cloud Container Registry in Code Engine project myproject という説明を付けて作成します。

    ibmcloud iam service-id-create codeengine-myproject-id --description "Service ID for IBM Cloud Container Registry in Code Engine project my proj"
    
  2. iam service-policy-create コマンドを使用して、IBM Cloud へのアクセス権限を付与するカスタム IBM Cloud Container Registry IAM ポリシーを、サービス ID に対して作成します。 iam service-policy-create コマンドとそのオプションの全リストについては、ibmcloud iam service-policy-create コマンドを参照してください。

    例えば、次のコマンドは、codeengine-myproject-id の役割を持つ Reader というサービス ID のポリシーを作成します。

    ibmcloud iam service-policy-create codeengine-myproject-id --roles Reader --service-name container-registry
    

    以下の表は、この例の iam service-policy-create コマンドで使用されるオプションを要約しています。 コマンドとそのオプションについて詳しくは、 ibmcloud iam service-policy-create コマンドを参照してください。

    表 4. iam service-policy-create コマンドのコンポーネント
    オプション 説明
    <service_ID> 必須。 前に作成したcodeengine-<project_name>-idサービス ID に置き換えます。
    --roles <service_access_role> 必須。 サービス ID のアクセス権の有効範囲を指定するために、IBM Cloud Container Registry の サービス・アクセス役割を入力します。 指定できる値は、ReaderWriterManager です。 イメージをプルする場合は、Reader アクセス権限で十分です。 詳しくは、イメージ・レジストリーに対する権限の設定を参照してください。
    --service-name <container-registry> 必須。 container-registry を入力して、IBM Cloud Container Registry の IAM ポリシーを作成します。
  3. iam-identity コマンドを使用して、iam service-policy-create サービスへのアクセスを許可するカスタム・サービス・ポリシーを作成し、Code Engine がサービス ID の API キーを取得できるようにします。

    例えば、codeengine-myproject-id の役割を持つ Operator というサービス ID のポリシーを作成するには、次のようにします。

    ibmcloud iam service-policy-create codeengine-myproject-id --roles Operator --service-name iam-identity
    

    以下の表は、この例の iam service-policy-create コマンドで使用されるオプションを要約しています。 コマンドとそのオプションについて詳しくは、 ibmcloud iam service-policy-create コマンドを参照してください。

    表 5. iam service-policy-create コマンドのコンポーネント
    オプション 説明
    <service_ID> 必須。 前に作成したcodeengine-<project_name>-idサービス ID に置き換えます。
    --roles <platform_access_role> 必須。 サービス ID のアクセス権限の有効範囲を指定するために、プラットフォーム・アクセス役割を入力します。 指定可能な値は、AdministratorEditorOperator、および Viewerです。 Operator 以上をサービス ID に指定する必要があります。
    --service-name <iam-identity> 必須。 iam-identity を入力し、IAM Identity サービスの IAM ポリシーを作成します。
  4. iam service-api-key-create コマンドで、サービス ID の API キーを作成します。 iam service-api-key-create コマンドとそのオプションの全リストについては、ibmcloud iam service-api-key-create コマンドを参照してください。 サービス ID に似た名前を API キーに付け、以前に作成したサービス IDcodeengine-<project_name>-idを含めます。 必ず、後でキーを思い出せるように説明を付けてください。

    例えば、以下のコマンドは、 codeengine-myproject-id サービス ID の codeengine-myproject-key というキーを作成し、 API key for service ID codeengine-myproject-id for Code Engine myproject という説明を付けます。

    ibmcloud iam service-api-key-create codeengine-myproject-key codeengine-myproject-id --description "API key for service ID codeengine-myproject-id for Code Engine myproject"
    

    出力例

    Please preserve the API key! It cannot be retrieved after it's created.
    
    Name          codeengine-myproject-key   
    Description   API key for service ID codeengine-myproject-id for Code Engine myproject   
    Bound To      crn:v1:bluemix:public:iam-identity::a/1bb222bb2b33333ddd3d3333ee4ee444::serviceid:ServiceId-ff55555f-5fff-6666-g6g6-777777h7h7hh   
    Created At    2019-02-01T19:06+0000   
    API Key       i-8i88ii8jjjj9jjj99kkkkkkkkk_k9-llllll11mmm1   
    Locked        false   
    UUID          ApiKey-222nn2n2-o3o3-3o3o-4p44-oo444o44o4o4   
    

    この API キーは再表示できないため、必ず安全な場所に記録してください。

    これで、サービス ID および作成された API キー用のアクセス・ポリシーが設定されたので、Code Engineへのアクセス権限の追加を使用してコンテナー・レジストリーからイメージをプルできます。

Code Engine ワークロードに対する Container Registry へのアクセスの制御

Code Engine がイメージをプルするときに、 IBM Cloud Container Registry へのアクセスを制御するとします。 例えば、特定の IP アドレスへの Container Registry へのアクセスを制御する必要があるとします。 以下の方法を検討してください。

  • コンテキスト・ベースの制限 を使用します。 コンテキスト・ベースの制限を使用することで、 Code Engine プロジェクトの IP アドレスが変更された場合でも、アクセス権限を変更する必要はありません。 Container Registry へのアクセスをネットワーク・ゾーンに制限できます。ネットワーク・ゾーンには、 Code Engine と、レジストリーへのアクセスが必要なすべてのものが含まれます。

  • IBM Cloud Container Registry へのパブリック・アクセスを無効にし、 Code Engine がパブリック・エンドポイントではなくプライベート・エンドポイントを使用するようにします。 Container Registryへの接続の保護 を参照してください。

  • 特定の IP 範囲によるアクセスを制御するには、API エンドポイントを使用して、特定の Code Engine プロジェクトの IP アドレスをフェッチします。 これらの IP アドレスは変更される可能性があることに注意してください。その場合は、適切な手順を実行する必要があります。 Code Engine パブリック IP アドレスとプライベート IP アドレス および Code Engine アプリを許可リストに追加する方法 を参照してください。

レジストリー内のイメージに関する考慮事項

アプリまたはジョブに使用するイメージの名前は、以下のいずれかの形式でなければなりません。

  • REGISTRY/NAMESPACEorDOCKERUSERorDOCKERORG/REPOSITORY:TAG。ここで、 REGISTRYTAG はオプションです。 REGISTRY を指定しない場合、そのデフォルトは docker.io です。 TAG を指定しない場合は、コロン (:) を含めないでください。 TAG のデフォルトは latest です。
  • REGISTRY/NAMESPACEorDOCKERUSERorDOCKERORG/REPOSITORY@IMAGEID ここで、 REGISTRY はオプションです。 REGISTRY が指定されていない場合、 Docker 組織としてのデフォルトは docker.io および ibm です。
表 6. イメージ名の規則
コンポーネント 許可される文字 Length 追加のルール
REGISTRY a-zA-Z0-9 -_. --__ 1-253 (0-127Periods)(label:1-63,noDashOnEnd)
NAMESPACE a-z 0-9 -_ --__ 4-30 (start/end with letterOrNumber)
DOCKERUSERorDOCKERORG a-z 0-9 4-30
REPOSITORY a-z 0-9 -_. / 2-255 (start/end with letterOrNumber)
TAG a-zA-Z0-9 -_. --__.. 0-128 (NOT start with periodOrDash)
IMAGEID a-z 0-9 : (startwith sha256: noOtherColon)

イメージ名の各部分は、以下の基準を満たしている必要があります。

  • REGISTRY は 253 文字以下でなければならず、小文字または大文字、数字、ピリオド (.)、ハイフン (-)、および下線 (_) を使用できます。 最後の文字としてダッシュ (.) を使用しないでください。 127 個を超えるピリオド (.) を使用しないでください。これらの間のラベルは 1 文字から 63 文字までの長さにすることができます。
  • NAMESPACE は 4 文字から 30 文字で、先頭と末尾は小文字または数字でなければなりません。 NAMESPACE には、小文字の英数字、ハイフン (-)、および下線 (_) を含めることができます。
  • DOCKERUSERorDOCKERORG は、 NAMESPACE の代わりに Docker レジストリーに使用できます。 Docker ユーザー名または Docker 組織を指定します。 Docker のユーザー名と組織名は、4 文字から 30 文字で、小文字の英数字または数字のみを使用する必要があります。
  • REPOSITORY は 2 文字から 255 文字で、先頭と末尾は小文字または数字でなければなりません。 REPOSITORY には、小文字の英数字、スラッシュ (/)、ピリオド (.)、ハイフン (-)、および下線 (_) を使用できます。
  • TAG は 0 から 128 文字でなければならず、小文字または大文字、数字、ピリオド (.)、ハイフン (-)、および下線 (_) を使用できます。 TAG は、ピリオドまたはダッシュで始まってはなりません。 TAG を指定しない場合は、コロンも含めないでください。
  • IMAGEID には sha256: という接頭部が付き、小文字と数字を含めることができます。