Support for external secret managers

[bbonafed]

Problem

GitHub Agentic Workflows require app: credentials (app-id, private-key) and engine tokens (e.g., COPILOT_GITHUB_TOKEN) to be stored as native GitHub Actions secrets and variables (${{ secrets.* }}, ${{ vars.* }}). In enterprise environments, secrets are managed by external providers like CyberArk Conjur, HashiCorp Vault, or AWS Secrets Manager -- and security policy may prohibit storing secrets directly in GitHub.

The compiled .lock.yml references ${{ secrets.* }} across multiple independent jobs (activation, agent, safe-outputs, conclusion). Since each job runs on a separate runner, a secret-fetching step in one job cannot make values available to the others through the ${{ secrets.* }} context.

Impact

Organizations that manage secrets through external providers (CyberArk Conjur, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) cannot adopt GitHub Agentic Workflows without either violating their secret management policies. A native integration would remove this friction for enterprise adoption.

Environment

• gh-aw version: v0.50.4

[pelikhan]

/scout give me details

[github-actions]

🔍 Scout Research Report

Triggered by @pelikhan

Executive Summary

This issue identifies a real and well-documented friction point for enterprise adoption: GitHub Actions' ${{ secrets.* }} context is job-scoped — each job on a separate runner must independently access its credentials. For gh-aw's .lock.yml which spans multiple independent jobs (activation, agent, safe-outputs, conclusion), this means external secrets must be fetched per-job, and bootstrap credentials (OIDC or a minimal vault token) must still exist somewhere. Research reveals several viable integration patterns, with GitHub OIDC Workload Identity Federation being the modern recommended approach that can minimize what's stored in GitHub Secrets.

Click to expand detailed findings

Research Findings

The Core Technical Constraint

GitHub Actions' secrets context is fundamentally per-job — secrets are resolved by the GitHub platform before a job starts on its runner. There is currently no native mechanism to share dynamically-fetched secrets between jobs running on different runners. Community discussions (#13082, #25225) confirm this is an open problem with no GitHub-native solution.

This means that for any multi-job workflow (like gh-aw's .lock.yml), any external-vault integration must either:

1. Fetch secrets independently in each job, or
2. Use a workaround (encrypted artifacts, pre-populated GitHub secrets)

Integration Pattern 1: OIDC Workload Identity Federation (Recommended)

GitHub Actions supports OpenID Connect (OIDC) — each job can request a short-lived signed JWT from GitHub's OIDC provider. This JWT can authenticate to:

• AWS Secrets Manager / Parameter Store via aws-actions/configure-aws-credentials@v4 with role-to-assume
• Azure Key Vault via federated credentials on App Registrations
• HashiCorp Vault via hashicorp/vault-action@v2 with method: jwt
• CyberArk Conjur via JWT authentication

Key benefit: Zero long-lived secrets stored in GitHub. Each job independently proves its identity via the OIDC JWT. Requires only permissions: id-token: write in the workflow — no ${{ secrets.* }} values needed.

Example using Vault with OIDC (no stored secrets):

permissions:
  id-token: write
  contents: read
steps:
  - name: Import Secrets
    uses: hashicorp/vault-action@v2
    with:
      url: ${{ vars.VAULT_ADDR }}   # non-secret variable
      method: jwt
      role: my-github-actions-role
      secrets: |
        kv/data/gh-aw app_id | APP_ID ;
        kv/data/gh-aw private_key | PRIVATE_KEY ;

Integration Pattern 2: Action-per-Provider (Step-based)

Existing GitHub Actions exist for each major provider:

• HashiCorp Vault: hashicorp/vault-action@v2 (3.8k users, actively maintained, supports JWT/OIDC auth)
• AWS Secrets Manager: aws-actions/configure-aws-credentials@v4 + aws secretsmanager get-secret-value
• Azure Key Vault: Azure/get-keyvault-secrets or azure/login + az CLI
• CyberArk Conjur: cyberark/conjur-action (supports JWT auth)

All of these still require the same fetch-in-each-job pattern — each job runs the provider-specific action to hydrate its local environment.

Integration Pattern 3: secrets: inherit for Reusable Workflows

GitHub supports secrets: inherit for passing secrets from a caller workflow to reusable workflows. However:

• Only works for reusable workflows (called with uses:), not independent parallel jobs
• Does not help for dynamically fetched secrets between jobs
• Useful if gh-aw's compiled workflow could structure some jobs as nested reusable calls

What This Means for gh-aw

The .lock.yml architecture (multiple independent jobs: activation, agent, safe-outputs, conclusion) makes cross-job secret sharing fundamentally hard with current GitHub primitives. Possible implementation approaches for gh-aw:

1. OIDC-first design: Allow users to configure external-secrets: in gh-aw config with a provider type (vault, aws, azure, conjur) and the OIDC role/audience. gh-aw injects a fetch step at the start of each job. Users only need vars.* (non-secret) configuration + OIDC trust set up on their vault side.

2. Custom resolver action hook: Allow users to specify a custom action to run at the start of each job for secret resolution (e.g., secret-resolver: my-org/vault-bootstrap@v1). This gives maximum flexibility without gh-aw needing per-provider implementations.

3. ${{ vars.* }} for non-sensitive config: Vault URLs, role names, namespaces can be vars.* (unencrypted), reducing what needs to be in secrets.* to only the bootstrap credential (or nothing with OIDC).

Recommendations

• Prioritize OIDC/JWT-based authentication as the target model — it's the only approach that can work without any GitHub-stored secrets and works per-job independently
• Consider a "secret-resolver hook" in the gh-aw job template — a user-supplied action that runs as the first step of every job to populate environment variables from their vault
• Document the OIDC path for each supported provider even before native integration — many enterprise teams can adopt this today with existing tools
• Explore whether jobs can be restructured as nested reusable workflows (using secrets: inherit) rather than fully independent jobs — this could enable secret-passing without changing secret sources

Key Sources

• GitHub Actions OIDC Overview
• hashicorp/vault-action — GitHub Actions integration
• [HashiCorp: Retrieve Vault secrets from GitHub Actions (OIDC pattern)]((developer.hashicorp.com/redacted)
• GitHub Community: Sharing secrets between jobs
• GitHub Docs: Reuse workflows (secrets: inherit)

Suggested Next Steps

1. Confirm whether gh-aw's multi-job structure could accommodate a per-job "secret bootstrap" step (e.g., injected first step in each job template)
2. Prototype an OIDC-based Vault integration for the activation job as a proof of concept
3. Survey users to understand which external vault providers are most commonly needed (Vault, CyberArk, AWS SM, Azure KV)
4. Consider a design where only a minimal bootstrap secret (or nothing with OIDC) is stored in GitHub, with all other credentials fetched at job start

References:

• §22454350847

🔭 Intelligence gathered by Scout