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
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).
Copy file name to clipboardExpand all lines: content/actions/get-started/understanding-github-actions.md
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,11 @@ For more information, see [AUTOTITLE](/actions/using-jobs).
78
78
79
79
### Actions
80
80
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
82
86
83
87
You can write your own actions, or you can find actions to use in your workflows in the {% data variables.product.prodname_marketplace %}.
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).
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.'
5
5
versions:
6
6
fpt: '*'
7
7
ghes: '*'
8
8
ghec: '*'
9
+
permissions: '{% data reusables.repositories.permissions-statement-write %}'
{% data reusables.actions.enterprise-github-hosted-runners %}
15
-
16
-
{% data reusables.repositories.permissions-statement-write %}
17
-
18
15
## Canceling a workflow run
19
16
20
17
{% data reusables.repositories.navigate-to-repo %}
@@ -24,12 +21,6 @@ redirect_from:
24
21
1. In the upper-right corner of the workflow, click **Cancel workflow**.
25
22
26
23
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
30
25
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).
Copy file name to clipboardExpand all lines: content/actions/how-tos/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-kubernetes-admission-controller.md
-22Lines changed: 0 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,28 +12,6 @@ redirect_from:
12
12
13
13
>[!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.
14
14
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
-
37
15
## Getting started with Kubernetes admission controller
38
16
39
17
To set up an admission controller for enforcing GitHub artifact attestations, you need to:
## 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
-
22
15
> [!WARNING]
23
-
> *If you make a private repository accessible to {% data variables.product.prodname_actions %} workflows in other repositories, outsidecollaborators 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 %}
24
17
> * {% data reusables.actions.scoped-token-note %}
25
18
26
19
## Sharing actions and workflows from your private repository
27
20
28
21
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**.
## 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
-
22
15
> [!WARNING]
23
16
> * {% data reusables.actions.outside-collaborators-actions %}
24
17
> * {% data reusables.actions.scoped-token-note %}
25
18
26
19
## Sharing actions and workflows with your organization
27
20
28
21
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**.
0 commit comments