Skip to content

CONCEPT Cited by 1 source

On-the-fly security principal rewrite

Definition

On-the-fly security principal rewrite is the design primitive of translating a request's authenticated identity into a different principal at an ingress service, after authentication has succeeded and before the request reaches the downstream authz check. The downstream check sees only the rewritten principal; the original identity is invisible to it.

The rewrite collapses a large, dynamic, per-tenant identity space (e.g. every password a customer has ever minted) into a small fixed set of synthetic principals (e.g. planetscale-reader, planetscale-writer, planetscale-admin) that the downstream authz system was designed to reason about. The mapping from original identity to synthetic principal is driven by an external credential store that holds the dynamic state.

Why it shows up on this wiki

This is the keystone primitive of the PlanetScale Password Roles architecture: the Vitess table ACL is static and tenant-agnostic, while PlanetScale customers mint passwords dynamically. The user query frontend bridges the two by authenticating the customer's password against the credential DB, looking up its role, and rewriting the MySQL-wire principal to one of three synthetic Vitess usernames before the query reaches vttablet.

Quoting the post: "By mapping all PlanetScale users' roles to the username from the Vitess ACL configuration, we can do an 'on the fly' rewrite of the security principal so that connections to the database get the right access levels." The post explicitly names the design move.

Why it's valuable

  • Downstream authz stays static. The ACL file, RBAC policy, or capability list the downstream system loads at boot never has to know about tenants. It can be shipped identically across fleets, cached aggressively, and reloaded on maintenance-window schedules.
  • Dynamic credential lifecycle lives in one place. Create, revoke, role-change all touch the external credential store, not the data-plane's ACL state.
  • Composes with existing systems. If the system you're building on top of has fixed, unrenegotiable authz semantics (because it's upstream OSS, because you don't own the runtime, because changing it would be risky), you can still get dynamic per-tenant authz by rewriting the principal at your ingress.

Constraints it imposes

  • All traffic must pass through the ingress. If a path exists that reaches the data plane without transiting the rewrite chokepoint, it will see the original identity (or no identity at all). The ingress becomes a central proxy chokepoint.
  • Audit / forensics gets a layer of indirection. Downstream logs see only the synthetic principal. Mapping "who actually did this" back to a customer requires joining against the credential DB + ingress telemetry.
  • Role-changes for in-flight connections are subtle. If the principal is computed at connection-open and cached for the session's lifetime, revoking or demoting a password only takes effect on new connections. Re-checking on every query costs round-trips to the credential store.

Seen in

Last updated · 319 distilled / 1,201 read