Machine Identity and Workload Authentication

Machine identity, secrets, and workload authentication cover the non-human side of IAM: service accounts, bots, automation pipelines, certificates, API keys, token exchange, and platform-issued workload credentials. This chapter focuses on where machine access goes wrong in real systems and how to design it so ownership, rotation, scope, and auditability are built in rather than patched on later.

Read the chapter in order. The first lesson explains why service accounts are often riskier than teams realize. The second distinguishes secrets, keys, and certificates, and shows why lifecycle discipline matters more than storage alone. The third explains workload identity and ephemeral credentials as the modern replacement for embedded long-lived machine secrets. The fourth covers CI/CD, automation, and bot access, where high-privilege non-human identities often accumulate quietly.

This chapter connects directly to privileged access, logging and governance, cloud control planes, and zero-trust access design. If your team treats machine credentials as “just configuration,” this is the chapter that should correct that assumption.

In this section

• Service Accounts and Their Risks
  Service accounts let software act without a human login, but they often become invisible, overprivileged, weakly owned identities with long-lived credentials.
• Secrets, Keys, Certificates, and Rotation
  Machine authentication depends on different credential types with different trust models, storage requirements, and rotation implications.
• Workload Identity and Ephemeral Credentials
  Workload identity lets platforms issue short-lived machine credentials based on trusted runtime context instead of static embedded secrets.
• CI/CD, Automation, and Bot Access
  Pipelines, deployment systems, and bots are high-value machine identities that need scoped permissions, strong separation, and short-lived credentials.