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 accountsDisable 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 existsSERVICE_ACCOUNT_KEY_NOT_ROTATED : a user-managed private key for a service account has not been rotated in 90 daysOVER_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 instanceCOMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED : project-wide SSH keys are used, allowing login to all Compute Engine instances in a projectADMIN_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
|