Skip to content

Instantly share code, notes, and snippets.

@vhbui02
Created December 13, 2023 04:03
Show Gist options
  • Save vhbui02/3a8500237dbd6cd41d658699c55c74c9 to your computer and use it in GitHub Desktop.
Save vhbui02/3a8500237dbd6cd41d658699c55c74c9 to your computer and use it in GitHub Desktop.
[IAM learning] Learning about Google Cloud IAM #google-cloud

Usage

  • Grant granular access to specific resources
  • Prevent access to other resources
  • Adopt the security principle of least privilege (nobody should have more permissions that they need)

Mechanism

who (identity) has what access (role) for which resource.

Example of resources

A1: Compute Engine VM instances, GKE, Cloud Storage buckets, ...
A2: Organizations*, Folders, Projects that used to organize above mentioned resources, are also resources.

Granularity

Permission to access a resource isn't granted directly to the end-user* Permission are grouped into roles, roles are granted to authenticated principals/member (old term)

Allow policy/IAM policy

Defines and enforces what roles are granted to which resouce
Each Allow policy is attached to 1 resource
When a principal attempts to access a resource, IAM checks the resouces's Allow policy to determine whether the action is permitted.

Model for IAM: 3 parts

Principal:

  • Google Account (for end users)
  • Service account (for applications and compute workloads)
  • Google Workspace account
  • Cloud Identity domain
  • Google group
  • All authenticated users
  • All users Each principal has identifier, which is an email address

Permission: operation which is allowed to perform on a resource.

Role: A collection of permissions. Grant a role to a principal = grant all permissions that the role contains.

Policy: an Allow policy is a collection of role bindings that bind 1 or more principals to individual roles.
What you want to define who (principal) has what type of access (role) on a resource, you create an allow policy and attach it to the resource.

Principal / Identity

  • 7 types of principals

Google Account

  • A dev, an admin, a person interacts with Google Cloud, a Gmail.

Service Account

  • For app + compute workload, instead of end user
  • You can create as many service accounts as needed!
  • Note: in GKE, exists K8s service accounts, different from IAM service accounts.

Google group

  • A named collection of Google Accounts and service accounts.
  • 1 Google group ~ 1 unique email address
  • This is used to apply access controls to a collection of users.
  • Add/Remove principals instead of modify allow policy
  • Don't have login credentials, it doesn't represent an identity to access a resource

Google Workspace account

  • A virtual group for all Google Accounts.
  • GG Workspace accounts are associated with organization's internet domain name (e.g. vnu.edu.vn), every Google Account, or emails use this domain ([email protected]), that Google Account is added to the virtual group.
  • No establish identity
  • Enable permission management.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment