4. Identity, Access and Secrets Management

Introduction and Context

Cloud platforms replace the relatively stable security boundary of a private data centre with a distributed environment containing users, applications, automated pipelines, containers, serverless functions, databases, APIs, and third-party services. Every interaction with a cloud resource therefore raises two questions: Who or what is making the request? and What is that identity permitted to do? Identity and access management (IAM) provides the answer to the first two questions. Secrets management extends the protection to passwords, tokens, private keys, certificates, and other sensitive values used by those identities.

In DevOps, these concerns are inseparable from delivery automation. A deployment pipeline may need to create infrastructure, a workload may need to read from object storage, and an administrator may need temporary access to production. Granting excessive permissions creates a large blast radius; granting insufficient permissions disrupts delivery and encourages unsafe workarounds. Mature cloud security therefore seeks a controlled balance between usability, automation, traceability, and risk.

AWS, Microsoft Azure, and Google Cloud use different product names and implementation details, but their underlying design principles are broadly similar. AWS Identity and Access Management (IAM), Microsoft Entra ID and Azure role-based access control, and Google Cloud Identity and Access Management all support identities, policies, roles, delegation, and auditability. The names differ, but the architectural questions remain consistent.

Learning Objectives

After studying this chapter, students should be able to:

1. Distinguish human identities, workload identities, service identities, roles, policies, and credentials.

2. Explain authentication, authorization, federation, SSO, RBAC, ABAC, and least privilege.

3. Design access models for AWS, Azure, and Google Cloud environments.

4. Select appropriate mechanisms for privileged access, key management, certificates, and secrets rotation.

5. Apply IAM controls in DevOps pipelines and infrastructure-as-code workflows.

6. Analyse risks, governance obligations, and operational trade-offs in identity architecture.

7. Recommend improvements for an organization’s identity and secrets-management programme.

Identity as the Control Plane of the Cloud

An identity is a subject that can be authenticated and evaluated for access. A subject may be a person, application, virtual machine, container, function, CI/CD pipeline, or external organization. Authentication establishes confidence in the claimed identity. Authorization evaluates whether that identity may perform a particular action on a particular resource under specified conditions.

A permission can be represented conceptually as:

Identity + Action + Resource + Conditions = Authorization decision

For example, a deployment role may be allowed to update a particular Kubernetes cluster only from an approved pipeline, during a deployment window, and with a specific set of tags. A policy is a formal expression of such permissions. Policies commonly specify actions, resources, effects such as allow or deny, and conditions.

Authentication mechanisms include passwords, multi-factor authentication, hardware security keys, certificates, workload identity tokens, and federated assertions. A credential is evidence used in authentication. Credentials should not be confused with identities: an identity is the entity being represented, whereas a password or token is one means of proving that representation.

Cloud IAM normally operates at several scopes. An organization or tenant may establish broad governance controls; accounts, subscriptions, or projects provide administrative boundaries; resource groups, folders, and individual resources allow progressively finer control. Effective permissions may be affected by policies at all these levels. This hierarchical structure supports centralized guardrails while allowing teams to manage their own services.

Users, Roles, and Service Identities

Human users should generally be represented through an enterprise identity provider rather than through numerous independent cloud-native accounts. Centralized identity improves onboarding, offboarding, multi-factor authentication, access reviews, and evidence collection. A cloud-native user may still be useful for exceptional technical purposes, but permanent individual access keys are a high-risk default.

A role is an identity with a defined set of permissions that can be assumed temporarily by an authorized subject. Roles are particularly important in cloud environments because they avoid embedding long-lived credentials in applications. A person may assume an administrative role for a short period; a CI/CD system may assume a deployment role; a virtual machine may obtain a role through its instance identity mechanism.

A service identity is an identity assigned to a workload or platform component. Examples include AWS roles for compute services, Azure managed identities, and Google Cloud service accounts. Service identities should be separate for different applications, environments, and trust boundaries. Sharing one powerful service account among many workloads makes attribution difficult and allows compromise of one workload to affect all others.

