vtgate to vttablet: expired MySQL backend credentials and sandbox-mode error propagation across the connection pool
0 reputation · 18 Jun 2022, 12:20 UTC
0 reputation · 18 Jun 2022, 12:20 UTC
In a Vitess cluster, vtgate terminates the client MySQL protocol while vttablet brokers queries to a backing MySQL instance using its own configured application and administrative accounts. When a backend MySQL account is subject to password expiration or is scoped to a least-privilege role, the failure mode at the vtgate-to-vttablet boundary is not obvious: MySQL places an expired account in sandbox mode after the handshake, commonly returning error 1820, but vttablet maintains a pool of already-authenticated connections that may mask the condition until a fresh connection is opened.
The practical uncertainty is whether Vitess detects this state and re-authenticates or refreshes the credential automatically, or whether the sandbox-mode error is propagated back through vtgate to the client. That behavior may also vary by Vitess release and by the MySQL authentication plugin in use, such as mysql_native_password versus caching_sha2_password, where sandbox semantics and error codes differ.
For operators enforcing least-privilege separation across keyspaces, the interaction between per-keyspace app users and pooled backend connections raises an unresolved design question.
Does an expired or least-privilege MySQL credential behind vttablet surface as a sandbox-mode error to vtgate clients, or does Vitess transparently recover? How does connection pooling affect when the failure appears? Are there version-specific differences in how this is handled across supported Vitess releases?
32275 reputation · 18 Jun 2022, 15:54 UTC
Vitess does not transparently recover from expired MySQL backend credentials. vttablet maintains a pool of authenticated connections that remain valid until they are closed, recycled, or fail a health check. The sandbox-mode error (MySQL 1820, ER_MUST_CHANGE_PASSWORD) only surfaces when vttablet attempts to open a new connection due to pool exhaustion, explicit reconnect, or failed validation. At that point, vttablet logs the error and returns a generic connection failure to vtgate, which propagates to the client.
ALTER USER ... PASSWORD EXPIRE because MySQL only enforces sandbox mode during the initial handshake.pool_size, max_idle_connections) controls the latency between credential expiration and visible failure. Larger pools delay detection.go-sql-driver/mysql) and typically returns 'access denied' or 'connection lost' to vtgate.| Plugin | Sandbox Behavior | Typical Error Code |
|---|---|---|
mysql_native_password |
Allows only SET PASSWORD in sandbox mode |
1820 (ER_MUST_CHANGE_PASSWORD) |
caching_sha2_password (MySQL 8.0+ default) |
Stricter; may block even SET PASSWORD until password change |
3948 (ER_PASSWORD_EXPIRED) or 1820 depending on server version |
Note: With caching_sha2_password using RSA key exchange, handshake can fail earlier if the public key is unavailable.
ER_MUST_CHANGE_PASSWORD or ERROR 1820 during connection acquisition.vtctl GetTablet <tablet_alias> and inspect pool stats; compare connection creation timestamps against rotation time.ALTER USER 'app_user'@'%' PASSWORD EXPIRE; then send traffic. Observe whether existing connections succeed and new ones fail.vtgate --version and vttablet --version; consult release notes for connection pool changes.Which authentication plugin is configured for the backend accounts (mysql_native_password versus caching_sha2_password)? This changes the exact error code surfaced and whether RSA key exchange adds an earlier failure mode.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.