Use of vault system and Secrets file at the same time

Introduction

A vault sysem is not meant for quickly adding or removing credentials, for example for testing purposes. Therefore, the Secrets Manager allows to use a vault system and a Secrets file at the same time. For example, a service in the Censhare Server shall be tested if it the external service behind is working as expected. For this reason, the credentials are added to the Secrets file first. Once, it has been decided to use the external service, the credentials are added to the vault system.

As there is no synchronization between the vault system and the Secrets file, the Secrets file cannot be used as backup for a vault system.

For an introduction on the concept of secrets storage in Censhare Server, see Understand secrets storage.

This article only applies to Censhare Classic. For Censhare Cloud, no Secrets file is supplied and the central vault system is managed by Censhare IT only. For more information, see Secrets storage in Censhare Classic and Censhare Cloud.

Configure dual use of vault system and Secrets file

The configuration of vault system and Secrets file for parallel use is the same as if you would only use vault system respective Secrets file:

Configure connection to the vault system
Set up vault system to use with Censhare Server: Add desired credentials
Configure access to the Secrets file
Create and configure Secrets file

For more information, see:

Check your log file for success

If you are using a vault system and Secrets file at the same time, you can also see in the logs how the SecretsManager is checking both systems for credentials.

The SecretManager in the Censhare Server first checks if a vault system connection exists. If so, it writes the following message and adds the prefix for the related service, for example:

CODE

Using vault service access to prefix: database

respective, for example:

CODE

Using vault service access to prefix: database, key: user.name

If the entry is found, it also writes the success message in the log, for example:

CODE

Using vault service access to prefix: database

If the entry has not been found, the SecretsManager writes the following message in the log, for example:

CODE

Vault Service entries not found for prefix : database

respective, for example:

CODE

Vault Service entry user.name not found for prefix : database

It then checks if a Secrets file exists. If it is exists, it writes the following message, for example:

CODE

Using local vault service access to prefix: database

respective, for example:

CODE

Using local vault service access to prefix: database, key: user.name

If the entry has been found, it writes a success message, for example:

CODE

Local vault service entries found secret for prefix: database

respective, for example:

CODE

Local vault service entries found secret for prefix: database, key: user.name

If the SecretsManager also does not find an entry in the Secrets file, it writes the following message in the log, for example:

CODE

Local vault service entries not found prefix: database

If the SecretsManager does not find the desired key for a service or no entry for a service at all, the Censhare Server is then looking at the entries in the XML configuration file of the service in question.

Nevertheless, it is recommended to remove credentials for any service which credentials are either managed by a vault system or a Secrets file. Otherwise, the protection for credentials by the SecretsManager is meaningless.

Here is an example as a whole where the SecretsManager is only looking for the user name for database access and finds it in the local Secrets file:

CODE

Using vault service access to prefix: database, key: user.name
Vault Service entry user.name not found for prefix : database
Using local vault service access to prefix: database, key: user.name
Local vault service entries found secret for prefix: database, key: user.name