Skip to content

Commit 0cee1c7

Browse files
docs-botdocs-bot
authored
Merge pull request #39468 from github/repo-sync
Repo sync
2 parents 4c728af + 3b59285 commit 0cee1c7

34 files changed

+641
-311
lines changed

‎content/actions/concepts/security/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,5 +12,6 @@ children:
1212
- /openid-connect
1313
- /script-injections
1414
- /compromised-runners
15+
- /kubernetes-admissions-controller
1516
---
1617

‎content/actions/concepts/security/kubernetes-admissions-controller.md

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
---
2+
title: Kubernetes admissions controller
3+
intro: Understand how you can use an admissions controller to enforce artifact attestations in your Kubernetes cluster.
4+
versions:
5+
fpt: '*'
6+
ghec: '*'
7+
---
8+
9+
## About Kubernetes admission controller
10+
11+
[Artifact attestations](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds) enable you to create unfalsifiable provenance and integrity guarantees for the software you build. In turn, people who consume your software can verify where and how your software was built.
12+
13+
Kubernetes admission controllers are plugins that govern the behavior of the Kubernetes API server. They are commonly used to enforce security policies and best practices in a Kubernetes cluster.
14+
15+
Using the open source [Sigstore Policy Controller](https://docs.sigstore.dev/policy-controller/overview/) project you can add an admission controller to your Kubernetes cluster that can enforce artifact attestations. This way, you can ensure that only artifacts with valid attestations can be deployed.
16+
17+
To [install the controller](/actions/how-tos/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-kubernetes-admission-controller), we offer [two Helm charts](https://github.com/github/artifact-attestations-helm-charts): one for deploying the Sigstore Policy Controller, and another for loading the GitHub trust root and a default policy.
18+
19+
### About image verification
20+
21+
When the Policy Controller is installed, it will intercept all image pull requests and verify the attestation for the image. The attestation must be stored in the image registry as an [OCI attached artifact](https://oras.land/docs/concepts/reftypes/) containing a [Sigstore Bundle](https://docs.sigstore.dev/about/bundle/) which contains the attestation and cryptographic material (e.g. certificates and signatures) used to verify the attestation. A verification process is then performed that ensures the image was built with the specified build provenance and matches any policies enabled by the cluster administrator.
22+
23+
In order for an image to be verifiable, it must have a valid provenance attestation in the registry, which can be done by enabling the `push-to-registry: true` attribute in the `actions/attest-build-provenance` action. See [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images) for more details on how to generate attestations for container images.
24+
25+
### About trust roots and policies
26+
27+
The Sigstore Policy Controller is primarily configured with trust roots and policies, represented by the Custom Resources `TrustRoot` and `ClusterImagePolicy`. A `TrustRoot` represents a trusted distribution channel for the public key material used to verify attestations. A `ClusterImagePolicy` represents a policy for enforcing attestations on images.
28+
29+
A `TrustRoot` may also contain a [TUF](https://theupdateframework.io/) repository root, making it possible for your cluster to continuously and securely receive updates to its trusted public key material. If left unspecified, a `ClusterImagePolicy` will by default use the open source Sigstore Public Good Instance's key material. When verifying attestations generated for private repositories, the `ClusterImagePolicy` must reference the GitHub `TrustRoot`.
30+
31+
## Next steps
32+
33+
When you're ready to use an admission controller, see [AUTOTITLE](/actions/how-tos/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-kubernetes-admission-controller).

‎content/actions/get-started/understanding-github-actions.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -78,7 +78,11 @@ For more information, see [AUTOTITLE](/actions/using-jobs).
7878

7979
### Actions
8080

81-
An **action** is a custom application for the {% data variables.product.prodname_actions %} platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your **workflow** files. An action can pull your Git repository from {% data variables.product.prodname_dotcom %}, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.
81+
An **action** is a pre-defined, reusable set of jobs or code that performs specific tasks within a **workflow**, reducing the amount of repetitive code you write in your workflow files. Actions can perform tasks such as:
82+
83+
* Pulling your Git repository from {% data variables.product.prodname_dotcom %}
84+
* Setting up the correct toolchain for your build environment
85+
* Setting up authentication to your cloud provider
8286

8387
You can write your own actions, or you can find actions to use in your workflows in the {% data variables.product.prodname_marketplace %}.
8488

‎content/actions/how-tos/administering-github-actions/making-retired-namespaces-available-on-ghecom.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ redirect_from:
1010
- /actions/administering-github-actions/making-retired-namespaces-available-on-ghecom
1111
---
1212

13-
## About retirement of namespaces
13+
## Overview
1414

1515
If you use {% data variables.enterprise.data_residency %}, members of your enterprise can create {% data variables.product.prodname_actions %} workflows that use actions directly from {% data variables.product.prodname_dotcom_the_website %} or [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions).
1616

‎content/actions/how-tos/index.md

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,6 @@ children:
1515
- /managing-self-hosted-runners
1616
- /using-larger-runners
1717
- /security-for-github-actions
18-
- /use-cases-and-examples
1918
- /administering-github-actions
2019
- /monitor-workflows
2120
- /troubleshooting-workflows

‎content/actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow.md

Lines changed: 4 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,17 @@
11
---
22
title: Canceling a workflow
33
shortTitle: Cancel a workflow
4-
intro: 'You can cancel a workflow run that is in progress. When you cancel a workflow run, {% data variables.product.prodname_dotcom %} cancels all jobs and steps that are a part of that workflow.'
4+
intro: 'You can cancel a workflow run, including all jobs and steps, that is in progress.'
55
versions:
66
fpt: '*'
77
ghes: '*'
88
ghec: '*'
9+
permissions: '{% data reusables.repositories.permissions-statement-write %}'
910
redirect_from:
1011
- /actions/managing-workflow-runs/canceling-a-workflow
1112
- /actions/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow
1213
---
1314

14-
{% data reusables.actions.enterprise-github-hosted-runners %}
15-
16-
{% data reusables.repositories.permissions-statement-write %}
17-
1815
## Canceling a workflow run
1916

2017
{% data reusables.repositories.navigate-to-repo %}
@@ -24,12 +21,6 @@ redirect_from:
2421
1. In the upper-right corner of the workflow, click **Cancel workflow**.
2522
![Screenshot showing the summary for a workflow that is currently running. The "Cancel workflow" button is highlighted with a dark orange outline.](/assets/images/help/repository/cancel-check-suite-updated.png)
2623

27-
## Steps {% data variables.product.prodname_dotcom %} takes to cancel a workflow run
28-
29-
When canceling workflow run, you may be running other software that uses resources that are related to the workflow run. To help you free up resources related to the workflow run, it may help to understand the steps {% data variables.product.prodname_dotcom %} performs to cancel a workflow run.
24+
## Next steps
3025

31-
1. To cancel the workflow run, the server re-evaluates `if` conditions for all currently running jobs. If the condition evaluates to `true`, the job will not get canceled. For example, the condition `if: always()` would evaluate to true and the job continues to run. When there is no condition, that is the equivalent of the condition `if: success()`, which only runs if the previous step finished successfully.
32-
1. For jobs that need to be canceled, the server sends a cancellation message to all the runner machines with jobs that need to be canceled.
33-
1. For jobs that continue to run, the server re-evaluates `if` conditions for the unfinished steps. If the condition evaluates to `true`, the step continues to run. You can use the `cancelled` expression to apply a status check of `cancelled()`. For more information see [AUTOTITLE](/actions/learn-github-actions/expressions#cancelled).
34-
1. For steps that need to be canceled, the runner machine sends `SIGINT/Ctrl-C` to the step's entry process (`node` for javascript action, `docker` for container action, and `bash/cmd/pwd` when using `run` in a step). If the process doesn't exit within 7500 ms, the runner will send `SIGTERM/Ctrl-Break` to the process, then wait for 2500 ms for the process to exit. If the process is still running, the runner kills the process tree.
35-
1. After the 5 minutes cancellation timeout period, the server will force terminate all jobs and steps that don't finish running or fail to complete the cancellation process.
26+
To learn about the process {% data variables.product.prodname_dotcom %} uses to cancel a workflow run, as well as the ways you can free up related resources, see [AUTOTITLE](/actions/reference/workflow-cancellation-reference).

‎content/actions/how-tos/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-kubernetes-admission-controller.md

Lines changed: 0 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -12,28 +12,6 @@ redirect_from:
1212

1313
>[!NOTE] Before proceeding, ensure you have enabled build provenance for container images, including setting the `push-to-registry` attribute in the [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance) as documented in [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images). This is required for the Policy Controller to verify the attestation.
1414
15-
## About Kubernetes admission controller
16-
17-
[Artifact attestations](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds) enable you to create unfalsifiable provenance and integrity guarantees for the software you build. In turn, people who consume your software can verify where and how your software was built.
18-
19-
Kubernetes admission controllers are plugins that govern the behavior of the Kubernetes API server. They are commonly used to enforce security policies and best practices in a Kubernetes cluster.
20-
21-
Using the open source [Sigstore Policy Controller](https://docs.sigstore.dev/policy-controller/overview/) project you can add an admission controller to your Kubernetes cluster that can enforce artifact attestations. This way, you can ensure that only artifacts with valid attestations can be deployed.
22-
23-
To [install the controller](#getting-started-with-kubernetes-admission-controller), we offer [two Helm charts](https://github.com/github/artifact-attestations-helm-charts): one for deploying the Sigstore Policy Controller, and another for loading the GitHub trust root and a default policy.
24-
25-
### About image verification
26-
27-
When the Policy Controller is installed, it will intercept all image pull requests and verify the attestation for the image. The attestation must be stored in the image registry as an [OCI attached artifact](https://oras.land/docs/concepts/reftypes/) containing a [Sigstore Bundle](https://docs.sigstore.dev/about/bundle/) which contains the attestation and cryptographic material (e.g. certificates and signatures) used to verify the attestation. A verification process is then performed that ensures the image was built with the specified build provenance and matches any policies enabled by the cluster administrator.
28-
29-
In order for an image to be verifiable, it must have a valid provenance attestation in the registry, which can be done by enabling the `push-to-registry: true` attribute in the `actions/attest-build-provenance` action. See [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images) for more details on how to generate attestations for container images.
30-
31-
### About trust roots and policies
32-
33-
The Sigstore Policy Controller is primarily configured with trust roots and policies, represented by the Custom Resources `TrustRoot` and `ClusterImagePolicy`. A `TrustRoot` represents a trusted distribution channel for the public key material used to verify attestations. A `ClusterImagePolicy` represents a policy for enforcing attestations on images.
34-
35-
A `TrustRoot` may also contain a [TUF](https://theupdateframework.io/) repository root, making it possible for your cluster to continuously and securely receive updates to its trusted public key material. If left unspecified, a `ClusterImagePolicy` will by default use the open source Sigstore Public Good Instance's key material. When verifying attestations generated for private repositories, the `ClusterImagePolicy` must reference the GitHub `TrustRoot`.
36-
3715
## Getting started with Kubernetes admission controller
3816

3917
To set up an admission controller for enforcing GitHub artifact attestations, you need to:

‎content/actions/how-tos/sharing-automations/sharing-actions-and-workflows-from-your-private-repository.md

Lines changed: 9 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -3,31 +3,28 @@ title: Sharing actions and workflows from your private repository
33
intro: You can share an action or reusable workflow without publishing them publicly.
44
versions:
55
fpt: '*'
6-
type: tutorial
76
topics:
87
- Actions
98
- Action development
10-
shortTitle: Share from your private repository
9+
shortTitle: Share across private repositories
1110
redirect_from:
1211
- /actions/creating-actions/sharing-actions-and-workflows-from-your-private-repository
1312
- /actions/sharing-automations/sharing-actions-and-workflows-from-your-private-repository
1413
---
1514

16-
## About {% data variables.product.prodname_actions %} access to private repositories
17-
18-
You can share actions and reusable workflows from your private repository, without making them public, by allowing {% data variables.product.prodname_actions %} workflows to access a private repository that contains the action or reusable workflow.
19-
20-
Any actions or reusable workflows stored in the private repository can be used in workflows defined in other private repositories owned by the same organization or user. Actions and reusable workflows stored in private repositories cannot be used in public repositories.
21-
2215
> [!WARNING]
23-
> * If you make a private repository accessible to {% data variables.product.prodname_actions %} workflows in other repositories, outside collaborators on the other repositories can indirectly access the private repository, even though they do not have direct access to these repositories. The outside collaborators can view logs for workflow runs when actions or workflows from the private repository are used.
16+
> * {% data reusables.actions.outside-collaborators-actions %}
2417
> * {% data reusables.actions.scoped-token-note %}
2518
2619
## Sharing actions and workflows from your private repository
2720

2821
1. Store the action or reusable workflow in a private repository. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories#about-repository-visibility).
29-
1. Configure the repository to allow access to workflows in other private repositories. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).
22+
1. On {% data variables.product.prodname_dotcom %}, navigate to the main page of the private repository.
23+
1. Under your repository name, click **{% octicon "gear" aria-hidden="true" aria-label="gear" %} Settings**.
24+
{% data reusables.repositories.settings-sidebar-actions-general %}
25+
1. To grant access to other private repositories, in the **Access** section at the bottom of the page, select **Accessible from repositories owned by 'USERNAME' user**.
26+
1. Click **Save** to apply the settings.
3027

31-
## Further reading
28+
## Next steps
3229

33-
* [AUTOTITLE](/actions/using-workflows/reusing-workflows)
30+
To reuse your shared workflows, see [AUTOTITLE](/actions/using-workflows/reusing-workflows).

‎content/actions/how-tos/sharing-automations/sharing-actions-and-workflows-with-your-organization.md

Lines changed: 7 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,6 @@ title: Sharing actions and workflows with your organization
33
intro: You can share an action or reusable workflow with your organization without publishing the action or workflow publicly.
44
versions:
55
fpt: '*'
6-
type: tutorial
76
topics:
87
- Actions
98
- Action development
@@ -13,21 +12,19 @@ redirect_from:
1312
- /actions/sharing-automations/sharing-actions-and-workflows-with-your-organization
1413
---
1514

16-
## About {% data variables.product.prodname_actions %} access to private repositories
17-
18-
You can share actions and reusable workflows within your organization, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access a private repository that contains the action or reusable workflow.
19-
20-
Any actions or reusable workflows stored in the private repository can be used in workflows defined in other private repositories owned by the same organization. Actions and reusable workflows stored in private repositories cannot be used in public repositories.
21-
2215
> [!WARNING]
2316
> * {% data reusables.actions.outside-collaborators-actions %}
2417
> * {% data reusables.actions.scoped-token-note %}
2518
2619
## Sharing actions and workflows with your organization
2720

2821
1. Store the action or reusable workflow in a private repository. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories#about-repository-visibility).
29-
1. Configure the repository to allow access to workflows in other private repositories. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).
22+
1. On {% data variables.product.prodname_dotcom %}, navigate to the main page of the private repository.
23+
1. Under your repository name, click **{% octicon "gear" aria-hidden="true" aria-label="gear" %} Settings**.
24+
{% data reusables.repositories.settings-sidebar-actions-general %}
25+
1. To grant access to other private repositories in the organization, in the **Access** section at the bottom of the page, select **Accessible from repositories in the 'ORGANIZATION-NAME' organization**.
26+
1. Click **Save** to apply the settings.
3027

31-
## Further reading
28+
## Next steps
3229

33-
* [AUTOTITLE](/actions/using-workflows/reusing-workflows)
30+
To learn how to reuse your shared workflows, see [AUTOTITLE](/actions/using-workflows/reusing-workflows).

‎content/actions/how-tos/use-cases-and-examples/index.md

Lines changed: 0 additions & 16 deletions
This file was deleted.

0 commit comments

Comments
 (0)