Skip to content


Identities and Roles

  • 4 types of Principals:
  • Two special members:
    • allAuthenticatedUsers: everyone authenticated to GCP, not just in your Org
    • allUser: anyone on the internet, authenticated or not
  • Set of permissions grouped together, each one representing a fine grained operation
  • Types:
    • Primitive (Basic) Roles
      • Apply 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

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
    • 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": ""


Cloud IAM recommender

  • Helps enforce the principle of least privilege by ensuring that members have only the permissions that they actually need
  • Functioning
    • Compares project-level role grants with permissions used within the last 90 days.
    • If a permission has not been used within that time, recommender will suggest revoking it
  • Gives three types of recommendations:
    • Revoke an existing role
    • Replace an existing role
    • Add permissions to an existing role

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


Recommendation Description
Manage Google Cloud permissions with groups
  • Avoid managing permissions for individual users
  • Best to assign Google Cloud roles to groups instead
Remove default permissions
  • When an Organization is first created, all users in the domain are automatically granted Project Creator and Billing Account Creator IAM roles at the organization level
Do not use the Default Compute Engine Service Account
  • By default, these default service accounts automatically receive the Editor role when they are created
  • Create a new Service Account and use it as the default account used by a VM
  • Disable Automatic IAM Grants for Default Service Accounts via Organizational Policies: constraints/iam.automaticIamGrantsForDefaultServiceAccounts
Back to top