Artifact Attestation on Action Runner Controller

[zizyan]

We provide Action Runner Controller (ARC) as an auto scaling solution to our enterprise customers who intend to host their self-hosted runners in a Kubernetes environment. We can see customers enjoy the ease of building their CI/CD pipeline using the runner scale sets and scaling it automatically by configuring a simple values.yaml file. Now, since my pipeline is automated, the question becomes “How can we make sure the software supply chain is verifiable”, “How do we control the build governance”, “ Does GitHub provide any solution to help verify that my artifact comes from a trusted source (e.g. my company’s organization/repository, or certified open source repository) and is it signed by a good public/private authority?”

We announced the Artifact Attestation in May 2024 and the product is generally available in June. Now customers can install a kubernetes admission controller in their Kubernetes environment to enforce the artifact attestation. Let’s walk you through the process of installing both ARC and Admission Controller on a Azure Kubernetes Service (AKS) cluster and configure them to work together for a secured/trustworthy auto-scaling runner environment.

I will first use the default settings of AKS to create a Kubernetes Cluster running on the latest 1.30.7 release, then I am going to install the latest ARC and a runner scale set 0.10.1 release on the cluster, and configure it at my example organization level and listen to job requests from all the repositories within the organization. Upon a successful run of matrix workflow jobs using the newly installed runner scale sets, I am going to install the software attestation admission controller on the same cluster and assign it a security policy to trust only attested artifacts from the same example organization. Lastly, I will show how the admission controller is applying the trust policy on my Action Runner Controller runner scale set namespace and disallow the runner pod creation without exemption, and how to make a simple change on the same trust policy so not only the artifact from my example organization is allowed, but also my base runner image from Github Packages is exempted so the runner pod can be created to pick up the jobs normally.

1. Create an AKS cluster

   

   Default

   

2. Installing ARC (Action Runner Controller) and configure it at organization level

    NAMESPACE="zizyan-arc-systems"
    helm install arc \
        --namespace "${NAMESPACE}" \
        --create-namespace \
     oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller
    
    INSTALLATION_NAME="arc-runner-set"
    NAMESPACE="arc-runners"
    helm install -f values.yaml "${INSTALLATION_NAME}" \
        --namespace "${NAMESPACE}" \
        --create-namespace \
        oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set
   

   Controller and Runner Scale Sets

   

   Example values.yaml file can be found here. In my setup, I have minRunners set to 1, thus I will always have at least 1 runner standby (Idle) waiting for jobs.

   Idle runner with minimum 1 runner setting

   

   Let’s do a quick test by kicking off matrix jobs requiring 5 runners and observe the runner scale set scaling up (to 5 runners executing matrix jobs in parallel) and down (to 1 idle runner).

   

   Matrix Job Completed

   

