Sync to GitHub Actions

- uses: seekritdev/github-action@v1
  with:
    token: ${{ secrets.SEEKRIT_TOKEN }}
    app: storefront
    env: production

When to sync anyway

GitHub resolves some things before any step of yours could run, so no Action can supply them. Those are the cases this connector is for:

• A third-party action that takes a credential as a with: input — the value is interpolated from the secrets context when the step is created.
• secrets: inherit into a reusable workflow, which passes the calling workflow's secrets context wholesale.
• Job-level container: and services: credentials, resolved before the job's first step.
• Dependabot and Codespaces, which read their own secret stores and run no workflow you control. (Those are separate GitHub APIs; this connector writes Actions secrets only.)

If your situation is not one of these, use the Action.

1. Create a token

Prefer a fine-grained personal access token with the Secrets repository permission set to Read and write, scoped to only the repositories this connection syncs. For organization secrets, it needs the organization Secrets permission instead.

A classic token needs repo — or admin:org for organization secrets — which grants vastly more than writing secrets. Use fine-grained where you can.

printf '%s' "$GITHUB_TOKEN" \
  | seekrit sync connect --name acme-github --provider github-actions

A github.com connection has no second half to state: a GitHub token addresses everything by owner/repo or org, and those are the binding's business. For a self-hosted GitHub Enterprise Server appliance, add --base-url https://github.acme.com/api/v3. Leave it off for github.com and for Enterprise Cloud. It must be https — that URL carries the token.

2. Bind an environment

GitHub has three secret scopes, and a binding picks one. They are three different endpoints with three different blast radii — and each has its own encryption key, so a value sealed for one cannot be written to another.

A repository's secrets

Readable by every workflow in it, including one added by a pull request from a collaborator with write access. That is GitHub's model, not seekrit's — and it is the reason to prefer the environment scope for anything touching production.

seekrit sync verify acme-github --provider github-actions \
  --gh-repo acme/storefront

seekrit sync enable --connection acme-github --provider github-actions \
  --gh-repo acme/storefront \
  --app storefront --env production --acknowledge-decryption

--gh-repo takes the pair as one flag, because that is how GitHub writes a repository everywhere; asking for it in two invites pasting the pair into one of them.

A deployment environment's secrets

The narrowest scope GitHub has, and the one to prefer:

seekrit sync enable --connection acme-github --provider github-actions \
  --gh-repo acme/storefront --gh-environment production \
  --app storefront --env production --acknowledge-decryption

A job reads these only by declaring environment: production, which also subjects it to that environment's protection rules — required reviewers, wait timers, and the branch policy. That combination is as close as GitHub gets to "this secret is for production, and reaching it takes an approval".

The environment must already exist. seekrit will not create one: an environment is a deployment gate, and silently creating an unprotected one because a name was misspelled would quietly remove the protection you were relying on.

An organization's secrets

The widest scope in the product, and the only destination on any provider that can hand a value to repositories nobody named.

seekrit sync enable --connection acme-github --provider github-actions \
  --gh-org acme --gh-visibility selected --gh-repo-ids 1296269,1296270 \
  --app storefront --env production --acknowledge-decryption

How a push behaves

• The value is encrypted before it leaves seekrit. GitHub does not accept a plaintext secret: each value is sealed to the scope's own X25519 public key as a libsodium sealed box, and GitHub decrypts it on receipt.

  One nice consequence: GitHub never sees a plaintext value at all, so it cannot echo one back into an error message — the failure reasons stored on a run row cannot carry a secret value even in principle. Other connectors scrub responses for exactly that reason; here there is nothing to scrub.

• Each scope has its own key, fetched once per run. A value sealed for a repository cannot be written to that repository's production environment, or to its organization — the three are different recipients. So a run is one GET for the key, then one PUT per name.

• A run is capped at 150 operations, sized against GitHub's secondary rate limit rather than its primary one: 900 points a minute, where a GET costs 1 and a PUT or DELETE costs 5. That is 180 mutating requests a minute, well below the 5,000-an-hour primary limit.

• seekrit cannot detect value drift here, only presence. Actions secrets are write-only: once set, no one can read a value back through the UI, CLI, or API — which is what you want for something a secrets manager owns.

Values take effect on the next workflow run; a sync run starts nothing.

Name and value rules

Troubleshooting

See also

• seekritdev/github-action — the option to prefer
• CI/CD & containers — wiring seekrit into pipelines without a copy at the destination
• Third-party sync — the shared model, naming and filtering, deletions