What Is a Service Account?
A service account is an identity that belongs to a system rather than a person - the account your CI pipeline authenticates as when it deploys or calls APIs.
Automation needs an identity. Reusing a real person's credentials is risky and breaks when they leave. A service account is a dedicated non-human identity for a workload, with its own permissions and credentials scoped to what that workload does.
Service account vs user account
A user account represents a person and is tied to that human. A service account represents a program - a CI pipeline, a deploy job - and is owned by the team, not an individual, so it survives staff changes.
How CI uses one
The pipeline authenticates as the service account (ideally via OIDC, otherwise via a key) and acts within that account's permissions. Scope those permissions to the pipeline's actual needs.
A small example
A deploy pipeline impersonates a ci-deployer service account that can update one service and read one secret - nothing else. If the pipeline is compromised, the attacker inherits only that narrow access, not a human admin's.
Securing service accounts
- Apply least privilege - grant only what the workload requires.
- Prefer keyless auth (OIDC / federation) over long-lived keys.
- Audit usage and rotate any keys regularly.
One account per purpose
Give each pipeline or environment its own service account rather than sharing one. Separate identities make access easy to scope, audit, and revoke without affecting unrelated workloads.
Key takeaways
- A service account is a non-human identity used by automation.
- It is owned by a team, not a person, so it outlives staff changes.
- Secure it with least privilege and keyless authentication.