Skip to content
Tutorials
Service Identities

Service Identities

A Service Identity is a non-human identity in Britive — used by automation, CI/CD pipelines, scripts, scheduled jobs, and workloads instead of a person. Where a User logs in interactively (often with SSO and MFA), a Service Identity authenticates programmatically with a token, then checks out profiles and credentials the same way a user does.

This series walks through service identities from the ground up. It will grow over time — start here and check back for new parts.

Why Service Identities

  • No shared human accounts for automation. Pipelines and jobs get their own identity, so activity is attributable in the audit log (actor.type = ServiceIdentity).
  • Just-in-time, not standing secrets. A service identity checks out short-lived credentials at run time instead of holding long-lived cloud keys.
  • Same governance as users. Assign access through tags, profiles, and policies — including approval and time-of-access conditions.

Service Identities are for machines. For people, use Users (with your identity provider). Don’t share a service identity token across unrelated workloads — create one per workload so access and audit stay clean.

In This Series

Getting Started
What a service identity is, how to create one, assign access, and authenticate from the CLI or API.

Planned

More parts are on the way:

  • Authentication methods — static API tokens vs. token-based federation (OIDC workload identity, e.g. GitHub Actions).
  • Service identities in CI/CD — wiring one into a pipeline for keyless cloud access.
  • Governing service identities — tags, policies, approvals, and rotation.
  • Auditing & alerting — tracking service-identity activity (see SIEM Recommended Alerts).
Last updated on