The distinction between a role and a service account varies by provider. In practical design, the important questions are whether credentials are short-lived, how the workload proves its identity, who may assume or impersonate it, and what permissions it receives.

Federation and Single Sign-On

Federation allows one identity system to trust authentication performed by another. An organization may use an enterprise provider such as Microsoft Entra ID, Okta, or another standards-based identity provider and federate users into AWS, Azure, or Google Cloud. Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and OAuth 2.0 are common technologies in this area. OAuth primarily addresses delegated authorization, while OIDC adds an authentication layer based on OAuth 2.0.

Single sign-on (SSO) improves usability by allowing users to authenticate through a central provider. Its security value depends on strong controls at that provider: phishing-resistant MFA, device and risk evaluation, lifecycle automation, and rapid account disablement. SSO does not mean that all users should receive the same cloud permissions. Federation establishes identity; authorization remains a separate design responsibility.

For CI/CD, OIDC federation is increasingly preferable to storing a cloud access key in a source-control or pipeline secret store. The pipeline presents a signed identity token containing claims such as repository, branch, workflow, or environment. The cloud provider validates the token and issues temporary credentials if the claims satisfy a trust policy. A robust trust policy restricts the precise repository and deployment context rather than trusting an entire organization or all branches.

Authorization Models: RBAC, ABAC, and Policy Evaluation

Role-based access control (RBAC) assigns permissions to roles and assigns subjects to roles. Typical roles include developer, security auditor, database operator, and deployment engineer. RBAC is understandable and efficient where job responsibilities are stable, but role proliferation may occur when organizations create a separate role for every exception.

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and context. Attributes may include department, environment, data classification, project, device assurance, network location, or resource tags. For example, a policy may allow a user with `team=payments` to access resources tagged `team=payments`, provided the environment is non-production. ABAC can scale better across dynamic environments, but inaccurate or inconsistent attributes can produce unexpected access.

Many cloud systems combine RBAC and ABAC. A role supplies a broad permission set, while conditions and tags narrow its use. Policy evaluation commonly follows an implicit-deny model: access is denied unless an applicable policy permits it. An explicit deny normally overrides an allow. Exact precedence rules differ among services and providers, so engineers must test policies rather than rely on assumptions.

A useful least-privilege analysis asks:

• Which identity needs access?
• Which exact actions are required?
• Which resources are involved?
• For how long is access needed?
• Under what conditions should access be permitted?
• What evidence will demonstrate that the access was appropriate?

Least privilege is not merely the removal of permissions. It is a continuous process of discovering actual requirements, constraining access, monitoring use, and revising policies as systems change. “Read-only” is not automatically safe: read access to source code, customer records, encryption keys, or configuration secrets can be highly consequential.

Privileged Access and Separation of Duties

Privileged identities can alter security controls, create credentials, access sensitive data, or disable monitoring. They require stronger safeguards than ordinary application access. Privileged access management (PAM) commonly includes just-in-time elevation, approval workflows, time limits, session recording, command logging, and emergency access procedures.

A practical model separates ordinary work from administrative work. An engineer uses a normal identity for email, source control, and routine cloud observation, then assumes a privileged role only when required. The privileged role may require phishing-resistant MFA, a ticket reference, a reason for access, and automatic expiry.

Separation of duties reduces the possibility that one person can initiate, approve, and conceal a sensitive action. For example, an engineer may prepare an infrastructure change, a second person may approve it, and an automated pipeline may apply it. Separation should be risk-based rather than bureaucratic; excessive approvals can encourage bypasses and delay incident response.

Break-glass access is an emergency mechanism for loss of normal identity services or severe outages. It should be rare, strongly protected, monitored, tested, and reviewed after use. A break-glass account that is never tested may fail precisely when it is needed.

Secrets, Keys, and Certificates

