What is ConfigSeeder®?

ConfigSeeder® configuration management system allows you to securely store your application configuration at a central place. It manages the configuration of all your applications and environments. ConfigSeeder® offers a fine-grained access control system and integrates with your existing security infrastructure.

Do you have different runtime environments? No problem for ConfigSeeder®. In contrast to most of our competitors, we offer integration into different runtime environments:

• Pull configuration data directly into your application, using one of our client libraries.
• Provision Secrets and ConfigMaps to Kubernetes Clusters using our Kubernetes Connector.
• Provision Files to Linux or Windows VMs using our OS Connector
• Use configuration data stored in ConfigSeeder® in Ansible using our Ansible Lookup Plugin.

Master common challenges with ConfigSeeder®

All applications need to be configured with data like URLs, login credentials, connection properties, … While the source code of the applications is properly structured and maintained and stored in a source control system, the proper handling of the required configuration data is usually neglected. Configuration data is distributed across all applications, configuration files are lying around on the servers, and confidential information is sometimes stored in plain text in a source code management system.

Find more reasons for using ConfigSeeder® on our website.

Asking how an application is configured

When configuration files are stored in a source control management system, usually only developers can view or even change the configuration. When configuration files are stored directly on the servers, perhaps only system engineers have access. It can get pretty complicated to just find out how an application is configured.

ConfigSeeder® provides easy access to configuration data. Assuming the necessary access rights, everyone can access the configuration data using the easy to use Web UI.

With ConfigSeeder®, application configuration can easily be managed by the application management or release management. There won’t be a reason to ask how an application is configured, just look it up in ConfigSeeder®.

Duplication of configuration data

In an application landscape, some configuration data is reused in multiple applications. Be it the URL of an API Gateway or downstream systems or default settings like log levels. When such configuration data changes, errors are nearly unavoidable.

With ConfigSeeder®, configuration data can be composed of multiple configuration groups.

Define configuration properties in one place and use it where required. Update a changing URL in one place and immediately provide it to all applications. Using ConfigSeeder® avoids duplication of configuration properties.

Media breaks

In lager companies, responsibilities are usually clearly defined, an example:

• The DB Admins set up accounts for the SQL Server
• The DevOps engineer creates a secret containing the username and password for a database connection
• The developer (or release or application manager) creates a lot of orders and coordinates the admins and engineers
• The release and application management is responsible for production / the developer might not be allowed to know production passwords

There is a lot of communication between everyone involved and a lot of media breaks. Every media break increases the likelihood of errors.

ConfigSeeder® allows you to reduce the number of media breaks.

Developers, release and application managers, or even the DBAs can directly configure an application.

Benefits of ConfigSeeder®

Use of Standards

One of the core principles of ConfigSeeder® is to use standards wherever possible. Our goal is to make the setup and integration of ConfigSeeder® as well as the import of configuration data as easy as possible. We also don’t want to create a vendor lock-in, but rather to make the export of data as easy as the import.

Some examples of the consequent use of standards:

