4. Identity, Access, Secrets and Cryptographic Controls

Introduction and Context

DevSecOps treats security as an engineering property of the delivery system rather than as a final inspection activity. Among the most consequential security properties are identity, access, secrets, and cryptographic controls. A vulnerable library may affect one application component; an overprivileged deployment identity or exposed signing key may affect an entire environment. Consequently, control over “who or what may perform which action, on which resource, under what conditions” is central to secure software delivery.

Modern pipelines contain human users, service accounts, build runners, containers, cloud workloads, repositories, registries, clusters, databases, certificates, tokens, and cryptographic keys. These entities interact across organizational and cloud boundaries. Traditional perimeter assumptions are therefore insufficient. Security must authenticate each actor, authorize each action, protect sensitive material, and create evidence that access was appropriate.

This chapter develops an integrated approach to identity and cryptographic governance in DevOps pipelines. It connects least privilege with IAM, RBAC and ABAC, federation and MFA, workload identities, privileged access management, secrets vaults, rotation, PKI, encryption, and machine-identity governance. The objective is not merely to list controls, but to show how they operate as a coherent system.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish authentication, authorization, accounting, identity governance, and cryptographic control.

2. Design least-privilege access using IAM, RBAC, ABAC, federation, MFA, and privileged access management.

3. Select suitable identities for people, pipelines, services, containers, and cloud workloads.

4. Design a secrets-management lifecycle involving vaulting, issuance, rotation, revocation, and monitoring.

5. Explain the functions of encryption, hashing, digital signatures, certificates, PKI, and key management.

6. Evaluate trade-offs, risks, and governance requirements in a DevSecOps identity architecture.

Identity as a Security Control Plane

An identity is a recognized representation of a human, service, device, workload, or organization. Authentication establishes confidence that an entity is the claimant associated with an identity. Authorization determines what that identity may do. Accounting records what occurred, when, and under which identity. These functions are often summarized as identification, authentication, authorization, and accountability, although practical systems also require lifecycle governance.

Identity governance covers creation, approval, modification, review, suspension, and deletion. A joiner–mover–leaver process is particularly important for employees and contractors. The same principle applies to machines: a workload should receive an identity when deployed, have its permissions adjusted when its function changes, and lose access when it is retired.

Least privilege means granting only the permissions necessary for a defined task, for the minimum practical duration, through the appropriate identity. It is not equivalent to granting broad access and asking users to behave carefully. Least privilege reduces blast radius, limits accidental changes, and makes audit findings more meaningful. It is also dynamic: a permission appropriate during an incident may be inappropriate during normal operations.

A useful access decision can be represented as:

Permit = authenticated identity + permitted action + target resource + valid context + policy compliance.

Context may include environment, time, network location, device posture, ticket number, deployment stage, data classification, or workload attestation.

IAM Models: RBAC, ABAC and Policy-Based Access

Role-based access control (RBAC) assigns permissions to roles and roles to identities. For example, a “release engineer” role may deploy to a staging cluster, while a “production approver” role may authorize a production release. RBAC is understandable and administratively efficient, particularly where job responsibilities are stable. Its weakness is role explosion: combinations of team, application, environment, and region can produce hundreds of narrowly tailored roles.

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might permit a workload to read a database secret only when the workload belongs to the payments service, runs in production, and is deployed from an approved image. ABAC is expressive and supports contextual decisions, but policy reasoning and testing become more difficult.

Many cloud platforms use policy-based systems combining RBAC and attributes. Effective authorization is commonly the result of identity policies, resource policies, organizational restrictions, explicit denies, and environmental conditions. A sound design therefore includes policy simulation, peer review, automated tests, and periodic access analysis rather than relying on role names alone.

Access should be separated by environment. Development identities should not automatically possess production privileges. Human approval and automated deployment should be represented by distinct identities, and a deployment process should not be able to approve its own high-risk change. Separation of duties is a governance principle that reduces the possibility of fraud, error, or uncontrolled release.

Federation, MFA and Privileged Access

Federation allows an organization to use a trusted identity provider to authenticate users to multiple services. Standards such as SAML and OpenID Connect support federated sign-on, while OAuth 2.0 is primarily an authorization framework for delegated access. Federation reduces local passwords and centralizes lifecycle actions, but trust relationships must be governed carefully. Claims, audience restrictions, token lifetime, signing keys, and account-provisioning rules require explicit design.

