Access control (IAM vs ACLs) in GCP - Trade-offs & Expert Analysis

Overview - Access control (IAM vs ACLs)

What is it?

Access control is how cloud systems decide who can do what with resources. IAM (Identity and Access Management) and ACLs (Access Control Lists) are two ways to set these permissions. IAM uses roles assigned to users or groups, while ACLs list specific permissions on individual resources. Both help keep cloud resources safe by controlling access.

Why it matters

Without access control, anyone could change or delete important cloud resources, causing data loss or security breaches. IAM and ACLs protect resources by making sure only the right people or systems can use them. This keeps data safe, prevents mistakes, and helps companies follow rules and laws.

Where it fits

Before learning access control, you should understand cloud resources and users. After this, you can learn about advanced security topics like encryption, auditing, and network security. Access control is a foundation for all cloud security practices.

Mental Model

Core Idea

Access control is like a security guard who checks a list to decide who can enter or use each resource.

Think of it like...

Imagine a building with rooms. IAM is like giving people badges that say what rooms they can enter. ACLs are like a list on each door showing exactly who can come in and what they can do inside.

Access Control System
┌───────────────┐       ┌───────────────┐
│     Users     │──────▶│     IAM       │
└───────────────┘       └───────────────┘
                            │
                            ▼
                     ┌───────────────┐
                     │ Cloud Resource│
                     └───────────────┘


Access Control List (ACL) on Resource:
┌─────────────────────────────┐
│ Resource: Storage Bucket     │
│ ACL:                        │
│ - User A: Read              │
│ - User B: Read, Write       │
│ - User C: No Access         │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is Access Control?

Concept: Access control means deciding who can use or change cloud resources.

Access control is a way to protect cloud resources like files, databases, or servers. It answers the question: who is allowed to do what? For example, who can read a file, who can change it, and who cannot touch it at all.

Result

You understand that access control is about permissions and security for cloud resources.

Knowing access control is the first step to keeping cloud resources safe from unwanted changes or access.

2

Foundation

Introduction to IAM

Concept: IAM assigns roles to users or groups to control access across many resources.

IAM stands for Identity and Access Management. It lets you create roles like 'Viewer', 'Editor', or 'Admin'. You assign these roles to users or groups. Each role has a set of permissions. For example, a Viewer can only read data, while an Editor can change it. IAM works across many resources in the cloud.

Result

You can explain how IAM uses roles to manage access for many users and resources.

Understanding IAM roles helps you manage permissions at scale without listing every user on every resource.

3

Intermediate

Understanding ACLs

Concept: ACLs list specific permissions for individual users on a single resource.

ACL stands for Access Control List. It is a list attached directly to a resource, like a storage bucket or a file. The list names users and what they can do, such as read or write. Unlike IAM, ACLs control access one resource at a time and are more detailed but harder to manage for many users.

Result

You can describe how ACLs work by listing permissions per user on each resource.

Knowing ACLs helps you understand fine-grained control but also why they can become complex in large systems.

4

Intermediate

Comparing IAM and ACLs

🤔Before reading on: do you think IAM or ACLs are better for managing access to many resources? Commit to your answer.

Concept: IAM is better for broad, role-based access; ACLs are for detailed, resource-specific control.

IAM lets you assign roles to users or groups once, and those roles apply to many resources. ACLs require setting permissions on each resource separately. IAM is easier to manage at scale and reduces mistakes. ACLs give more detailed control but can be hard to keep consistent.

Result

You understand when to use IAM versus ACLs based on scale and control needs.

Knowing the strengths and limits of IAM and ACLs helps you design secure and manageable access policies.

5

Intermediate

How IAM Roles and Permissions Work

🤔Before reading on: do you think a user can have multiple roles at once? Commit to your answer.

Concept: Users can have multiple roles, and permissions combine to allow or deny actions.

In IAM, a user can have many roles from different groups or projects. Permissions from all roles add up. If any role allows an action, the user can do it unless explicitly denied. This lets you build flexible access by mixing roles. Roles are predefined sets of permissions or custom sets you create.

Result

You can explain how multiple roles combine to give users their final permissions.

Understanding role combination prevents confusion about why a user can or cannot do something.

6

Advanced

Using IAM and ACLs Together

🤔Before reading on: do you think IAM and ACLs can be used at the same time on the same resource? Commit to your answer.

Concept: IAM and ACLs can both control access, but IAM usually overrides ACLs in GCP.

In Google Cloud, IAM is the main way to control access. Some resources still support ACLs for backward compatibility or special cases. When both exist, IAM permissions generally take priority. Using both can cause confusion, so best practice is to use IAM whenever possible and avoid ACLs unless necessary.

Result

You know how IAM and ACLs interact and why to prefer IAM.

Knowing how IAM and ACLs overlap helps avoid security gaps and simplifies management.

7

Expert

IAM Policy Evaluation and Inheritance

🤔Before reading on: do you think IAM policies set on a project apply to all resources inside it? Commit to your answer.

Concept: IAM policies inherit down the resource hierarchy, combining permissions from parent to child.

IAM policies can be set at different levels: organization, folder, project, or resource. Permissions set at a higher level apply to all resources below it unless overridden. When a user requests access, GCP evaluates all relevant policies from top to bottom and combines them. This inheritance makes managing permissions easier but requires careful planning to avoid unintended access.

