Skip to content

Cloud IAM

With Cloud IAM you can grant granular access to specific GCP resources and prevent unwanted access to other resources. Cloud IAM lets you adopt the security principle of least privilege, so you grant only the necessary access to your resources

In Cloud IAM, you grant access to members. Members can be of following types:

  • People:
    • Google Account
    • Google Group (
    • G Suite Domain
      • A G Suite domain represents a virtual group of all the Google accounts that have been created in an organization's G Suite account. Like google Groups, G Suite domains cannot be used to establish identity, but they enable convenient permission management.
    • Cloue Identity domain
      • A Cloud Identity domain is like a G Suite domain because it represents a virtual group of all Google accounts in an organization. However, Cloud Identity domain users don't have access to G Suite applications and features.
  • Service Account:
    • Application access

Service Account

  • Special type Google Account that belongs to your application
  • Identity for carrying out server to server interactions in a project
    • example: Local server backup apps writting data to Cloud Storage
  • Identified with an Email address
    • <project_number>


  • Collection fo permission to give access to a given resource
  • Permission respresented in form <service>.<resource>.<verb>. Eg: compute.instaces.delete
  • Users are not directly assigned permissions, but are assigned roles which contain a collection of permissions
    • compute.instanceAdmin (role)
      • compute.instances.delete
      • compute.instances.get
      • compute.instances.list
      • compute.instances.start

Primitive vs Predefined (Curated) and Custom Roles


Historically available GCP roles before Cloud IAM waas implemented

  • Applied to Project level (can not assign to individual resources)
  • Broad roles
    • Viewer
      • Read only actions that perserve state (Can not make changes)
    • Editor
      • Same as above + can modify state
    • Owner
      • Same as above + mange access to project and all project resources
      • setup project billing


  • Much more granualar access, prevent unwanted access to other resources
  • Greanted at resource level
    • Eg: App Engine Admin - Full access to only App Engine resources
  • Multiple predefined roles can be given to an indiviual user

Custom Roles

  • Roles that you create to tailor permissions to the needs of your organization when predefined roles don't meet your needs

IAM Policy

  • You can grant roles to users by creating a Cloud IAM policy, which is a collection of statements that define who has what type of access. A policy is attached to a resource and is used to enforce access control whenever that resource is accessed.
  • A Cloud IAM policy is represented by the IAM Policy object. An IAM Policy object consists of a list of bindings. A Binding binds a list of members to a role.
  • You can set a Cloud IAM policy at any level in the resource hierarchy: the organization level, the folder level, the project level, or the resource level. Resources inherit the policies of the parent resource. If you set a policy at the organization level, it is automatically inherited by all its children projects, and if you set a policy at the project level, it's inherited by all its child resources. The effective policy for a resource is the union of the policy set at that resource and the policy inherited from higher up in the hierarchy.