Multi-factor authentication combines independent factors, commonly something known, possessed, or inherent. Phishing-resistant methods, such as hardware security keys using modern public-key protocols, are generally stronger than one-time codes delivered through easily compromised channels. MFA should be mandatory for administrative access, cloud consoles, source-code repositories, CI/CD controls, and secrets-management systems. Emergency access accounts should be few, strongly protected, monitored, and tested without becoming permanent bypasses.

Privileged access management (PAM) governs high-impact permissions. It may provide just-in-time access, approval workflows, credential isolation, session recording, command restrictions, and automatic expiry. A mature PAM design avoids permanent administrator accounts. It also distinguishes emergency access from routine administration and ensures that emergency use triggers review.

Workload Identity in Automated Pipelines

A workload identity is a non-human identity assigned to a process, service, job, or deployment workload. The central design question is whether a workload can prove what it is without receiving a long-lived password. In a secure pipeline, a build runner obtains a short-lived token from an identity provider, exchanges it for narrowly scoped cloud access, and loses that access when the job ends.

Static cloud keys stored in CI variables are dangerous because they may be copied into logs, artifacts, forks, caches, or developer machines. Federated workload identity reduces this exposure by binding access to claims such as repository, branch, workflow, commit, runner, namespace, or service account. Those claims must be constrained. “Any job from this repository” may be too broad if untrusted pull requests can execute code.

Workload identity also applies inside orchestration platforms. A pod should use a service account associated with its service, not a shared administrator account. The service account should be permitted to access only required APIs and secrets. Network controls, image provenance, runtime restrictions, and workload attestation can strengthen the identity decision, but they do not replace authorization policy.

Machine identities create scale problems. Organizations should maintain an inventory of service accounts, certificates, keys, tokens, owners, purposes, environments, expiration dates, and dependencies. Ownership must be a team or accountable role rather than an unavailable individual. Unused identities should be detected and retired.

Secrets: From Storage to Lifecycle Management

A secret is sensitive data used to authenticate, authorize, or establish trust. Examples include passwords, API tokens, private keys, database connection strings, signing credentials, recovery codes, and encryption keys. Encoding is not encryption, and storing a secret in a private source repository is not secure secrets management.

A secrets vault provides controlled storage, access policies, encryption, audit events, versioning, and often automated issuance and rotation. Applications should retrieve secrets at runtime through an authenticated mechanism rather than embedding them in source code, container images, configuration files, or pipeline definitions. Secret values should be prevented from appearing in logs and diagnostic traces.

A robust secrets lifecycle includes:

• discovery and classification of existing secrets;
• ownership, purpose, scope, and expiry metadata;
• secure generation using appropriate randomness;
• controlled distribution through short-lived access;
• monitoring and audit of retrieval and use;
• rotation before or at expiry;
• revocation after suspected compromise; and
• secure deletion and confirmation of retirement.

Rotation is not merely changing a value on a calendar. It requires updating dependent consumers, validating the new credential, preserving controlled overlap where necessary, and revoking the old credential. Automatic rotation is valuable, but it can cause outages if dependencies are unknown. Rotation must therefore be tested as an operational process.

Secret scanning in repositories and artifacts is useful for detection, not permission to store secrets there. Preventive controls should include pre-commit hooks, push protection, CI scanning, redaction, limited log retention, and rapid revocation. If a secret is exposed, deleting the line from the latest commit does not make the secret safe; the credential must be revoked or rotated and historical copies considered.

Cryptographic Controls and PKI

Cryptography supports confidentiality, integrity, authentication, and non-repudiation-related assurance. Symmetric encryption uses one shared secret and is efficient for data protection. Asymmetric cryptography uses public and private keys and supports key exchange, digital signatures, and identity binding. Hash functions create fixed-length integrity values but do not provide confidentiality. Passwords should be protected with slow, salted password-hashing schemes rather than ordinary hashes.

Encryption in transit protects communications between users, pipeline components, registries, APIs, and workloads. Encryption at rest protects storage media, databases, backups, artifacts, and state files. Application-level or field-level encryption may be required when storage administrators should not see particular values. Encryption does not eliminate authorization: a stolen decryption capability can defeat otherwise strong encryption.

Key management includes generation, storage, distribution, use, rotation, backup, recovery, revocation, and destruction. Keys should be held in a hardware-backed or strongly protected key-management service where risk justifies it. Key-encryption keys and data-encryption keys may be separated to limit exposure. Access to key operations should be logged and restricted independently from access to encrypted data.

Public key infrastructure (PKI) binds public keys to identities through certificates issued by a certificate authority (CA). A certificate chain allows a relying party to validate that a certificate was issued by a trusted authority and remains valid for its intended purpose. Certificate governance includes inventory, subject naming, SAN values, validity periods, renewal, revocation, trust-store management, and private-key protection.

TLS certificates, code-signing certificates, workload certificates, and internal service certificates have different uses and risk profiles. Code signing can establish that an artifact was signed by an approved publisher and was not altered after signing, but it does not prove that the code is safe. Signing keys therefore require strong protection, restricted use, and auditable release procedures. Short-lived certificates and automated renewal reduce operational risk, provided monitoring detects failed renewal.

A Reference Control Architecture

A practical DevSecOps identity architecture can be designed in layers. The enterprise identity provider authenticates people and issues federated claims. A privileged access layer governs administrative elevation. The cloud or platform IAM layer evaluates roles, resource policies, and conditions. Workload identity binds pipeline jobs and services to short-lived credentials. A secrets and key-management layer protects sensitive material. PKI establishes certificate-based trust. Finally, centralized logging and analytics provide accountability.

The architecture should enforce several boundaries: separate development, testing, and production accounts or subscriptions; isolate build and release functions; restrict artifact publication; require approval for high-risk production actions; and prevent a single pipeline credential from controlling source, build, deployment, secrets, and audit systems simultaneously.

Policy should be treated as code where appropriate. Policies can be peer-reviewed, versioned, tested against positive and negative cases, scanned for dangerous wildcards, and deployed through controlled workflows. Automated analysis can identify unused permissions, privilege escalation paths, stale accounts, exposed secrets, certificate expiry, anomalous token use, and unusual geographic or temporal patterns. Automation supports governance but does not remove the need for accountable owners and human judgment.

Applied Case: Securing a Multi-Cloud Release Pipeline

Background

The following is an illustrative case. Meridian Payments operates services across two public clouds and a managed Kubernetes platform. Its CI/CD system used shared administrator credentials stored as encrypted pipeline variables. Developers occasionally received production access to troubleshoot incidents. Certificates were renewed manually, and a source-scanning tool had detected tokens without consistently revoking them.

Situation and Analysis

An internal review identified excessive privilege, weak separation of duties, uncertain credential ownership, and limited evidence of who approved production changes. The shared credentials made attribution difficult and created a large blast radius. Long-lived tokens could be copied by any process able to read the pipeline environment. Manual certificate renewal created a foreseeable availability risk.

The review categorized identities by function: developer, build job, release controller, runtime workload, administrator, and emergency responder. It mapped each identity to resources, actions, environment, owner, and required duration. This exercise revealed that build jobs needed to publish signed artifacts but did not need production database access, while runtime services needed selected secrets but not source-repository administration.

Strategy and Solution

Meridian adopted federation for human access and required phishing-resistant MFA for privileged roles. Production administration moved to PAM with approval, just-in-time elevation, session logging, and automatic expiry. Development and production were separated into distinct administrative boundaries.

CI jobs exchanged short-lived federated tokens based on repository, workflow, branch, and environment claims. Pull-request jobs could test code but could not obtain production credentials. A release identity could deploy only approved, signed artifacts to the designated production cluster. Runtime workloads received separate service identities with narrowly scoped permissions.

Secrets were migrated to a vault. Applications retrieved versioned secrets at runtime, while database credentials were dynamically issued where supported. Existing exposed tokens were revoked, not merely deleted from source history. Certificates moved to automated issuance and renewal, with alerts for failed renewal and a documented emergency process.

Policies were stored and reviewed as code. Automated tests checked that no production role contained unrestricted administrative actions, that build identities could not approve their own releases, and that dormant identities were reported. Centralized logs connected user identity, workflow run, artifact digest, deployment, approval, and runtime access.

Outcome and Learning Points

The redesigned system reduced standing privilege and improved attribution. More importantly, it changed security from a collection of manually remembered practices into an enforceable delivery architecture. The migration also exposed operational dependencies that had been hidden by shared credentials.

