Roles (basic, predefined, custom) in GCP - Deep Dive

Overview - Roles (basic, predefined, custom)

What is it?

Roles in Google Cloud Platform (GCP) are sets of permissions that define what actions a user or service can perform. There are three main types: basic roles, predefined roles, and custom roles. Basic roles are broad and cover many permissions, predefined roles are more specific and tailored to common tasks, and custom roles let you create your own permission sets. These roles help control access to cloud resources safely and efficiently.

Why it matters

Without roles, anyone could do anything in your cloud environment, which risks security and accidental damage. Roles let you give just the right amount of access to people or programs, protecting your data and services. This control helps companies avoid costly mistakes, data leaks, or downtime, making cloud use safer and more reliable.

Where it fits

Before learning about roles, you should understand basic cloud concepts like projects and permissions. After roles, you can learn about Identity and Access Management (IAM) policies and how to apply roles to users and services. This knowledge leads to mastering secure cloud architecture and compliance.

Mental Model

Core Idea

A role is a key that unlocks specific doors (permissions) in your cloud environment, controlling what actions are allowed.

Think of it like...

Think of roles like job badges in a company: a janitor badge lets you clean rooms, a manager badge lets you approve budgets, and a custom badge can be made for special tasks. Each badge gives access only to the areas needed for that job.

┌───────────────┐
│   User/Service│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│     Role      │
│ (Set of       │
│  Permissions) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Cloud Resource│
│ (What can be  │
│  accessed)    │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Permissions and Access

Concept: Permissions are specific actions allowed on cloud resources, like reading data or starting a server.

In GCP, every action you want to do needs permission. For example, to view files in storage, you need 'storage.objects.get' permission. Permissions are the smallest unit of access control.

Result

You know that permissions control what can be done, but managing them one by one is hard.

Understanding permissions is key because roles are just groups of these permissions bundled together.

2

Foundation

What Are Roles in GCP?

Concept: Roles group permissions to simplify access management.

Instead of assigning many permissions individually, GCP uses roles. A role is a collection of permissions. Assigning a role to a user or service account grants all permissions in that role.

Result

You can manage access more easily by assigning roles instead of individual permissions.

Knowing roles group permissions helps you see how GCP simplifies security management.

3

Intermediate

Basic Roles: Broad Access Sets

🤔Before reading on: do you think basic roles give very specific or very broad access? Commit to your answer.

Concept: Basic roles are broad and cover many permissions across all services.

GCP has three basic roles: Owner, Editor, and Viewer. Owner can do everything including managing roles, Editor can change resources but not manage roles, and Viewer can only see resources. These roles are easy to use but can give too much access.

Result

Assigning a basic role grants wide access, which might be more than needed.

Understanding basic roles helps you avoid giving too much access accidentally.

4

Intermediate

Predefined Roles: Tailored Permissions

🤔Before reading on: do you think predefined roles are created by users or by Google? Commit to your answer.

Concept: Predefined roles are created by Google to fit common job functions with specific permissions.

Google offers many predefined roles like 'Storage Admin' or 'Compute Viewer' that include only the permissions needed for those tasks. These roles help follow the principle of least privilege, giving users only what they need.

Result

Using predefined roles improves security by limiting access to necessary actions.

Knowing predefined roles exist helps you assign more precise access without creating roles yourself.

5

Intermediate

Custom Roles: Creating Your Own Access

🤔Before reading on: do you think custom roles can include any permissions or only a fixed set? Commit to your answer.

Concept: Custom roles let you combine permissions from any service to fit unique needs.

If basic or predefined roles don’t fit your needs, you can create custom roles. You pick exactly which permissions to include. This is useful for special jobs or security policies.

Result

Custom roles give you full control over access but require careful planning.

Understanding custom roles empowers you to tailor security precisely to your organization.

6

Advanced

Assigning Roles with IAM Policies

🤔Before reading on: do you think roles are assigned directly to users or through policies? Commit to your answer.

Concept: Roles are assigned to users or service accounts using IAM policies that define who has what role on which resource.

IAM policies are JSON documents that bind members (users, groups, or service accounts) to roles on resources like projects or buckets. This lets you control access at different levels.

Result

You can manage access flexibly and securely across your cloud environment.

Knowing how roles fit into IAM policies is crucial for effective access control.

7

Expert

Role Hierarchy and Permission Inheritance

🤔Before reading on: do you think permissions from roles assigned at a higher level apply to lower resources? Commit to your answer.

Concept: Roles assigned at higher resource levels apply to all resources below, creating inheritance of permissions.

If you assign a role at the project level, it applies to all resources in that project. This inheritance simplifies management but can cause unintended access if not carefully planned.