A secret is sensitive data used to authenticate or authorize access. It may be a password, API token, database connection string, signing key, refresh token, or webhook credential. A cryptographic key is a value used by a cryptographic algorithm, while a certificate binds a public key to an identity through a trusted certification authority. Certificates do not usually contain the private key; protecting the private key is essential.

Secrets should be stored in a dedicated secrets manager or a hardware-backed key management service rather than in source code, container images, plain-text configuration files, tickets, or ordinary pipeline variables. Examples include AWS Secrets Manager and Systems Manager Parameter Store, Azure Key Vault, and Google Secret Manager. These services generally provide encryption at rest, access policies, audit logs, versioning, and integration with workload identities.

Key management services (KMS) protect and control the use of encryption keys. A useful separation exists between data encryption keys and key-encryption keys. Data may be encrypted using a data key, while the data key is protected by a managed master or key-encryption key. Key policies should specify administrators, users, permitted operations, rotation expectations, and deletion safeguards. Key administrators should not automatically receive permission to decrypt business data; separating key administration from key use limits insider risk.

Certificates have a defined validity period and require renewal before expiry. Automated certificate issuance and renewal reduce outages caused by forgotten expiration dates. Private certificate authorities may be appropriate for internal services, while public certificates are used for publicly trusted endpoints. Certificate inventory should include owner, purpose, subject, issuer, expiry, renewal method, and revocation procedure.

Rotation and the Secrets Lifecycle

Secrets management is a lifecycle, not simply a storage decision. The lifecycle includes creation, distribution, use, monitoring, rotation, revocation, archival where justified, and destruction. Rotation changes a credential while preserving service continuity. A safe database-password rotation often creates a new version, updates the consumer, verifies successful connections, and retires the previous version after a controlled overlap period.

Rotation can be time-based, event-based, or risk-based. Time-based rotation is easy to govern but may create unnecessary operational change. Event-based rotation is essential after suspected exposure, staff departure, vendor compromise, or unauthorized access. Short-lived tokens reduce the value of stolen credentials and are often preferable to repeatedly rotating long-lived keys.

Applications should retrieve secrets at runtime through an authenticated API or injected mechanism, rather than logging or packaging them into images. They should also handle version changes gracefully. Logs, traces, error messages, crash dumps, and metrics must be examined for accidental secret disclosure. Secret scanning in repositories is useful, but it cannot replace prevention, access control, and rapid revocation.

IAM Across AWS, Azure, and Google Cloud

AWS IAM uses users, groups, roles, identity policies, resource policies, permission boundaries, and organization-level service control policies. Cross-account role assumption is a central pattern. AWS workloads can obtain temporary credentials through roles attached to compute resources or through federated identity mechanisms.

Azure separates Microsoft Entra identities from Azure resource authorization. Azure RBAC assigns roles at scopes such as management group, subscription, resource group, or resource. Managed identities allow Azure resources to authenticate to supported services without developers managing credentials. Privileged Identity Management supports controlled elevation and review of privileged roles.

Google Cloud IAM grants roles to principals at organization, folder, project, or resource scope. Roles may be predefined or custom. Service accounts represent workloads, and Workload Identity Federation allows external workloads such as CI systems to obtain short-lived access without storing service-account keys. Organization policies and hierarchical resource structure provide governance controls.

These services are not interchangeable in detail. A multi-cloud organization should standardize principles and evidence rather than force identical syntax. A useful control catalogue maps concepts such as human federation, workload identity, temporary privilege, secret storage, key administration, logging, and access review to each provider’s implementation.

IAM in DevOps and Infrastructure as Code

IAM must be treated as code and as a production dependency. Terraform, CloudFormation, Bicep, or Deployment Manager configurations can define roles, policies, trust relationships, key settings, and secret references. Code review, static analysis, policy-as-code, and automated tests can identify wildcards, public access, excessive privilege, missing conditions, and unintended privilege escalation.

The pipeline itself requires a carefully designed identity. A plan stage may need read access, whereas an apply stage needs controlled write access. Production deployment should use a distinct role from development deployment. Trust should be limited to approved repositories, protected branches, signed workflows, and defined environments. Credentials should be temporary and should not be printed in command output.

