DB_PASSWORD & Configuration Files

[shealavington]

How does this work for DB_PASSWORD?

I ask as this is loaded as a facade, and facades are loaded after configurations, therefore, I can not use the facade inside the configuration files to get the database connection details. 🤔

@stephen-isc

[stephen-isc]

Do you mean you want to load a value in the database config file from a key vault using this package?

[shealavington]

Pretty much. Is that how you intended for this package to work, or do you handle DB_PASSWORD differently?

Thanks for the reply

[stephen-isc]

I've just tested it and it doesn't work, I'm afraid. Which is rather disappointing since I have a feeling we did write it for your use case (probably not for $DB_PASSWORD, but still for use in config files) and never actually used it.

I think if you wanted to do that then you would have to instantiate the Vault class yourself. The service provider uses config() to get the vault credentials anyway, so using it in a config file is going to fail.

You would have to do something like

$vault = new InsitesConsulting\AzureKeyVault\Vault(
                    env('AZURE_AD_TENANT_ID'),
                    env('AZURE_AD_CLIENT_ID'),
                    env('AZURE_AD_CLIENT_SECRET'),
                    env('AZURE_KEY_VAULT_NAME')
                );

at the top of your config file, and then 'password' => $vault->secret('database-password'), where you want to get the value.

Unfortunately, the global helper method wraps the facade method as well. Perhaps it should be changed to call app('vault') instead, though I'm not sure that helps you since that still requires using config() to instantiate the Vault class anyway.

[shealavington]

Thanks, Stephen.

I thought this was the case, unfortunately, it still won't work as I did try that. Your package here uses the Laravel library Http::class which is a Facade, and facades are loaded after the configuration files. Because of this situation, when trying to use Vault inside a configuration, Laravel complains that the Facades have not been initated yet. Therefore, unfortunately id doesn't work. I did managed to get it to work by converting it all to Guzzle HTTP requests instead and removing the Cache adapter, but that's all less than ideal.

Out of curiosity, have you proceeded with using Azure Vault or any vault for your own usage? I'm currently in a POC phase using Azure Vault, and I'm personally finding it more complex than the time worth implementing.

[stephen-isc]

Ah. Then there's probably no way forward without more work than I have the time to do on this at the moment.

We didn't end up using this package ourselves, no - the plan to use it for storing secrets common to several apps (e.g. tokens for accessing other services) was overtaken by other events. If we do end up doing it, though, we'll have to find a way to make it work in config files.

The thing which might be worth doing is to add something to the documentation clarifying that this won't work in config files, to save someone else from going round the loop you have.

[shealavington]

No worries, thanks for the insight. Implementing Vaults so far has proven rather complex aha.

Sounds like a good idea, that'll be helpful to others, I did have to spend a while debugging, would be good to stop others from needing to do the same.

[BARNZ]

A similar scenario for us - we are investigating whether to use Azure Key Vault as we have been asked not to store any db passwords in plaintext on our server. In this case, I dont think you would want to be able to use this package in config files as the moment you run php artisan config:cache laravel would be writing the resolved secrets as plaintext straight into bootstrap/cache/config.php