Identity, Access and Resource Governance

Introduction

Cloud deployment is not controlled only by compute, storage, and networking. It is controlled by identities: people, applications, automated pipelines, and external partners that request access to resources. Identity and access management (IAM) determines who or what may perform an action, on which resource, and under which conditions. Resource governance extends this control by organizing resources, applying common policies, recording ownership, limiting consumption, and making decisions auditable.

AWS and Google Cloud (GCP) use different terminology and implementation details, but they address the same operational questions:

• How is an identity authenticated?
• What permissions does it receive?
• How can access be limited to the minimum necessary?
• How are temporary and machine identities managed?
• How are cloud resources organized and identified?
• How are cost, security, compliance, and regional constraints enforced?
• How can an organization prove who accessed what and why?

Poor governance commonly produces excessive privileges, unmanaged credentials, abandoned resources, unexpected bills, and weak accountability. Effective governance treats access as a lifecycle rather than a one-time configuration task.

Learning Objectives

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

1. Distinguish users, groups, roles, service accounts, and federated identities.
2. Explain authentication, authorization, least privilege, and separation of duties.
3. Configure basic IAM patterns in AWS and GCP.
4. Design resource hierarchies using AWS Organizations and GCP resource structures.
5. Apply labels, tags, quotas, and organization-level policies.
6. Use temporary credentials and federation safely.
7. Maintain access accountability through logging, review, and change control.
8. Evaluate governance trade-offs in a realistic cloud deployment.

1. Identity and Access as a Control System

Authentication answers “Who are you?” Authorization answers “What may you do?” Accounting or accountability answers “What did you do, when, and under whose authority?” These are related but distinct controls.

An IAM decision can be represented conceptually as:

Here, a principal is an identity making a request; an action is an operation such as reading an object or deleting a virtual machine; a resource is the target; conditions include context such as time, source network, or authentication strength; and policy is the collection of rules evaluated by the platform. This is a conceptual model rather than a universal provider formula. Actual evaluation differs between AWS and GCP.

A request normally passes through these stages:

1. The principal authenticates, directly or through a federation provider.
2. The cloud platform identifies the requested action and resource.
3. Applicable policies are collected from the identity, group, role, resource, and organizational levels.
4. Explicit prohibitions, policy boundaries, or organization constraints are applied.
5. The request is allowed or denied.
6. An audit record may be generated.

A permission grant is not equivalent to successful access. The resource may not exist, the service may reject the request, a quota may be exceeded, or an organization policy may prohibit the operation.

Important terminology

2. AWS and GCP IAM Models

AWS

AWS IAM contains identities and policy documents. IAM users represent people or long-lived application identities inside an AWS account, although AWS generally recommends federated human access and IAM roles instead of creating many permanent users. Groups collect users and allow policies to be attached collectively. Roles are assumable identities that provide temporary credentials. Policies may be identity-based, resource-based, permissions boundaries, session policies, or organization-level controls such as service control policies (SCPs).

An AWS role has a trust policy and permission policies. The trust policy states who may assume the role; the permission policy states what the role may do after assumption. Confusing these two policies is a common configuration error.

For example, a deployment role might trust a CI/CD identity and permit deployment only to a designated account and service set. A production read-only role might be assumable by an operations group but deny modification actions.

AWS account boundaries are important governance units. AWS Organizations can group accounts into organizational units (OUs), attach SCPs, consolidate billing, and manage accounts centrally. An SCP sets the maximum permissions available to principals in member accounts; it does not itself grant permissions.

GCP

GCP IAM grants roles to principals on resources. A role contains permissions. A policy binds one or more principals to a role, optionally with conditions. Roles may be predefined by Google, basic roles such as Owner, Editor, and Viewer, or custom roles created by an organization.

GCP service accounts are identities for workloads. A workload can be granted permission to act as a service account, while the service account itself receives permissions on target resources. This distinction is central to secure impersonation. Google recommends avoiding service-account keys where possible and using attached identities, workload identity federation, or service-account impersonation.

GCP resources form a hierarchy: organization, folders, projects, and resources. Policies generally inherit downward. A policy at organization or folder level can affect many projects, while project-level policies provide local control. GCP Organization Policy constrains resource configuration, for example by restricting allowed locations or requiring specific constraints.

