Understand secrets storage

Introduction

Censhare Server requires to connect to a lot of different external services. There are internal services, for example database or Keycloak. There are external services, for example S3 storage for hotfolder or Amazon Elastic Transcoder. To all these services, Censhare Server must authenticate itself. The Censhare Server provides several ways to store credentials for these services. These different secret storage options differ from each other in the level of security and complexity. This article gives you a general introduction into the concepts, the related architecture and the advantages of the various options.

The following article describes the setup and usage of the secret storage options for the Censhare Server - On-premise.

This article gives you a general overview of the integration of secrets storage in a general. With Censhare Server, you have a full control and flexibility on the functionality and its configuration. But, it is also on your side setup the secrets storage in a way that it fits best to your environment.

For now, Censhare Classic - SaaS allows the same functionality and configuration as the On-Premise option. Note that this is subject to change without further notice!

For more information on the configuration for Censhare Classic - On-premise, see:

• Configure secrets storage using vault system

• Configure secrets storage using file

With Censhare Cloud, your solutions run on a fully managed platform by Censhare IT. This releases most of the burden for setup and configuration. As a consequence, part of the functionality is hidden from you and you have less control on the configuration.

The Censhare Cloud - Bridging Option is handled in the same way as you deal with Censhare Classic - On-premmise.

Provide secure storage of passwords and other secrets

Censhare Server provides three different ways to store credentials for services access:

• External vault system. For now, we support Vault by HashiCorp. HashiCorp Vault is an identity-based secrets and encryption management system. For more information, see What is Vault.

• Secrets file that is stored at the machine that is running Censhare Server. All credentials are stored in a file that is placed outside of the Censhare Server file system.

• XML configuration files that are managed by the Censhare Admin Client. The XML configuration file for a service also stores the credentials for the access to the service. The credentials are stored in plain text. XML configuration files have been the only place where credentials have been stored before inception of a secrets storage.

Here is a short comparison of the three different ways to store credentials:

Obviously, a vault system provides the highest level of security for storing credentials. As a consequence of this high level of security, a lot of management effort is necessary. If a company is already operating a vault system, it does make sense to integrate credentials management for the Censhare Server. If Censhare Server is the only system which uses a vault system for credentials management, it should be weighted carefully if the related effort is really justified.

If there is only a certain level of security required, Secrets file can be the option of choice. It removes the credentials from the XML configuration files that are managed by the Censhare Admin Client. The Secrets file then can be placed somewhere outside of the Censhare Server at the file system of the machine that runs the Censhare Server.

XML configuration files can be an option if no higher level of security is required. This might be the case if Censhare Classic is running on the machine of a Solution Developer.

If a vault system or Secrets file is used, the credentials entries in the XML configuration files can and should be empty. That prevents that they are still revealed via Censhare Admin Client.

Which kind of storage for credentials is applied, you can see in the system properties.

Architecture of secrets storage

When Censhare Server requires to access a service, it checks which keys are assigned to the desired service. Censhare Server then checks which credentials storage has been configured. It then uses the key to retrieve the credentials from the configured storage.

If no Secrets file or vault system are configured, the Censhare Server uses the XML configuration files as storage. This has two advantages:

• It is possible to run the Censhare Server without configuration of a more secure credentials storage.

• Censhare Server can be upgraded to a version with vault system/Secrets support without interruption: After the upgrade of the Censhare Server, it continues to use the XML configuration files. In a second step, another credential storage can be set up. vault system/Secrets support has been introduced with version 2025.1.

Which services are protected

The following list serves as an example of the services in the Censhare Server that can be managed by a more secure credentials store:

• Acrolinx

• Custom authentication

• Database

• DPS Upload

• Google Map

• Kafka API key

• Keycloak

• Mail

• Online Channel

• Pentaho interface

• S3 Filesystem

• Video: Amazon Elastic Translate Encoder

• Video: Amazon Media Convert

• Video : Sorenson

• XEditor

For a complete and up-to-date list, always see the Secrets template file in the Censhare Server directory:

CODE

../censhare/censhare-Server/app/config/secrets

Hierarchy of the various secrets storage levels

Typically, one type credential storage is configured. So, you either use a vault system, a Secrets file, or the XML configuration files. But, if required, the secrets storage implementation provides you with a great flexibility. This means that you are not required to manage all credentials via vault or via Secrets file. Some of your credentials can be managed via vault system, some via a Secrets file and some can still reside in their XML configuration files.

Here are two examples when this might be useful:

Example: Use Secrets file for test accounts

You manage your credentials via a vault system. Now, you are interested to use the Amazon Elastic Translate Encoder service on the Censhare Server. But, you are not sure if this is exactly what you are looking for and decide for a trial period before you finally want to use it.

Therefore, you want to store the credentials in a vault system only when you have finally decided for Amazon Elastic Translate Encoder. As of that, you setup a Secrets file on your Censhare Server and add the credentials for Amazon Elastic Translate Encoder here.

When the Censhare Server is looking for the Amazon Elastic Translate Encoder credentials, it checks the vault system first. The vault system tells that there are no Amazon Elastic Translate Encoder credentials stored. As of that, the Censhare Server now checks if there is a Secrets file defined and then checks if the credentials are stored in this place.

If you decide not to go for the Amazon Elastic Translate Encoder service, you can easily remove the credentials from the Secrets file. Or, you have decided to use the Amazon Elastic Translate Encoder service. You add the credentials to the vault system and remove them from the Secretes file. Censhare Server now receives these credentials from the vault system.

Example: Smooth migration to Secrets file

You are running a Censhare Server without any secure storage. Now, you plan to use a Secrets file. For a smooth integration, you plan to add the credentials for the various services step-by-step to the Secrets file.

You start and add the database credentials to the Secrets file first. You restart the Censhare Server and check if the Censhare Server is reading the database credentials from the Secrets file. This works as expected and the database credentials can be removed from the respective XML configuration file.

As the Censhare Server does not find credentials for other services in the Secrets file, it checks the XML configuration of the respective service. This way, you can migrate your credentials as suits best to you.

The hierarchy of secure storage access

The Censhare Server follows a certain hierarchy when its looking for credentials of a certain service:

1. vault system

2. Secrets file

3. XML configuration files

The process is the following:

1. Check if a vault system is configured.

2. If vault system is configured, check if the key for the desired credentials exists.

3. Check if a Secrets file is configured.

4. If a Secrets file is configured, check if the key(s) for the desired credentials exists.

5. Otherwise: Use the key(s) to read the credentials from the XML configuration file for the respective service.

Once the Censhare Server has received the credentials, it does not check the remaining secrets storage places for the desired credentials anymore.

No fallback to another credentials store layer

The described hierarchy is not designed to provide a fallback mechanism if the preferred credentials storage is not available. Here are some reasons why this is not recommended.

The Secrets file cannot be used as backup for a vault system:

• There is no synchronization mechanism between a vault system and a Secrets file.

• A vault system can provide high availability by design and does not require a backup by a Secrets file.

XML configuration files cannot be used as backup for a vault system or a missing Secrets file:

• After using a vault system or Secrets file, the credentials in XML configuration files should be removed as they are stored as plain text. It does not make sense to use a Secrets file if the credentials are still available in the Censhare Admin Client.

• There is no sychronization mechanism between XML configuration files and a vault system respective Secrets file.