3. Identity, Access and Secrets Management

Introduction and Context

Cloud deployment changes the security boundary of an application. In a traditional data centre, access was often controlled through network location, corporate firewalls, and a relatively small number of administrators. In cloud environments, applications, users, automated pipelines, databases, storage services, and third-party systems interact through programmable interfaces. The central security question is therefore not simply whether traffic can reach a resource, but whether a particular identity is permitted to perform a specific action on a specific resource under defined conditions.

Identity, access and secrets management provides the control layer for answering that question. Identity management establishes who or what is requesting access. Access management determines what that identity may do. Secrets management protects credentials and other sensitive values used by applications. Together, these capabilities support confidentiality, integrity, accountability, regulatory compliance, and operational resilience.

The three major cloud platforms implement these ideas through different services and terminology. AWS uses IAM, roles, policies, STS, KMS and Secrets Manager. Google Cloud uses Cloud Identity, IAM, service accounts, the Security Token Service, Cloud KMS and Secret Manager. Microsoft Azure uses Microsoft Entra ID, Azure RBAC, managed identities, Microsoft Entra tokens, Key Vault and related identity governance capabilities. Although the products differ, the underlying principles are transferable.

Learning Objectives

After completing this chapter, a learner should be able to:

1. Explain identity, authentication, authorization, accountability and secrets management.

2. Apply least privilege, role-based access control and attribute-based access control.

3. Compare human identities, workload identities, service accounts, roles and temporary credentials across AWS, Azure and Google Cloud.

4. Design federation and single sign-on arrangements for enterprise cloud environments.

5. Select suitable approaches to key management, encryption and secret storage.

6. Identify common identity-related risks and propose controls, monitoring and governance measures.

7. Evaluate an access architecture using technical, organizational and compliance criteria.

The Identity Plane of Cloud Computing

An identity is a principal capable of requesting an operation. A principal may be a person, application, virtual machine, container, serverless function, external organization, or cloud service. Authentication establishes confidence in the claimed identity, while authorization evaluates whether the authenticated principal may perform the requested operation.

A useful authorization expression is:

Decision = policy(principal, action, resource, context)

The principal is the requester; the action may be read, write, delete, deploy or administer; the resource is the target object; and context may include time, device posture, network location, authentication strength, tags, project, subscription or environment. A request is allowed only when applicable policies produce an effective allow and no explicit deny overrides it.

Identification, authentication and authorization must be distinguished. Identification states an identity, such as a username or service account. Authentication verifies it using a password, cryptographic key, certificate, token or biometric factor. Authorization determines permitted actions. Accounting or auditing records what occurred, when, by whom, and against which resource. Confusing these stages creates weak designs; successful login, for example, does not imply unrestricted access.

Cloud providers generally use a shared responsibility model. The provider secures the underlying infrastructure and identity service, whereas the customer remains responsible for configuring policies, protecting credentials, governing privileged access, and monitoring activity. A misconfigured customer policy can expose data even when the cloud platform itself is operating correctly.

Least Privilege as a Design Principle

Least privilege means granting only the permissions necessary for an identity to perform an approved task, for only as long as necessary. It is not equivalent to denying all access. Excessive permission increases blast radius: if an account, token or application is compromised, an attacker can perform more damaging actions.

Least privilege has several dimensions. Permissions should be limited by action, resource, environment, time and conditions. A deployment pipeline may need permission to update a particular production service but not to retrieve database passwords or alter identity policies. A reporting analyst may need read access to selected datasets but not the ability to export all storage objects.

Least privilege is an iterative process rather than a one-time configuration. Teams should begin with a clearly defined task, grant narrowly scoped permissions, observe legitimate use, remove unused privileges, and review changes periodically. Deny-by-default policies, separation of duties, approval workflows, and short-lived credentials reinforce this approach.

RBAC, ABAC and Policy-Based Control

Role-based access control (RBAC) assigns permissions to roles and assigns users or workloads to those roles. Typical roles include developer, security auditor, deployment operator and billing analyst. RBAC is understandable and administratively efficient when responsibilities are stable. Its weakness is role explosion: organizations may create hundreds of near-duplicate roles to represent every project, region and environment.

Attribute-based access control (ABAC) evaluates attributes associated with the principal, resource and request. Examples include department, data classification, environment, project identifier, device trust and time of day. A policy might allow a principal with department=finance to read resources tagged data-classification=internal within the finance project. ABAC improves scalability and contextual precision, but it requires reliable attributes, consistent tagging and strong governance.