Comparison

The names differ, but the design principle is the same: central governance should constrain local administration without requiring every operational action to be performed centrally.

3. Least Privilege and Separation of Duties

Least privilege means granting only the permissions necessary for a defined task, for only as long as they are needed. It has four dimensions:

1. Action scope: permit required actions, not an entire service by default.
2. Resource scope: identify specific resources, projects, accounts, or paths.
3. Time scope: use temporary access and expiration where possible.
4. Context scope: restrict by environment, network, device, or authentication condition.

A useful design sequence is:

1. Define the task and owner.
2. Identify required actions and target resources.
3. Start with a narrow role or predefined role.
4. Test in a non-production environment.
5. Observe denied requests and add only justified permissions.
6. Remove unused permissions after deployment.
7. Review the role periodically.

Avoid beginning with AdministratorAccess in AWS or broad Owner/Editor grants in GCP merely to make deployment succeed. Such shortcuts conceal the real permission requirements and create difficult-to-remove privilege.

Separation of duties prevents one person or identity from controlling an entire sensitive process. For example, a developer may deploy application code, while a security administrator approves production policy changes. A CI/CD role may publish an artifact but not alter its approval record.

Permission boundaries and organization constraints provide defense in depth. A delegated administrator may create roles, but a boundary can prevent those roles from exceeding an approved maximum. A deny-based central policy can block risky services or regions even if a local administrator accidentally grants broad access.

Least privilege is not identical to “fewest permissions imaginable.” Excessive restriction can cause insecure workarounds, shared accounts, or disabled controls. The correct objective is the smallest justified permission set that supports the business task reliably.

4. Human Access, Workloads, and Federation

Human users

Human users should normally authenticate through a corporate identity provider (IdP), using single sign-on and multi-factor authentication (MFA). In AWS, federation can lead to role assumption through IAM Identity Center or another supported mechanism. In GCP, workforce identity federation can allow external employees to access cloud resources without maintaining separate Google credentials.

Direct root or superuser access should be exceptional, protected by MFA, monitored, and used only for tasks that require it. Root credentials must not be used by applications or routine administrators.

Workload identities

Applications need identities too. A virtual machine, container, function, or pipeline should receive a distinct identity appropriate to its task. Never embed access keys, service-account keys, or passwords in source code, container images, user data, or unrestricted configuration files.

Preferred patterns include:

• AWS IAM roles for EC2, ECS tasks, Lambda functions, and CI/CD federation.
• GCP service accounts attached to workloads.
• Short-lived tokens obtained through workload identity federation.
• Secret-manager systems for secrets that genuinely cannot be replaced by identity-based access.

A deployment pipeline should have separate identities for development, staging, and production. Production credentials should not be reusable in lower environments, and a compromise of a test account should not automatically provide production access.

Federation

Federation establishes trust between a cloud provider and an external IdP using standards such as SAML 2.0 or OpenID Connect (OIDC). The user authenticates with the IdP, and the cloud provider receives assertions or tokens containing identity and group information. The cloud platform maps those attributes to roles or permissions.

Federation reduces password duplication and supports centralized joiner, mover, and leaver processes. However, it introduces dependencies: incorrect attribute mappings, excessive group membership, clock problems, or an overly broad trust configuration can produce widespread access failures or privilege escalation.

Federation should therefore include:

• MFA and conditional access at the IdP.
• Explicit audience, issuer, and subject validation.
• Restricted trust relationships.
• Short token lifetimes.
• Tested emergency access procedures.
• Logging at both the IdP and cloud provider.

5. Resource Hierarchies and Governance Boundaries

Cloud hierarchy determines where policies, billing, administrators, and controls are applied. A sound structure reflects business and risk boundaries, not merely the organizational chart.

A typical AWS structure may contain a management account, security account, logging account, shared-services account, and separate workload accounts. OUs can group accounts by environment, business unit, or control requirements. Production accounts should normally be separated from development accounts because account-level isolation limits blast radius.

A typical GCP structure may contain one organization, folders for business units or environments, and projects for applications or bounded workloads. Projects are important because they commonly contain APIs, IAM bindings, quotas, billing associations, and service resources.

Governance questions include:

