When you do have to directly expose a VM with an external IP address, ensure that your firewall rules restrict network access to only the ports and IP addresses that your application needs. 



  • Assign private IP addresses to your VMs; don’t give them public IP addresses at all. Use IAP TCP forwarding to connect to your VMs for administration and Cloud NAT to allow your VMs to access the internet. IAP works by verifying a user’s identity and the context of the request to determine if a user should be allowed to access an application or a VM. Follow these instructions to set up IAP for your Compute Engine instances. 

  • Use Organization Policies to define allowed external IPs for VM instances, so new VM instances don’t get created or configured with an external IP address.

  • Use Security Health Analytics to detect VMs that have external IP addresses and firewall rules that are too permissive. (Note: Some Security Heath Analytics features are available only in the Premium edition of Security Command Center.) Identify and resolve the following security findings:

    • PUBLIC_IP_ADDRESS: Indicates that a Compute Engine instance is assigned an external IP address.

    • OPEN_FIREWALL: Indicates that a firewall rule is configured to allow access from any IP address or on any port.

  • Use VPC Service Controls to configure security perimeters that isolate Google Cloud resources and prevent sensitive data exfiltration—even by authorized clients.

  • Disable legacy Compute Engine instance metadata APIs and migrate your application to the v1 metadata API to help protect it against Server-Side Request Forgery (SSRF) attacks. 

But what if, despite your preventative efforts, an attacker still manages to compromise a VM? Let’s look at some ways to minimize the impact and ensure that the attacker isn’t able to move laterally and gain access to more resources.

Disable the default service accounts

Configuring identity and API access is a critical step in creating a VM. This configuration includes specifying which service account should be used by applications running on the VM. Google Cloud offers two approaches for granting privileges to your application: using a Compute Engine default service account or a user-created service account.

The Compute Engine default service account is automatically created by the Google Cloud Console project and has an auto-generated name and email address. To simplify customer onboarding, it is automatically granted the Project Editor IAM role, which means that it has read and write access to almost all resources in the project (including the ability to impersonate other service accounts). Because these privileges are so permissive, we recommend using Organization Policies to disable the automatic granting of this role. Instead, remove any access grants given to the Compute Default Service Account, and use a new service account that’s granted only the permissions your VM needs. 


  • Use the Compute Engine default service account with the primitive Editor role.

  • Use the same service account for different applications running on different VMs.


  • Revoke the Editor role for the Compute Engine default service account and create a new service account for your VM that has only the needed permissions.

  • 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.

  • Use Security Health Analytics to detect and resolve the following misconfigurations: 

Limit access to service account credentials

To limit an attacker’s ability to impersonate your service accounts, you should avoid creating service account keys whenever possible and protect access to existing keys. Service account keys are intended to allow external, non-Google Cloud workloads to authenticate as the service account, but when you’re operating inside Google Cloud, it’s almost never necessary to use a service account key.


  • Generate and download private keys for your service accounts. Your Compute Engine instance can automatically assume the identity of the configured service account. 

  • Grant the Service Account User or Service Account Token Creator roles at the project level. Instead, you should grant these roles on individual service accounts, when needed. The Service Account User role allows a user to start a long-running job on behalf of a service account. The Service Account Token Creator role allows a user to directly impersonate (or assert) the identity of that service account.


  • 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. This minimizes the possibility that the service account private key will be exposed.

  • Use the –impersonate-service-account flag to execute gcloud commands as a service account instead of using an exported service account key. This can be configured per-request or for all gcloud commands by running “gcloud config set auth/impersonate_service_account service_account_email”

  • Use Security Health Analytics to detect broad use of the Service Account User role and existing service account keys. Look for:

    • SERVICE_ACCOUNT_KEY_USER_MANAGED: Indicates that a user-managed private key for service accounts exists.

    • SERVICE_ACCOUNT_KEY_NOT_ROTATED: Indicates that a user-managed private key for a service account has not been rotated in 90 days.

    • OVER_PRIVILEGED_SERVICE_ACCOUNT_USER: Indicates that an IAM member has the Service Account User role at the project level, instead of for a specific service account.

Use OS Login to manage access to your VMs 

One way for an attacker to escalate privileges and gain access to additional VMs is by looking for SSH keys stored in the project’s metadata. Manually managing SSH keys used for VM access is time-consuming and risky. Instead, you should use OS Login to grant access to your VMs based on IAM identities. If OS Login is enabled, an attacker can’t obtain access to new VMs by uploading SSH keys to the instance metadata, because those keys get ignored. To preserve backwards compatibility for workflows that rely on configuring their own users and SSH keys, OS Login is not enabled by default. You can learn more about managing access to your VM instances here.



  • Use OS Login to manage access to your 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. Look for the following misconfiguration types:

    • OS_LOGIN_DISABLED: Indicates that OS Login is disabled on a VM instance.

    • COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED: Indicates that project-wide SSH keys are used, allowing login to all Compute Engine instances in a project.

    • ADMIN_SERVICE_ACCOUNT: Indicates that a service account is configured with Owner access or administrator roles such as roles/compute.osAdminLogin, which may allow them to change OS Login settings or have sudo access.

Apply the principle of least privilege

Ensuring that every VM instance, service account, or user is able to access only the information and resources that are necessary for legitimate business operations can be a challenge, especially if you have a lot of VMs. Google Cloud’s IAM Recommender uses machine learning to help organizations right-size privilege management through monitoring a project’s actual permission usage and recommending specific, constrained roles to replace overly permissive ones. It recommends permissions that are safe to remove, and also predicts future access needs.

Leave a Reply

Your email address will not be published. Required fields are marked *