RBAC and ABAC are complementary. A production deployment role may establish the broad job function, while attributes restrict it to resources tagged environment=production and owned by a particular team. Policy-based access control combines these mechanisms with explicit conditions and organizational policies.

A practical policy review asks four questions: Who is the principal? What exact action is required? Which resource is affected? Under what conditions should the action be permitted? Policies should be written for named resources wherever possible, rather than using broad wildcards. Exceptions should be documented, approved and time-limited.

Human Identity, Federation and Single Sign-On

Organizations should normally manage human identities through a central identity provider rather than creating independent cloud accounts for every employee. Federation connects an enterprise identity provider with a cloud provider. Standards such as SAML 2.0 and OpenID Connect support the exchange of authentication assertions or tokens. The employee authenticates with the organization, and the cloud platform receives a trusted assertion mapped to an appropriate role or group.

Single sign-on (SSO) improves user experience and centralizes lifecycle controls. When an employee leaves the organization, disabling the corporate identity can remove access to multiple cloud environments. SSO also supports centralized multifactor authentication, conditional access, password policy and audit collection. It does not eliminate authorization design: a federated user may still receive excessive cloud permissions if group-to-role mappings are poorly configured.

Privileged access should be separated from ordinary access. Administrators should use dedicated privileged identities, phishing-resistant multifactor authentication where feasible, approval processes, just-in-time elevation and detailed logging. Break-glass accounts may be retained for emergencies, but they must be few, strongly protected, monitored and tested periodically.

AWS IAM Identity Center can provide workforce access to AWS accounts and permission sets. Microsoft Entra ID supports enterprise SSO, conditional access, privileged identity management and application federation. Google Cloud commonly integrates Cloud Identity or an external identity provider with workforce identity federation. The precise service configuration changes over time, but the architectural goal remains centralized authentication with carefully governed authorization.

Workload Identities and Temporary Credentials

Applications should not use personal accounts. A workload identity represents software and allows its permissions to be separated from the permissions of developers or operators. Examples include AWS IAM roles, Azure managed identities and Google Cloud service accounts.

Temporary credentials are preferable to long-lived access keys. They are issued for a limited lifetime and may be restricted to a role, audience, scope or workload. AWS Security Token Service issues temporary role credentials. Google Cloud Security Token Service supports token exchange for federated workloads. Azure resources can obtain tokens through managed identities and Microsoft Entra ID without storing client secrets in application code.

Workload identity federation is especially valuable for external CI/CD systems. Instead of storing a permanent cloud key in a source-code platform, the pipeline presents an external identity token. The cloud provider validates its claims and issues short-lived credentials subject to conditions such as repository, branch, organization and workflow identity.

A service identity should be assigned at the narrowest useful scope. A web application that reads objects from one bucket should not receive administrator privileges. Separate identities should be used for development, testing and production. Credentials should not be copied between environments, embedded in container images, committed to repositories or placed in unencrypted configuration files.

Key Management and Cryptographic Separation

Encryption protects data, but encryption alone does not establish sound key governance. Key management includes generation, storage, use, rotation, access control, backup, revocation and destruction. A key-encryption key may protect data-encryption keys, allowing large volumes of data to be encrypted efficiently while centralizing control over key access.

Cloud key management services include AWS Key Management Service, Google Cloud KMS and Azure Key Vault. These services can provide software-protected keys and, in suitable configurations, hardware-backed protection. Customer-managed keys may be required where an organization needs direct control over rotation, disablement, usage audit or regulatory separation. Provider-managed encryption may be operationally simpler for lower-risk data.

Key permissions should be separated. The ability to administer a key should not automatically imply the ability to use it for decryption. Encryption and decryption operations must be logged and reviewed. Rotation reduces exposure but does not repair a compromised application or remove already exposed plaintext. Key deletion is potentially irreversible and therefore requires retention, recovery and change-control procedures.

Envelope encryption is a common architecture. The application generates or receives a data-encryption key, encrypts the data locally, and asks the KMS to encrypt that data key. The encrypted data key is stored with the ciphertext. During retrieval, an authorized workload asks KMS to decrypt the data key and uses it to decrypt the data. This reduces the need to send large data volumes through the key service.

Secrets Management in Application Delivery

