Managing Database Logins

Much like the SSH login, you can use Vault to manage access to a database server, such as a MySQL server. This is a valuable feature for cloud instances, because you no longer need to maintain a static password in the template. Every instance gets its own username:password combination, which is also time-restricted.

A word of caution: For many cloud services, such as Amazon EC2 and Amazon RDS, the machines and databases reside together on virtual private networks. If that is not the case in your setup, make sure you encrypt the MySQL connections using TLS. This is not normally the case for MySQL.

First add the MySQL back end and write the connection to your MySQL server in the back end configuration path:

$ vault mount mysql
$ vault write /mysql/config/connection connection_url="user:password@tcp(w.x.y.z:3306)/"

The connection settings can no longer be read out after doing this. Make sure that MySQL also distinguishes users by hostname. In other words, you need to specify the correct host entry of the vault server for the user. Additionally, the user must have GRANT rights to create additional users with different rights.

Next, set the validity period and the duration of use for MySQL access in the back end's configuration path. First, set the validity period to one hour. At the end of this hour, the lease can be extended up to the maximum period of 24 hours, as per your definition:

$ vault write /mysql/config/lease lease=1h lease_max=24h

The MySQL back end supports random names for roles that can have user access. A role definition includes the MySQL statement for creating the user. As an example, I will define a readonly role that can only perform SELECTs on all tables:

$ vault write /mysql/roles/readonly sql="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';"

Vault replaces the placeholders {{name}} and {{password}} with the generated values. The following commands show the stored roles and the associated SQL statements:

$ vault list /mysql/roles
$ vault read /mysql/roles/readonly

For access to the MySQL database, the application itself – or a job that runs at regular intervals – requests access and receives the username/password combination:

$ vault read /mysql/creds/readonly

The access assignments are automatically revoked when the validity period expires. If you manage multiple MySQL servers, you can do this by additionally integrating the MySQL back end with a second path. Transfer this path to the mount command using the path argument:

$ vault mount -path mysql2 mysql

Auditing via Log Data

Vault provides two back ends for creating logs for auditing access to the vault server in case of heavy utilization. You can choose between file and syslog, or both back ends can be used at the same time. In this example, I will only be using the syslog back end, which you've probably already integrated into your existing monitoring. To activate, run the following command with the vault tag and the AUTH syslog facility. The logs can be sorted directly by syslog in the usual way:

$ vault audit-enable syslog tag="vault" facility="AUTH"

Vault's log data is very detailed and contains information about the login credentials used. However, Vault hashes these by default using SHA256 and a salt, so they do not end up in plain text in the logs.

Conclusions

Far beyond the capabilities of classic password managers, Vault provides options for structured management and distribution of secrets and the dynamic handling of user access. Policy-based authorization, together with the authentication and audit back ends, enables technically and procedurally safe deployment, and not only in cloud environments. Compared with the Keywhiz program [4], which is similar in terms of the basic concept, structure and data storage with Vault is more sophisticated and more flexible.

The use of Shamir's Secret Sharing procedure is useful to distribute responsibility reliably across several shoulders. However, stopping provisioning (e.g., in an emergency) is something the administrator can do alone. Authentication back ends like the one used by GitHub are useful and shift the work from the production to the administrative level.

Only when you create your own back end, which you would have to compile directly with Vault, is the process a little awkward. A system with dynamic addition at run time would be beneficial. Nevertheless, thanks to the low barriers to entry, Vault is a useful optimization tool in the daily working life of an admin team.