The bastion host isn't dead: secure access for regulated Kubernetes

"Bastion hosts are legacy" is a popular opinion that doesn't survive contact with a compliance audit. In regulated environments - healthcare, HR data, financial services - the pattern is very much alive, just implemented differently than it was a decade ago.

Three ways to reach a private cluster

SSH through a bastion. The traditional pattern: a hardened jump host in a public subnet, private clusters reachable only through it. Simple, well understood by every auditor who's seen it before, and still the easiest to explain in a compliance review. The tradeoff is key management - someone has to own SSH key lifecycle, and a leaked key is a real incident.

SSM Session Manager. No open inbound ports, no SSH keys to manage or rotate, and every session is logged centrally by default. Access is controlled through IAM rather than key distribution, which is usually easier to audit and easier to revoke instantly. The tradeoff is a harder dependency on the cloud provider's control plane being available.

EC2 Instance Connect. Short-lived SSH keys pushed just-in-time for a single connection, then discarded. It keeps the familiar SSH workflow while removing long-lived key management, sitting between the other two in both convenience and audit story.

What regulated environments actually need

The specific mechanism matters less than three properties, all of which an auditor will ask about directly:

• Every session is attributable to a named person, not a shared credential
• Every session is logged, ideally to a destination the person accessing the system can't modify
• Access is revocable in minutes, not on the next key rotation cycle

SSM Session Manager satisfies all three with the least operational overhead, which is why it's our default recommendation for new builds. But "we use a bastion" is not automatically wrong, and ripping one out to chase a trend without fixing logging and revocation first is a downgrade, not an upgrade.

The mistake we see most often

Teams treat this as a one-time architecture decision and then never revisit the access list. A bastion or SSM configuration that was tightly scoped at launch accumulates stale IAM roles and forgotten CIDR allowlists over eighteen months of feature work. The mechanism matters less than the review cadence - whatever you choose, put a recurring audit on the calendar, not just the initial setup.