IAM-Bound SSH Access

When working with SSH key files, remember that the key file is the credential. Whoever holds the key gets in, and the key itself doesn’t know whether someone left the organization.

GCP’s OS Login and AWS’s SSM Session Manager both solve this the same way: they stop treating the key as the credential and make IAM grant the credential instead.

What actually changes

With OS Login, SSH access is tied to a Google identity plus an IAM role — roles/compute.osAdminLogin (or the viewer variant), plus roles/iam.serviceAccountUser when you connect to a VM through an attached service account:

gcloud compute instances add-metadata lab-vm-01 \
  --zone=us-east1-b \
  --project=PROJECT_ID \
  --metadata=enable-oslogin=TRUE

gcloud compute ssh lab-vm-01 \
  --zone=us-east1-b \
  --project=PROJECT_ID

There’s still an SSH key involved — gcloud generates one and registers it to your OS Login profile, but the key isn’t what’s granting access. The guest agent on the VM checks your IAM binding against Google’s metadata service on every connection attempt. Remove the binding, and the same key that worked moments ago produces “does not have login permission.”

gcloud projects remove-iam-policy-binding PROJECT_ID \
  --member="user:[email protected]" \
  --role="roles/compute.osAdminLogin"

This means no key rotation, no redistribution, and no tracking down which servers they could reach if an employee leaves the company.

AWS’s SSM Session Manager gets to the same place from a different direction — it drops the SSH protocol entirely. The instance needs a role with AmazonSSMManagedInstanceCore attached, and the identity needs ssm:StartSession in their own IAM policy.

aws ssm start-session --target i-0123456789abcdef0

Revoke it by detaching the policy or removing the binding. Both platforms centralize the authorization trail: Google Cloud records relevant administrative activity in Cloud Audit Logs, and AWS records Session Manager API activity in CloudTrail. Command or session-content logging still has to be configured separately.

From a compliance perspective, account management and remote-access controls ask: can you prove access was authorized, and can you prove it ended when it should have? Static keys scattered across authorized_keys files make that difficult to answer consistently. IAM bindings and centralized audit records give you a much stronger trail.

Protect the identity plane

Moving remote access into IAM makes the cloud identity the credential that matters. If that identity is compromised, an attacker can use the same centralized access path. Hardware-backed MFA protects the Google or AWS sign-in that grants access; it does not replace OS Login, Session Manager, or the IAM bindings that authorize the session.

I use this model for SSH authentication, Linux login through PAM, Authentik, Okta, and other identity workflows. For this article, the relevant use is protecting the identity that controls remote access.

Framework mapping

Why this is the better default

But the comparison that matters is what revocation looks like under time pressure.

Since the credential now lives in IAM, offboarding an employee is a single policy change instead of a scavenger hunt across every box they ever touched.