Secrets Handling for Applications, Option Files, Environment Variables, and Rotation

Learning outcomes

The ServiceHub application account is now least-privileged and TLS-capable, but its password can still leak before MySQL ever sees it—through a process list, terminal history, repository, CI log, environment dump, or world-readable file. Secret handling is therefore an application/operating-system boundary as much as a database boundary.

The secret can leak before authentication

The correct choice depends on threat model and deployment. A developer's local interactive workflow can reasonably use -p. A production service should usually obtain credentials from a protected runtime secret mechanism rather than commit them to configuration files.

Use login paths as a safer local-client convenience

DROP USER IF EXISTS 'svc12_secret_a'@'127.0.0.1';DROP USER IF EXISTS 'svc12_secret_b'@'127.0.0.1';CREATE USER 'svc12_secret_a'@'127.0.0.1'  IDENTIFIED BY 'Lab-A-ChangeMe!2026'  REQUIRE SSL;GRANT SELECT, INSERT ON servicehub_security_lab.*  TO 'svc12_secret_a'@'127.0.0.1';SHOW GRANTS FOR 'svc12_secret_a'@'127.0.0.1';

# mysql_config_editor prompts for the password.mysql_config_editor set --login-path=servicehub-lab-a   --host=127.0.0.1 --port=3306 --user=svc12_secret_a --passwordmysql_config_editor print --allmysql --login-path=servicehub-lab-a --ssl-mode=REQUIRED   -e "SELECT CURRENT_USER(), @@hostname;"

The login-path file is protected from casual cleartext disclosure and its displayed password is masked. However, Oracle explicitly warns that the obfuscation is not unbreakable against a determined attacker with administrative access to the machine. Host access control still matters.

Why command-line and environment secrets are risky

# UNSAFE: password is part of the command line.mysql -h 127.0.0.1 -u svc12_secret_a -pLab-A-ChangeMe!2026# ALSO AVOID for long-lived production credentials:# MYSQL_PWD is deprecated in MySQL 8.4 and process environments may be inspectable.# Linux/macOS example only:export MYSQL_PWD='Lab-A-ChangeMe!2026'mysql -h 127.0.0.1 -u svc12_secret_aunset MYSQL_PWD

Even if a client later overwrites a command-line password argument, there can be a window in which other processes see it. Shell history can also preserve the command indefinitely. Environment variables are not automatically private; debuggers, administrators, crash reports, and platform tooling can expose them.

# In mysql, inspect history-related client options from the installed client:mysql --help | grep -i hist# Windows PowerShell can search help output similarly:mysql --help | Select-String -Pattern hist

Client history behavior and shell history are two different layers. Avoid issuing password-bearing SQL interactively when you do not control history settings; use secure provisioning/rotation workflows.

Protected option files: permissions are part of the secret

A plaintext option file can be appropriate for some local automation if it is accessible only to the service identity and protected by the operating system. On Unix-like systems, MySQL ignores world-writable option files. A file mode such as 600 is a common local pattern, but deployment-specific access-control systems may provide stronger controls.

# ~/.my.cnf  (example content — use only disposable credentials)[client]host=127.0.0.1port=3306user=svc12_secret_apassword=Lab-A-ChangeMe!2026ssl-mode=REQUIRED# Unix-like permissions:chmod 600 ~/.my.cnf

Rotate without a forced application outage

A robust rotation changes one dependency at a time. Instead of immediately changing the only password and hoping every connection pool refreshes correctly, create or enable an overlapping credential, deploy the application to use it, observe successful new sessions, then revoke the old credential.

CREATE USER 'svc12_secret_b'@'127.0.0.1'  IDENTIFIED BY 'Lab-B-ChangeMe!2026'  REQUIRE SSL;GRANT SELECT, INSERT ON servicehub_security_lab.*  TO 'svc12_secret_b'@'127.0.0.1';SHOW GRANTS FOR 'svc12_secret_b'@'127.0.0.1';

mysql_config_editor set --login-path=servicehub-lab-b   --host=127.0.0.1 --port=3306 --user=svc12_secret_b --passwordmysql --login-path=servicehub-lab-b --ssl-mode=REQUIRED   -e "SELECT CURRENT_USER(); SELECT COUNT(*) FROM servicehub_security_lab.security_events;"

At this point both credentials are intentionally valid. In a real service, deploy the new secret, wait for new connections/pools to use it, and monitor authentication failures. Only then lock or drop the old account.

ALTER USER 'svc12_secret_a'@'127.0.0.1' ACCOUNT LOCK;SHOW CREATE USER 'svc12_secret_a'@'127.0.0.1';-- After validating the new credential, remove the old lab identity.DROP USER 'svc12_secret_a'@'127.0.0.1';

A connection that was already authenticated may remain alive after credential changes depending on what you changed; rotation plans must distinguish existing sessions from new authentication. The acceptance test is therefore a fresh connection with the new secret and a fresh negative connection attempt with the old secret.

Production judgment

Production applications should avoid embedding MySQL passwords in images, binaries, repositories, environment templates, or broad shared configuration. Prefer a runtime identity/secret mechanism that supports access control, audit, rotation, and short exposure windows. Keep database privileges narrow enough that secret compromise does not become server compromise.

Secret rotation is an operational process, not merely ALTER USER. Define owner, cadence or trigger, rollout ordering, validation, rollback, session/pool refresh behavior, and emergency revocation. Store the procedure beside the service's operational documentation, not only in one administrator's memory.

Summary and bridge to Lesson 4

A database password is only as private as every layer that carries and stores it. The next lesson asks the inverse question: once clients act, what trustworthy evidence should the server retain—and what sensitive data should it avoid retaining unnecessarily?

Authoritative references

• MySQL 8.4 — End-User Guidelines for Password Security
• MySQL 8.4 — Using Option Files
• MySQL 8.4 — Environment Variables
• MySQL — mysql_config_editor