• Where should billing responsibility be assigned?
• Which administrators may create accounts or projects?
• Which locations and services are approved?
• How are logs retained centrally?
• What is the boundary for incident containment?
• Which resources must never be deployed together?

Policies inherited from high levels should be understandable and tested. A central restriction that is too broad can block legitimate operations; one that is too weak may provide a false sense of security.

6. Labels, Tags, and Ownership Metadata

Metadata supports governance, automation, cost allocation, and incident response. AWS tags are key-value metadata attached to supported resources. GCP labels are key-value metadata used for organization and cost analysis, while GCP tags, including network tags and resource-manager tags, serve different purposes depending on their type and use. These concepts should not be treated as interchangeable.

A practical metadata standard may require:

Metadata must be validated. A tag saying “production” does not itself enforce production security. Governance systems should combine metadata with policies, deployment controls, and audits. Required-tag controls may be implemented through AWS tag policies and preventive or detective controls, or through GCP policy and automation patterns, but provider support varies by resource type.

7. Quotas, Budgets, and Organization Policies

A quota limits resource consumption or API use, often to protect service capacity and prevent accidental exhaustion. A budget monitors or alerts on spending; it does not necessarily stop resource creation. A policy governs whether a configuration or action is allowed.

These controls address different failure modes:

AWS service quotas can be viewed and, for some services, increased. AWS Budgets provides alerts and actions, but cost data may be delayed. GCP quotas limit resource and API consumption and may be adjustable; Cloud Billing budgets provide monitoring and alerts. Neither quota nor budget replaces IAM.

AWS SCPs can deny use of unapproved regions or services across accounts. GCP Organization Policy constraints can restrict properties such as resource locations, allowed domains, external IP usage, or service-account key creation, subject to the specific constraint and product behavior. Policies must be tested against legitimate dependencies before enforcement.

8. Accountability, Auditing, and Access Reviews

Accountability requires reliable evidence. Audit logs should identify the principal, action, target resource, timestamp, source context, authentication method, and result where available. AWS CloudTrail records API activity, while GCP Cloud Audit Logs records administrative and data-access events according to service and configuration. Logs should be protected from alteration and centralized in a security-controlled location.

A mature review process includes:

1. An inventory of identities, roles, service accounts, keys, and policies.
2. An owner for every privileged identity and production role.
3. Regular review of membership and effective permissions.
4. Detection of unused credentials and anomalous activity.
5. Prompt removal when personnel or systems change.
6. Evidence of approval, review date, and remediation.

Access reviews should evaluate effective access, not merely direct grants. A user may receive permissions through multiple groups, inherited policies, role assumption, or service-account impersonation.

Useful operational indicators include the number of long-lived keys, age of unused credentials, percentage of resources with owners, number of privileged identities with MFA, and time taken to remove leavers. These are management indicators, not complete security measures; a low key count does not prove that permissions are appropriate.

9. Practical Configuration Patterns

AWS role-based deployment pattern

A practical arrangement is:

• Corporate IdP authenticates engineers.
• Engineers assume named roles in development or production accounts.
• CI/CD uses OIDC federation to assume a deployment role.
• The deployment role trusts only the approved CI provider and repository context.
• The role can modify specified services and resources, but cannot change organization controls or audit storage.
• CloudTrail logs are centralized and protected.

Illustrative AWS policy fragments should always be adapted and tested; policy syntax and supported condition keys vary by service. A resource scope such as a specific S3 bucket is safer than a wildcard, but some actions require broader resource notation because the service does not support resource-level permissions.

GCP service-account pattern

A GCP pipeline can authenticate through workload identity federation, impersonate a deployment service account, and receive short-lived credentials. The service account is granted only the roles required in the target project. A separate production service account is used for production, and the pipeline identity is granted the ability to impersonate it only from the approved repository and branch context.

For both providers, infrastructure should be defined as code where practical. Pull requests can require security review, automated policy checks, and plan review before applying changes. The state store or deployment metadata must itself be protected because it may contain resource identifiers and sensitive configuration.

10. Illustrative Case: Northstar Retail Platform

Background

Northstar Retail operates an online store and is migrating to AWS and GCP. Developers currently share administrator credentials during releases. Production and test resources are mixed, resource ownership is unclear, and monthly cloud costs fluctuate unexpectedly.

