Skip to main content
synthetiq infra provision registers the infrastructure with your Synthetiq organization, so it runs with a Synthetiq identity. Locally that’s your own login. In CI it’s a service account — a machine member of your org — authenticated via an OIDC trust: no stored token, the workflow exchanges its GitHub-issued token for a short-lived Synthetiq token on each run. You need one service account, on the built-in CI Provision Apply role (holds the Synthetiq platform’s infra:provision scope), trusted for your infra repo’s main branch.
Do not create a trust for the pull_request subject. PR branches control their own workflow files, so the PR context must never map to a Synthetiq identity — synthetiq infra generate doesn’t need one. See CI Integration.

​
Create it

  1. Find the id of the built-in CI Provision Apply role:
synthetiq role list
  1. Create the service account — prints the service account’s id on creation:
synthetiq service-account create infra-apply \
  --role-id <role-id>
Running service-account create requires the org:service-accounts scope in your Synthetiq organization. Contact your admin if you do not have it.
  1. Create the trust on it — tokens matching this issuer and subject authenticate as the service account:
synthetiq trust create \
  --service-account-id <service-account-id> \
  --issuer https://token.actions.githubusercontent.com \
  --subject "repo:acme/infra:ref:refs/heads/main"
Running trust create requires the org:trusts scope in your Synthetiq organization. Contact your admin if you do not have it.
Any OIDC issuer works (GitHub Enterprise Server, GitLab, Buildkite); the subject is matched exactly. Token signatures are verified one of two ways:
  • Default — keys are fetched from the issuer’s OIDC discovery endpoint, which must be reachable from the Synthetiq platform. Key rotation is handled automatically. The right choice for public issuers like GitHub.com.
  • Static keys — pass --jwks <path> with a JWK Set file ({ "keys": [...] }) of the issuer’s signing keys, validated when the trust is created. Verification uses only these keys and never contacts the issuer — for issuers the platform can’t reach, such as a firewalled GitHub Enterprise Server. Update the trust when the issuer rotates its keys.