MSSQL is one of the supported plugins for the database secrets engine. This
plugin generates database credentials dynamically based on configured roles for
the MSSQL database.
See the database secrets engine docs for
more information about setting up the database secrets engine.
Note: The example above demonstrates a connection with SQL server user named vaultuser, although the user vaultuser might be Windows Authentication user part of Active Directory domain, for example: DOMAIN\vaultuser.
In this case, we've configured Vault with the user "sa" and password
"yourStrong(!)Password", connecting to an instance at "localhost" on port 1433. It is
not necessary that Vault has the sa login, but the user must have privileges
to create logins and manage processes. The fixed server roles
securityadmin and processadmin are examples of built-in roles that grant
these permissions. The user also must have privileges to create database
users and grant permissions in the databases that Vault manages. The fixed
database roles db_accessadmin and db_securityadmin are examples or
built-in roles that grant these permissions.
Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
$ vault write database/roles/my-role \
db_name=my-mssql-database \
creation_statements="CREATE LOGIN [{{name}}] WITH PASSWORD = '{{password}}';\
CREATE USER [{{name}}] FOR LOGIN [{{name}}];\
GRANT SELECT ON SCHEMA::dbo TO [{{name}}];" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
$ vault write database/roles/my-role \ db_name=my-mssql-database \ creation_statements="CREATE LOGIN [{{name}}] WITH PASSWORD = '{{password}}';\ CREATE USER [{{name}}] FOR LOGIN [{{name}}];\ GRANT SELECT ON SCHEMA::dbo TO [{{name}}];" \ default_ttl="1h" \ max_ttl="24h"Success! Data written to: database/roles/my-role
Be aware! If no revocation_statement is supplied,
vault will execute the default revocation procedure.
In larger databases, this might cause connection timeouts.
Please specify a revocation statement in such a scenario.
Here is a complete example using Azure SQL Database. Note that databases in Azure SQL Database are contained databases and that we do not create a login for the user; instead, we associate the password directly with the user itself. Also note that you will need a separate connection and role for each Azure SQL database for which you want to generate dynamic credentials. You can use a single database backend mount for all these databases or use a separate mount for of them. In this example, we use a custom path for the database backend.
First, we mount a database backend at the azuresql path with vault secrets enable -path=azuresql database. Then we configure a connection called "testvault" to connect to a database called "test-vault", using "azuresql" at the beginning of our path:
When we no longer need the backend, we can unmount it with vault unmount azuresql. Now, you can use the MSSQL Database Plugin with your Azure SQL databases.
The MSSQL plugin supports databases running on Amazon RDS,
but there are differences that need to be accommodated. A key limitation is that Amazon RDS doesn't support
the "sysadmin" role, which is used by default during Vault's revocation process for MSSQL. The workaround
is to add custom revocation statements to roles, for example:
vault write database/roles/my-role revocation_statements="\ USE my_database; \ IF EXISTS \ (SELECT name \ FROM sys.database_principals \ WHERE name = N'{{name}}') \ BEGIN \ DROP USER [{{name}}] \ END \ IF EXISTS \ (SELECT name \ FROM master.sys.server_principals \ WHERE name = N'{{name}}') \ BEGIN \ DROP LOGIN [{{name}}] \ END"
vault write database/roles/my-role revocation_statements="\ USE my_database; \ IF EXISTS \ (SELECT name \ FROM sys.database_principals \ WHERE name = N'{{name}}') \ BEGIN \ DROP USER [{{name}}] \ END \ IF EXISTS \ (SELECT name \ FROM master.sys.server_principals \ WHERE name = N'{{name}}') \ BEGIN \ DROP LOGIN [{{name}}] \ END"