3. Installing Kubernetes Admission Controller for Artifact Attestation

   helm upgrade policy-controller --install --atomic \
     --create-namespace --namespace artifact-attestations \
     oci://ghcr.io/github/artifact-attestations-helm-charts/policy-controller \
     --version v0.12.0-github10
   

   Policy installation option 1: Upgrade(or install) trust policy inline

   helm upgrade trust-policies --install --atomic \
    --namespace artifact-attestations \
    oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies \
    --version v0.6.2 \
    --set policy.enabled=true \
    --set policy.organization=MY-ORGANIZATION
   

   The organization parameter is used to validate the signer workflow's identity. An attestation is valid if it was generated inside a repository owned by this organization. You may also embed all configurable values inside a yaml file using option 2 below to install(or upgrade) the controller’s trust policy.
   Policy installation option 2: Upgrade(or install) trust policy using a local trust_policy.yaml

   https://github.com/github/artifact-attestations-helm-charts/blob/main/charts/trust-policies/values.yaml

   helm upgrade trust-policies --install --atomic  --namespace artifact-attestations  oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies  --version v0.6.2 -f trust_policy.yaml
   

   Example trust_policy.yaml

   # A default policy can be created by setting policy.enabled to true.
   policy:
     # To verify an attestation, we must validate the identity of the workflow that signed it, which is stored in the attestation's certificate's subject alternative name.
     # To validate the signer workflow's identity, you can set the subjectRegExp value, or set the organization and the repository values below.
     #
     # policy.organization is used to validate the signer workflow's identity. An attestation is valid if it was generated inside a repository owned by this organization.
     # Required if policy.enabled is true and policy.subjectRegExp has not been set.
     organization: 'example-organization'
     # policy.repository is used to validate the signer workflow's identity. An attestation is valid if it was generated inside this specific repository.
     # Must be used in combination with the policy.organization value.
     repository: '.*'
     # policy.subjectRegExp is a regex used to validate the signer workflow's identity. Use this if your attestations are generated with a reusable workflow.
     # Required if policy.enabled is true and policy.organization has not been set.
     subjectRegExp:
     # policy.predicateType defines the type of predicate that the default policy expects
     predicateType: https://slsa.dev/provenance/v1
     # images is a list of image glob patterns that the policy applies to
     images:
   	- "ghcr.io/example-organization/**"
     # exemptImages is a list of image glob patterns that will be allowed to run without verification
     exemptImages: []
     # policy.enabled enables the default policy
     enabled: false
     # policy.trust identifies which signing authorities should be trusted as part of the policy
     trust:
   	# trust the GitHub signing authority
   	github: true
   	# githubTrustDomain is determined by where your GitHub enterprise account is hosted.
   	# If your enterprise is on GitHub.com, leave this field blank.
   	# If your enterprise is on GHE.com, then githubTrustDomain must be set to the output of the following command:
   	# $ gh api meta --jq .domains.artifact_attestations.trust_domain
   	# For more information, see: https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-kubernetes-admission-controller
   	githubTrustDomain: ''
   	# trust the Sigstore public-good signing authority
   	sigstorePublic: true
   

   

   In the example trust_policy.yaml, the controller will only trust artifact attestation bundles generated from the example-organization (any repositories since we put ‘.*’ after the repository setting). If we are leaving the exemptImages blank as example shows, the controller will only allow images defined in the images section, for instance with images: [‘ghcr.io/example-org/**’] the controller will only trust images from the example-organization hosted on github packages, in this case even the ARC created runner (by default, it is using ghcr.io/actions/actions-runner:latest image) will be denied when such a policy is applied to the namespace.

   Enable the policy control on the designated namespace, here it is the arc-runner namespace arc-runners created in the runner scale set installation step:

   kubectl label namespace arc-runners policy.sigstore.dev/include=true
   

   Now when we try to trigger the same matrix jobs again, these jobs would all be in pending state because no new runner pods can be created due to the admission controller trust policy.

   So in order to allow images other than the ones from example-organization hosted on github packages, in the trust_policy.yaml file you can use exemptImages: ['ghcr.io/actions/actions-runner**'] to allow base runner images, or a list of glob patterns defining different registry places like Docker, Artifactory, GitHub Packages or even your own Artifact Management source.

[Rahul-2025-prog]

This is a great step forward in securing the software supply chain for CI/CD pipelines running on self-hosted GitHub Actions runners in Kubernetes. With Artifact Attestation and the admission controller, enterprises can enforce strict build governance, ensuring only trusted artifacts from verified sources are used. Integrating this with ARC makes the auto-scaling process more secure while maintaining efficiency. Looking forward to seeing how organizations adopt this for a more robust and verifiable CI/CD workflow.

[zwanski2019]

Hi @zizyan,

Thanks for sharing this detailed walkthrough of integrating Artifact Attestation with Action Runner Controller (ARC)! This is a critical use case for enterprises prioritizing software supply chain security. A few additional insights to complement your setup:

1. Managing Base Runner Images:
In your trust_policy.yaml, exempting the ARC base runner image (ghcr.io/actions/actions-runner) ensures runner pods can spawn. For stricter control, pin the image to a specific tag/digest instead of latest:

exemptImages:  
  - "ghcr.io/actions/actions-runner@sha256:..."  

2. Multi-Organization Trust:
If your workflow spans multiple GitHub organizations (e.g., shared libraries), expand the subjectRegExp to include trusted sources:

policy:  
  subjectRegExp: "https://github.com/(your-org|another-org)/.*"  

3. Auditing Admission Decisions:
Enable logging for the admission controller to track policy enforcement:

kubectl logs -n artifact-attestations deployment/policy-controller -f  

4. Custom Predicate Types:
If you’re generating custom attestations (e.g., SBOMs), update the predicateType in the policy to match:

policy:  
  predicateType: https://my-org.com/custom-predicate/v1  

5. Private Registry Support:
For artifacts from private registries (e.g., Azure Container Registry), add credentials to the admission controller’s imagePullSecrets to avoid authentication issues during validation.

GitHub’s Artifact Attestation docs provide further guidance on advanced policy configurations.

This setup elegantly balances automation (via ARC) and governance (via attestations). Would love to hear how others are adapting this for hybrid/multi-cloud environments!