Compute Engine VMs without their own enable-oslogin=TRUE metadata

What metadata-based SSH keys leave behind

Without OS Login, SSH access to a Linux VM is granted by public keys stored in project or instance metadata. Those keys outlive the people who added them. Nothing ties a key to an employee record, so an offboarded contractor’s key keeps working until someone finds and deletes it.

OS Login replaces that with IAM. Google lists the benefits directly: a Linux account tied to the user’s Google identity, fine-grained grants such as login without sudo, and automatic revocation, because removing the IAM permission removes access and Google checks permissions on every login attempt.

Where the setting actually lives

enable-oslogin can be set in project-wide metadata, which applies to every VM in the project, or on an individual instance. The setup guide notes that an instance value of FALSE switches OS Login off for that VM even when the project says TRUE. Check both levels:

gcloud compute project-info describe \
  --format="value(commonInstanceMetadata.items)"

gcloud compute instances describe VM_NAME --zone=ZONE \
  --format="value(metadata.items)"

What ZopNight reads before flagging

ZopNight reads the enable-oslogin item in each instance’s own metadata during inventory. When that item is anything other than TRUE, including absent, the instance is flagged. A VM that was not fully inventoried is skipped rather than guessed at.

Findings that may already be compliant

The rule looks at instance metadata only. A VM with no instance-level value that inherits TRUE from the project is protected in practice, and the finding tells you to check the project setting before changing anything. That is the most common reason to dismiss this finding. An instance that explicitly sets FALSE is a genuine exception to a project-wide policy and worth a conversation.

An access-control gap, not a cost

There is no saving. The risk is standing SSH access that no IAM review can see, plus the operational drag of rotating keys by hand.

Turning OS Login on

1. Decide the scope. Project-wide is simpler: gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE. For one VM: gcloud compute instances add-metadata VM_NAME --zone=ZONE --metadata enable-oslogin=TRUE.
2. Grant roles/compute.osLogin, or roles/compute.osAdminLogin for administrators, to the people who need access. Users of VMs that run as a service account also need roles/iam.serviceAccountUser.
3. Test a login with gcloud compute ssh before removing old keys.
4. Remove the SSH keys left in instance and project metadata.