Members (users, groups, service accounts) in GCP - Deep Dive

Overview - Members (users, groups, service accounts)

What is it?

Members in Google Cloud Platform (GCP) are identities that can be given access to resources. These identities include individual users, groups of users, and service accounts which are special accounts used by applications or services. Each member can be assigned roles that define what actions they can perform on cloud resources. This system helps control who can do what in a cloud project.

Why it matters

Without members and their access controls, anyone could change or delete cloud resources, causing security risks and accidental damage. Members allow organizations to safely share cloud resources with the right people or services, ensuring only authorized actions happen. This protects data, controls costs, and keeps systems reliable.

Where it fits

Before learning about members, you should understand basic cloud concepts like projects and resources. After mastering members, you can learn about roles and permissions, and then dive into Identity and Access Management (IAM) policies that combine members and roles to secure cloud environments.

Mental Model

Core Idea

Members are the identities—people, groups, or services—that you give permission to use or manage cloud resources.

Think of it like...

Think of members like keys to a house: each key (user, group, or service) can open certain doors (resources) depending on the permissions given.

┌─────────────┐       ┌─────────────┐       ┌─────────────┐
│   User      │       │   Group     │       │ Service Acct│
└─────┬───────┘       └─────┬───────┘       └─────┬───────┘
      │                     │                     │
      │                     │                     │
      └─────────────┬───────┴─────────────┬───────┘
                    │                     │
             ┌──────▼──────┐       ┌──────▼──────┐
             │ Permissions │       │ Permissions │
             │ (Roles)     │       │ (Roles)     │
             └──────┬──────┘       └──────┬──────┘
                    │                     │
             ┌──────▼─────────────────────▼──────┐
             │           Cloud Resources           │
             └─────────────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What Are Members in GCP

Concept: Introduce the basic types of members in GCP: users, groups, and service accounts.

Members are identities that can access GCP resources. Users are individual people with Google accounts. Groups are collections of users managed together. Service accounts are special accounts used by applications or services to interact with GCP.

Result

You understand the three main member types and their roles in cloud access.

Knowing the types of members helps you decide who or what needs access to your cloud resources.

2

Foundation

How Members Relate to Access Control

Concept: Explain that members are assigned roles that grant permissions to resources.

In GCP, you don't give permissions directly to members. Instead, you assign roles to members. Roles bundle permissions like 'read storage' or 'manage compute instances'. This way, members get the right level of access without confusion.

Result

You see members as holders of roles that define their access.

Understanding this separation prevents giving too much or too little access by mistake.

3

Intermediate

Users vs Groups: Managing Access Efficiently

🤔Before reading on: do you think assigning permissions to groups is more efficient than to individual users? Commit to your answer.

Concept: Introduce groups as a way to manage many users at once.

Groups collect multiple users under one name. Instead of assigning roles to each user, you assign roles to the group. All users in the group inherit those roles. This saves time and keeps access consistent.

Result

You can manage access for many users by controlling group membership.

Knowing groups reduce repetitive work and errors when managing many users.

4

Intermediate

Service Accounts: Identities for Applications

🤔Before reading on: do you think service accounts are used by people or by programs? Commit to your answer.

Concept: Explain service accounts as non-human members used by applications or services.

Service accounts let programs authenticate and access GCP resources securely. For example, a web app can use a service account to read data from a database. They have their own keys and roles, separate from users.

Result

You understand that service accounts are essential for automated, secure cloud operations.

Recognizing service accounts prevents mixing human and program access, improving security.

5

Intermediate

Member Identity Formats in GCP

Concept: Show the exact format used to identify members in IAM policies.

Members are identified by strings like 'user:[e-mail]', 'group:[e-mail]', or 'serviceAccount:[e-mail]'. This format tells GCP what type of member it is and who exactly.

Result

You can read and write IAM policies with correct member identifiers.

Knowing the format avoids errors when setting permissions manually or via scripts.

6

Advanced

How Member Changes Affect IAM Policies

🤔Before reading on: do you think removing a user from a group immediately revokes their access? Commit to your answer.

Concept: Explain how member changes propagate through IAM policies and their timing.

When you add or remove members, IAM policies update to reflect changes. Removing a user from a group revokes their group-based permissions, but cached tokens might delay effect. Understanding this helps troubleshoot access issues.

Result

You can predict when access changes take effect and troubleshoot delays.

Knowing policy propagation timing prevents confusion about lingering access or sudden lockouts.

7

Expert

Service Account Impersonation and Delegation

🤔Before reading on: do you think any user can act as a service account by default? Commit to your answer.

Concept: Introduce advanced member usage where users or services can impersonate service accounts.

GCP allows users or services to 'impersonate' a service account if granted the 'Service Account Token Creator' role. This lets them act with the service account's permissions temporarily. It's powerful but must be tightly controlled to avoid privilege escalation.