Policy-as-code tools can enforce organizational rules such as “storage must not be public,” “production roles require MFA or workload federation,” or “customer-data resources must use approved encryption keys.” These controls should distinguish preventative guardrails from detective controls. A deployment blocked for a legitimate exception requires an auditable exception process rather than an informal bypass.

Applied Case: Securing a Multi-Cloud Retail Platform

Background

A fictional retailer, Northstar Retail, operates an e-commerce platform across AWS and Azure. Developers use a shared cloud administrator account, deployment pipelines contain long-lived access keys, and database passwords are stored in a private source-code repository. A security review finds that contractors retain access after project completion and that no reliable inventory exists for certificates or service accounts.

Situation and Analysis

The immediate risk is not only credential theft. Shared accounts prevent attribution, permanent keys enlarge the window of misuse, and excessive administrative privilege permits a compromise in one workload to affect unrelated systems. Repository access also exposes historical secrets even after a file is deleted. The organization has both human-identity and workload-identity weaknesses.

Strategy and Solution

Northstar first establishes a central identity provider with mandatory MFA and federated access to both clouds. Individual administrator accounts are removed from routine use. Engineers receive ordinary read or developer roles and use time-limited privileged elevation for production changes.

Separate service identities are created for each pipeline and major workload. AWS pipelines use OIDC federation with repository, branch, and environment restrictions. Azure pipelines use federated workload credentials or managed identities where the execution environment supports them. Development and production roles are separated, and production changes require approved workflows.

Database credentials move to managed secret stores. Applications retrieve them using workload identity, and automated rotation is implemented with a tested overlap procedure. Encryption keys are placed under defined administrative and usage boundaries. Certificates are inventoried and renewed automatically. Infrastructure-as-code policies block public storage, unrestricted administrative actions, and unapproved key configurations.

Finally, Northstar centralizes audit logs, reviews privileged activity, scans repositories for exposed credentials, and conducts quarterly access reviews. Emergency accounts are protected separately and tested under controlled conditions.

Outcome

The retailer reduces persistent credentials, improves attribution, limits the blast radius of compromised workloads, and obtains evidence for access reviews. The transition initially increases design and testing effort, particularly around rotation and pipeline trust. However, automation makes secure access more repeatable than manual credential handling.

Learning Points

The case illustrates that IAM modernization is an operating-model change, not merely a product installation. Federation, short-lived workload credentials, separate roles, managed secrets, and continuous review must work together. Controls that cannot be observed, tested, and maintained will eventually decay.

Risks, Limitations, and Common Mistakes

Frequent mistakes include granting administrator access to solve a deployment failure, using a single service account across environments, trusting all branches in a federated pipeline, placing secrets in logs, failing to remove former users, and assuming that encryption alone prevents unauthorized use. Wildcard permissions are sometimes necessary for narrowly governed services, but they should be treated as exceptions requiring justification and monitoring.

IAM can also become too complex. Thousands of roles, inconsistent tags, undocumented exceptions, and overlapping policy layers make effective access difficult to understand. Usability is a security concern: if legitimate work is constantly blocked, staff may share credentials or request permanent privilege. Access design should therefore be tested with real workflows and accompanied by clear support and exception processes.

Cloud-provider outages, identity-provider failures, clock errors, expired certificates, and incorrect trust conditions can interrupt operations. Resilience may require carefully protected emergency access, cached non-sensitive configuration, multiple authentication paths for critical operations, and tested recovery procedures. These safeguards must not become unmonitored back doors.

Governance, Ethics, and Professional Responsibility

Identity systems process information about employees, customers, contractors, and system behaviour. Organizations should collect and retain audit data proportionately, restrict access to logs, communicate monitoring practices, and comply with applicable privacy, employment, financial, health, and contractual requirements. Access reviews should not become indiscriminate surveillance.