The principal lessons are that least privilege must be designed around tasks, workload identities should be short-lived and claim-constrained, secret rotation must be operationally tested, and cryptographic controls require lifecycle ownership. Strong tools cannot compensate for unclear accountability or excessive trust between pipeline stages.

Risks, Limitations and Common Mistakes

Least privilege can be implemented so rigidly that teams create unsafe workarounds. Excessive approval steps may encourage credential sharing or bypasses. Access design should therefore distinguish high-risk actions from routine automation and provide fast, auditable emergency procedures.

Common mistakes include wildcard permissions, shared service accounts, permanent administrator access, unbounded trust in CI runners, secrets in logs, untested rotation, certificates with unmanaged private keys, and failure to remove access when staff or workloads leave. Another mistake is confusing authentication with authorization: proving that a process is genuine does not mean it should access every resource.

RBAC may become unmanageable when roles encode every exception, while ABAC may become opaque when policies depend on unverified or poorly governed attributes. Both require documentation, testing, monitoring, and periodic review. Cryptography also has limitations: weak key protection, incorrect certificate validation, insecure randomness, and poor recovery planning can undermine technically sound algorithms.

Governance, Ethics and Professional Responsibility

Identity systems process personal and behavioral data, including login records, administrative sessions, location indicators, and access histories. Monitoring should be proportionate, transparent, access-controlled, and retained according to legal and organizational requirements. Security teams must avoid collecting more information than necessary and must protect audit data itself.

Governance should assign owners for identities, roles, secrets, keys, certificates, policies, and exceptions. Exceptions should have a business justification, risk acceptance, compensating controls, expiration date, and approving authority. Regulatory obligations may require strong authentication, segregation of duties, evidence of access review, encryption, retention controls, or demonstrable incident response. Professional judgment is required because compliance is a floor, not a complete security design.

Current Developments and Best Practices

Zero-trust architectures increasingly treat identity, device posture, workload claims, and transaction context as inputs to every access decision. Short-lived credentials, passwordless authentication, software supply-chain signing, confidential computing, and automated certificate management are becoming more practical. Machine identity is expanding rapidly as microservices, ephemeral runners, infrastructure automation, and AI-enabled services create large numbers of non-human principals.

Recommended practice is to inventory identities; eliminate shared accounts; separate human and workload access; prefer federation and short-lived credentials; require strong MFA; isolate environments; constrain policies by resource and context; vault and rotate secrets; protect keys with appropriate hardware-backed services; automate certificate lifecycle; test access policies and recovery procedures; monitor privilege use; and review both effectiveness and operational impact.

Chapter Summary

Secure DevOps pipelines depend on a connected control system for identity, authorization, secrets, and cryptography. IAM establishes who may act; RBAC and ABAC express permissions; federation and MFA strengthen human access; PAM controls elevated activity; and workload identities replace many long-lived machine credentials. Vaults and lifecycle processes protect secrets, while encryption, key management, digital signatures, certificates, and PKI protect data and establish trust. Effective governance requires least privilege, separation of duties, short-lived access, inventory, ownership, monitoring, automated testing, and tested rotation and recovery. The strongest architecture is one that reduces blast radius without driving users toward insecure workarounds.

Key Terms

Identity: A recognized representation of a human, workload, device, or service.

Authentication: Verification that a claimant controls or represents an identity.

Authorization: A decision about whether an identity may perform an action on a resource.

Least privilege: Granting only the minimum necessary access for the required time.

IAM: Processes and technologies for managing identities, authentication, authorization, and access governance.

RBAC: Access control based on roles associated with job functions or responsibilities.

ABAC: Access control based on attributes of subjects, resources, actions, and context.

Federation: Trust that allows one identity provider to authenticate users to another service.

MFA: Authentication using two or more independent factor categories.

PAM: Governance of privileged access through controls such as approval, elevation, and session monitoring.

Workload identity: A non-human identity assigned to a process, service, job, or runtime workload.

Secret: Sensitive authentication or trust material such as a password, token, or private key.

Vault: A controlled system for storing, issuing, auditing, and rotating secrets.

Encryption: Transformation of data so that only authorized parties can recover its meaning.

Hash: A one-way digest used primarily for integrity verification or secure password storage schemes.

Digital signature: A cryptographic mechanism providing evidence of key-holder approval and data integrity.

PKI: A system of certificates, authorities, keys, policies, and validation processes.

Certificate authority: A trusted entity that issues and signs digital certificates.

