Cloud/Settings/Service Accounts
Service Accounts
Identities for the machines: non-human accounts for automations, CI/CD pipelines and OIDC workloads, with rotating keys and no human attached.
Service Accounts answers a question the member list cannot: what identity does your automation use? The description: "Non-human identities for automations, CI/CD and OIDC workloads." Managing them requires org:manage.
Service Accounts
Non-human identities for automations, CI/CD and OIDC workloads.
vsk_live_••••••••3f9aCreated Mar 2025federatedCreated Jun 2025The mockup is the real surface. Rotate a static key to reveal the fresh one, and note the OIDC workload account that carries no key at all.
Two kinds of identity
Create service account offers both kinds:
- Static key: the account holds a generated key, shown once under "Service account key" and masked afterwards, for scripts and pipelines that authenticate with a secret. Rotate key mints a fresh key when the old one may have leaked;
- OIDC workload identity: no stored secret at all. The automation proves who it is through its own OIDC provider, GitHub Actions being the classic case, and the organization trusts that proof. Nothing to leak, nothing to rotate.
One row per account
Each account shows its name, its kind, its masked key or the federated marker, and when it was created. Delete service account removes the identity outright: every automation using it stops authenticating, which is exactly why the button sits behind confirmation.
Why this page exists
Pipelines should never run under a person's account: the day that person leaves, the deployment dies with their credentials. Service accounts give machines their own names, their own keys and their own lifecycle, separate from the humans on Members. They are how the organization's automations survive staffing changes.
What comes next
API Keys is the sibling surface: scoped keys for programmatic access to the organization's resources.