6.3 OS Login and VM Manager for Fleet Configuration
Key Takeaways
- OS Login ties SSH access to IAM identities via roles/compute.osLogin (standard) or roles/compute.osAdminLogin (sudo), replacing raw metadata keys
- Instance-level enable-oslogin metadata overrides project-level metadata; constraints/compute.requireOsLogin enforces it org-wide with no opt-out
- VM Manager has three distinct components: OS patch management (applies patches), OS inventory management (reports only, scans every ~10 minutes), and OS configuration management (enforces or dry-run-reports desired state)
- OS configuration management (OS policies) supports dry-run mode for compliance-only reporting and an enforcement mode that actively corrects drift
- VM Manager requires the Compute Engine and OS Config APIs plus a running guest environment and OS Config agent on each VM
Why This Topic Matters
The exam guide's remaining two Compute Engine deployment bullets -- "Configuring OS Login" and "Configuring VM Manager" -- are compact but frequently tested because they sit at the intersection of deployment and day-two operations: once you have launched instances and grouped them into MIGs, how do you securely access them and keep their operating systems patched and compliant at fleet scale?
OS Login: IAM-Tied SSH Access
OS Login replaces per-instance or per-project metadata SSH keys with SSH access controlled directly through Cloud Identity and Access Management (IAM). Instead of managing raw public keys, you grant a user or group one of two IAM roles:
| Role | Access Level |
|---|---|
roles/compute.osLogin | Standard (non-administrator) SSH access |
roles/compute.osAdminLogin | SSH access with sudo/administrator privileges |
roles/compute.osLoginExternalUser | Grants OS Login access to identities outside the organization (external users) |
You enable OS Login by setting the enable-oslogin metadata key to TRUE at the project level (applies to every instance) or at the instance level (applies to just that VM). Metadata precedence works the same way it does for SSH keys generally: instance-level metadata overrides project-level metadata. This means a project can enforce OS Login broadly while a specific instance sets enable-oslogin=FALSE to opt back out to legacy metadata keys -- or vice versa, enabling it on one sensitive instance in an otherwise unmanaged project.
To make OS Login mandatory across an entire organization or folder (so no project can opt out), administrators use the organization policy constraint constraints/compute.requireOsLogin. This is the exam's usual answer whenever a scenario says "enforce fleet-wide, centrally, with no per-project exceptions."
Two additional details worth knowing:
- POSIX accounts: OS Login derives Linux POSIX user/group IDs from the caller's Cloud Identity profile by default, but you can set custom POSIX UIDs/GIDs to keep them consistent across many VMs (important for shared file permissions).
- Auditability: because access maps to IAM identities, every login is tied to a real principal and can be centrally revoked by removing the IAM binding -- the reason OS Login, not metadata keys, is the enterprise-recommended default.
VM Manager: Fleet-Wide OS Operations
VM Manager is a suite of tools for managing the operating systems running across a fleet of Compute Engine VMs without connecting to each one individually. It has three components, and distinguishing what each one actually does is a common exam trap because their names sound similar:
| Component | What It Does | Key Detail |
|---|---|---|
| OS patch management | Applies OS patches to VMs | Patch jobs can run on demand, be scheduled once, or run on a recurring schedule; instance filters target VMs by zone, label, group, or all instances; a patch compliance dashboard shows fleet-wide status |
| OS inventory management | Reports on installed software and OS state -- does not change anything | The OS Config agent runs an inventory scan roughly every 10 minutes and reports installed packages, available updates, and known vulnerabilities to the metadata server, the OS Config API, and log/BigQuery exports |
| OS configuration management (OS policies) | Enforces a declarative desired configuration state | Policies can run in dry-run (compliance reporting only, no changes applied) or enforcement mode, and can exclude or include VMs by label (for example, excluding GKE nodes from a policy meant only for standalone VMs) |
The trap to watch for: inventory management only reports -- it never applies a fix. If a scenario says "list which packages are outdated across my fleet" without asking for a fix, the answer is inventory management. If it says "keep my fleet patched to the latest security updates automatically every month," the answer is patch management. If it says "make sure every VM has a specific config file or package installed, and I want a compliance report if any drift," the answer is OS configuration management (OS policies).
Prerequisites
VM Manager requires the Compute Engine API and OS Config API to be enabled on the project, and each VM must be running the guest environment plus the OS Config agent -- pre-installed on most Google-provided public images, but something you must install manually on custom or third-party images. IAM roles such as roles/osconfig.patchDeploymentAdmin and roles/osconfig.inventoryDisplayViewer control who can create patch jobs or view inventory data.
Worked Scenario
A platform team manages 500 Compute Engine VMs labeled by environment (env=prod, env=staging) and needs three things: (1) monthly security patches applied automatically to production without manual intervention, (2) a live inventory of installed packages for a security audit, and (3) confirmation that a required monitoring agent is present on every VM with no unauthorized removal. The solution: a recurring patch job filtered to env=prod, scheduled monthly, checked against the patch compliance dashboard; OS inventory management enabled fleet-wide so the security team can query installed packages and known CVEs; and an OS configuration management policy in enforcement mode that reinstalls the monitoring agent if it is ever found missing, reported through the compliance UI. All SSH access to any of these 500 VMs for manual troubleshooting is controlled through OS Login with roles/compute.osAdminLogin granted only to on-call engineers -- auditable and centrally revocable the moment someone rotates off the on-call rotation.
A security team wants a live report of every package installed across 500 Compute Engine VMs, without changing anything on those VMs. Which VM Manager component fits this need?
An organization wants to guarantee that OS Login is enabled on every project in every folder, with no project able to opt out. What should they configure?
Which IAM role grants a user sudo/administrator-level SSH access through OS Login?