Key rotation: Replacement of a cryptographic key or credential according to a controlled lifecycle process.

Machine-identity governance: Inventory, ownership, policy, monitoring, and lifecycle management for non-human identities.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization and accountability.

2. Why is least privilege a dynamic rather than permanent condition?

3. State two differences between RBAC and ABAC.

4. What is the purpose of a secrets vault?

5. Why does deleting an exposed token from a repository not resolve the exposure?

Long Answer Questions

1. Explain how federation, MFA, PAM, and separation of duties can secure human administrative access.

2. Describe a secure workload-identity design for a CI/CD pipeline.

3. Explain the lifecycle of a secret from generation through revocation and deletion.

4. Discuss the roles of encryption, hashing, digital signatures, certificates, and PKI in DevSecOps.

5. Design a governance model for machine identities across cloud and Kubernetes environments.

Analytical / Application Questions

1. A build job can read production secrets, approve releases, publish artifacts, and deploy to production. Analyze the risks and propose a redesigned permission model.

2. An organization experiences outages whenever database credentials are rotated. Analyze likely process weaknesses and design a safer rotation approach.

3. A company uses ABAC policies based on repository and branch claims, but untrusted pull requests can execute pipeline code. Evaluate the trust model and recommend controls.

22. Multiple Choice Questions with Answers

Question 1

Which design best expresses least privilege for a production deployment pipeline?

A. Give the pipeline permanent administrator access so deployments cannot fail

B. Give the pipeline a short-lived identity limited to approved artifacts and its target environment

C. Use one shared credential for developers, builds, and production

D. Allow the pipeline to access all secrets but monitor its logs

Correct Answer: B. Give the pipeline a short-lived identity limited to approved artifacts and its target environment

Question 2

What is the principal strength of ABAC compared with a simple RBAC design?

A. It removes the need for authentication

B. It permits decisions using contextual attributes such as resource, environment, and workload claims

C. It guarantees that policies cannot conflict

D. It requires no policy testing

Correct Answer: B. It permits decisions using contextual attributes such as resource, environment, and workload claims

Question 3

Which control most directly reduces the risk of a stolen CI credential remaining useful for months?

A. Longer passwords

B. Short-lived federated workload credentials

C. More comments in pipeline code

D. A larger shared role

Correct Answer: B. Short-lived federated workload credentials

Question 4

A secret is accidentally committed to a public repository. What should happen first?

A. Rename the repository

B. Delete only the offending line

C. Revoke or rotate the exposed credential and investigate copies

D. Encrypt the existing commit without changing the credential

Correct Answer: C. Revoke or rotate the exposed credential and investigate copies

Question 5

Which statement about a hash is correct?

A. It is normally used to recover plaintext data

B. It provides confidentiality by itself

C. It produces a digest useful for integrity verification

D. It is identical to a digital certificate

Correct Answer: C. It produces a digest useful for integrity verification

Question 6

What is a central purpose of privileged access management?

A. To make every user an administrator

B. To provide controlled, often temporary, access to high-impact permissions

C. To replace all audit logging

D. To eliminate the need for authorization policies

Correct Answer: B. To provide controlled, often temporary, access to high-impact permissions

Question 7

Why should a workload identity be separate from a developer identity?

A. Workloads never require authentication

B. It improves attribution and permits task-specific, independently governed access

C. Developer identities cannot use encryption

D. It guarantees that software contains no vulnerabilities

Correct Answer: B. It improves attribution and permits task-specific, independently governed access

Question 8

Which activity belongs to certificate lifecycle governance?

A. Ignoring expiry because certificates are self-renewing

B. Tracking issuance, private-key protection, renewal, trust, and revocation

C. Storing private keys in source control

D. Using one certificate for every unrelated purpose

Correct Answer: B. Tracking issuance, private-key protection, renewal, trust, and revocation

Question 9

A release pipeline can both approve and execute its own high-risk production change. Which principle is most clearly violated?

A. Separation of duties

B. Data compression

C. Hash collision resistance

D. Certificate chaining

Correct Answer: A. Separation of duties

Question 10

Why is automated secret rotation potentially disruptive if poorly designed?

A. Rotation always removes encryption

B. Consumers may depend on the old value and fail without coordinated update and validation

C. Vaults cannot record access events

D. Short-lived secrets cannot be audited

Correct Answer: B. Consumers may depend on the old value and fail without coordinated update and validation