This action federates the GitHub Actions identity token for a GitHub App token according to the Trust Policy in the target organization or repository.

Consider the following workflow in my-org/my-repo:

permissions:
  id-token: write # Needed to federate tokens.

steps:
  - uses: DataDog/dd-octo-sts-action@main
    id: octo-sts
    with:
      scope: your-org/your-repo # the target repository
      policy: foo # policy filename excluding `.sts.yaml`

  - env:
      GITHUB_TOKEN: ${{ steps.octo-sts.outputs.token }}
    run: |
      gh repo list

The above will load a "trust policy" from .github/chainguard/foo.sts.yaml in the repository your-org/your-repo. Suppose this contains the following, then workflows in my-org/my-repo will receive a token with the specified permissions on my-org/my-repo.

issuer: https://token.actions.githubusercontent.com
subject: repo:my-org/my-repo:ref:refs/heads/main

permissions:
  contents: read
  issues: write

Org-wide permissions are accessible by only providing the GitHub organization name as scope and referencing a policy in your-org/.github repo under .github/chainguard/.

The action supports application pools, which distribute requests across multiple GitHub App installations for better throughput and rate limit isolation.

To use the pool endpoint, add the pool_name input:

permissions:
  id-token: write # Needed to federate tokens.

steps:
  - uses: DataDog/dd-octo-sts-action@main
    id: octo-sts
    with:
      scope: your-org/your-repo
      policy: foo
      pool_name: dd-octo-sts

  - env:
      GITHUB_TOKEN: ${{ steps.octo-sts.outputs.token }}
    run: |
      gh repo list

The scope input works the same for both endpoints:

• your-org/your-repo for repository-scoped tokens
• your-org for organization-scoped tokens

For enterprise-scoped tokens, use scope_enterprise instead of scope:

- uses: DataDog/dd-octo-sts-action@main
  id: octo-sts
  with:
    scope_enterprise: your-enterprise
    policy: foo
    pool_name: dd-octo-sts

If you need to target a specific application rather than a random one from the pool, use application_id instead of pool_name:

- uses: DataDog/dd-octo-sts-action@main
  id: octo-sts
  with:
    scope: your-org/your-repo
    policy: foo
    application_id: your-app-id