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.

Practice

1. What is the main difference between IAM and ACLs in Google Cloud Platform?

easy

A. IAM and ACLs are exactly the same in functionality.

B. IAM controls network traffic, and ACLs control user passwords.

C. IAM is only for virtual machines, ACLs are for storage only.

D. IAM manages access at resource levels using roles, while ACLs manage access at object or bucket levels.

Solution

1. Step 1: Understand IAM scope

   IAM controls access broadly by assigning roles to users or groups at resource levels like projects or services.

2. Step 2: Understand ACL scope

   ACLs control access more narrowly, typically at the object or bucket level in storage services.

3. Final Answer:

   IAM manages access at resource levels using roles, while ACLs manage access at object or bucket levels. -> Option D

4. Quick Check:

   IAM = broad roles, ACLs = fine-grained object permissions [OK]

Hint: IAM is broad roles; ACLs are fine-grained permissions [OK]

Common Mistakes:

• Confusing IAM with network controls
• Thinking ACLs control passwords
• Assuming IAM and ACLs are identical

2. Which of the following is the correct way to grant a user the role of 'Storage Object Viewer' using IAM in GCP?

easy

A. Edit the user's password in the IAM console.

B. Add the user to the ACL of the bucket with read permission.

C. Use the command: gcloud projects add-iam-policy-binding my-project --member='user:[e-mail]' --role='roles/storage.objectViewer'

D. Create a firewall rule allowing the user access.

Solution

1. Step 1: Identify IAM command syntax

   The correct gcloud command to grant IAM roles uses 'add-iam-policy-binding' with member and role flags.

2. Step 2: Verify role and member format

   The role 'roles/storage.objectViewer' and member format 'user:[e-mail]' are correct for granting read access to storage objects.

3. Final Answer:

   Use the command: gcloud projects add-iam-policy-binding my-project --member='user:[e-mail]' --role='roles/storage.objectViewer' -> Option C

4. Quick Check:

   IAM role grant uses gcloud add-iam-policy-binding [OK]

Hint: Use gcloud add-iam-policy-binding with correct role and member [OK]

Common Mistakes:

• Confusing ACL changes with IAM commands
• Editing passwords instead of roles
• Using firewall rules for access control

3. Given the following IAM policy snippet for a bucket, what access does the user 'user:[e-mail]' have?

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": ["user:[e-mail]"]
    }
  ]
}

medium

A. Alice can only read objects in the bucket.

B. Alice can create, delete, and update objects in the bucket.

C. Alice has no access to the bucket.

D. Alice can manage IAM policies but not objects.

Solution

1. Step 1: Identify the role assigned

   The role 'roles/storage.objectAdmin' allows full control over objects in the bucket, including create, delete, and update.

2. Step 2: Confirm member access

   The member 'user:[e-mail]' is assigned this role, so Alice has these permissions.

3. Final Answer:

   Alice can create, delete, and update objects in the bucket. -> Option B

4. Quick Check:

   roles/storage.objectAdmin = full object control [OK]

Hint: objectAdmin role means full object permissions [OK]

Common Mistakes:

• Confusing objectAdmin with read-only roles
• Assuming no access without explicit bucket ACL
• Mixing IAM roles with IAM policy management

4. You tried to grant a user access to a Cloud Storage bucket by adding them to the bucket's ACL, but they still cannot access the objects. What is the likely issue?

medium

A. The bucket has uniform bucket-level access enabled, which disables ACLs.

B. The user needs to restart their computer.

C. The user's email address was misspelled in the ACL.

D. The user was not granted an IAM role at the project level.

Solution

1. Step 1: Understand uniform bucket-level access

   When uniform bucket-level access is enabled, ACLs are disabled and only IAM controls access.

2. Step 2: Check ACL effect

   Adding users to ACLs has no effect if uniform bucket-level access is on, so the user cannot access objects despite ACL changes.

3. Final Answer:

   The bucket has uniform bucket-level access enabled, which disables ACLs. -> Option A

4. Quick Check:

   Uniform bucket-level access disables ACLs [OK]

Hint: Uniform bucket-level access disables ACLs [OK]

Common Mistakes:

• Assuming ACLs always work regardless of bucket settings
• Blaming user typos without verification
• Thinking user restart affects cloud permissions

5. You want to allow a third-party service to read specific objects in your Cloud Storage bucket without giving it full project access. Which approach is best?

hard

A. Add the service account to the bucket's ACL with READER permission on specific objects.

B. Enable uniform bucket-level access and grant the service account the storage.admin role.

C. Grant the service an IAM role at the project level with storage.objectViewer permission.

D. Create a firewall rule to allow the service IP to access the bucket.

Solution

1. Step 1: Understand access scope needs

   The third-party service needs access only to specific objects, not the whole project.

2. Step 2: Choose fine-grained control method

   ACLs allow granting permissions on specific objects or buckets, ideal for limited access.

3. Step 3: Evaluate other options

   IAM roles at project level are too broad; storage.admin is too powerful; firewall rules do not control storage access.

4. Final Answer:

   Add the service account to the bucket's ACL with READER permission on specific objects. -> Option A

5. Quick Check:

   Use ACLs for fine-grained object access [OK]

Hint: Use ACLs for specific object access, IAM for broad access [OK]

Common Mistakes:

• Granting overly broad IAM roles
• Confusing firewall rules with access control
• Using storage.admin role unnecessarily