You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/packages/guides/configuring-access-control-and-visibility-for-container-images.md
+49-1Lines changed: 49 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ The selected users will automatically be given access and don't need to accept a
26
26
27
27
If you have admin permissions to an organization-owned container image, you can assign read, write, or admin roles to other users and teams. For more information about these permission roles, see "[Visibility and access permissions for container images](/packages/getting-started-with-github-container-registry/about-github-container-registry#visibility-and-access-permissions-for-container-images)."
28
28
29
-
If your package is owned by an organization and private, then you can only give access to other organization members or teams.
29
+
If your package is private or internal and owned by an organization, then you can only give access to other organization members or teams.
30
30
31
31
For organization image containers, organizations admins must enable packages before you can set the visibility to public. For more information, see "[Enabling improved container support](/packages/getting-started-with-github-container-registry/enabling-improved-container-support)."
32
32
@@ -38,6 +38,40 @@ For organization image containers, organizations admins must enable packages bef
38
38
39
39
The selected users or teams will automatically be given access and don't need to accept an invitation first.
40
40
41
+
### Inheriting access for a container image from a repository
42
+
43
+
To simplify package management through {% data variables.product.prodname_actions %} workflows, you can enable a container image to inherit the access permissions of a repository by default.
44
+
45
+
If you inherit the access permissions of the repository where your package's workflows are stored, then you can adjust access to your package through the repository's permissions.
46
+
47
+
Once a repository is synced, you can't access the package's granular access settings. To customize the package's permissions through the granular package access settings, you must remove the synced repository first.
48
+
49
+
{% data reusables.package_registry.package-settings-from-org-level %}
50
+
2. Under "Repository source", select **Inherit access from repository (recommended)**.
To ensure that a {% data variables.product.prodname_actions %} workflow has access to your package, you must give explicit access to the repository where the workflow is stored.
56
+
57
+
The specified repository does not need to be the repository where the source code for the package is kept. You can give multiple repositories workflow access to a package.
58
+
59
+
{% note %}
60
+
61
+
**Note:** Syncing your container image with a repository through the **Actions access** menu option is different than connecting your container to a repository. For more information about linking a repository to your container, see "[Connecting a repository to a container image](/packages/guides/connecting-a-repository-to-a-container-image)."
62
+
63
+
{% endnote %}
64
+
65
+
{% data reusables.package_registry.package-settings-from-org-level %}
66
+
1. In the left sidebar, click **Actions access**.
67
+
68
+
2. Click **Add repository** and search for the repository you want to add.
3. Using the "role" drop-down menu, select the default access level that you'd like repository members to have to your container image. Outside collaborators will not be included.
71
+
72
+
73
+
To further customize access to your container image, see "[Configuring access to container images for an organization](#configuring-access-to-container-images-for-an-organization)."
74
+
41
75
### Configuring visibility of container images for your personal account
42
76
43
77
When you first publish a package, the default visibility is private and only you can see the package. You can modify a private or public container image's access by changing the access settings.
@@ -55,6 +89,20 @@ A public package can be accessed anonymously without authentication. Once you ma
55
89
- To make the container image visible to a custom selection of people, click **Make private**.
### Container creation visibility for organization members
93
+
94
+
You can choose the visibility of containers that organization members can publish by default.
95
+
96
+
{% data reusables.profile.access_profile %}
97
+
{% data reusables.profile.access_org %}
98
+
{% data reusables.organizations.org_settings %}
99
+
4. On the left, click **Packages**.
100
+
6. Under "Container creation", choose whether you want to enable the creation of public, private, or internal container images.
101
+
- To enable organization members to create public container images, click **Public**.
102
+
- To enable organization members to create private container images that are only visible to other organization members, click **Private**. You can further customize the visibility of private container images.
103
+
-**For {% data variables.product.prodname_ghe_cloud %} only:** To enable organization members to create internal container images that are only visible to other organization members, click **Internal**.
104
+
105
+
58
106
### Configuring visibility of container images for an organization
59
107
60
108
When you first publish a package, the default visibility is private and only you can see the package. You can grant users or teams different access roles for your container image through the access settings.
Copy file name to clipboardExpand all lines: content/packages/guides/enabling-improved-container-support.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,8 +34,8 @@ Before organization owners or members can publish container images to {% data va
34
34
4. On the left, click **Packages**.
35
35
5. Under "Improved container support", select "Enable improved container support" and click **Save**.
36
36
37
-
6. Under "Container creation", choose whether you want to enable the creation of public and/or private container images.
37
+
6. Under "Container creation", choose whether you want to enable the creation of public, private, or internal container images.
38
38
- To enable organization members to create public container images, click **Public**.
39
39
- To enable organization members to create private container images that are only visible to other organization members, click **Private**. You can further customize the visibility of private container images. For more information, see "[Configuring access control and visibility for container images](/packages/managing-container-images-with-github-container-registry/configuring-access-control-and-visibility-for-container-images)."
40
-
41
-
40
+
-**For {% data variables.product.prodname_ghe_cloud %} only:** To enable organization members to create internal container images that are only visible to other organization members, click **Internal**.
41
+
Copy file name to clipboardExpand all lines: content/packages/guides/using-github-packages-with-github-actions.md
+124-4Lines changed: 124 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,6 +39,45 @@ For an authentication example, see "[Authenticating with the {% data variables.p
39
39
40
40
You can reference the `GITHUB_TOKEN` in your workflow file using the {% raw %}`{{secrets.GITHUB_TOKEN}}`{% endraw %} context. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token)."
41
41
42
+
### About permissions and package access for repository-owned packages
43
+
44
+
{% note %}
45
+
46
+
**Note:** Repository-owned packages include RubyGems, npm, Apache Maven, NuGet, Gradle, and Docker packages that use the package namespace `docker.pkg.github.com`.
47
+
48
+
{% endnote %}
49
+
50
+
When you enable GitHub Actions, GitHub installs a GitHub App on your repository. The `GITHUB_TOKEN` secret is a GitHub App installation access token. You can use the installation access token to authenticate on behalf of the GitHub App installed on your repository. The token's permissions are limited to the repository that contains your workflow. For more information, see "[Permissions for the GITHUB_TOKEN](/actions/reference/authentication-in-a-workflow#about-the-github_token-secret)."
51
+
52
+
{% data variables.product.prodname_registry %} allows you to push and pull packages through the `GITHUB_TOKEN` available to a {% data variables.product.prodname_actions %} workflow.
53
+
54
+
{% if currentVersion == "free-pro-team@latest" %}
55
+
### About permissions and package access for {% data variables.product.prodname_container_registry %}
56
+
57
+
The {% data variables.product.prodname_container_registry %} (`ghcr.io`) allows users to create and administer containers as free-standing resources at the organization level. Containers can be owned by an organization or personal user account and you can customize access to each of your containers separately from repository permissions.
58
+
59
+
All workflows accessing the {% data variables.product.prodname_container_registry %} should use the `GITHUB_TOKEN` instead of a personal access token. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
60
+
61
+
### Default permissions and access settings for containers modified through workflows
62
+
63
+
When you create, install, modify, or delete a container through a workflow, there are some default permission and access settings used to ensure admins have access to the workflow. You can adjust these access settings as well.
64
+
65
+
For example, by default if a workflow creates a container using the `GITHUB_TOKEN`, then:
66
+
- The container inherits the visibility and permissions model of the repository where the workflow is run.
67
+
- Repository admins where the workflow is run become the admins of the container once the container is created.
68
+
69
+
These are more examples of how default permissions work for workflows that manage packages.
70
+
71
+
| {% data variables.product.prodname_actions %} workflow task | Default permissions and access |
72
+
|----|----|
73
+
| Download an existing container | - If the container is public, any workflow running in any repository can download the container. <br> - If the container is internal, then all workflows running in any repository owned by the Enterprise account can download the container. For enterprise-owned organizations, you can read any repository in the enterprise <br> - If the container is private, only workflows running in repositories that are given read permission on that container can download the container. <br>
74
+
| Upload a new version to an existing container | - If the container is private, internal, or public, only workflows running in repositories that are given write permission on that container can upload new versions to the container.
75
+
| Delete a container or versions of a container | - If the container is private, internal, or public, only workflows running in repositories that are given delete permission can delete existing versions of the container.
76
+
77
+
You can also adjust access to containers in a more granular way or adjust some of the default permissions behavior. For more information, see "[Configuring access control and visibility for container images](/packages/guides/configuring-access-control-and-visibility-for-container-images)."
78
+
79
+
{% endif %}
80
+
42
81
### Publishing a package using an action
43
82
44
83
You can use {% data variables.product.prodname_actions %} to automatically publish packages as part of your continuous integration (CI) flow. This approach to continuous deployment (CD) allows you to automate the creation of new package versions, if the code meets your quality standards. For example, you could create a workflow that runs CI tests every time a developer pushes code to a particular branch. If the tests pass, the workflow can publish a new package version to {% data variables.product.prodname_registry %}.
Defines the registry that will host the resulting packages. This example uses {% data variables.product.prodname_registry %}.{% if currentVersion == "github-ae@latest" %} Replace <code>YOUR-HOSTNAME</code> with the name of your enterprise.{% endif %}
302
+
Defines the registry that will host the resulting packages. This example uses {% data variables.product.prodname_registry %}.{% if currentVersion == "github-ae@latest" %} Replace <code>YOUR-HOSTNAME</code> with the name of your enterprise.{% endif %} {% if currentVersion == "free-pro-team@latest" %} If you're using the {% data variables.product.prodname_container_registry %}, then use <code>ghcr.io</code> as the hostname.{% endif %}
264
303
</td>
265
304
</tr>
266
305
<tr>
@@ -291,7 +330,7 @@ tag_with_sha: true
291
330
</tr>
292
331
<tr>
293
332
<td>
294
-
333
+
295
334
{% raw %}
296
335
```yaml
297
336
tag_with_ref: true
@@ -307,14 +346,95 @@ tag_with_ref: true
307
346
- This new workflow will run automatically every time you push a change to a branch named `release` in the repository. You can view the progress in the **Actions** tab.
308
347
- A few minutes after the workflow has completed, the new package will visible in your repository. To find your available packages, see "[Viewing a repository's packages](/packages/publishing-and-managing-packages/viewing-packages#viewing-a-repositorys-packages)."
309
348
349
+
310
350
### Installing a package using an action
311
351
312
352
You can install packages as part of your CI flow using {% data variables.product.prodname_actions %}. For example, you could configure a workflow so that anytime a developer pushes code to a pull request, the workflow resolves dependencies by downloading and installing packages hosted by {% data variables.product.prodname_registry %}. Then, the workflow can run CI tests that require the dependencies.
313
353
314
-
Installing packages hosted by {% data variables.product.prodname_registry %} through {% data variables.product.prodname_actions %} requires minimal configuration or additional authentication when you use `GITHUB_TOKEN`.{% if currentVersion == "free-pro-team@latest" %} Data transfer is also free when an action installs a package. For more information, see "[About billing for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages)."{% endif %}
354
+
Installing packages hosted by the {% data variables.product.prodname_registry %} through {% data variables.product.prodname_actions %} requires minimal configuration or additional authentication when you use the `GITHUB_TOKEN`.{% if currentVersion == "free-pro-team@latest" %} Data transfer is also free when an action installs a package. For more information, see "[About billing for {% data variables.product.prodname_registry %}](/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-packages)."{% endif %}
315
355
316
356
{% if currentVersion == "free-pro-team@latest" %}
317
-
`GITHUB_TOKEN`cannot install packages from any private repository besides the repository where the action runs. You cannot currently use `GITHUB_TOKEN` to authenticate to {% data variables.product.prodname_github_container_registry %}.
318
357
{% endif %}
319
358
320
359
{% data reusables.package_registry.actions-configuration %}
360
+
361
+
{% if currentVersion == "free-pro-team@latest" %}
362
+
### Upgrading a workflow that accesses `ghcr.io`
363
+
364
+
{% data reusables.package_registry.github-token-security-over-pat %}
365
+
366
+
Using the `GITHUB_TOKEN` instead of a PAT, which includes the `repo` scope, increases the security of your repository as you don't need to use a long-lived PAT that offers unnecessary access to the repository where your workflow is run. For more information about security best practices, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#using-secrets)."
367
+
368
+
1. Navigate to your package landing page.
369
+
1. In the left sidebar, click **Actions access**.
370
+
371
+
2. To ensure your container package has access to your workflow, you must add the repository where the workflow is stored to your container. Click **Add repository** and search for the repository you want to add.
**Note:** Adding a repository to your container through the **Actions access** menu option is different than connecting your container to a repository. For more information, see "[Ensuring workflow access to your package](/packages/guides/configuring-access-control-and-visibility-for-container-images#ensuring-workflow-access-to-your-package)" and "[Connecting a repository to a container image](/packages/guides/connecting-a-repository-to-a-container-image)."
376
+
377
+
{% endnote %}
378
+
3. Optionally, using the "role" drop-down menu, select the default access level that you'd like the repository to have to your container image.
379
+
380
+
5. Open your workflow file. On the line where you login to `ghcr.io`, replace your PAT with {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %}.
381
+
382
+
For example, this workflow publishes a Docker container using {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %} to authenticate.
383
+
384
+
{% raw %}
385
+
```yaml{:copy}
386
+
name: Demo Push
387
+
388
+
on:
389
+
push:
390
+
# Publish `master` as Docker `latest` image.
391
+
branches:
392
+
- master
393
+
- seed
394
+
395
+
# Publish `v1.2.3` tags as releases.
396
+
tags:
397
+
- v*
398
+
399
+
# Run tests for any PRs.
400
+
pull_request:
401
+
402
+
env:
403
+
IMAGE_NAME: ghtoken_product_demo
404
+
405
+
jobs:
406
+
# Push image to GitHub Packages.
407
+
# See also https://docs.docker.com/docker-hub/builds/
0 commit comments