Skip to main content

允许代码空间访问私有映像注册表

您可以使用密钥允许 Codespaces 访问私有映像注册表

代码空间可用于使用 GitHub Team 或 GitHub Enterprise Cloud 的组织。 更多信息请参阅“GitHub 的产品”。

关于私人映像注册表和 Codespaces

A registry is a secure space for storing, managing, and fetching private container images. You may use one to store one or more devcontainers. There are many examples of registries, such as GitHub Container Registry, Azure Container Registry, or DockerHub.

GitHub Container Registry can be configured to pull container images seamlessly, without having to provide any authentication credentials to Codespaces. For other image registries, you must create secrets in GitHub to store the access details, which will allow Codespaces to access images stored in that registry.

Accessing images stored in GitHub Container Registry

GitHub Container Registry is the easiest way for GitHub Codespaces to consume devcontainer container images.

For more information, see "Working with the Container registry".

Accessing an image published to the same repository as the codespace

If you publish a container image to GitHub Container Registry in the same repository that the codespace is being launched in, you will automatically be able to fetch that image on codespace creation. You won't have to provide any additional credentials, unless the Inherit access from repo option was unselected when the container image was published.

Inheriting access from the repository from which an image was published

By default, when you publish a container image to GitHub Container Registry, the image inherits the access setting of the repository from which the image was published. For example, if the repository is public, the image is also public. If the repository is private, the image is also private, but is accessible from the repository.

This behavior is controlled by the Inherit access from repo option. Inherit access from repo is selected by default when publishing via GitHub Actions, but not when publishing directly to GitHub Container Registry using a Personal Access Token (PAT).

If the Inherit access from repo option was not selected when the image was published, you can manually add the repository to the published container image's access controls. 更多信息请参阅“配置包的访问控制和可见性”。

Accessing an image published to the organization a codespace will be launched in

If you want a container image to be accessible to all codespaces in an organization, we recommend that you publish the container image with internal visibility. This will automatically make the image visible to all codespaces within the organization, unless the repository the codespace is launched from is public.

If the codespace is being launched from a public repository referencing an internal or private image, you must manually allow the public repository access to the internal container image. This prevents the internal image from being accidentally leaked publicly. For more information, see "Ensuring Codespaces access to your package."

Accessing a private container from a subset of repositories in an organization

If you want to allow a subset of an organization's repositories to access a container image, or allow an internal or private image to be accessed from a codespace launched in a public repository, you can manually add repositories to a container image's access settings. For more information, see "Ensuring Codespaces access to your package."

Publishing a container image from a codespace

Seamless access from a codespace to GitHub Container Registry is limited to pulling container images. If you want to publish a container image from inside a codespace, you must use a personal access token (PAT) with the write:packages scope.

We recommend publishing images via GitHub Actions. For more information, see "Publishing Docker images."

Accessing images stored in other container registries

If you are accessing a container image from a registry that isn't GitHub Container Registry, Codespaces checks for the presence of three secrets, which define the server name, username, and personal access token (PAT) for a container registry. 如果找到这些密钥,Codespaces 将在代码空间中提供注册表。

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

您可以在用户、仓库或组织级别存储密钥,从而在不同的代码空间之间安全地共享它们。 当您为私有映像注册表创建一组密钥时,您需要用一致的标识符替换名称中的 “<*>”。 更多信息请参阅“管理代码空间的加密密码”和“管理代码空间的仓库和组织加密密码“。

如果您在用户或组织级别设置机密,请确保将这些机密分配到仓库,您将从下拉列表中选择访问策略来创建代码空间。

映像注册表密钥示例

示例机密

如果您在 Azure 中拥有私有映像注册表,则可以创建以下机密:

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

有关通用映像注册表的信息,请参阅“通用映像注册表服务器”。 Note that accessing AWS Elastic Container Registry (ECR) is different.

映像注册表密钥示例

添加机密后,您可能需要停止并启动您所在的代码空间,以便将新的环境变量传递到容器。 更多信息请参阅“暂停或停止代码空间”。

访问 AWS Elastic Container Registry

To access AWS Elastic Container Registry (ECR), you can provide an AWS access key ID and secret key, and GitHub can retrieve an access token for you and log in on your behalf.

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

You must also ensure you have the appropriate AWS IAM permissions to perform the credential swap (e.g. sts:GetServiceBearerToken) as well as the ECR read operation (either AmazonEC2ContainerRegistryFullAccess or ReadOnlyAccess).

Alternatively, if you don't want GitHub to perform the credential swap on your behalf, you can provide an authorization token fetched via AWS's APIs or CLI.

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

Since these tokens are short lived and need to be refreshed periodically, we recommend providing an access key ID and secret.

While these secrets can have any name, so long as the *_CONTAINER_REGISTRY_SERVER is an ECR URL, we recommend using ECR_CONTAINER_REGISTRY_* unless you are dealing with multiple ECR registries.

For more information, see AWS ECR's "Private registry authentication documentation."

通用映像注册表服务器

下面列出了一些通用映像注册表服务器:

Debugging private image registry access

If you are having trouble pulling an image from a private image registry, make sure you are able to run docker login -u <user> -p <password> <server>, using the values of the secrets defined above. If login fails, ensure that the login credentials are valid and that you have the apprioriate permissions on the server to fetch a container image. If login succeeds, make sure that these values are copied appropriately into the right Codespaces secrets, either at the user, repository, or organization level and try again.