Identity and Access
Identity is the control plane of modern infrastructure. Users, services, CI jobs, workloads, and automation all need identities. DevOps failures often begin when a broad credential is copied into a pipeline, stored as a long-lived secret, and forgotten.
Least Privilege
Least privilege means granting only the permissions needed, for the shortest reasonable time, with auditing. It is not just a security phrase. It reduces blast radius when automation misbehaves. A deploy job may need permission to update one service, not administer the whole cluster.
Workload Identity
Modern platforms increasingly prefer federated or workload identity over static secrets. A CI job can exchange a short-lived token for cloud access based on repository, branch, workflow, and environment policy. This reduces secret storage but raises the importance of protecting pipeline definitions.
Human Access
Production access should be explicit, logged, time-limited, and tied to incident or change context. Break-glass access is necessary, but it should be rare enough that every use is reviewed.
Service-to-Service Access
Service identity should be as deliberate as human identity. A service that can read every database because it runs in a trusted subnet is overprivileged. Modern platforms can issue workload-specific identities and attach policies to those identities. This enables finer authorization and better audit trails.
Authentication proves who is calling. Authorization decides what that caller may do. DevOps systems need both. A valid CI job identity should still be limited to the repository, branch, workflow, and environment it is allowed to affect.
Access Reviews
Permissions drift over time. Temporary exceptions become permanent, old service accounts remain active, and former teams keep access to resources they no longer own. Regular access review is operational maintenance. The review should focus on high-risk permissions first: admin roles, production data, secret stores, billing, identity management, and deployment authority.
Example: Break-Glass Design
A break-glass role might require multi-factor authentication, ticket reference, short duration, session logging, and post-use review. The purpose is not to make emergency access impossible. The purpose is to make emergency access accountable and rare.
Study Task
Create an access matrix for one deployment path. List humans, CI workflows, runtime services, secret stores, artifact registries, clusters, and cloud roles. For each permission, write why it exists and how it is revoked.
Operational Review
Identity should be reviewed whenever ownership, architecture, or automation changes. A new service, repository transfer, team reorganization, or CI workflow can leave stale permissions behind. Access review is not suspicion; it is hygiene for a system where credentials are powerful.
The review should pay special attention to privilege escalation paths. A user who can edit a workflow that has deployment credentials may effectively have deployment access. A service that can read a secret store and create pods may be able to impersonate other workloads. Real access is the set of actions a principal can cause, not only the role name it holds.
Strong identity design is visible in incident response. When something suspicious happens, the team should know which identity acted, from where, using which permission, and how to disable it quickly.
A CI workflow deploys one web service but uses a cloud token that can create users, delete networks, and administer databases.