CONCEPT Cited by 1 source

External credential store

Definition

An external credential store is a dedicated database that holds authentication and authorization state — user identifiers, password hashes, role assignments, optionally revocation metadata — outside the data-plane pods that evaluate authz. The data-plane consults the store (directly or via a fronting ingress service) rather than loading credential state from local files at boot.

The canonical shape on this wiki, from the PlanetScale Password Roles post, stores four fields per password:

Display name	Role	password_sha1_hash	password_sha2_hash

• Display name — user-facing label for the password in the PlanetScale dashboard (distinct from the synthetic Vitess principal the role gets mapped to).
• Role — one of read-only, write-only, read/write, admin. Selects which synthetic Vitess principal the user query frontend rewrites the connection to.
• password_sha1_hash + password_sha2_hash — two hash flavours kept (per natural reading, for mysql_native_password SHA-1 vs caching_sha2_password SHA-256 client-auth-plugin backward compatibility; the post doesn't spell this out but the field layout is unambiguous).

Why it shows up on this wiki

The external credential store is the design primitive that lifts dynamic per-tenant credential state out of the data plane. The Password Roles post enumerates four concrete benefits over the alternative of pushing ACL state to every vttablet pod:

1. Instant credential effect — "a dynamic user credential store allows us to create/delete user mappings to roles instantly, without the need for a refresh interval." The create → effective latency is the credential-DB write, not a refresh-interval tick.
2. Pod-independent state — credentials don't depend on any pod's local file; rollouts don't race.
3. Restart-safe — "Since all authentication and authorization data is stored on an external data store, all pods that we create for a database will have the same ACL state." A restarted pod reconstructs its authz context by consulting the store, not by parsing local disk.
4. Universal data-plane config — the data-plane ACL becomes an invariant. The post says that "since the base ACL configuration is the same across all PlanetScale databases, debugging and fixing any issues with ACL enforcement is simplified."

These four benefits are the 1:1 dual of the four failure modes of static, file-based ACL in managed-multi-tenant deployments, and they argue for the external credential store as the default position when building tenant-dynamic authz on top of systems with static-authz assumptions.

What it requires

• An ingress service that can terminate the client-auth handshake, consult the store, and (when composed with the principal rewrite primitive) translate the authenticated identity into a downstream-recognised principal.
• A low-latency path from ingress to store — the credential lookup is on the connection-open hot path (possibly on every query, depending on the revocation SLA).
• Credential store HA. The store becomes a hard dependency of every data-plane connection; its availability bounds the product's availability.

Seen in

• sources/2026-04-21-planetscale-behind-the-scenes-how-we-built-password-roles — canonical disclosure of the four-field schema, the four failure modes of the alternative (ACL state on each pod), and the four architectural wins. The user query frontend is the ingress that reads from it.

Related

• patterns/external-credential-store-with-principal-rewrite — pattern that composes this primitive with ingress-level principal rewrite.
• concepts/on-the-fly-security-principal-rewrite — the companion primitive.
• concepts/table-group-acl — the static, data-plane authz shape this primitive is designed to preserve as an invariant.
• systems/planetscale-user-query-frontend — canonical ingress consumer.
• systems/vitess-table-acl — canonical static-authz mechanism the store decouples from.
• systems/planetscale — managed-DB product.
• systems/mysql — wire protocol whose client-auth plugins motivate the dual-hash (SHA-1 + SHA-256) schema.