Problem

An audit finds long-lived access keys in a build server, no reliable record of who made production changes, and several unused virtual machines. The organization needs faster deployments without sacrificing accountability.

Analysis

The central problems are shared identity, excessive privilege, weak environment separation, and missing metadata. Merely changing passwords would not solve them. Northstar needs distinct human and workload identities, temporary access, resource boundaries, and monitoring.

Approach and solution

Northstar establishes separate production and non-production accounts/projects. A corporate IdP provides MFA and federated access. Developers receive read access by default and may assume a time-limited deployment role after approval. The pipeline uses OIDC or workload identity federation rather than stored cloud keys.

Production deployment roles are restricted to the services required by the application. Security administrators control logging and organization policies; developers cannot disable centralized audit storage. Every resource must include application, environment, owner, cost-center, and managed-by metadata. Budgets alert service owners, while quotas limit regional and API consumption.

AWS CloudTrail and GCP Cloud Audit Logs are centralized. Weekly automated checks identify unused keys, missing owners, public exposure, and policy changes. A quarterly human review confirms that role permissions still match job responsibilities.

Outcome

Northstar removes shared credentials, improves attribution, and reduces accidental production changes. Cost reporting becomes possible by application and team. Deployment initially requires more design work, but routine releases become safer because the pipeline has a predictable, narrowly defined identity.

Learning points

1. Identity separation is more effective than credential rotation alone.
2. Temporary federation reduces the exposure of long-lived secrets.
3. Hierarchy and metadata make governance scalable.
4. Budgets alert about cost; they do not replace quotas or authorization.
5. Accountability requires both technical logs and documented ownership.

11. Challenges, Ethics, and Contemporary Practice

IAM creates ethical and organizational responsibilities. Excessive monitoring can infringe privacy, while insufficient logging prevents investigation. Organizations should define legitimate purposes, retention periods, access controls for logs, and procedures for handling employee data. Regulatory requirements may apply to personal data, financial records, health information, or critical infrastructure; cloud controls should be mapped to the relevant legal and contractual obligations rather than assumed compliant by default.

Automation and AI can assist with permission analysis, anomaly detection, policy generation, and identifying unused access. However, automated recommendations may misunderstand business context or propose overly broad permissions. Human approval, testing, explainability, and rollback remain necessary. AI systems should not receive unrestricted administrative credentials merely because they generate infrastructure code.

Common limitations include provider-specific policy semantics, incomplete resource-level permission support, delayed audit or billing data, and operational pressure to bypass controls. Multi-cloud governance also creates translation problems: an AWS role is not identical to a GCP service account, and “tag,” “label,” “project,” and “account” have provider-specific meanings.

Best practices are therefore principle-based:

• Prefer federation and short-lived credentials.
• Use separate identities for people, pipelines, and applications.
• Grant narrow permissions at the narrowest practical scope.
• Separate production from non-production.
• Apply preventive controls centrally and detective controls continuously.
• Require ownership metadata and maintain an accurate inventory.
• Protect and review audit logs.
• Test policies before broad enforcement.
• Review effective access after organizational or application change.
• Document exceptions with an owner, reason, expiry date, and compensating controls.

Chapter Summary

Identity and resource governance provide the control foundation for safe cloud deployment. Authentication establishes identity, authorization evaluates permissions, and accountability records actions. AWS uses IAM users, groups, roles, policies, accounts, OUs, and SCPs; GCP uses principals, roles, policy bindings, service accounts, projects, folders, organizations, and Organization Policy. In both platforms, least privilege, separation of duties, temporary credentials, and federation reduce risk.

Resource hierarchies provide scalable policy and administrative boundaries. Tags and labels support ownership and cost allocation but do not independently enforce security. Quotas control consumption, budgets provide financial alerts, and organization policies restrict configurations. Audit logs, access reviews, credential lifecycle management, and documented exceptions maintain accountability. Effective governance is a continuing operational process that combines technical controls, human review, and clear ownership.

Key Terms

Identity: A represented person, workload, device, or external entity.

Principal: The identity evaluated in an access request.

Authentication: Verification of an identity.

Authorization: Evaluation of whether an action is permitted.

IAM: Identity and Access Management.

Role: A reusable set of permissions assumed by an identity.

