Skip to main content

codespace がプライベートイメージレジストリにアクセスできるようにする

シークレットを使用して、GitHub Codespaces がプライベート イメージ レジストリにアクセスできるようにすることができます

プライベート イメージ レジストリと GitHub Codespaces について

レジストリは、プライベート コンテナー イメージを保存、管理、フェッチするためのセキュリティで保護された領域です。 1 つ以上の画像を保存するために使用できます。 レジストリには、Container registry、npm registry、Azure Container Registry または DockerHub など多くの例があります。

Container registry and npm registry は、認証資格情報を指定する必要なく、codespace の作成時にコンテナー イメージを GitHub Codespaces にシームレスにプルできるように構成できます。 その他のイメージ レジストリの場合は、アクセスの詳細を保存するために、GitHub にシークレットを作成する必要があります。これにより、GitHub Codespaces はそのレジストリに保存されているイメージにアクセスできます。

Container registry and npm registry に保存されているイメージへのアクセス

Container registry and npm registry により、GitHub Codespaces が dev container コンテナー イメージを使用する最も簡単な方法が提供されます。

詳しくは、「コンテナー レジストリの操作」と「npm レジストリの操作」をご覧ください。

codespace と同じリポジトリに公開されたイメージへのアクセス

codespace が起動されたのと同じリポジトリ内のコンテナー イメージを Container registry or npm registry に公開すると、codespace の作成時にそのイメージを自動的にフェッチできるようになります。 コンテナー イメージの公開時に [リポジトリからアクセス権を継承する] オプションの選択を解除したのでない限り、追加の資格情報を指定する必要はありません。

イメージ公開元リポジトリからのアクセス権の継承

既定では、コンテナー イメージを Container registry or npm registry に公開すると、そのイメージはイメージの公開元リポジトリのアクセス設定を継承します。 たとえば、リポジトリがパブリックの場合、イメージもパブリックになります。 リポジトリがプライベートの場合、イメージもプライベートですが、リポジトリからアクセスできます。

この動作は、 [リポジトリからアクセス権を継承する] オプションによって制御されます。 [リポジトリからアクセス権を継承する] は、GitHub Actions を使用して公開する場合は既定で選択されますが、personal access token を使用して Container registry or npm registry に直接公開する場合は選択されません。

イメージの公開時に [リポジトリからアクセス権を継承する] オプションを選択しなかった場合は、公開されたコンテナー イメージのアクセス制御にリポジトリを手動で追加できます。 詳細については、「パッケージのアクセス制御と可視性の設定」を参照してください。

codespace が起動される Organization に公開されたイメージへのアクセス

Organization 内のすべての codespace からコンテナー イメージにアクセスできるようにする場合は、内部可視性を設定したコンテナー イメージを公開することをお勧めします。 これにより、codespace を起動するリポジトリがパブリックである場合以外は、Organization 内のすべての codespace にイメージが自動的に表示されます。

内部またはプライベートのイメージを参照するパブリック リポジトリから codespace を起動する場合は、パブリック リポジトリに内部コンテナー イメージへのアクセスを手動で許可する必要があります。 これにより、内部イメージが誤って公開されるのを防ぐことができます。 詳細については、「パッケージへの Codespaces アクセスの確保」を参照してください。

Organization 内のリポジトリのサブセットからプライベート コンテナーにアクセスする

Organization のリポジトリのサブセットがコンテナー イメージにアクセスできるようにする場合、またはパブリック リポジトリで起動された codespace から内部またはプライベートのイメージへのアクセスを許可する場合は、コンテナー イメージのアクセス設定にリポジトリを手動で追加できます。 詳細については、「パッケージへの Codespaces アクセスの確保」を参照してください。

codespace からのコンテナー イメージの公開

codespace から Container registry or npm registry へのシームレスなアクセスは、コンテナー イメージのプルに制限されています。 codespace 内からコンテナー イメージを公開する場合は、write:packages スコープの personal access token (classic) を使用する必要があります。

