Policy Store

The policy store holds a collection of customized policies for your workflows, allowing you to easily manage and update policies in a single location.

Steps To Create and Use a Policy

For GitHub-Hosted Runners

Step 1: Navigate to the Policy Store

• Go to the Harden Runner section

• Click Policy Store

StepSecurity Policy Store page

Step 2: Create a Policy

• Click Create Policy

• Enter a policy name

• Manually add allowed endpoints

StepSecurity Policy Store page

Step 3: Import Endpoints (Optional)

• You can also automatically import endpoints from baseline

StepSecurity Policy Store page

Step 4: Select a baseline source

Choose the source you want to use as the baseline. This can be one of the following:

• Organization

• Repository

• Arc Cluster

• Job

• Local file

StepSecurity Policy Store page

Step 5: Click Import Endpoints

StepSecurity Policy Store page

Step 6: Save the Policy

• Click Add Policy

StepSecurity Policy Store page

Step 7: Apply the Policy in Your Workflow

• Remove any existing manual policy configurations.

• Add the policy name under the Harden Runner step.

• Ensure id-token: write permission is explicitly set in your workflow file. This permission is required to authenticate with the StepSecurity backend API and fetch the policy.

Here’s an example:

name: CI

on:
  pull_request:

permissions:
  contents: read
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Harden Runner
      uses: step-security/harden-runner@446798f8213ac2e75931c1b0769676d927801858 # v2.10.0
      with:
        policy: new policy

Step 8: Verify the Integration

• Run a test workflow to ensure the policy is applied correctly.

For GitHub-Hosted Custom VMs and Self-Hosted Runners

Policies are applied based on scope, following a defined precedence. If a workflow-level policy exists, it takes priority. If not, the system checks for a repository-level policy. If that's also absent, an organization-level policy will be applied. Finally, if none of the above are defined, the cluster-level policy will be enforced

To use the Policy Store with self-hosted runners or GitHub-Hosted Custom Vms, you first need to configure a pre-job hook:

Pre-Job Hook Setup

• Go to Settings → Harden-Runner Installation → Runner Job Hooks.

• Follow the provided script to configure the hook as a pre-job hook for your runner.

Once the hook is configured, proceed with policy creation:

Step 1: Navigate to the Policy Store

• Go to the Harden Runner section

• Click Policy Store

StepSecurity Policy Store page

Step 2: Create a Policy

• Click Create Policy

• Enter a policy name

• Manually add allowed endpoints

StepSecurity Policy Store page

Step 3: Import Endpoints (Optional)

• You can also automatically import endpoints from baseline

StepSecurity Policy Store page

Step 4: Select a baseline source

Choose the source you want to use as the baseline. This can be one of the following:

• Organization

• Repository

• Arc Cluster

• Job

• Local file

StepSecurity Policy Store page

Step 5: Click Import Endpoints

StepSecurity Policy Store page

Step 6: Save the Policy

• Click Add Policy

StepSecurity Policy Store page

Step 5: Attach the Policy

• Click the three-dot menu next to the policy.

• Select Attach Policy.

StepSecurity Policy Store page

Step 6: Choose whether to attach it to a Cluster, Organization, Repository, or Workflow.

StepSecurity Policy Store page

Step 7: Click "Attach Policy"

StepSecurity Policy Store page

Example: Policy Enforcement

• Suppose you create a policy that only allows specific endpoints

StepSecurity Policy Store page

• During a workflow run, if the job attempts to call a domain not on the allowlist, the request will be automatically blocked.

Job Markdown

• On the Network Events tab of the Insights page, you can see that the policy was responsible for blocking the request and causing the run to fail

Network Events Tab

Alternative way of Creating Policies

You can also create policies directly from the Baseline page.

When you do this, the endpoints associated with the selected job, repository, ARC cluster, or GitHub organization are automatically used to configure the policy.

Step 1: Navigate to the Baseline page under the Harden-Runner dropdown

Step 2: Click "Create Policy"

Step 3: Click "Create Policy" again to confirm

Step 4: You will be redirected to the new policy page, with the relevant endpoints automatically populated.

Step 5(Optional): Export the endpoints to a text file by clicking Export Endpoints.

Step 6: Click "Add policy" to finalize the setup.

Lockdown Mode

Lockdown Mode is currently available only for ARC clusters

Lockdown Mode provides automatic blocking of CI/CD jobs when critical security threats are detected in real-time.

How Lockdown Mode Works

When Lockdown Mode is active for a workflow, Harden-Runner continuously monitors the job at runtime. If a detection matching one of the configured detection types is triggered:

• The running job is immediately terminated.

• A notification is sent with details about the blocked threat, including the detection type, job ID, and workflow run.

• The detection event is recorded in the StepSecurity dashboard and forwarded to any configured integrations (e.g., Webhook, Slack, S3).

Configuring Lockdown Mode

To enable Lockdown Mode for your workflows:

• Navigate to the Policy Store

• Create a new policy or edit an existing one

• Add the lockdown configuration using the following syntax:

lockdown-mode:
  enabled: true
  detections:
    - Privileged-Container
    - Runner-Worker-Memory-Read
    - Reverse-Shell

• Attach the policy to your desired scope (cluster, organization, repository, or workflow)

Supported Detection Types

Detection	Description
Privileged-Container	Blocks containers running with elevated privileges
Runner-Worker-Memory-Read	Blocks unauthorized memory reading attempts
Reverse-Shell	Blocks reverse shell connection attempts

Note: When lockdown mode is enabled and a threat is detected, the job will be immediately terminated and you will receive a notification with details about the blocked threat.

Exempting Workflows from Lockdown Mode

In some cases, you may need to exempt specific workflows from Lockdown Mode — for example, workflows that intentionally run privileged containers for testing or infrastructure provisioning.

To exempt a workflow, create a separate policy with lockdown mode disabled:

lockdown-mode:
  enabled: false

Then attach this policy to the specific scope you want to exempt. The exemption policy can be applied at any level:

• Workflow level — Disables lockdown for a single workflow.

• Repository level — Disables lockdown for all workflows in a repository.

• Organization level — Disables lockdown for all workflows in an organization.

Use the most specific scope possible when creating exemptions. For instance, if only one workflow in a repository needs to run privileged containers, attach the exemption policy at the workflow level rather than disabling lockdown for the entire repository.