Service account: A workload identity used by an application or automation.

Federation: Trust that permits an external identity provider to authenticate users or workloads.

Least privilege: Granting only the access necessary for a task.

Separation of duties: Dividing sensitive responsibilities among identities or teams.

Policy: Rules that grant, restrict, or condition access or configuration.

AWS Organizations: AWS service for centrally managing multiple accounts.

Service Control Policy: AWS organizational maximum-permission guardrail.

GCP project: A principal resource boundary containing services, resources, IAM, and quotas.

Organization Policy: GCP constraints applied through the resource hierarchy.

Tag: Provider-specific key-value or classification metadata, especially in AWS.

Label: GCP key-value metadata commonly used for organization and cost analysis.

Quota: A limit on resource or API consumption.

Audit trail: Evidence of actions, identities, resources, and outcomes.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorization?
2. Why should a workload generally use a role or service account instead of a person’s credentials?
3. What is the purpose of an AWS SCP?
4. How does a quota differ from a budget?
5. Why are tags and labels useful in governance?

Long Answer Questions

1. Explain how least privilege, separation of duties, and temporary credentials work together in a production deployment.
2. Compare AWS IAM roles with GCP service accounts, including trust, permission assignment, and workload use.
3. Describe a secure federation architecture for human administrators.
4. Explain how resource hierarchy supports centralized governance while preserving team autonomy.
5. Discuss the controls required to maintain accountability for production changes.

Analytical / Application Questions

1. A CI pipeline has administrator access in both development and production. Design a migration to federated, environment-specific identities and explain the controls you would introduce.
2. An organization wants to enforce a required owner tag on every cloud resource. Analyze why metadata alone is insufficient and propose preventive and detective controls.
3. A project repeatedly exhausts API quotas and incurs unexpected costs. Distinguish the IAM, quota, budget, metadata, and organizational-policy measures needed to address the problem.

Multiple Choice Questions with Answers

Question 1

Which AWS object primarily defines who is allowed to assume a role?

A. The role trust policy

B. The billing policy

C. The tag policy

D. The CloudTrail event

Correct Answer: A. The role trust policy

Question 2

What does least privilege require?

A. Giving every developer administrator access

B. Granting only the access necessary for a defined task

C. Disabling audit logging

D. Using one shared account for all deployments

Correct Answer: B. Granting only the access necessary for a defined task

Question 3

Which GCP resource commonly provides an identity for a workload?

A. A folder

B. A billing account

C. A service account

D. A label

Correct Answer: C. A service account

Question 4

What is the main purpose of federation?

A. To duplicate passwords across cloud accounts

B. To establish trust with an external identity provider

C. To increase storage quotas automatically

D. To replace audit logs

Correct Answer: B. To establish trust with an external identity provider

Question 5

What does an AWS Service Control Policy do?

A. Automatically grants administrator permissions

B. Sets a maximum permissions boundary for accounts

C. Creates application resources

D. Replaces MFA

Correct Answer: B. Sets a maximum permissions boundary for accounts

Question 6

Which control primarily limits resource or API consumption?

A. Quota

B. Label

C. Role trust policy

D. Audit record

Correct Answer: A. Quota

Question 7

Why should production and development workloads commonly be separated?

A. To prevent all use of automation

B. To reduce blast radius and clarify governance boundaries

C. To eliminate the need for IAM

D. To make billing impossible

Correct Answer: B. To reduce blast radius and clarify governance boundaries

Question 8

Which practice best protects workload credentials?

A. Embedding permanent keys in source code

B. Sharing a human administrator password

C. Using attached identities or short-lived federated credentials

D. Publishing keys in deployment logs

Correct Answer: C. Using attached identities or short-lived federated credentials

Question 9

What is the primary purpose of audit logs?

A. To grant permissions

B. To provide evidence of actions and access

C. To increase CPU capacity

D. To replace resource tags

Correct Answer: B. To provide evidence of actions and access

Question 10

Which statement correctly distinguishes a budget from a quota?

A. A budget monitors spending, while a quota limits consumption or API use

B. A budget authenticates users, while a quota records logs

C. A budget grants roles, while a quota creates projects

D. They are identical controls

Correct Answer: A. A budget monitors spending, while a quota limits consumption or API use