Governance should define ownership for identities, roles, policies, keys, certificates, and secrets. It should specify approval, review frequency, retention, incident response, exception handling, and evidence requirements. Security professionals have a duty to report material weaknesses, avoid concealing failures, and design controls that protect people as well as systems.

Current Developments

Passwordless authentication using passkeys and hardware-backed credentials is reducing dependence on passwords and phishing-prone second factors. Workload identity federation is replacing many static cloud keys in external CI systems. Zero-trust architectures increasingly evaluate identity, device, workload, and context continuously rather than relying on network location.

Machine learning and analytics can help identify unusual privilege use, impossible travel, abnormal API calls, and dormant accounts. Such systems are decision-support tools, not substitutes for sound policy. False positives can create alert fatigue, while opaque automated denial can disrupt critical operations. Generative AI may assist with policy explanation and review, but generated policies require expert validation because a plausible policy can still grant dangerous access.

Best-Practice Design Principles

A defensible identity architecture generally follows these principles:

• Federate human access through a central provider and require strong MFA.
• Prefer roles and short-lived credentials to permanent access keys.
• Give every workload a distinct, minimally privileged identity.
• Combine RBAC with carefully governed attributes and conditions.
• Separate development, testing, and production access.
• Store secrets and keys in managed services, never in source code or images.
• Automate rotation, certificate renewal, discovery, and revocation.
• Use policy-as-code, peer review, and automated IAM testing.
• Apply just-in-time privilege, separation of duties, and monitored break-glass access.
• Centralize audit evidence and perform regular access reviews.
• Test failure, recovery, rotation, and emergency procedures.

Chapter Summary

Cloud IAM establishes who may perform which actions on which resources and under what conditions. Human users should normally access cloud platforms through federation and SSO, while workloads should use distinct service identities and temporary credentials. Roles, RBAC, ABAC, policy conditions, and least privilege provide the foundations of authorization. Privileged access requires elevation controls, approval, separation of duties, and monitoring.

Secrets, keys, and certificates must be managed throughout their lifecycle. Dedicated secret stores, KMS services, managed identities, workload federation, automated rotation, and certificate renewal reduce exposure and operational failure. AWS, Azure, and Google Cloud implement these ideas differently, but the same architectural principles apply. Effective IAM is continuous: it combines design, automation, governance, audit, testing, and informed professional judgement.

Key Terms

Identity: A person, workload, or system component that can be authenticated and authorized.

Authentication: Verification of a claimed identity.

Authorization: Determination of whether an identity may perform an action.

IAM: The discipline and services used to manage identities, permissions, and access.

Role: A permission-bearing identity assumed temporarily by an authorized subject.

Service identity: An identity assigned to an application, workload, or platform service.

Federation: A trust relationship allowing one identity provider to authenticate users for another system.

SSO: Single sign-on, enabling access to multiple systems through a central authentication event.

RBAC: Role-based access control, in which permissions are assigned through roles.

ABAC: Attribute-based access control, using identity, resource, environmental, or action attributes.

Least privilege: Granting only the access necessary for an approved purpose and duration.

PAM: Privileged access management, controlling high-risk administrative access.

Secret: Sensitive authentication or authorization data such as a password or token.

KMS: A key management service used to create, protect, control, and audit cryptographic keys.

Certificate: A digitally signed binding between a public key and an identity.

Rotation: Replacement of a credential, key, or certificate according to a controlled process.

OIDC: An identity layer that provides authentication assertions using OAuth 2.0 mechanisms.

Policy-as-code: Machine-readable policy that can be reviewed, tested, and enforced automatically.

Break-glass access: Protected emergency access used when normal administrative paths fail.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.

2. Why are workload identities preferable to embedded long-lived access keys?

3. Define RBAC and ABAC.

4. What is the purpose of a key management service?

5. Why should certificate renewal be automated?

Long Answer Questions

1. Explain how federation, SSO, MFA, and role assumption can be combined to secure human access to multiple cloud providers.

2. Compare RBAC and ABAC, including their advantages, limitations, and appropriate uses in a cloud environment.

