Access control (IAM vs ACLs) in GCP - CLI Comparison

Introduction

Access control helps decide who can do what with your cloud resources. IAM and ACLs are two ways to set these permissions. IAM gives broad control over resources, while ACLs control access to individual objects.

When you want to give a team member permission to manage all resources in a project.

When you need to allow a user to read only a specific storage bucket.

When you want to restrict access to a single file inside a storage bucket.

When you want to assign roles like viewer or editor to users across your cloud project.

When you want to control access at a very detailed level for individual objects.

Commands

This command gives Alice the Viewer role on the entire project, allowing her to view all resources but not change them.

Terminal

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

Expected Output

Updated IAM policy for project [example-project].

→

--member - Specifies the user or group to grant the role.

→

--role - Specifies the role to assign.

This command gives Bob read access to the specific storage bucket named example-bucket using ACLs.

Terminal

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

Expected Output

Updated ACL on gs://example-bucket.

→

-u - Specifies the user to change permissions for.

→

:R - Grants read permission.

This command shows the current ACL permissions set on the example-bucket so you can verify who has access.

Terminal

gsutil acl get gs://example-bucket

Expected Output

[

  {

    "entity": "[e-mail]",

    "role": "READER"

  },

  {

    "entity": "project-owners-123456789",

    "role": "OWNER"

  }

]

Key Concept

If you remember nothing else, remember: IAM controls access broadly at the project or resource level, while ACLs control access narrowly at the individual object level.

Common Mistakes

Trying to use ACLs to manage access for all project resources.

ACLs only work for individual storage objects or buckets, not for broad project permissions.

Use IAM roles to manage access at the project or resource level.

Assigning IAM roles without specifying the correct member format.

IAM commands require the member to be in the correct format like user:email or serviceAccount:email.

Always specify members with the correct prefix, for example user:[e-mail].

Not verifying ACL changes after applying them.

Without verification, you might not know if the permissions were applied correctly.

Use 'gsutil acl get' to check the current ACL settings after changes.

Summary

Use 'gcloud projects add-iam-policy-binding' to assign broad roles to users at the project level.

Use 'gsutil acl ch' to change access permissions on individual storage buckets or objects.

Verify ACL changes with 'gsutil acl get' to ensure correct permissions.

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