How do you enable OS Login for Google Compute Engine projects?

Enable OS Login at the project level so instance access is tied to Google identities rather than local Linux users and manually managed SSH keys. Apply the setting to the project, then verify that users obtain access through IAM. Review existing metadata and local accounts, because unmanaged keys or local users can bypass the control if they remain in place.

Project-level os login shifts Compute Engine access from machine-local Linux accounts toward centrally governed Google identities. That matters because the access decision is no longer just who has a key on a VM, it becomes who is authorised in Cloud IAM, how metadata-based SSH is controlled, and whether old local users or keys still exist as an alternate path into the instance.

The practical benefit is consistency. When OS Login is enabled at the project level, new instances inherit a single access model, which reduces drift between VMs and makes review easier. It also changes the failure mode: if the project policy is correct but existing metadata keys or local accounts remain, the control can be partially bypassed rather than fully enforced.

How to Turn It On and Confirm It Is Working

Enable OS Login on the project itself, then verify the setting is applied to the instances that matter, including any fleets created from templates or automation. The control only becomes meaningful when users can authenticate through IAM-backed access and the project no longer depends on manually maintained SSH keys for routine login.

The main validation step is not just whether the flag is set, but whether the effective access path has changed. Test that a user with the right Google identity and IAM permission can connect, and that a user without that permission cannot fall back to a pre-existing local account or stale metadata key. In mixed environments, remember that configuration inheritance and per-instance overrides can create surprises.

For project-wide governance and the surrounding Google Cloud access model, Google Cloud IAM and Service Accounts Guide is the most direct foundation, while the broader Google Cloud Security Guide helps place OS Login inside the larger hierarchy, policy and audit context.

What Still Needs Cleanup After You Enable It

OS Login does not automatically remove pre-existing exposure. Existing instance metadata entries, manually created Linux users, and any retained SSH keys can keep working unless you actively remove or disable them. That is why the project setting should be treated as an access-model change, not a complete cleanup by itself.

In practice, the hard part is reducing alternate paths. If old accounts remain on the VM, they may still allow direct login outside the intended IAM workflow. If legacy keys are still present in instance metadata or user profiles, they can preserve access even after the project setting is enabled. Treat those remnants as part of the rollout, not as optional housekeeping.

Risk and Threat Considerations

OS Login reduces key sprawl, but it does not remove the risk of shadow access if local users or unmanaged SSH keys remain on instances. The main exposure is inconsistency: the project may be governed centrally while individual VMs still accept a bypass path that is harder to inventory and review.

Failure mechanism: A stale metadata key or residual local account continues to authenticate even after the project policy changes, so access is still possible outside the intended IAM-controlled path.

Impact: Attackers or insiders can retain or regain access through a legacy route, and responders may miss it if they only check the project-level OS Login state rather than effective instance access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CSA Cloud Controls Matrix	IAM — Identity & Access Management	OS Login centralises instance access through IAM-backed identity.
Recommendation — Align Compute Engine login controls with IAM and remove direct key-based access paths.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Project login now depends on authenticated user identities for access decisions.
	IA-5 — Authenticator Management	SSH key and credential cleanup is part of preventing stale access paths.
	AC-6 — Least Privilege	OS Login should be paired with minimal IAM entitlements for VM access.
Recommendation — Require authenticated organizational users before allowing Compute Engine access. Manage and retire authenticators so unused SSH keys do not preserve access. Grant only the IAM permissions needed for Compute Engine login.
ISO/IEC 27001:2022	A.5.15 — Access control	The topic is a cloud access control change with residual access cleanup requirements.
Recommendation — Apply access control rules consistently across project and instance login paths.

Practitioner Guidance

What to verify: Confirm the effective state on real instances, not just the project flag. Check for inherited templates, instance-level metadata overrides, existing local users and any keys that still provide login access.

Common mistake: Teams enable OS Login and assume the fleet is now governed, but leave behind legacy accounts or SSH keys that preserve an older access path. That creates false confidence and complicates incident response.

Decision rule: If a VM can still be reached without the intended IAM path, treat the rollout as incomplete and clean up the bypass before calling the project hardened. If you cannot remove the bypass immediately, keep the instance in a higher-risk state until the alternate access is eliminated.

Practitioner takeaway: The control is only effective when the project setting, IAM entitlement and instance-level cleanup all align, because OS Login governs the preferred path, not every possible path.