Does VTTablet credential caching delay password expiration enforcement?
0 reputation · 18 Nov 2024, 20:41 UTC
0 reputation · 18 Nov 2024, 20:41 UTC
Vitess delegates authentication to the underlying MySQL server, where least-privilege access is managed via standard MySQL user privileges. When a user's password expires on the MySQL server, VTGate typically forwards the authentication request, and the connection fails with MySQL error 1820.
However, VTTablet maintains a cache of connections to the underlying MySQL instance. There is uncertainty regarding the behavior of these cached connections when a password is changed or expires while the connection is still active in the pool.
If the underlying MySQL account is modified or expires, does VTTablet continue to reuse existing cached connections until they are naturally closed or the tablet is restarted? What is the expected propagation delay for credential updates across a cluster in Vitess 2.x?
30775 reputation · 18 Nov 2024, 22:03 UTC
In Vitess 2.x, VTTablet does not immediately enforce a MySQL password expiration that occurs while a connection is still held in its internal connection pool. The cached connection continues to be used until the pool entry is evicted or the tablet is restarted. Password changes or expirations are only checked on the next authentication attempt that forces VTTablet to refresh its cached credentials.
VTTablet stores user credentials in a local cache that is refreshed only when a new authentication request is made or when the cache entry expires. Because the pool holds open connections, those connections are not re‑authenticated against MySQL until they are closed or the tablet restarts. Therefore, a password that has expired on the MySQL server can remain usable via an existing pool connection for the duration of the cache lifetime.
vtctld.cfg or the tablet’s admin console and locate the credential_cache_timeout setting. Document its current value.
credential_cache_timeout to a very short interval (e.g., 60 seconds) or disable caching entirely if the deployment permits.
In some older VTTablet builds, the cache timeout might not be exposed in configuration files. In such cases, the default may be longer, leading to a larger window of delayed enforcement. Verify by checking the tablet’s logs for entries related to credential cache eviction.
If you are unsure whether your tablet uses the credential_cache_timeout setting, please check the current value in the configuration file or admin console. Knowing this will help determine the exact propagation delay for credential updates.
Use comments to ask for clarification. Post a solution as an answer.
30,775 reputation · 19 Nov 2024, 01:34 UTC
One clarification worth adding: this behavior isn't really specific to VTTablet's caching. MySQL itself only validates credentials at connection handshake time — an already-authenticated session remains usable even after the account's password is changed or expires. So any pooled connection, in Vitess or a plain application pool, will keep working until it is closed and re-authenticated.
That means the enforcement delay is bounded by whatever closes pooled connections: the tablet's idle timeout, pool eviction, or a restart. If you need immediate enforcement (e.g., during a credential rotation or incident response), don't rely on natural expiry — restart the affected tablets or shrink the pool idle timeout temporarily so connections are re-established.
Also worth verifying in your environment: watch for error 1820 versus 1862 in the tablet logs. 1820 (must reset password in sandbox mode) and 1862 (expired password) surface differently depending on the MySQL server's disconnect_on_expired_password setting, which changes whether clients can even connect to reset it.