Result

You understand how to securely delegate permissions using service account impersonation.

Recognizing impersonation risks and controls is key to maintaining secure, flexible cloud environments.

Under the Hood

GCP IAM stores member identities as strings linked to roles in policies attached to resources. When a request is made, GCP checks the member's identity against these policies to allow or deny actions. Groups are resolved by checking if a user belongs to them, and service accounts authenticate using cryptographic keys. The system caches permissions for performance but updates policies asynchronously.

Why designed this way?

This design separates identity from permissions for flexibility and security. Using strings for members allows easy integration with external identity providers. Groups simplify management at scale. Service accounts enable secure automation. Caching balances speed with eventual consistency, a tradeoff accepted for cloud scale.

┌───────────────┐
│   Request     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ IAM Policy DB │
│ (Members +    │
│  Roles)       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Access Check  │
│ (User in      │
│  Group?       │
│  ServiceAcct  │
│  Key Valid?)  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Allow or Deny │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think removing a user from a group instantly revokes their access? Commit to yes or no.

Common Belief: Removing a user from a group immediately removes their access to all resources granted to that group.

Reality: Access revocation can be delayed due to caching and token lifetimes, so users might retain access briefly after removal.

Why it matters: Assuming instant revocation can cause security gaps or confusion during audits and troubleshooting.

Quick: Do you think service accounts are just like regular user accounts? Commit to yes or no.

Common Belief: Service accounts are the same as user accounts and can be used interchangeably by people.

Reality: Service accounts are meant for applications and services, not humans, and have different authentication methods and security considerations.

Why it matters: Misusing service accounts for human access can lead to poor security and management difficulties.

Quick: Do you think assigning permissions directly to users is always better than using groups? Commit to yes or no.

Common Belief: Assigning permissions directly to individual users is simpler and better than using groups.

Reality: Using groups is more scalable and reduces errors by managing access for many users at once.

Why it matters: Ignoring groups leads to complex, error-prone permission management as teams grow.

Quick: Do you think any user can impersonate any service account by default? Commit to yes or no.

Common Belief: All users can act as any service account without extra permissions.

Reality: Impersonation requires explicit roles; without them, users cannot act as service accounts.

Why it matters: Assuming open impersonation risks overestimating security and missing necessary controls.

Expert Zone

1

Service accounts can have keys rotated automatically to reduce risk of key compromise, a practice often missed by beginners.

2

Groups can be nested, meaning a group can contain other groups, which affects how permissions propagate and complicates access reviews.

3

IAM policies are evaluated in a union model, so multiple roles from different bindings combine permissions, which can lead to unexpected access if not carefully audited.

When NOT to use

Avoid using broad group memberships or overly permissive service account roles in sensitive environments. Instead, use least privilege principles with narrowly scoped roles and consider using workload identity federation for external identities.

Production Patterns

In production, teams use groups to manage user access by department or project, service accounts for automated tasks with minimal permissions, and impersonation for temporary elevated access. Regular audits and automated policy checks ensure compliance and security.

Connections

Role-Based Access Control (RBAC)

Members are the 'who' in RBAC, which combines them with roles and permissions to control access.

Understanding members clarifies the identity part of RBAC, making it easier to design secure access systems.

Public Key Infrastructure (PKI)

Service accounts use cryptographic keys to authenticate, linking members to PKI concepts.

Knowing PKI basics helps understand how service accounts securely prove their identity without passwords.

Organizational Behavior

Groups in GCP mirror real-world teams and departments, reflecting organizational structures.

Recognizing this connection helps design access controls that align with how people work together.

Common Pitfalls

#1 Assigning permissions directly to many individual users instead of using groups.

Wrong approach:

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

Correct approach:

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

Root cause:

Not understanding that groups simplify permission management and reduce errors.

#2 Using a service account key file for a human user to log in.

Wrong approach:

gcloud auth activate-service-account --key-file=service-account-key.json
# Human tries to use this key to access resources

Correct approach:

gcloud auth login
# Human authenticates with their own Google account

Root cause:

Confusing service accounts with user accounts and their authentication methods.

#3 Assuming removing a user from a group immediately revokes access.

Wrong approach:

Remove user from group and expect instant access loss without checking token lifetimes or caches.

Correct approach:

Remove user from group and understand access may persist briefly; revoke tokens if immediate effect needed.

Root cause:

Not knowing about IAM policy caching and token expiration delays.

Key Takeaways

Members in GCP are identities like users, groups, and service accounts that receive permissions to access cloud resources.

Groups help manage many users efficiently by assigning roles once to the group instead of individually.

Service accounts are special members used by applications, not humans, and have unique authentication methods.

IAM policies link members to roles, controlling what actions they can perform on resources.

Understanding member types and their management is essential for secure and scalable cloud access control.