3. Describe a complete secrets lifecycle from creation through revocation and destruction.

4. Explain how privileged access management and separation of duties reduce the risk of administrative compromise.

5. Design an IAM model for a CI/CD system deploying separately to development and production environments.

Analytical / Application Questions

1. A pipeline stores an AWS access key in a repository secret and deploys to three environments using one administrator role. Analyse the risks and propose a migration using federation, separate roles, and least privilege.

2. An organization has hundreds of cloud roles, inconsistent resource tags, and frequent access-denied incidents. Recommend a rationalization and governance approach without encouraging excessive privilege.

3. A database password may have been exposed in application logs. Develop an incident response and long-term improvement plan covering investigation, rotation, revocation, monitoring, and application redesign.

22. Multiple Choice Questions with Answers

Question 1

A CI/CD pipeline needs to deploy only to a production service from a protected repository branch. Which design best follows least privilege?

A. Store a permanent administrator key in the pipeline

B. Use OIDC federation with a narrowly scoped, temporary deployment role

C. Use one shared service account for every environment

D. Allow all branches to assume the production role

Correct Answer: B. Use OIDC federation with a narrowly scoped, temporary deployment role

Question 2

Which statement best distinguishes authentication from authorization?

A. Authentication assigns roles, while authorization encrypts data

B. Authentication verifies identity, while authorization evaluates permitted actions

C. Authentication rotates secrets, while authorization issues certificates

D. Authentication records logs, while authorization creates users

Correct Answer: B. Authentication verifies identity, while authorization evaluates permitted actions

Question 3

A policy allows a user to access resources only when the user's team attribute matches the resource tag. This is primarily an example of:

A. RBAC

B. ABAC

C. Passwordless authentication

D. Certificate revocation

Correct Answer: B. ABAC

Question 4

Why is a distinct service identity recommended for each major workload?

A. It eliminates the need for authorization policies

B. It makes all workloads administrators

C. It improves attribution and limits the blast radius of compromise

D. It prevents the use of encryption

Correct Answer: C. It improves attribution and limits the blast radius of compromise

Question 5

Which practice provides the strongest protection for routine human administrative access?

A. Permanent administrator privileges for convenience

B. Shared administrator credentials with monthly rotation

C. Time-limited elevation with MFA, approval, and audit logging

D. Allowing administrative access from any unmanaged device

Correct Answer: C. Time-limited elevation with MFA, approval, and audit logging

Question 6

What is the main security advantage of short-lived workload credentials?

A. They never require authorization

B. Their value and misuse window are reduced if exposed

C. They remove the need for audit logs

D. They allow unrestricted access to all resources

Correct Answer: B. Their value and misuse window are reduced if exposed

Question 7

Which activity belongs to a secrets lifecycle?

A. Creation, controlled distribution, rotation, monitoring, and revocation

B. Copying passwords into source code and retaining them indefinitely

C. Disabling all logging to protect confidentiality

D. Using one password for every environment

Correct Answer: A. Creation, controlled distribution, rotation, monitoring, and revocation

Question 8

In a typical implicit-deny policy model, what happens when no applicable policy grants a requested action?

A. The action is automatically allowed

B. The action is denied

C. The action is performed anonymously

D. The resource becomes public

Correct Answer: B. The action is denied

Question 9

Which separation most effectively limits insider risk in key management?

A. Giving key administrators automatic permission to decrypt all business data

B. Separating key administration from permission to use keys for decryption

C. Allowing developers to export all private keys

D. Disabling key-usage audit logs

Correct Answer: B. Separating key administration from permission to use keys for decryption

Question 10

A database credential is rotated but the application fails because it reads the old value from a container image. What design improvement is most appropriate?

A. Build a larger container image containing multiple passwords

B. Retrieve the secret at runtime through an authenticated workload identity

C. Disable rotation permanently

D. Print the new password in deployment logs

Correct Answer: B. Retrieve the secret at runtime through an authenticated workload identity