Result

You understand how access flows through resource hierarchy and can avoid privilege leaks.

Understanding inheritance prevents security mistakes and helps design clear access boundaries.

Under the Hood

GCP stores IAM policies as JSON documents attached to resources. Each policy lists bindings that connect members to roles. When a user requests an action, GCP checks all policies from the resource up through its parents to see if any role grants the needed permission. This evaluation happens quickly and securely to enforce access control.

Why designed this way?

This design balances flexibility and performance. By attaching policies at different resource levels and using role inheritance, GCP lets administrators manage access efficiently without repeating settings. It also supports a wide range of use cases from simple to complex security needs.

┌───────────────┐
│   User/Member │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│   IAM Policy  │
│ (Bindings:    │
│  Member → Role)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│    Role       │
│ (Permissions) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Cloud Resource│
│ (Project,     │
│  Bucket, VM)  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does assigning a basic role always give minimal access? Commit to yes or no.

Common Belief: Basic roles are safe because they are predefined and simple.

Reality: Basic roles are very broad and often give more permissions than needed, risking security.

Why it matters: Using basic roles carelessly can expose your cloud environment to accidental or malicious changes.

Quick: Can custom roles include permissions from any GCP service? Commit to yes or no.

Common Belief: Custom roles are limited to a fixed set of permissions.

Reality: Custom roles can include any permissions available in GCP, allowing precise access control.

Why it matters: Knowing this lets you create roles perfectly matched to your needs, improving security.

Quick: Does assigning a role at a resource level affect only that resource? Commit to yes or no.

Common Belief: Roles assigned to a resource affect only that resource.

Reality: Roles assigned at higher levels (like projects) apply to all child resources, due to inheritance.

Why it matters: Misunderstanding inheritance can lead to unintended access and security breaches.

Quick: Are IAM policies only attached to users? Commit to yes or no.

Common Belief: IAM policies are assigned only to individual users.

Reality: IAM policies can assign roles to users, groups, and service accounts, enabling flexible access management.

Why it matters: Ignoring service accounts or groups can cause gaps or excesses in access control.

Expert Zone

1

Custom roles must be carefully maintained as GCP updates permissions; some permissions may be deprecated or added, requiring role updates.

2

Predefined roles are updated by Google to reflect best practices, so using them can reduce maintenance compared to custom roles.

3

Role assignment at the organization level can override project-level roles, creating complex access scenarios that require careful policy review.

When NOT to use

Avoid using basic roles in production environments due to their broad permissions; prefer predefined or custom roles. For very dynamic or temporary access, consider using IAM Conditions or Access Context Manager instead of static roles.

Production Patterns

In production, teams often use predefined roles for common tasks and custom roles for specialized needs. They assign roles at the project or folder level to manage access inheritance and use service accounts with minimal roles for automation. Regular audits ensure roles match current needs.

Connections

Access Control Lists (ACLs)

Both control access but ACLs assign permissions directly to resources, while roles group permissions for easier management.

Understanding roles helps grasp why grouping permissions simplifies access control compared to managing many ACL entries.

Principle of Least Privilege (Security)

Roles enable applying the principle by granting only necessary permissions to users or services.

Knowing roles supports least privilege helps design secure cloud environments that minimize risk.

Organizational Hierarchies (Business Management)

Role inheritance in GCP mirrors how authority flows in organizations from top management to teams.

Seeing this connection clarifies why permissions assigned at higher levels affect all sub-levels, just like decisions cascade in companies.

Common Pitfalls

#1 Assigning Owner role to all users for convenience.

Wrong approach:

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

Correct approach:

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

Root cause:

Misunderstanding that Owner role grants full control, which is often unnecessary and risky.

#2 Creating custom roles without reviewing permissions regularly.

Wrong approach:

Creating a custom role once and never updating it as GCP evolves.

Correct approach:

Regularly auditing and updating custom roles to align with current permissions and security needs.

Root cause:

Assuming roles are static and do not require maintenance.

#3 Assigning roles only at resource level without considering inheritance.

Wrong approach:

Assigning a role to a VM instance but ignoring project-level roles that grant broader access.

Correct approach:

Reviewing IAM policies at all levels to understand effective permissions.

Root cause:

Not understanding how IAM policies inherit permissions through resource hierarchy.

Key Takeaways

Roles in GCP group permissions to control who can do what with cloud resources.

Basic roles are broad and easy but often too powerful; predefined roles offer more precise access.

Custom roles let you tailor permissions exactly but require careful management.

IAM policies assign roles to users or services, and permissions inherit down resource hierarchies.

Understanding roles and their assignment is essential for secure and efficient cloud access control.