GitHub Actions を使用してイメージを公開することをお勧めします。 詳しくは、「Docker イメージの発行」と「Node.js パッケージの発行」をご覧ください。

他のコンテナー レジストリに保存されているイメージへのアクセス

Container registry or npm registry ではないレジストリからコンテナー イメージにアクセスする場合、GitHub Codespaces で、コンテナー レジストリのサーバー名、ユーザー名、personal access token を定義する 3 つのシークレットが存在するかどうかが確認されます。 これらのシークレットが見つかった場合、GitHub Codespaces はレジストリを codespace 内で使用できるようにします。

  • <*>_CONTAINER_REGISTRY_SERVER
  • <*>_CONTAINER_REGISTRY_USER
  • <*>_CONTAINER_REGISTRY_PASSWORD

シークレットは、ユーザ、リポジトリ、または Organization レベルで保存できるため、異なる Codespaces 間で安全に共有できます。 プライベート イメージ レジストリのシークレットのセットを作成するときは、名前の "<*>" を一貫した識別子に置き換える必要があります。 詳しくは、「codespaces の暗号化されたシークレットを管理する」および「リポジトリの暗号化されたシークレットと GitHub Codespaces の Organization を管理する」をご覧ください。

ユーザーまたは Organization のレベルでシークレットを設定する場合は、ドロップダウン リストからアクセス ポリシーを選択して、codespace を作成するリポジトリにシークレットを割り当てるようにしてください。

イメージ レジストリ シークレットの例

シークレットの例

Azure のプライベート イメージ レジストリの場合は、次のシークレットを作成できます。

ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>

一般的なイメージ レジストリの詳細については、「一般的なイメージ レジストリ サーバー」を参照してください。 AWS Elastic Container Registry (ECR) へのアクセスは異なることに注意してください。

イメージ レジストリ シークレットの例

シークレットを追加したら、新しい環境変数をコンテナーに渡すために、現在の codespace を停止してから開始することが必要になる場合があります。 詳細については、「codespace の一時停止または停止」を参照してください。

AWS Elastic Container Registry へのアクセス

AWS Elastic Container Registry (ECR) にアクセスするには、AWS アクセス キー ID と秘密鍵を指定することで、GitHub がユーザーに代わってアクセス トークンを取得してログインできるようになります。

*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>

また、資格情報のスワップ (例: sts:GetServiceBearerToken) と ECR 読み取り操作 (AmazonEC2ContainerRegistryFullAccess または ReadOnlyAccess) を実行するための適切な AWS IAM アクセス許可があることを確認する必要があります。

または、GitHub でユーザーに代わって資格情報のスワップが実行されないようにする場合は、AWS の API または CLI を使用してフェッチされた承認トークンを指定できます。

*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = AWS
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>

これらのトークンは有効期間が短く、定期的に更新する必要があるため、アクセス キー ID とシークレットを指定することをお勧めします。

*_CONTAINER_REGISTRY_SERVER が ECR URL である限り、これらのシークレットには任意の名前を付けることができますが、複数の ECR レジストリを扱う場合を除き、ECR_CONTAINER_REGISTRY_* を使用することをお勧めします。

詳細については、AWS ECR のプライベート レジストリの認証に関するドキュメントを参照してください。

一般的なイメージ レジストリ サーバー

一般的なイメージ レジストリ サーバーの一部を次に示します。

プライベート イメージ レジストリ アクセスのデバッグ

プライベート イメージ レジストリからイメージをプルするときに問題が発生した場合は、上記で定義したシークレットの値を使用して、docker login -u <user> -p <password> <server> を実行できることを確認してください。 ログインに失敗した場合は、ログイン資格情報が有効であること、およびコンテナー イメージをフェッチするためのサーバーに対する適切なアクセス許可があることを確認します。 ログインに成功した場合は、ユーザー、リポジトリ、または組織のレベルで、これらの値が正しい GitHub Codespaces シークレットに適切にコピーされていることを確認し、もう一度やり直してください。