GCP Identity and Access Management – IAM

GCP Identity and Access Management

  • Google Cloud Identity and Access Management (IAM) lets administrators authorize who can take what action on which resources
  • IAM provides a unified view into security policy across the entire organization, with built-in auditing to ease compliance processes.

IAM Components

IAM manages access control by defining who (identity) has what access (role) for which resource

IAM architecture


    • A member can be a Google Account (for end users), a service account (for apps and virtual machines), a Google group, or a Google Workspace or Cloud Identity domain that can access a resource.
    • Identity of a member is an email address associated with a user, service account, or Google group; or a domain name associated with Google Workspace or Cloud Identity domains.


    • Permission to access a resource isn’t granted directly to the end user
    • A role is a collection of permissions and roles are granted to authenticated members.
    • Permissions are represented in the form service.resource.verb for e.g. compute.instances.list
    • Permissions determine what operations are allowed on a resource.
    • Role granted to a member grants all the permissions that the role contains
    • GCP supports different role types
      • Basic roles
        • Roles historically available in the Google Cloud Console. Also, referred to as primitive roles
        • Roles are Owner, Editor, and Viewer.
        • Provide board level of permissions and not recommended
      • Predefined roles
        • Roles that give finer-grained granular access control than the basic roles.
        • Roles are created and maintained by Google and automatically  updated as necessary, such as when Google Cloud adds new features or services.
      • Custom roles
        • Roles created to tailor permissions to the needs of the organization, when predefined roles don’t meet the needs.
        • Custom roles are not maintained by Google; when new permissions, features, or services are added to Google Cloud, the custom roles will not be updated automatically.

IAM Policy

    • IAM policy binds one or more members to a role.
    • An IAM policy defines and enforces what roles are granted to which members, and this policy is attached to a resource.
    • IAM policy attach to the resource defines who (member) has what type of access (role) on the resource
    • IAM policy can be set at any level in the resource hierarchy:  organization level,  folder level, the project level, or the resource level.
    • IAM Policy inheritance is transitive and resources inherit the policies of all of their parent resources.
    • Effective policy for a resource is the union of the policy set on that resource and the policies inherited from higher up in the hierarchy.
  • Basically  Permissions -> Roles -> (IAM Policy) -> Members
  • When an authenticated member attempts to access a resource, IAM checks the resource’s policy to determine whether the action is permitted.

Service Accounts

  • A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
  • Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as Google Workspace or Cloud Identity users through domain-wide delegation.
  • A service account is identified by its email address, which is unique to the account.
  • Service accounts do not have passwords, and cannot log in via browsers or cookies.
  • Service accounts are associated with private/public RSA key-pairs that are used for authentication to Google.
  • Other users or service accounts cannot impersonate a service account.
  • Service accounts are not members of the Google Workspace domain, unlike user accounts. If you share Google Workspace assets, like docs or events, with all members in your Google Workspace domain, they are not shared with service accounts.

Workload Identity Federation

  • Using identity federation, on-premises or multi-cloud workloads can be granted access to GCP resources, without using a service account key.
  • Identity federation can be used with AWS, or with any identity provider that supports OpenID Connect (OIDC), such as Microsoft Azure
  • With identity federation, IAM can be used to grant external identities IAM roles, including the ability to impersonate service accounts using short-lived access token, and eliminates the maintenance and security burden associated with service account keys.

IAM Recommender

  • IAM recommender helps enforce the principle of least privilege by ensuring that members have only the permissions that they actually need.
  • IAM uses Recommender to compare project-level role grants with the permissions that each member used during the past 90 days.
  • Depending on the usage of the member and permissions provided, IAM recommender recommends less permissive role or to revoke the role.
  • IAM recommender never suggests a change that increases a member’s level of access.
  • IAM recommender also uses machine learning to identify permissions in a member’s current role that the member is likely to need in the future, even if the member did not use those permissions in the past 90 days.
  • IAM recommender does not apply recommendations automatically, but the recommendations should be reviewed and then applied or dismissed.
  • IAM recommender does not evaluate
    • Role grants made at the folder or organization level
    • Role grants made below the project level; that is, role grants on service-specific resources within a project
    • Conditional role grants
    • Role grants for Google-managed service accounts
    • Access controls that are separate from IAM

IAM Audit Logging

  • Google Cloud services write audit logs to help answer the questions, “Who did what, where, and when?”
  • Cloud projects contain only the audit logs for resources that are directly within the project. Other entities, such as folders, organizations, and Cloud Billing accounts, contain the audit logs for the entity itself.
  • IAM writes Admin Activity audit logs, which record operations that modify the configuration or metadata of a resource. Admin Activity audit logs cannot be disabled
  • IAM writes Data Access audit logs, if explicitly enabled. Data Access audit logs contain API calls that read the configuration or metadata of resources, as well as user-driven API calls that create, modify, or read user-provided resource data.
  • IAM doesn’t write System Event audit logs.
  • IAM doesn’t write Policy Denied audit logs.
  • Cloud Audit Logs provides the following audit logs for each Cloud project, folder, and organization:
    • Admin Activity audit logs
    • Data Access audit logs
    • System Event audit logs
    • Policy Denied audit logs