[pull] main from github:main

content/actions/concepts/runners/about-actions-runner-controller.md → content/actions/concepts/runners/actions-runner-controller.md

@@ -1,16 +1,15 @@
 ---
-title: About Actions Runner Controller
-shortTitle: About ARC
+title: Actions Runner Controller
 intro: 'You can host your own runners and customize the environment used to run jobs in your {% data variables.product.prodname_actions %} workflows.'
 versions:
   fpt: '*'
   ghec: '*'
   ghes: '*'
-type: overview
 topics:
   - Actions Runner Controller
 redirect_from:
   - /actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller
+  - /actions/concepts/runners/about-actions-runner-controller
 ---
 
 ## About {% data variables.product.prodname_actions_runner_controller %}
@@ -146,18 +145,6 @@ RUN curl -f -L -o runner-container-hooks.zip https://github.com/actions/runner-c
 USER runner
 ```
 
-## Executing workflows
-
-After installation and configuration are complete, you can use ARC to execute workflow runs. A workflow can be created in the same repository that can target a self hosted runner created by ARC. For more information about targeting workflows to run on self-hosted runners, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow).
-
-### Using ARC runners in a workflow
-
-{% data reusables.actions.actions-runner-controller-labels %} For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/using-actions-runner-controller-runners-in-a-workflow).
-
-## Scaling runners
-
-You can scale runners statically or dynamically depending on your needs. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller#scaling-runners).
-
 ## Software installed in the ARC runner image
 
 The ARC [runner image](https://github.com/actions/runner/pkgs/container/actions-runner) is bundled with the following software:
@@ -183,3 +170,11 @@ The supported runner image is released as a separate container image, which you
 ## Legal notice
 
 {% data reusables.actions.actions-runner-controller-legal-notice %}
+
+## Next steps
+
+When you're ready to use ARC to execute workflows, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/using-actions-runner-controller-runners-in-a-workflow).
+
+{% data reusables.actions.actions-runner-controller-labels %} For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow).
+
+You can scale runners statically or dynamically depending on your needs. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller#scaling-runners).

content/actions/concepts/runners/about-github-hosted-runners.md → content/actions/concepts/runners/github-hosted-runners.md

@@ -1,6 +1,5 @@
 ---
-title: About GitHub-hosted runners
-shortTitle: GitHub-hosted runners
+title: GitHub-hosted runners
 intro: '{% data variables.product.prodname_dotcom %} offers hosted virtual machines to run workflows. The virtual machine contains an environment of tools, packages, and settings available for {% data variables.product.prodname_actions %} to use.'
 redirect_from:
   - /articles/virtual-environments-for-github-actions
@@ -14,6 +13,7 @@ redirect_from:
   - /actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners
   - /actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners
   - /actions/how-tos/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners
+  - /actions/concepts/runners/about-github-hosted-runners
 versions:
   fpt: '*'
   ghes: '*'

content/actions/concepts/runners/index.md

@@ -7,12 +7,12 @@ versions:
   ghes: '*'
   ghec: '*'
 children:
-  - /about-github-hosted-runners
-  - /about-larger-runners
-  - /about-self-hosted-runners
-  - /about-private-networking-with-github-hosted-runners
-  - /about-runner-groups
-  - /about-runner-scale-sets
-  - /about-actions-runner-controller
-  - /about-support-for-actions-runner-controller
+  - /github-hosted-runners
+  - /larger-runners
+  - /self-hosted-runners
+  - /private-networking-with-github-hosted-runners
+  - /runner-groups
+  - /runner-scale-sets
+  - /actions-runner-controller
+  - /support-for-actions-runner-controller
 ---

content/actions/concepts/runners/about-larger-runners.md → content/actions/concepts/runners/larger-runners.md

@@ -1,6 +1,5 @@
 ---
-title: About larger runners
-shortTitle: Larger runners
+title: Larger runners
 intro: 'Learn about the types and uses of {% data variables.product.prodname_dotcom %}-hosted {% data variables.actions.hosted_runners %}.'
 permissions: '{% data reusables.actions.larger-runner-permissions %}'
 versions:
@@ -10,6 +9,7 @@ versions:
 redirect_from:
   - /actions/using-github-hosted-runners/about-larger-runners/about-larger-runners
   - /actions/using-github-hosted-runners/using-larger-runners/about-larger-runners
+  - /actions/concepts/runners/about-larger-runners
 ---
 
 {% ifversion ghes %}

content/actions/concepts/runners/about-private-networking-with-github-hosted-runners.md → content/actions/concepts/runners/private-networking-with-github-hosted-runners.md

@@ -1,12 +1,11 @@
 ---
-title: About private networking with GitHub-hosted runners
+title: Private networking with GitHub-hosted runners
 shortTitle: About private networking
 intro: '{% data reusables.actions.private-networking-intro %}'
 versions:
   fpt: '*'
   ghes: '*'
   ghec: '*'
-type: overview
 topics:
   - Actions
   - Action development
@@ -17,6 +16,7 @@ topics:
   - CD
 redirect_from:
   - /actions/using-github-hosted-runners/connecting-to-a-private-network/about-private-networking-with-github-hosted-runners
+  - /actions/concepts/runners/about-private-networking-with-github-hosted-runners
 ---
 
 {% data reusables.actions.enterprise-github-hosted-runners %}

content/actions/concepts/runners/about-runner-groups.md → content/actions/concepts/runners/runner-groups.md

@@ -1,12 +1,12 @@
 ---
-title: About runner groups
-shortTitle: Runner groups
+title: Runner groups
 intro: 'Learn about what a runner group is, and how to use them to control access to runners at the organization{% ifversion ghec or ghes %} and/or enterprise levels{% else %} level.{% endif %}'
 versions:
   fpt: '*'
   ghec: '*'
   ghes: '*'
-type: overview
+redirect_from:
+  - /actions/concepts/runners/about-runner-groups
 ---
 
 ## About runner groups

content/actions/concepts/runners/about-runner-scale-sets.md → content/actions/concepts/runners/runner-scale-sets.md

@@ -1,15 +1,15 @@
 ---
-title: About runner scale sets
-shortTitle: Runner scale sets
+title: Runner scale sets
 intro: 'Learn about what a runner scale set is and how they can interact with the {% data variables.product.prodname_actions_runner_controller %}.'
 layout: inline
 versions:
   fpt: '*'
   ghec: '*'
   ghes: '*'
-type: overview
 topics:
   - Actions Runner Controller
+redirect_from:
+  - /actions/concepts/runners/about-runner-scale-sets
 ---
 
 ## About runner scale sets

content/actions/concepts/runners/about-self-hosted-runners.md → content/actions/concepts/runners/self-hosted-runners.md

@@ -1,17 +1,16 @@
 ---
-title: About self-hosted runners
-shortTitle: Self-hosted runners
+title: Self-hosted runners
 intro: 'You can host your own runners and customize the environment used to run jobs in your {% data variables.product.prodname_actions %} workflows.'
 redirect_from:
   - /github/automating-your-workflow-with-github-actions/about-self-hosted-runners
   - /actions/automating-your-workflow-with-github-actions/about-self-hosted-runners
   - /actions/hosting-your-own-runners/about-self-hosted-runners
   - /actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
+  - /actions/concepts/runners/about-self-hosted-runners
 versions:
   fpt: '*'
   ghes: '*'
   ghec: '*'
-type: overview
 ---
 
 A self-hosted runner is a system that you deploy and manage to execute jobs from {% data variables.product.prodname_actions %} on {% data variables.product.github %}.

content/actions/concepts/runners/about-support-for-actions-runner-controller.md → content/actions/concepts/runners/support-for-actions-runner-controller.md

@@ -1,7 +1,7 @@
 ---
-title: About support for Actions Runner Controller
+title: Support for Actions Runner Controller
+shortTitle: Support for ARC
 intro: 'What to know before you [contact {% data variables.contact.github_support %}](support/contacting-github-support) for assistance with Actions Runner Controller.'
-shortTitle: About Support for ARC
 versions:
   fpt: '*'
   ghec: '*'
@@ -11,11 +11,10 @@ topics:
   - Support
 redirect_from:
   - /actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-support-for-actions-runner-controller
+  - /actions/concepts/runners/about-support-for-actions-runner-controller
 ---
 
-You can [contact {% data variables.contact.github_support %}](/support/contacting-github-support) for assistance with Actions Runner Controller.
-
-## About support for Actions Runner Controller Versions
+## Overview
 
 The Actions Runner Controller (ARC) project [was adopted by GitHub](https://github.com/actions/actions-runner-controller/discussions/2072) to release as a new GitHub product. As a result, there are currently two ARC releases: the legacy community-maintained ARC and GitHub's Autoscaling Runner Sets.
 

content/actions/concepts/security/artifact-attestations.md

@@ -0,0 +1,55 @@
+---
+title: Artifact attestations
+intro: 'Understand the usage and security benefits of artifact attestations.'
+shortTitle: Artifact attestations
+topics:
+  - Actions
+  - Security
+versions:
+  fpt: '*'
+  ghec: '*'
+---
+
+## Overview
+
+{% data reusables.actions.about-artifact-attestations %}
+
+## SLSA levels for artifact attestations
+
+The SLSA framework is an industry standard used to evaluate supply chain security. It is organized into levels. Each level represents an increasing degree of security and trustworthiness for a software supply chain. Artifact attestations by itself provides SLSA v1.0 Build Level 2.
+
+This provides a link between your artifact and its build instructions, but you can take this a step further by requiring builds make use of known, vetted build instructions. A great way to do this is to have your build take place in a reusable workflow that many repositories across your organization share. Reusable workflows can provide isolation between the build process and the calling workflow, to meet SLSA v1.0 Build Level 3. For more information, see [AUTOTITLE](/actions/security-guides/using-artifact-attestations-and-reusable-workflows-to-achieve-slsa-v1-build-level-3).
+
+For more information on SLSA levels, see [SLSA Security Levels](https://slsa.dev/spec/v1.0/levels).
+
+## How {% data variables.product.github %} generates artifact attestations
+
+To generate artifact attestations, {% data variables.product.prodname_dotcom %} uses Sigstore, which is an open source project that offers a comprehensive solution for signing and verifying software artifacts via attestations.
+
+**Public repositories** that generate artifact attestations use the [Sigstore Public Good Instance](https://openssf.org/blog/2023/10/03/running-sigstore-as-a-managed-service-a-tour-of-sigstores-public-good-instance/). A copy of the generated Sigstore bundle is stored with GitHub and is also written to an immutable transparency log that is publicly readable on the internet.
+
+**Private repositories** that generate artifact attestations use GitHub's Sigstore instance. GitHub's Sigstore instance uses the same codebase as the Sigstore Public Good Instance, but it does not have a transparency log and only federates with {% data variables.product.prodname_actions %}.
+
+## When to generate attestations
+
+Generating attestations alone doesn't provide any security benefit, the attestations must be verified for the benefit to be realized. Here are some guidelines for how to think about what to sign and how often:
+
+You should sign:
+
+* Software you are releasing that you expect people to run `gh attestation verify ...` on.
+* Binaries people will run, packages people will download, or manifests that include hashes of detailed contents.
+
+You should **not** sign:
+
+* Frequent builds that are just for automated testing.
+* Individual files like source code, documentation files, or embedded images.
+
+## Verifying artifact attestations
+
+If you consume software that publishes artifact attestations, you can use the {% data variables.product.prodname_cli %} to verify those attestations. Because the attestations give you information about where and how software was built, you can use that information to create and enforce security policies that elevate your supply chain security.
+
+>[!WARNING] It is important to remember that artifact attestations are _not_ a guarantee that an artifact is secure. Instead, artifact attestations link you to the source code and the build instructions that produced them. It is up to you to define your policy criteria, evaluate that policy by evaluating the content, and make an informed risk decision when you are consuming software.
+
+## Next steps
+
+To start generating and verifying artifact attestations for your builds, see [AUTOTITLE](/actions/how-tos/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds).

content/actions/concepts/security/index.md

@@ -10,7 +10,8 @@ children:
   - /secrets
   - /github_token
   - /openid-connect
+  - /artifact-attestations
   - /script-injections
   - /compromised-runners
+  - /kubernetes-admissions-controller
 ---
-

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

@@ -0,0 +1,33 @@
+---
+title: Kubernetes admissions controller
+intro: Understand how you can use an admissions controller to enforce artifact attestations in your Kubernetes cluster.
+versions:
+  fpt: '*'
+  ghec: '*'
+---
+
+## About Kubernetes admission controller
+
+[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.
+
+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.
+
+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.
+
+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.
+
+### About image verification
+
+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.
+
+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.
+
+### About trust roots and policies
+
+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.
+
+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`.
+
+## Next steps
+
+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

@@ -78,7 +78,11 @@ For more information, see [AUTOTITLE](/actions/using-jobs).
 
 ### Actions
 
-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.
+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:
+
+* Pulling your Git repository from {% data variables.product.prodname_dotcom %}
+* Setting up the correct toolchain for your build environment
+* Setting up authentication to your cloud provider
 
 You can write your own actions, or you can find actions to use in your workflows in the {% data variables.product.prodname_marketplace %}.
 

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

@@ -10,7 +10,7 @@ redirect_from:
   - /actions/administering-github-actions/making-retired-namespaces-available-on-ghecom
 ---
 
-## About retirement of namespaces
+## Overview
 
 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).
 

content/actions/how-tos/index.md

@@ -15,7 +15,6 @@ children:
   - /managing-self-hosted-runners
   - /using-larger-runners
   - /security-for-github-actions
-  - /use-cases-and-examples
   - /administering-github-actions
   - /monitor-workflows
   - /troubleshooting-workflows

content/actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-forks.md

@@ -0,0 +1,22 @@
+---
+title: Approving workflow runs from forks
+intro: 'You can manually approve workflow runs that have been triggered by a contributor''s pull request.'
+versions:
+  fpt: '*'
+  ghec: '*'
+  ghes: '*'
+shortTitle: Approve workflow runs
+redirect_from:
+  - /actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
+  - /actions/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-public-forks
+  - /actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-private-forks
+  - /actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-public-forks
+---
+
+Workflow runs triggered by a contributor's pull request from a fork may require manual approval from a maintainer with write access. You can configure workflow approval requirements for a [repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-required-approval-for-workflows-from-public-forks), [organization](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#configuring-required-approval-for-workflows-from-public-forks), or [enterprise](/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-fork-pull-requests-in-your-enterprise).
+
+Workflow runs that have been awaiting approval for more than 30 days are automatically deleted.
+
+## Approving workflow runs on a pull request from a public fork
+
+{% data reusables.actions.workflows.approve-workflow-runs %}