Permissions Reference

Permissions Reference for GCP IAM: A website built in order to provide an alternate, community-driven source of truth for GCP identity

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 Service Account of Compute Engine
  • By default, these default service accounts automatically receive the Editor role when they are created
  • Steps
    • Create a new dedicated Service Account and use it as the default account used by a VM
    • Revoke the Editor role for the Compute Engine default service account
    • Disable the default Compute Engine service account
    • Use Organization Policies to Disable Automatic IAM Grants for Default Service Accounts so the Compute Engine Default Service Account is not granted the Editor role by default (constraints/iam.automaticIamGrantsForDefaultServiceAccounts)
    • Use Security Health Analytics to detect FULL_API_ACCESS, indicating that a VM instance is configured to use the default service account with full access to all Google Cloud APIs
Limit access to service account credentials
  • Avoid creating service account keys whenever possible
  • Use Organization Policies to:
    • Disable service account key creation and ensure that users can't create and download user-managed private keys for service accounts
    • Disable service account creation for projects that shouldn't host service accounts
  • Use Upload Service Account key to authenticate on-prem services with Google Cloud using a key in a Hardware Security Module
  • Use the --impersonate-service-account flag to execute gcloud commands as a service account instead of using an exported service account key
  • Use Security Health Analytics to detect broad use of the Service Account User role and existing service account keys:
    • SERVICE_ACCOUNT_KEY_USER_MANAGED: a user-managed private key for service accounts exists
    • SERVICE_ACCOUNT_KEY_NOT_ROTATED: a user-managed private key for a service account has not been rotated in 90 days
    • OVER_PRIVILEGED_SERVICE_ACCOUNT_USER: an IAM member has the Service Account User role at the project level, instead of for a specific service account.
Reduce the Authorization Scopes with IAM Recommender
  • IAM Recommender continuously scan role bindings and suggest changes to reduce the authorization scope
Use IAM Boundaries
Use IAM Deny Policies
  • IAM deny policies allows to set guardrails on access to Google Cloud resources
  • You can define deny rules that prevent certain principals from using certain permissions, regardless of the roles they're granted
Choose the best way to use and authenticate service accounts on Google Cloud
Best practices for securing service accounts
  • This guide presents best practices for limiting the privileges of service accounts and mitigating major risks they might incur in
Use OS Login to manage access to VMs
  • Avoid manually managing SSH keys in VM instance metadata
  • Avoid allowing project-wide SSH keys that can be used to connect to all VMs in a project
  • Use OS Login to manage access to VMs based on IAM identities
  • Use Organization Policies to Require OS Login: all VM instances created in new projects will have OS Login enabled. On new and existing projects, this constraint prevents metadata updates that disable OS Login at the project or instance level.
  • Use Security Health Analytics to ensure that OS Login is enabled and that project-wide SSH keys are not used
    • OS_LOGIN_DISABLED: OS Login is disabled on a VM instance
    • COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED: project-wide SSH keys are used, allowing login to all Compute Engine instances in a project
    • ADMIN_SERVICE_ACCOUNT: a service account is configured with Owner access or administrator roles (e.g., roles/compute.osAdminLogin), which may allow them to change OS Login settings or have sudo access