A secret is sensitive information used to authenticate or authorize access, including passwords, API keys, database connection strings, OAuth client secrets, certificates and private keys. Secrets differ from ordinary configuration because disclosure can enable unauthorized access.

AWS Secrets Manager, Google Secret Manager and Azure Key Vault provide centralized storage, controlled retrieval, encryption, versioning, audit logging and, in some cases, automated rotation. Applications should retrieve secrets at runtime through a workload identity. A secret should not be placed in source code, a public build log, a container image layer or an unprotected environment file.

Secret management must cover the entire lifecycle: creation, approval, storage, distribution, use, rotation, revocation and destruction. Rotation is effective only when dependent applications can obtain and use the new version. Database credentials may require coordinated rotation or dual-validity periods. Applications should fail safely when a secret is unavailable and should avoid printing secret values in exceptions or diagnostic logs.

Not every sensitive value should be treated identically. A public application identifier is not a secret, whereas a private signing key is highly sensitive. Data classification helps determine retention, access, rotation frequency and monitoring requirements. Secrets should be referenced by identifiers rather than copied across systems.

A Unified Access Architecture Across the Three Clouds

A multi-cloud organization benefits from common principles even when implementations differ. The enterprise identity provider should be the authoritative source for human identities. Cloud-native workload identities should be used for applications. Federation should replace duplicated passwords and permanent external keys. Central security teams should define baseline controls, while application teams own resource-specific permissions.

AWS organizes resources largely through accounts, IAM policies, roles, resource policies and organizational controls. Azure uses tenants, subscriptions, management groups, Microsoft Entra identities, Azure RBAC and resource locks or policies. Google Cloud uses organizations, folders, projects, IAM policies, service accounts and organization policies. These structures are not interchangeable, but each can express administrative boundaries, environment separation and delegated ownership.

A useful governance model includes: a central identity team responsible for federation and authentication standards; platform teams responsible for landing zones, policy guardrails and logging; application teams responsible for least-privilege roles; and security or audit teams responsible for independent review. Access should be provisioned through code and approved workflows where possible, creating traceability and reducing manual drift.

Applied Case: Securing a Multi-Cloud Delivery Platform

Background

Consider an illustrative company, Northstar Retail, operating an online platform across AWS and Azure, with analytics workloads in Google Cloud. Developers use a corporate directory, and an automated delivery system builds containers and deploys them to separate development, staging and production environments.

Situation and Problem

The initial design used shared administrator accounts, permanent cloud access keys stored in pipeline variables, database passwords copied into deployment manifests, and a single service account across all environments. A security review found that a compromised build job could retrieve production data, alter identity policies and access encryption keys. Audit records could not reliably distinguish human activity from automation.

Analysis

The principal weaknesses were excessive privilege, long-lived credentials, inadequate separation of duties, poor environment isolation and weak secret lifecycle control. The problem was not solved merely by changing passwords because the architecture allowed credentials to proliferate and made legitimate access difficult to attribute.

Approach and Solution

Northstar federated its corporate directory with AWS IAM Identity Center, Microsoft Entra ID and Google Cloud workforce access. Developers received environment-specific permission sets rather than administrator access. Production elevation required multifactor authentication, approval and a time-limited role.

Each deployment environment received a distinct workload identity. The delivery platform used workload identity federation, exchanging its signed external token for short-lived cloud credentials. Repository, branch and environment claims were checked before credentials were issued. The production deployment identity could update only the approved service and could not read database secrets.

Database credentials were moved to AWS Secrets Manager, Azure Key Vault and Google Secret Manager according to workload location. Applications retrieved secrets at runtime using their own identities. Encryption keys were managed through the corresponding KMS or Key Vault services, with separate administration and use permissions. Central logging recorded authentication, role assumption, secret access, key use and policy changes.

Outcome

The revised design reduced the duration and scope of credentials, separated human and machine access, improved attribution and made environment boundaries explicit. The organization also gained a repeatable process for reviewing access as applications changed. Operational work increased initially because teams had to define resource scopes and rotation procedures, but the resulting controls reduced the impact of credential compromise.

Learning Points

The case demonstrates that identity security is an architectural property. Federation is valuable only when authorization is carefully mapped. Temporary credentials reduce persistence but do not compensate for an overprivileged role. Secret stores protect values, but applications still require correct identities and logging. Finally, access governance must be integrated into delivery processes rather than treated as a final audit activity.

Risks, Limitations and Common Mistakes