Result

You understand how IAM policies inherit and combine across resource levels.

Understanding policy inheritance is key to designing secure and scalable access control in GCP.

Under the Hood

IAM works by storing policies that map users or groups to roles with permissions. When a user tries to access a resource, the system checks all policies attached to that user and resource, including inherited ones, to decide if the action is allowed. ACLs are simpler lists attached directly to resources, checked individually for each access request.

Why designed this way?

IAM was designed to simplify managing permissions at scale by grouping permissions into roles and applying them broadly. ACLs existed earlier for fine-grained control but became hard to manage as cloud environments grew. IAM's hierarchical policies and roles reduce errors and improve security by centralizing control.

IAM Policy Evaluation Flow
┌───────────────┐
│ User Request  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Check IAM     │
│ Policies at:  │
│ Org > Folder >│
│ Project > Res │
└──────┬────────┘
       │ Combine
       ▼ Permissions
┌───────────────┐
│ Allow or Deny │
└───────────────┘


ACL Check (if used):
┌───────────────┐
│ Resource ACL  │
│ List of Users │
│ and Permissions│
└──────┬────────┘
       │ Check if user
       ▼ has access
┌───────────────┐
│ Allow or Deny │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think ACLs are the main way to control access in GCP today? Commit yes or no.

Common Belief: ACLs are the primary method for access control in Google Cloud.

Reality: IAM is the main and recommended access control method in GCP; ACLs are legacy and limited.

Why it matters: Relying on ACLs can cause inconsistent security and harder management, risking accidental exposure.

Quick: Do you think a user denied permission in one IAM role can still perform the action if another role allows it? Commit yes or no.

Common Belief: If any role denies a permission, the user cannot perform the action, even if another role allows it.

Reality: IAM uses an allow-based model; explicit denies are rare. If any role allows the action, the user can perform it.

Why it matters: Misunderstanding this can lead to over-restricting or under-restricting access, causing security or usability issues.

Quick: Do you think IAM policies set at the project level do NOT affect resources inside the project? Commit yes or no.

Common Belief: IAM policies only apply to the exact resource they are set on, not to child resources.

Reality: IAM policies inherit down the resource hierarchy, so project-level policies affect all resources inside the project.

Why it matters: Ignoring inheritance can cause unexpected access or denial, leading to security holes or blocked workflows.

Quick: Do you think using both IAM and ACLs together always improves security? Commit yes or no.

Common Belief: Using both IAM and ACLs together makes access control more secure by adding layers.

Reality: Using both can cause confusion and conflicts, making security weaker and management harder.

Why it matters: Mixing controls without clear rules can lead to mistakes and accidental access.

Expert Zone

1

IAM roles can be predefined by Google or custom-created, allowing precise permission tailoring.

2

IAM policy bindings support conditions, enabling access only under specific circumstances like time or IP address.

3

ACLs still exist for some legacy services and interoperability but are being phased out in favor of IAM.

When NOT to use

Avoid using ACLs for new projects; prefer IAM for scalable and manageable access control. Use ACLs only when working with legacy systems or specific resources that require them.

Production Patterns

In production, teams use IAM roles combined with groups and service accounts to manage access. They apply least privilege principles, granting only needed permissions. Policies are set at organization or project levels to simplify management and use conditions for extra security.

Connections

Role-Based Access Control (RBAC)

IAM is a cloud implementation of RBAC principles.

Understanding RBAC helps grasp why IAM uses roles to simplify permission management across many users and resources.

Firewall Rules

Both control access but at different layers: IAM controls user permissions, firewalls control network traffic.

Knowing the difference helps design layered security, combining who can access resources with how network traffic is allowed.

Legal Access Control in Physical Security

Both use lists and roles to control who can enter or use assets.

Recognizing access control in physical security clarifies cloud access control concepts and the importance of clear policies.

Common Pitfalls

#1 Granting overly broad permissions to users.

Wrong approach:

gcloud projects add-iam-policy-binding my-project --member='user:[e-mail]' --role='roles/editor'

Correct approach:

gcloud projects add-iam-policy-binding my-project --member='user:[e-mail]' --role='roles/viewer'

Root cause:

Misunderstanding the principle of least privilege leads to giving users more access than needed, increasing risk.

#2 Setting ACLs without considering IAM policies.

Wrong approach:

gsutil acl ch -u [e-mail]:R gs://my-bucket

Correct approach:

Use IAM roles to grant access: gcloud projects add-iam-policy-binding my-project --member='user:[e-mail]' --role='roles/storage.objectViewer'

Root cause:

Not knowing that IAM is preferred and ACLs can conflict causes inconsistent access control.

#3 Assuming IAM policies do not inherit.

Wrong approach:

Setting permissions only on individual resources and ignoring project-level policies.

Correct approach:

Set IAM policies at the project or folder level to cover all resources inside.

Root cause:

Lack of understanding of IAM policy inheritance leads to incomplete or redundant permissions.

Key Takeaways

Access control protects cloud resources by deciding who can do what.

IAM uses roles assigned to users or groups for scalable and manageable permissions.

ACLs list permissions per user on individual resources but are less scalable.

IAM policies inherit down the resource hierarchy, simplifying broad access management.

Using IAM over ACLs reduces complexity and improves security in Google Cloud.