Members (users, groups, service accounts) in GCP - Commands & Configuration

Introduction

In Google Cloud, members are identities like users, groups, or service accounts that can access resources. Managing members lets you control who can do what in your cloud projects.

When you want to give a colleague access to a project to view or edit resources.

When you need to allow a group of people to manage billing or permissions together.

When an application needs to access cloud resources securely using a service account.

When you want to remove access from someone who no longer needs it.

When setting up automated tasks that require permissions without using personal accounts.

Commands

This command adds Alice as a user with the Viewer role to the example-project, letting her see 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 member to add, such as a user, group, or service account.

→

--role - Defines the permissions level granted to the member.

This command shows the current list of members and their roles for the example-project, so you can verify who has access.

Terminal

gcloud projects get-iam-policy example-project

Expected Output

bindings:

- members:

  - user:[e-mail]

  role: roles/viewer

etag: BwWWja0YfJA=

version: 1

This command removes Alice's Viewer role from the example-project, revoking her access.

Terminal

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

Expected Output

Updated IAM policy for project [example-project].

→

--member - Specifies the member to remove.

→

--role - Specifies the role to remove from the member.

Key Concept

If you remember nothing else from this pattern, remember: members are identities you grant roles to, controlling their access to cloud resources.

Common Mistakes

Using the wrong member type prefix like 'user:' when adding a service account.

The command will fail or assign permissions incorrectly because the member type must match the identity.

Use 'serviceAccount:' prefix for service accounts, 'user:' for individual users, and 'group:' for groups.

Not specifying the correct role when adding a member.

The member may get too many or too few permissions, causing security risks or inability to perform tasks.

Choose the least privilege role that fits the member's needs, like roles/viewer for read-only access.

Forgetting to verify the IAM policy after changes.

You might think the change worked but the member still lacks or has access.

Always run 'gcloud projects get-iam-policy' to confirm the current members and roles.

Summary

Use 'gcloud projects add-iam-policy-binding' to add users, groups, or service accounts with specific roles.

Check current members and roles with 'gcloud projects get-iam-policy'.

Remove access using 'gcloud projects remove-iam-policy-binding' when no longer needed.

Practice

1. Which of the following is a correct way to specify a user as a member in GCP IAM?

easy

A. user:[e-mail]

B. serviceaccount:[e-mail]

C. group:[e-mail]

D. member:[e-mail]

Solution

1. Step 1: Understand member types in GCP IAM

   GCP IAM requires a prefix to identify the member type, such as user, group, or serviceaccount.

2. Step 2: Identify the correct prefix for a user

   The prefix for an individual user is user:. So the correct format is user:email.

3. Final Answer:

   user:[e-mail] -> Option A

4. Quick Check:

   User members start with 'user:' [OK]

Hint: User members always start with 'user:' prefix [OK]

Common Mistakes:

• Using 'member:' prefix which is invalid
• Confusing group and user prefixes
• Using serviceaccount prefix for users

2. Which of the following is the correct syntax to specify a service account member in GCP IAM?

easy

A. service-account:[e-mail]

B. serviceaccount:[e-mail]

C. group:[e-mail]

D. user:[e-mail]

Solution

1. Step 1: Recall the prefix for service accounts

   Service accounts use the prefix serviceaccount: followed by the full service account email.

2. Step 2: Check each option's prefix

   Only serviceaccount:[e-mail] uses the correct prefix serviceaccount: without hyphens or mistakes.

3. Final Answer:

   serviceaccount:[e-mail] -> Option B

4. Quick Check:

   Service accounts use 'serviceaccount:' prefix [OK]

Hint: Service accounts use 'serviceaccount:' prefix without hyphens [OK]

Common Mistakes:

• Using 'service-account:' with a hyphen
• Using 'user:' prefix for service accounts
• Using incomplete email addresses

3. Given the following IAM policy binding snippet, which member will have access?

{"role": "roles/viewer", "members": ["group:[e-mail]", "user:[e-mail]"]}

medium

A. Only users in the dev-team group and Bob

B. Only Bob

C. Only the dev-team group

D. All users in the project

Solution

1. Step 1: Analyze the members list in the policy

   The members list includes group:[e-mail] and user:[e-mail]. Both are granted the role.

2. Step 2: Understand access granted by group and user members

   All users in the dev-team group plus the individual user Bob have the role permissions.

3. Final Answer:

   Only users in the dev-team group and Bob -> Option A

4. Quick Check:

   Group and user members both get access [OK]

Hint: Group members grant access to all group users [OK]

Common Mistakes:

• Assuming only one member gets access
• Confusing group with user access scope
• Thinking all project users get access

4. You tried to add a member with user:alice to an IAM policy but got an error. What is the likely cause?

medium

A. IAM policy does not support user members

B. Using 'user:' prefix instead of 'group:'

C. Service account email used instead of user email

D. Missing full email address after 'user:' prefix

Solution

1. Step 1: Check the required format for user members

   User members must include the full email address after the user: prefix.

2. Step 2: Identify the error cause

   Using just user:alice is incomplete and causes a format error.

3. Final Answer:

   Missing full email address after 'user:' prefix -> Option D

4. Quick Check:

   User members need full email [OK]

Hint: Always include full email after 'user:' [OK]

Common Mistakes:

• Using only username without domain
• Confusing user and group prefixes
• Assuming IAM rejects user members

5. You want to grant a Cloud Function access to a Pub/Sub topic using a service account. Which member string should you add to the Pub/Sub IAM policy?

hard

A. group:[e-mail]

B. user:[e-mail]

C. serviceaccount:[e-mail]

D. service-account:[e-mail]

Solution

1. Step 1: Identify the correct member type for Cloud Function access

   Cloud Functions use service accounts to access other resources, so the member must be a service account.

2. Step 2: Use the correct prefix for service accounts

   The prefix is serviceaccount: followed by the full service account email.

3. Step 3: Verify the options

   Only serviceaccount:[e-mail] uses the correct prefix and format.

4. Final Answer:

   serviceaccount:[e-mail] -> Option C

5. Quick Check:

   Service accounts use 'serviceaccount:' prefix [OK]

Hint: Use 'serviceaccount:' prefix for Cloud Function identities [OK]

Common Mistakes:

• Using 'user:' prefix for service accounts
• Adding group instead of service account
• Using incorrect prefix with hyphen