> ## Documentation Index
> Fetch the complete documentation index at: https://synthetiq.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Service Account

> Create the Synthetiq service account CI uses to apply infrastructure changes

`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**.

<Warning>
  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](/docs/platform-docs/deployments/byoi/ci-integration).
</Warning>

## Create it

1. Find the id of the built-in **CI Provision Apply** role:

```bash theme={null}
synthetiq role list
```

2. Create the service account — prints the service account's id on creation:

```bash theme={null}
synthetiq service-account create infra-apply \
  --role-id <role-id>
```

<Note>
  Running `service-account create` requires the `org:service-accounts` scope in your Synthetiq organization. Contact your admin if you do not have it.
</Note>

3. Create the trust on it — tokens matching this issuer and subject authenticate as the service account:

```bash theme={null}
synthetiq trust create \
  --service-account-id <service-account-id> \
  --issuer https://token.actions.githubusercontent.com \
  --subject "repo:acme/infra:ref:refs/heads/main"
```

<Note>
  Running `trust create` requires the `org:trusts` scope in your Synthetiq organization. Contact your admin if you do not have it.
</Note>

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.