What is a service account?

A service account is an account that belongs to an application, a server or a pipeline rather than to a person, so the software can authenticate and be granted permissions in its own name, and its access can be reviewed, limited and revoked separately from anyone's personal account.

How clouds define it

Google Cloud's definition is typical: "a special kind of account typically used by an application or compute workload … rather than a person", identified by an email address (Google Cloud). AWS has IAM roles for the same purpose; Git hosts have bot accounts and app installations; many SaaS tools have API-only users.

What makes a service account useful is the separation. Actions taken by the deploy pipeline show up as the pipeline, not as whichever engineer set it up. When that engineer leaves, the pipeline keeps working.

How it authenticates

This is where service accounts get risky. There are broadly two ways:

• Attached or federated identity. The platform vouches for the workload. Google calls attaching a service account to the resource running the application "the most common way" to authenticate as one, and workload identity federation does the same for workloads outside Google Cloud. The credentials are short-lived and are not stored with the software.
• A key. A key file or token you download and give to the software. Google warns that "service account keys are a security risk if not managed correctly" and that you "should choose a more secure alternative to service account keys whenever possible."

A downloaded key turns a well-scoped identity back into a long-lived secret that can be copied, committed or left on a laptop.

Common mistakes

• People using service accounts. A developer signing in with the app's credentials to "check something" erases the audit trail. OWASP lists this as "Human Use of NHI" in its Non-Human Identities Top 10.
• One account for everything. A single service account for tests, builds and production gives the test job production power.
• Owner or editor roles "to get it working". They stay.
• Keys without an owner. Nobody knows which servers hold copies.

Service accounts and Crunu

Crunu's equivalent for CI is the service token, and for servers the machine. Both are identities in their own name, separate from members.

A service token is created entirely in an admin's browser and shown once; the server receives only its public keys, so the server can't recover or reissue the token from its database. It is granted only the environments the pipeline needs, and can have a lease, a usage limit and network restrictions. With a CI binding (OIDC), it works only together with a matching JWT from the CI job, which brings back the "platform vouches for the workload" property for a credential that is otherwise stored.

permissions:  id-token: write  contents: readsteps:  - name: Deploy to staging    env:      CRUNU_TOKEN: ${{ secrets.CRUNU_TOKEN }}      CRUNU_SERVER: ${{ vars.CRUNU_SERVER }}    run: exec crunu run --env web-app/staging -- npm run deploy

$ exec crunu run --env web-app/staging -- npm run deploy> web-app@1.8.0 deploy> node scripts/deploy.mjs stagingstaging deploy finished

Crunu doesn't create or manage service accounts in your cloud. For giving pipelines cloud access without keys, see CI/CD secrets with OIDC.

Sources

• Google Cloud: Service accounts overview, checked October 30, 2026.
• OWASP Non-Human Identities Top 10 (2025), checked October 30, 2026.