A service account, sometimes called a machine user, is an identity used by automation rather than controlled by one person. It lets pipelines keep working when an employee changes teams or leaves. Where an organizational token is unavailable, using a personal access token instead can make automation depend on that person’s continuing access. Keep service-account credentials in a team secrets store so the identity is managed as a team resource. section 6.2.1
For cloud infrastructure pipelines, separate the identity from its permissions. In the AWS pattern, a service account has permission to assume a role; the role grants the actions a particular pipeline needs. Give each pipeline a dedicated role limited to the resources it manages. Keep corresponding roles consistent across platform accounts to reduce complexity without giving every pipeline the same access. section 6.4.4 section 6.5
Make the identity lifecycle part of the platform workflow:
- During team onboarding, provision the team’s secrets space and permissions alongside any service account needed by its pipelines or deployment integrations. section 6.2.2
- Start with the minimum service-account configuration needed to run infrastructure pipelines, then let those pipelines manage accounts, roles, and credentials. section 6.4.4 section 6.5
- Automate credential rotation. In the AWS example, the secrets store holds the newest credential while the previous one remains valid until the next rotation, avoiding disruption to jobs already running. section 6.4.4
Figure 6.19 Our service account has two valid credentials at any given time. Only the latest credential is maintained in the secrets store, and the prior keys remain valid until the next rotation to prevent workloads and orchestration from failing due to the race condition of the key being changed while a job is already in process.
The rotation diagram shows why replacing a stored credential need not immediately invalidate the key an in-progress job may still be using. section 6.4.4
A service account is not the only automation identity pattern. OIDC trust can connect tools and cloud resources directly, but it takes additional integration work to make that experience self-service. Choose the pattern your tools support, and account for provisioning, permission boundaries, credential management, and rotation rather than leaving those tasks to individual developers. section 6.2.1 section 6.2.2