Common mistakes include granting administrator permissions for convenience, using wildcard resources, allowing applications to assume arbitrary roles, leaving unused accounts active, sharing service identities, and placing secrets in source repositories. Another frequent error is confusing encryption at rest with complete protection; an authorized but compromised application may still decrypt data.

Role-based systems can become difficult to maintain when roles are created without ownership or expiry. ABAC can fail when tags are missing, inaccurate or user-controlled. Federation can create a single point of administrative failure if the identity provider is unavailable or compromised. Temporary credentials may still be stolen during their valid lifetime. Key rotation can interrupt applications if compatibility and rollback are not planned.

Organizations should test incident response by revoking credentials, disabling identities, rotating secrets, suspending keys and reviewing audit trails. Access reviews should examine actual use, not merely whether a permission was once approved. Automated policy analysis can identify public access, unused permissions, privilege escalation paths and anomalous activity, but findings require human interpretation.

Governance, Ethics and Compliance

Identity systems process information about employees, contractors and customers. Monitoring must be proportionate, transparent and limited to legitimate security or operational purposes. Excessive surveillance can damage trust and may conflict with privacy obligations. Access logs should be protected from unauthorized alteration and retained according to legal, contractual and operational requirements.

Separation of duties is important where one individual could otherwise request, approve and implement sensitive access. Emergency access should be exceptional and retrospectively reviewed. Organizations must also consider data residency, cross-border identity federation, regulatory requirements for privileged access, and contractual obligations involving third-party operators.

Security teams should define policy, but application owners and business stakeholders must help determine what access is genuinely necessary. Governance is strongest when it combines technical enforcement, accountable ownership, documented exceptions and periodic independent review.

Emerging Directions and Best Practices

Zero-trust architectures treat every request as requiring verification rather than trusting network location. Continuous evaluation may consider identity, device health, workload attestation, behavioral signals and resource sensitivity. Identity threat detection increasingly uses analytics to identify impossible travel, unusual token use, anomalous privilege changes and suspicious secret retrieval.

Policy-as-code enables access rules, organization constraints and compliance checks to be reviewed through version control and automated pipelines. Confidential computing and hardware-backed workload attestation may strengthen trust in sensitive processing environments. Passkeys and phishing-resistant authentication are reducing reliance on passwords, while machine identities are becoming more numerous than human identities.

Effective practice can be summarized as follows:

• centralize human authentication and enforce strong multifactor authentication;
• use roles and attributes to express narrowly scoped access;
• prefer workload identities and short-lived credentials;
• separate development, testing and production identities;
• store secrets and keys in managed services, not code or images;
• separate key administration from cryptographic use;
• log, review and automate access decisions;
• test revocation, rotation and emergency procedures;
• treat access as code and review it through controlled change processes.

Chapter Summary

Identity, access and secrets management forms the foundation of secure cloud deployment. Authentication verifies a principal, authorization evaluates permitted actions, and auditing provides accountability. Least privilege limits the blast radius of mistakes and compromise. RBAC organizes access by job function, while ABAC introduces resource, identity and contextual attributes for more precise decisions.

Federation and SSO centralize human authentication, whereas workload identities and temporary credentials provide safer application access than permanent keys. AWS IAM and STS, Microsoft Entra ID and managed identities, and Google Cloud IAM, service accounts and token federation implement these principles in different ways. KMS, Key Vault and cloud secret stores support controlled encryption and secret lifecycles, but correct application identity and policy design remain essential.

A mature architecture separates environments, distinguishes human from machine access, uses approval and monitoring, automates policy review, and plans for rotation and revocation. Governance must address privacy, accountability, compliance and separation of duties. The principal professional skill is not memorizing provider-specific screens, but translating business responsibilities into verifiable, least-privilege and auditable cloud permissions.

Key Terms

Identity: A person, workload or system recognized as a principal.

Authentication: Verification of a claimed identity.

Authorization: Determination of which actions an authenticated principal may perform.

Accountability: Ability to associate activity with a responsible identity through records and controls.

Least privilege: Granting only the minimum necessary permissions for a justified task.

RBAC: Access control based on roles representing job functions.

ABAC: Access control based on attributes of principals, resources and requests.

Federation: Trust relationship allowing one identity system to authenticate users for another system.

Single sign-on: Authentication to multiple services through a central identity provider.

Workload identity: A non-human identity assigned to an application or automated process.

Temporary credential: Access credential issued for a limited duration or scope.

