Disclosure: I work on Tessera, which is one of the proxy-shaped tools. Both shapes are legitimate and I try to be fair to the other one below.
Most comparisons of access-control tools start with feature tables. That is the wrong end. The decision that actually determines whether a rollout finishes is the deployment shape, and there are only two.
Shape one: agents and certificates
You run an internal certificate authority. Hosts are configured to trust it. Users get certificates that expire in a few hours. For Kubernetes, an agent runs inside the cluster and brokers access from there.
What this buys you is genuinely good. Expiry does revocation automatically, which removes the human step that fails. The credential on the user's laptop is worthless tomorrow. The model scales well because the CA does not sit in the data path — once the certificate is issued, the user talks to the target directly, so there is no proxy to size and no bandwidth to plan.
What it costs is that you have to change production before you get anything. sshd_config gets rewritten across the estate to add TrustedUserCAKeys. An agent gets deployed into every cluster. In some setups the tool's binary is copied onto hosts.
None of that is technically hard. It is organisationally hard. You need a change window, sign-off from whoever owns those hosts, and a rollback plan — for a project whose entire benefit is "nothing bad will happen later". That conversation is where access-control rollouts stall, and it stalls most reliably in exactly the organisations that need the tool most: the ones where nobody is quite sure who owns which box.
The other cost is that the CA private key becomes the most sensitive object your company owns, and now you operate a CA.
Shape two: a proxy
The credential stays on a controller. The user authenticates to the controller. The controller opens its own connection to the target, authenticates with the real credential, and relays. The target sees a normal connection from a normal service account. Nothing on the target changes.
What this buys is that you can deploy it on a Tuesday. No change window on production, no agent to get approved for the cluster, no CA to operate. For an organisation that cannot easily get permission to touch production configuration, this is not a nice-to-have — it is the difference between having access control and not having it.
The second thing it buys is less obvious and it is the reason I find this shape interesting. Because the proxy is in the data path, it decides about every byte. So the permission level can live in session state rather than in the credential, which means you can change it while the session is open. An admin can drop a live session from read-write to read-only and the connection does not drop — on SSH, on Kubernetes and on SQL. In a certificate model that is structurally hard: the permissions are baked into a certificate the target has already accepted, so changing them means a new connection.
The same property gives you real read-only enforcement on protocols where it can be parsed. If you sit on the HTTP path to the kube-apiserver you can reject mutating verbs before they reach the cluster. If you parse the PostgreSQL wire protocol you can reject writes and DDL before they reach the database. Neither of those depends on the target being configured to cooperate.
SSH is the exception, and the difference is worth keeping straight. There is no wire-level notion of a read-only shell, so what you get there is a command blocklist applied at the channel level — a guardrail against someone who forgot they were on prod, not a boundary against someone determined to get around it. An interactive shell is a Turing-complete environment, and any blocklist inside one can be defeated in principle. If you need a hard guarantee on SSH, point the proxy at a read-only OS account.
What the proxy costs
Three things, and none of them are small.
It is in the access path. If it is down, nobody gets in. That is a dependency you are accepting, and it has to be operated accordingly — hardened, backed up, with a break-glass procedure that does not depend on it.
Traffic passes through twice. Client → controller → target and back, so N bytes cost 2N on the controller's interface. In our measurements 20 concurrent SSH sessions over loopback run at ~440 MB/s versus ~540 MB/s native, so roughly 20% overhead — and loopback is deliberately chosen to isolate the proxy cost from the network, which means a real network is worse. It is irrelevant for interactive work and it matters a lot for bulk transfer, which is why the sane advice is to route dumps and CI artefacts around the proxy entirely.
It holds long-lived credentials. This is the criticism that deserves the most respect. A box full of production credentials is an attractive target in a way that a certificate model's short-lived tokens are not. Encryption at rest, memory-only decryption, a write-only console and a pentest before go-live are all mitigations, not answers. If your threat model puts most weight on "what happens when one machine is compromised", the certificate model is genuinely the better fit and you should take that seriously.
How to choose
Ask two questions, in this order.
Can you change production configuration in the next quarter? If getting sshd_config edits and a cluster agent approved is realistic, the certificate model is available to you and it is a strong choice. If it is not realistic — and for a lot of organisations it honestly is not — then the proxy shape is not a compromise, it is the only shape that will actually ship.
Do you need to control the session or only the connection? If your requirement stops at "who can connect", certificates cover it well. If it extends to "what can they do once they are in", "can I reduce that mid-session", and "what exactly did they run", the proxy shape has structural advantages, because it is the only one that is present while the session is happening.
Everything else in the comparison tables is downstream of those two answers.
Certificate-shaped: Teleport. Proxy-shaped: Tessera, which I work on. Boundary sits in between, with several governance features in Enterprise or HCP rather than the open-source edition. Checked against each vendor's own docs, 14 August 2026.
Top comments (0)