Skip to content


Identities and Roles

  • 4 types of Principals:
  • Two special members:
    • allAuthenticatedUsers: everyone authenticated to GCP, not just in your Org
    • allUsers: anyone on the internet, authenticated or not
  • Set of permissions grouped together, each one representing a fine grained operation
  • Boundaries
    • Can set limits on the roles that a member can grant: let you create limited IAM admins who can manage their own team's IAM policies, but only within the boundaries set
    • IAM Conditions: you can attach conditions to role bindings. For example you can set an expiration time, or you can scope down the binding to affect only certain resources matching a pattern
  • Types:
    • Primitive (Basic) Roles
      • Applied across all resources in a project
      • Managed by Google, so the set of permissions can change over time
      • Can assign ACL grants (legacy authz system for Buckets/BigQuery) to those bound to a primitive role in the Project
    • Predefined roles
      • Apply to a particular GCP service in a project
      • Provide granular access for a specific service
      • Managed by Google
    • Custom Roles
  • Each policy contains a set of roles and role members
  • Policies are inherited downwards in the hierarchy
  • Resource policies are a UNION of parent and resource:
    • Policies implemented at a higher level in the hierarchy can't take away access that's granted at a lower level
    • If a parent policy is less restrictive, it overrides a more restrictive resource policy
    • If a parent policy is more restrictive, it does not override a less restrictive resource policy

Policy Evaluation

Service Accounts

General Info


Type Description
User Managed
  • Manually created by users, alongside a private key
  • Google only stores the public portion of a user-managed key
  • Keys lifecycle is your responsibility
Google Managed
  • All service accounts have Google-managed keys
  • Google stores both the public and private portion of the key
    • No need to generate keys for them
    • Private keys are never directly accessible
  • Applications can just assume their identity
  • Example:
    • Each Project comes with a default service account that is used by Compute Engine (GCE) services (assigned the Project Editor role)
    • VMs will transparently be identified by that service account, and they are authorized to request short-lived authorization tokens from the internal metadata service
Structure of a Service Account Key
  "type": "service_account",
  "project_id": "project-id",
  "private_key_id": "key-id",
  "private_key": "-----BEGIN PRIVATE KEY-----\nprivate-key\n-----END PRIVATE KEY-----\n",
  "client_email": "service-account-email",
  "client_id": "client-id",
  "auth_uri": "",
  "token_uri": "",
  "auth_provider_x509_cert_url": "",
  "client_x509_cert_url": ""

Access Scopes

  • Access scopes provide the ability to limit what permissions are allowed when using the GCE default service account
  • Although is better to use a custom SA with IAM roles
  • Only apply on a per-instance basis (instance must be stopped to change it)


Scope Description
Allow default access Read-only access to storage, access to Stackdriver logging and monitoring
Allow full access Grant full access to all Cloud APIs
Set access for each API Grant access to only the APIs required by the programs running on the VM

Other Useful Services

Service Description
Workload Identity federation
  • General Info
    • Keyless application authentication mechanism that allows workloads running on-premises, in AWS, or in Azure to federate with an external Identity provider (IdP) and call Google Cloud resources without using a service account key
    • Workloads instead call GCP's security token service (STS) endpoint to exchange the authentication token they obtained from the IdP for a short-lived GCP access token
    • Workloads then use this access token to impersonate a service account and inherit the permissions of the service account to access GCP resources
  • Setup Process
    • Create a workload identity pool resource object (the pool acts as a container for the collection of external identities)
    • Connect one or more IdPs to the workload identity Pool. The IdP can be an AWS or Azure account(s) or provider(s) that support OIDC protocol
    • Grant the pool access to resources by defining two IAM policies
      • A policy granting a service account access to desired resources. You can create a new service account or re-use an existing service account
      • A policy that allows identities from the pool to impersonate the service account
    • Authenticate workloads to the STS endpoint, impersonate the service account, and have them call the desired GCP APIs
  • See also: Best practices for using workload identity federation
Cloud IAM recommender
IAM Policy Simulator
  • Lets you see how an IAM policy change might impact a member's access before you commit to making the change
IAM Policy Troubleshooter
  • Helps more closely examine policies that govern user access to a particular resource
  • Makes it easier to understand why a user has access to a resource or doesn't have permission to call an API
  • Functioning
    • Requires a member email, a resource name, and a permission to check
    • Examines all IAM policies that apply to that resource
    • Reports on whether that member's roles include that permission to that resource
    • Reports on which policies bind that member to those roles
  • Limitations
    • It will only access policies that the user has permissions to view
    • If you do not have access to a resource policy, it will not be analyzed
    • Maximum effectiveness requires the Security Reviewer (roles/iam.securityReviewer) role