Service account: An identity used by an application or service rather than a person.

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

Key management: Governance of cryptographic keys throughout their lifecycle.

Envelope encryption: Encrypting data keys with a separate key-encryption key.

KMS: A managed cloud service for creating and controlling cryptographic keys.

Policy: A formal statement of permitted or denied actions under specified conditions.

Privilege escalation: Obtaining permissions beyond those originally granted.

Just-in-time access: Time-limited privilege granted only when an approved task requires it.

Workload identity federation: Exchange of an external workload assertion for temporary cloud credentials.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization and accountability.

2. What is the purpose of least privilege?

3. Define workload identity and give one example.

4. Why are temporary credentials generally safer than permanent access keys?

5. What is envelope encryption?

Long Answer Questions

1. Explain how RBAC and ABAC can be combined in a multi-cloud organization.

2. Discuss the role of federation and SSO in enterprise cloud identity management.

3. Compare human identity management with workload identity management.

4. Explain the lifecycle controls required for secrets and cryptographic keys.

5. Describe a governance model for managing access across AWS, Azure and Google Cloud.

Analytical / Application Questions

1. A CI/CD pipeline has a permanent administrator key and can read all production secrets. Identify the risks and design a least-privilege replacement.

2. An organization uses one service account for development, testing and production. Analyze the consequences and propose an improved identity architecture.

3. A company wants to use ABAC but resource tags are inconsistent. Evaluate the risks and recommend controls before relying on attribute-based decisions.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes least privilege?

A. Every employee receives administrator access for operational flexibility.

B. A principal receives only the permissions necessary for an approved task.

C. All access is denied permanently unless a security incident occurs.

D. Users are allowed to access any resource within their network.

Correct Answer: B. A principal receives only the permissions necessary for an approved task.

Question 2

A policy allows access only when the principal belongs to Finance and the resource is tagged Internal. This is primarily an example of:

A. ABAC

B. Password authentication

C. Network segmentation

D. Data backup

Correct Answer: A. ABAC

Question 3

What is the strongest reason for using federation with an enterprise identity provider?

A. It eliminates the need for authorization policies.

B. It allows every user to share one cloud account.

C. It centralizes authentication and supports lifecycle control across services.

D. It prevents all identity-provider outages.

Correct Answer: C. It centralizes authentication and supports lifecycle control across services.

Question 4

Which design is most appropriate for a cloud deployment pipeline?

A. A developer’s personal administrator account

B. A permanent access key committed to a private repository

C. A shared service account used in every environment

D. A narrowly scoped workload identity using short-lived federated credentials

Correct Answer: D. A narrowly scoped workload identity using short-lived federated credentials

Question 5

In envelope encryption, what is encrypted by the key-encryption key?

A. The entire application source code directly

B. The data-encryption key

C. The user’s multifactor authentication device

D. The audit log destination

Correct Answer: B. The data-encryption key

Question 6

Which practice creates the greatest risk in secrets management?

A. Retrieving secrets at runtime through a workload identity

B. Versioning secrets in a managed secret store

C. Printing database passwords in build logs

D. Rotating credentials with application coordination

Correct Answer: C. Printing database passwords in build logs

Question 7

Why should administration of a cryptographic key be separated from its use for decryption?

A. To support separation of duties and reduce unauthorized cryptographic use

B. To make encryption impossible for applications

C. To eliminate the need for audit logs

D. To ensure all employees can decrypt data

Correct Answer: A. To support separation of duties and reduce unauthorized cryptographic use

Question 8

A compromised build job can assume any role in an organization. Which control most directly reduces this risk?

A. Increase the token lifetime

B. Permit role assumption only for named roles and verified pipeline claims

C. Disable all application logging

D. Store more permanent keys in the pipeline

Correct Answer: B. Permit role assumption only for named roles and verified pipeline claims

Question 9

Which statement about temporary credentials is correct?

A. They are risk-free once issued.

B. They remove the need for authorization policies.

C. They reduce persistence but may still be misused during their valid lifetime.

D. They must always be stored in source code.

Correct Answer: C. They reduce persistence but may still be misused during their valid lifetime.

Question 10

What is a major limitation of ABAC?

A. It cannot use resource information.

B. It requires reliable attributes and consistent governance of those attributes.

C. It always grants broader access than RBAC.

D. It cannot support contextual conditions.

Correct Answer: B. It requires reliable attributes and consistent governance of those attributes.