Executive Summary: Cloud IAM Boundary Breakdown in Compute Engine

Google Cloud Platform (GCP) has mitigated a significant local privilege escalation (LPE) vulnerability, CVE-2020-8907, impacting the guest-oslogin package across Google Compute Engine (GCE) Linux virtual machine instances. The flaw enabled standard enterprise users granted only the non-administrative roles/compute.osLogin Identity and Access Management (IAM) role to escalate their privileges to full root on target VM instances.

In Google Cloud architecture, OS Login links Linux user accounts directly to Google Cloud identities (Cloud Identity or Google Workspace), eliminating the need to manually distribute and manage SSH public keys via instance metadata. By exploiting an unintended Unix group mapping vulnerability, non-root users effectively bypassed Google IAM segregation, gaining unconstrained administrative access to cloud workloads.

Architectural Breakdown: How OS Login Bridges IAM to PAM/NSS

OS Login functions by integrating a custom Pluggable Authentication Module (PAM) and Name Service Switch (NSS) daemon into the Linux operating system. When a cloud user attempts an SSH connection to a Compute Engine instance:

  1. The Google Cloud guest environment contacts the internal instance metadata server (http://metadata.google.internal/computeMetadata/v1/) using the instance's service account credentials.
  2. The metadata server queries the Cloud IAM policy to verify whether the connecting user holds roles/compute.osLogin (standard user) or roles/compute.osAdminLogin (privileged administrator).
  3. The libnss_oslogin library dynamically generates a POSIX user and maps default supplementary groups on the Linux host.

The security boundary collapsed because versions of guest-oslogin between 20190304 and 20200507 included the local docker group within the default supplementary group template assigned to standard OS Login users on container-optimized and developer instances.

Vulnerability Anatomy: The Docker Group Privilege Escalation Path

In Unix-like systems, granting membership in the docker group is fundamentally equivalent to granting root privileges. The Docker daemon runs as root and exposes a Unix domain socket (/var/run/docker.sock). Any user with write permissions to this socket can command the daemon to launch privileged containers with arbitrary host mounts: 

# Attacker terminal session with roles/compute.osLogin permissions
$ id
uid=1001(developer_example_com) gid=1001(developer_example_com) groups=1001(developer_example_com),999(docker)

# Exploit execution: mount host root filesystem into container
$ docker run --rm -v /:/host-fs alpine sh -c "echo 'developer_example_com ALL=(ALL) NOPASSWD: ALL' >> /host-fs/etc/sudoers"

# Verify instant privilege escalation on Google Compute Engine host
$ sudo whoami
root

By mounting the root directory of the host OS (/) into a lightweight container, the attacker wrote directly to /etc/sudoers or modified /etc/group to inject their account into the sudo / wheel group. This completely broke the administrative boundary intended between compute.osLogin and compute.osAdminLogin.

Cloud Workload Lateral Movement & Blast Radius

Once host-level root access is achieved on a Compute Engine instance, an adversary can extract sensitive runtime assets:

  • Service Account Token Theft: Although OS Login users cannot query the local instance metadata server without local shell access, once root is acquired, attackers can inspect memory or intercept tokens issued to the VM instance service account (compute@developer.gserviceaccount.com), pivoting into Cloud Storage buckets, BigQuery datasets, or Secret Manager vaults.
  • Container Workspace Tampering: In multi-tenant developer environments or continuous integration (CI) runners, attackers can tamper with build scripts, backdooring software binaries prior to production artifact deployment.

Remediation & Cloud Architecture Hardening Playbook

Hardening Layer Recommended Configuration Technical Impact
Guest OS Package Update google-compute-engine-oslogin to latest version Removes docker from default group membership configuration in /etc/group/security.conf
IAM Least Privilege Enforce roles/compute.osLogin with Condition constraints Restricts login to specific target VM tags; blocks unauthorized VM hopping
Docker Socket Protection Migrate to rootless Podman or disable unauthenticated Docker daemon socket Eliminates root escalation vector even if users belong to administrative user groups
IMDSv2 Enforcment Set can-ip-forward=false and enforce metadata-flavor: Google token headers Prevents SSRF and lateral metadata exfiltration from compromised host containers

Manual Remediation for Legacy Custom Images

For enterprise organizations operating custom Linux golden images or air-gapped Compute Engine instances that cannot automatically pull Google guest updates, manual remediation must be applied: 

# Edit /etc/group/security.conf on target GCE Linux instances
# Remove the 'docker' entry from the OS Login group assignment mapping:
sudo sed -i '/docker/d' /etc/group/security.conf

# Restart the OS Login NSS daemon
sudo systemctl restart google-oslogin-cache.service