• For security integration, OIDC, SAML 2.0, and pre-authentication based on HTTP headers are supported.
• ConfigSeeder® allows that existing configuration data in the form of property files and YAML files can directly be imported
• Configuration data stored in ConfigSeeder® can be exported as JSON, YAML, properties, or INI.
• Our libraries for the use with frameworks follow the relevant standards (We provide a Property Source for Spring and a ConfigSource for Eclipse MicroProfile. If an application is based on the Spring or Eclipse MicroProfile standard, our Library can be added to the dependencies and the application will receive configuration data stored in ConfigSeeder® without any code changes required.

Validity of configuration values

When the configuration of an application is put together, a few facts should be considered: For which environment should the application be configured? for which application version will the configuration be used? (a new downstream system may be integrated in the next version. So that the configuration for the current version does not take the new downstream URL into account, but the next version does.)

With ConfigSeeder® there are different possibilities to define the validity of a configuration value.

Environment based configuration values

A configuration value can be valid for all environments or for just one environment.
Example: The credentials of a DB account are usually different for test and production.

Time-based configuration values

A configuration value might be relevant not before a defined date or only between two known dates.
Example: A new feature is activated with a feature toggle at a defined date

Version based configuration values

With a new version an application might introduce a new configuration option, the value of a configuration option might change or a configuration option is perhaps not relevant anymore.
Example: When integrating a new downstream system, an application might need a new configuration option for its URL.
The version based configuration is one of ConfigSeeder®’s great strengths: Configuration changes for an upcoming release can be entered days or weeks before the release is done. As long as the current installation of the application retrieves its configuration with its own version, the future changes won’t have any effect. As soon as the new release is installed (and retrieves the configuration with the new version), the changed configuration immediately applies.

Context-based configuration values

Use the context if neither the environment, time-based configuration nor version based configuration seems applicable. Identify an operating system, a specific hostname, the name of a Kubernetes cluster, or even the configuration of an individual developer with the context.
Example: An application is running installed directly on a VM, and also inside a docker container. The configuration might be almost identical, but for the docker container, one value is different. In this case, the context could be set to Docker or something similar.

Comparing Configuration Data

Some production issues are caused by invalid configuration data: A newly introduced configuration value was forgotten for production. The communication scheme has changed from HTTP to HTTPS, but nobody changed it for production.

ConfigSeeder® makes it easy to compare configuration data by environment, version, or date. Compare the configuration data of your production and test environment and be sure that you didn’t forget to change anything.

Of course with the required access permissions, the hidden values can be revealed.

Audit Log

Have you ever wondered why a configuration value has the value it has? And who set that specific value?

ConfigSeeder® keeps an access log that shows who changed when what configuration value(s).

In the event of an involuntary change, you can return to a previous value with a simple click.

In addition to the audit log, ConfigSeeder® offers a description field for all configuration objects with which you can document configuration changes. We also keep a history of access to the data.

Secure Data Storage

The configuration data managed by ConfigSeeder® is stored in encrypted form. The key used for encrypting and decrypting is kept outside the database. So if somebody gains access to the database, he can’t retrieve the configuration values.

Available integrations

The functionality of ConfigSeeder® is made available as a Rest API and can therefore be used by any technology. In addition to the Rest API, we provide the following integrations that make accessing the configuration data easy.

Client libraries for integration in your applications

The libraries are meant to be integrated into your applications and will make configuration data stored in ConfigSeeder® accessible by your applications. This form of integration allows receiving configuration changes during the runtime of an application without the need for a restart.

Libraries are available for Java (Plain, Spring, Eclipse Microprofile, Maven) and Go, see the description of our client libraries.

OS Connector – Provision files to a VM

With the ConfigSeeder® extension OS Connector, different kinds of files can easily be provisioned to a VM.

The following types of files are supported (Target OS can be Linux or Windows):

• Files with static content
• Files created dynamically based on a template
• Files with static binary content
• Files containing a key store or trust store

Use the OS Connector directly in a VM (as a daemon process or embedded in an installation process) or use it as an init container to provide configuration files for your containerized applications.

See the description of the OS integration feature for more details.

Kubernetes Connector – Provision API Keys, ConfigMaps and Secrets to Kubernetes

With the ConfigSeeder® extension Kubernetes Connector, ConfigMaps and Secrets can easily be provisioned to a Kubernetes (or Openshift) cluster.

The following objects are supported:

• ConfigMaps containing key/value pairs
• ConfigMaps containing multiline values (‘files’) based on templates
• Secrets containing API Keys (that grant access to ConfigSeeder®)
• Secrets containing key/value pairs
• Secrets containing a key store or trust store

See the description of the Kubernetes integration feature for more details.

Ansible Lookup Plugin – Use configuration data in Ansible

With the Ansible Lookup Plugin, configuration data stored in ConfigSeeder® can be used directly in Ansible Playbooks.

This plugin reduces the duplication of configuration data used by both your applications and infrastructure.

See the description of the Ansible integration feature for more details.

Next steps

If this article piqued your interest, you can easily test ConfigSeeder®. Try out our demo instance or have a look at our quickstart setup guide if you like to install ConfigSeeder® yourself.

Don’t hesitate to contact us if you have any questions or if you need a trial license.