Centralizing DB credentials on T Vault

As of now, the credentials for the database connection are read from T-Vault. The API is defaulted to read from the t-vault shared safe name which is specified with the name of the config file. In order for this to be configured properly, an approle with read access must be created on t-vault, then assigned to the safe or safes being used. To create an approle on the t-vault UI, you can go to the "Manage" tab -> "AppRole Management" -> select "Create new Approle". The following settings are an example of how to configure the approle

With these settings, the app role authentication will not expire, but each token will only last 15 minutes, which will work as intended since qAPI will authenticate with T-Vault per request.

If you have not created a safe yet, this can be done under "Manage" -> "Safe Management" -> "Shared Safe" -> "Create new Safe". Here, you can specify the name of the safe, who the owner is, and a small description. When creating the safe, make sure to select "Shared Safe" under type. Below is a screenshot of a sample safe creation configuration.

After creating a safe, you can add user permissions to who will be able to access the write to the safe. If you do not see the safe you created under "Safes" tab -> "Shared Safes" , you will have to give yourself read and write permissions to the safe. Do this in "Manage" -> "Safe Management" -> "Shared Safe" -> "Your safe" -> "Permissions" -> "Users". Once you add yourself, you may have to re-login to view the safe under the "Safes" tab.

Here, you can configure however many nested folders you want, which will determine the "env" path in qAPI. Below is an example of the safe having two folders for each environment.

In each folder, you would have your database credentials. Below are examples of secret configurations for each type of database. To know more about what each field should have, please visit the wikipage Locally encrypted secret files for details on each field.

Note that if teams decide to organize their database credentials with more detail and specific, they can choose to do so. For example, if they have different applications, and different environments in that application, they can organize their safe to be "application/env" and have their secrets in such folder. This would lead to the "env" path of the request to be seperated with extra "/" , depending on the amount of nested folders.

Once the approle and safe are created, the shared safe will need to give the app role read permissions. This can be done under "Manage" -> "Safe Management" -> "Shared Safe" -> "Your safe" -> "Permissions" -> "AppRoles" -> "Add Approle to Safe" . Then, select the name of the Approle you created.

After this, in order to get the roleId and secretId from the approle, you can go to "Manage" -> "AppRole Management", and under the Approle you created, select "Create Secret Id". Then, make sure you select "Download" after generating the id. This will download an csv file. You can open the csv file, and you can find roleID and secretId under their corresponding columns. These values may now be mapped in your application.yml file, whether that may be written manually if running locally, or tied to a PCF service if managing on Pivotal Cloud Foundry, or however else you wish to map them.