1. Introduction

Almost every application needs configuration data to work as intended. This configuration data normally comes in form of property files, json- or yaml-formatted files, as environment variables set by a start-script or in some other form.

The OS Connector is a ConfigSeeder component that provides configuration data in form of files to an OS (Linux or Windows).

The following types of files can be provided to applications:

  • Files with static content

  • Files with templating (e.g. content of file can differ depending on filter critera)

  • Files with binary content

1.1. Use cases

  1. Provide Configuration Data at installation time

    During the install process, the OS Connector is executed and provides configuration files. These files are used by the installation process and copied to the right loation. At startup time, the OS Connector (and therefore the ConfigSeeder) isn’t required any more.

    You can also execute the OS Connector with a tool like Ansible to setup a Linux VM (There will also be the possibility to retrieve configuration data directly with Ansible with an Ansible Plugin. Please contact us if you are interested in trying out our Ansible Integration).

  2. Provide Configuration Data at startup time

    Before an application is started, the OS Connector is executed and provides configuration data for the application.

    The OS Connector is also available as docker container (configseeder/linux-connector:<version>) which can be used as init-container.

2. Quickstart

2.1. Introduction

2.1.1. Content of the quickstart manual

The OS Connector is able to provide configuration files to a linux or windows machine. This quickstart guide gives an introduction to the use of the OS Connector.

You will understand, how

  • static configuration files are defined in ConfigSeeder

  • configuration files with templating are defined in ConfigSeeder

  • the OS Connector provides configuration files to Linux or Windows

This quickstart guide also offers links to more detailed information.

2.1.2. Preconditions

  • ConfigSeeder up and running

  • Connectivity from the Linxu/Windows VM running the OS Connector to the ConfigSeeder

  • Licence which supports the use of OS Connector

2.2. Prepare configuration groups in ConfigSeeder

  1. Create a Configuration Group os-connector-quickstart (the name of the Configuration Group can be chosen as desired)

    Create _Configuration Group_ OS Connector Quickstart

    When creating the Configuration Group, just enable the filter columns Environment and Context and leave the security options on their default values.

  2. Create the two environments TEST and PROD (the name of the Environments can be chosen as desired)

  3. Create two API Keys with permission to access the Configuration Group os-connector-quickstart One API Key should have permissions to access the Test-environment, the other one for Production.

    Create API Key for Test-Environment

    Copy the generated API Key to a secure location. ConfigSeeder doesn’t store API Keys so you can’t retrieve it again.

2.3. Scenario 1: Static configuration

2.3.1. Prepare configuration values in ConfigSeeder

  1. Open the Configuration Group os-connector-quickstart, switch to the Value Assemblies-Tab and create the following Assembly of Type File: static:

    Create Config Values for static-file TEST

    Remarks:

    • In the example file.name is set to quickstart-static.txt. It can also be set to a absolute or relative path.

    • With the value shown in the screenshot, the file will be created at the location where the OS Connector is executed.

    • If you are trying out the OS Connector on Linux, paths can be entered like <path>/<filename> where <path> can be absolute or relative

    • If you are trying out the OS Connector on Windows, be sure to enter a valid windows path like c:\temp...

2.3.2. Setup OS Connector

  1. Download und unpack the OS Connector to your system (see https://preview.configseeder.com/download/, depending on your os please use linux-connector or windows-connector)

  2. Create the file connector.yaml with the follwing content:

    connector:
  configSeeder:
    configurationGroupKeys: "os-connector-quickstart"
    tenantKey: "userdocumentation"                                   (1)
    environmentKey: "TEST"                                           (2)
    context: "example-static"                                        (3)
    serverUrl: "https://staging-postgresql-config-seeder.oneo.cloud" (4)
    connectionTimeout: 2000
    readTimeout: 2000
    apiKey: "eyJraWQiO..."                                           (5)
    1 Tenant, in which the configuration is stored. The name of the default tenant is default (it is only required to specify the tenant if not the default tenant is used. If no tenant is specified default is used by convention)
    2 Environment, for which the configuration should be read.
    3 The context, for which the configuration should be retrieved. Is normally the name of the os (hostname) but can be any value or not used at all. If multiple os connectors are used, the combination of environment and context should be unique. In this quickstart guide, context is used to distinguish the different scenarios.
    4 URL under which the ConfigSeeder is reachable.
    5 Api Key with permissions to access the configured configuration groups and enviroment.

2.3.3. Execute os-connector

Start the OS Connector by executing ./linux-connector or executing windows-connector.exe

As a result, the OS Connector should log Created file /tmp/quickstart-static.txt for Application quickstart and the file /tmp/quckstart-static.txt should have been created with the configured content.

If the executable is run again, the OS Connector should log something like LastUpdate matches, no action required for file /tmp/quickstart-static.txt for Application quickstart and the file should be unchanged. If the content is changed and the command rerun, the OS Connector will change content of the file so it matches the configured content again.

2.4. Scenario 2: Configuration with templating

2.4.1. Prepare configuration values in ConfigSeeder

  1. Open the Configuration Group os-connector-quickstart-values and create the following Configuration Values:

    Create Config Values for replacing in the template

  2. Open the Configuration Group os-connector-quickstart, switch to the Value Assemblies-Tab and create the following Assembly of Type File: template:

    Assembly Template File

  3. Click on the Value of file.template and enter the template:

    Preview of the template

Remarks:

  • In this example there is no environment set. The content of the file is controlled by the values which are used for the templating, see next step.

2.4.2. Setup OS Connector

  1. Ensure that the OS Connector is available.

  2. Change the connector.yaml to

    connector:
  configSeeder:
    configurationGroupKeys: "os-connector-quickstart"
    tenantKey: "userdocumentation"
    environmentKey: "TEST"
    context: "example-templating" (1)
    serverUrl: "https://staging-postgresql-config-seeder.oneo.cloud"
    connectionTimeout: 2000
    readTimeout: 2000
    apiKey: "eyJraWQiO..."
    1 change context to example-templating

2.4.3. Execute OS Connector

Start the OS Connector by executing ./linux-connector or executing windows-connector.exe

As a result, the OS Connector should log Created file quickstart-templating.txt for Application quickstart and the file quckstart-template.txt should have been created with the content configured for test.

3. Configuration Options

3.1. Ways to configure the Connector

This section describes every available configuration option available for OS Connector and it’s modules.

There are three ways to configure the connector:

  1. Configuration by file (lowest priority)

    Default filename is connector.yaml, the connector looks for the file in the directoy it is started from. The filename can be overwritten, see Configuration Options.

    Example:

    connector:
  log:
    level: DEBUG
  fileProperties:
    directoryWhitelist:
    - /tmp
  configSeeder:
    tenantKey: "configseeder"
    environmentKey: "TEST"
    configurationGroupKeys: "os-connector-integrationtest"
    serverUrl: "https://staging-postgres-config-seeder.oneo.cloud"

  2. Configuration by environment variables

    Example:

    export CONNECTOR_LOG_LEVEL=DEBUG
export CONNECTOR_CONFIGSEEDER_APIKEY=xxxx
...
linux-connector

  3. Configuration by startup parameter (highest priority)

    Example:

    linux-connector -connector.log.level=DEBUG -connector.configseeder.apikey=xxx ...

It is possible to mix the different ways to configure the connector. You probably want to configure the connector by file and provide the API Key with an environment variable so it isn’t readable by anyone (You don’t want to provide the API Key as a startup parameter because the values of startup parameters can be retrieved by anyone using ps awx).

Priorities of ways to configure the connector

  • A parameter configured by file can be overwritten by environment variable or startup parameter

  • A parameter configured by environment variable can be overwritten by startup parameter

3.2. Configuration Options

The OS Connector can be configured by the following options:

All keys are prefixed with connector.. This prefix is neglected in the table to save space.
Key Mandatory Value

configfile

no

Location and name of the configfile containing the connector configuration.

Defaults to connector.yaml.

binaryFile.disabled

no

Set to true to disable the binary file module.

configseeder.apiKey

yes

API Key used by Connector to access ConfigSeeder.

The API Key must be of Type OS connector

configseeder.certificateFilename

no

Allows to specify a file containing additional (PEM-formatted) certificates that are used for tls verification when connecting to configseeder. If this configuration option is not set, tls verification is done with the system certificate pool.

configseeder.configurationGroupKeys

yes

Defines which configuration groups should be read by the Connector.

configseeder.context

no

Optional for filtering configuration values by context. Either context or labels can be used, not both at the same time. Context is deprecated and will be removed in favor of labels.

configseeder.connectionTimeout

no

Connection Timeout, defaults to 1000 (ms).

configseeder.dateTime

no

Optional for filtering configuration values by validFrom & validTo.

configseeder.labels

no

Optional for filtering configuration values by labels. Either context or labels can be used, not both at the same time.

Defaults to now.

configseeder.environmentKey

yes

Environment for which the Connector is running.

configseeder.maxRetries

no

Defines, how many times the connector should try to connect to ConfigSeeder

Defaults to 3.

configseeder.readTimeout

no

Read Timeout, defaults to 2000 (ms).

configseeder.retryWaitTime

no

Time in Milliseconds between failed tries to connect to ConfigSeeder.

Defaults to 500 (ms).

configseeder.serverUrl

yes

URL under which ConfigSeeder can be reached.

configseeder.tenantKey

no

Defaults to Tenant default.

configseeder.version

no

Optional for filtering configuration values by versionFrom & versionTo

fileProperties.allowExecutableMode

no

Set to true if the OS Connector is allowed to create files which are executable (Only relevant under Linux)

Defaults to false.

fileProperties.directoryWhitelist

no

If set, the OS Connector is only allowed to manage files in the specified directories.

fileProperties.fileMode

no

Default file mode, if no mode is specified.

Defaults to 644.

fileProperties.pathPrefix

no

Optional prefix for files with a relative path. If set, all relative files are prefixed with this value.

generatedFile.disabled

no

Set to true to disable the generated file module.

log.filename

no

Name of the Logfile if logging to a file is configured.

Defaults to os-connector-<YYYY-MM-DD>.log.

log.level

no

ogLevel for the connector, valid levels are: trace, debug, info, warning, error, fatal, panic.

Defaults to 'info'

log.target

no

Target for the connector logging, valid targets are CONSOLE, CONSOLE_AND_FILE and FILE.

Defaults to 'CONSOLE'.

startupMaxWaitTime

no

Maximum duration in milliseconds which is waited if there is a problem connecting to the ConfigSeeder at startup time. Not setting startupMaxWaitTime means endless retries

Defaults to endless retries (not default set).

startupRetryWaitTime

no

Duration in milliseconds which is waited between retries if there is a problem connecting to the ConfigSeeder at startup time.

Defaults to 15000 (ms)

staticFile.disabled

no

Set to true to disable the static file module.

templateFile.disabled

no

Set to true to disable the template file module.

templateFile.replacingPostfix

no

Postfix for keys which will be replaced by ConfigSeeder.

Defaults to }.

templateFile.replacingPrefix

no

Prefix for keys which will be replaced by ConfigSeeder.

Defaults to ${.

useHostnameAsContext

no

Defines if the hostname should be sent to ConfigSeeder as context when looking up configuration values.

Defaults to false.

The specified keys can be easily translated to environment variable names:

  • Take the specified key

  • Replace . with _

  • Only use UPPERCASE Characters

connector.configseeder.apiKey becomes CONNECTOR_CONFIGSEEDER_APIKEY

4. Modules

4.1. Introduction

The different modules are responsible for managing different types of files. The following table gives an overview of the available modules.

Table 1. Kubernetes Connector Modules
Module Assembly Description

Binary File

File: Binary

Create and manage files which contain binary content

Generated File

File: Generated

Create and manage files created out of existing configuration data

Keystore File

File: Keystore

Create and manage Key-/Truststores based on PEM Certificates and Private Keys

Static File

File: Static

Create and manage files which contain static content

Template File

File: Template

Create and manage files which are created using a templating mechanism

The modules can by configured with different options. The following table shows the configuration options which are valid for all the modules:

Table 2. Common configuration options
Key Mandatory Value

assembly.active

yes

With this flag, an assembly can be activated or deactivated for different scenarios.

To enable an assembly for just environment TEST:

  • Set assembly.active to false

  • Copy assembly.active, set environment to TEST and value to true

To disable an assembly for label machine-2:

  • Set assembly.active to true

  • Copy assembly.active, add label machine-2 and set value to false

file.name

yes

Name of the file

file.name can have different kind of values:

  • filename.txt if only the filename is specified

  • ./my/relative/path/filename.txt if a relative filename must be used

  • /absolute/path/filename.txt if the file should be managed with an absolut path

If relative or absolut paths are configured, the correct path separators must be used:

  • Linux: …​/…​

  • Windows: c:\...

If a file should be provided to a Linux and a Windows VM, there could be the following configuration:

  • file.name = /tmp/filename with label Linux

  • file.name = c:\\temp\\filename.txt with label Windows

file.mode

no

File mode which should be set:

  • Linux: All modes can be set. Owner should have at least read-access. Otherwise, managing the file isn’t possible

  • Windows: Only 0444 and 0666 are valid modes.

See Configuration Options for setting a default mode.

file.user

no

Owner of the file, examples:

  • Linux: user

  • Windows: Setting the owner is not supported under Windows

Setting the user is only supported under linux.
When using owner, the OS Connector must be run as root

file.group

no

Group of the file, examples:

  • Linux: group

  • Windows: Setting the group is not supported under Windows

Setting the group is only supported under linux.
When using group, the OS Connector must be run as root

4.2. Module Binary File

4.2.1. Introduction

This module is responsible for creating configuration files with binary content on a Linux or Windows VM.

Binary Files are configured with Value Assemblies of type File: Binary

4.2.2. Configuration Values within Value Assemblies

Key Mandatory Value

file

yes

Binary content of the file.

If a different file content is required for different environments (or other filter criteria), there could be

  • a file with content <Content for Test> with environment TEST

  • a file with content <Content for Production> with environment PROD

4.3. Module Generated File

4.3.1. Introduction

This module is responsible for creating configuration files out of the configuration data stored in ConfigSeeder. The configuration values from one or more configuration groups are converted into a file of one of several predefined formats.

Generated Files are configured with Value Assemblies of type File: Generated

4.3.2. Configuration Values within Value Assemblies

Key Mandatory Value

file.format

yes

Format in which the file should be generated. Can be one of:

  • INI

  • Json

  • Properties

  • Yaml

file.configuration-groups.source

yes

This value specifies which Configuration Groups are used for the generation of the file. Defaults to the Configuration Group in which the Value Assembly is defined.

4.3.3. Examples

  1. Define the following values

    Values for Assembly File: Generated

  2. Create the following assembly

    Assembly File: Generated

  3. Run the OS Connector with the different labels or just open the preview

4.3.3.1. INI
Preview (INI) for File: Generated
4.3.3.2. JSON
Preview (JSON) for File: Generated
4.3.3.3. Properties
Preview (Properties) for File: Generated
4.3.3.4. Yaml
Preview (Yaml) for File: Generated

4.4. Module Keystore File

4.4.1. Introduction

This module is responsible for creating PKCS12 files containing only Certificates (Truststore) or also Private Keys (Keystore).

Keystores are configured with Value Assemblies of type File: Keystore

4.4.2. Configuration Values within Value Assemblies

Key Mandatory Value

keystore.certificates-configuration-groups.source

no

Reference to one or multiple configuration groups containing certificates. All Configuration Values with the type CERTIFICATE will be copied into the key-/truststore by the OS Connector.

  • Referenced Certificates must stored in PEM format

keystore.certificates-configuration-groups.filter-regex

no

Without this attribute, all Certificates contained in the configuration groups referenced by keystore.certificates-configuration-groups.source are copied by the OS Connector into the created key-/truststore.

This attribute enables to filter these certificates.

Examples:

  • certificates\.rootCA: Matches only the certificate with the exact key certificates.rootCA

  • certificates\..*: Matches all certificates with a key starting with certificates.

keystore.password

yes

Password of the Key-/Truststore

Requirements:

  • Length: 6 - 30 characters

  • Must start with [a-zA-Z0-9]

  • Can only contain [a-zA-Z0-9-+$_@#~,.?!%&*]

keystore.type

no

Type of the Keystore. The following types are supported:

  • JKS

  • PKCS12 (default)

private-key.1.*

The following configuration values have an 1 in their name. 1 specifies the alias of the private key entry and can be changed to another value. Per default and if the alias is not required, 1 should be used. Every private key entry requires at least a key and a certificate. The other configuration options are optional.

private-key.1.encrypted-key-password

no

Password if the private key is stored encrypted in ConfigSeeder®.

It the private key is not stored encrypted, this password will be ignored.

private-key.1.key

no

PEM encoded Private Key

  • Starts with -----BEGIN RSA PRIVATE KEY-----

  • Ends with -----END RSA PRIVATE KEY-----

private-key.1.certificate

no

PEM encoded Certificate

  • Mandatory if keystore.privateKey is set.

  • Starts with -----BEGIN CERTIFICATE-----

  • Ends with -----END CERTIFICATE-----

private-key.xxx.key-encryption-password

no

Password with which the private key is protected when stored in the key store.

This password can only be set for Keystores with type JKS.

4.4.3. Examples

  1. Add a certificate (optional, keystores can be created without additional certificates)

    Values for Assembly File: Generated

  2. Create the following assembly (adding private keys is optional, of course, and not required if a truststore should be created)

    Assembly File: Keystore

By hitting the preview Button, the keystore defined the assembly is created on the fly:

Keystore Preview

4.5. Module Static File

4.5.1. Introduction

This module is responsible for creating configuration files with static content on a Linux or Windows VM.

Static Files are configured with Value Assemblies of type File: Static

4.5.2. Configuration Values within Value Assemblies

Key Mandatory Value

file.static-content

yes

Static content of the file.

If a different file content is required for different environments (or other filter criteria), there could be

  • a file with content Content for Test with environment TEST

  • a file with content Content for Production with environment PROD

4.6. Module Template File

4.6.1. Introduction

This module is responsible for creating configuration files with a templating mechanism on a Linux or Windows VM.

Template Files are configured with Value Assemblies of type File: Template

4.6.2. Configuration Values within Value Assemblies

Key Mandatory Value

file.template

yes

Content/Template of the file. This content isn’t written directly to a VM, but first sent to the templating service of ConfigSeeder. See Supported templating engines.

file.configuration-groups.source

yes

This value specifies which Configuration Groups are used for the templating. Defaults to the Configuration Group in which the Value Assembly is defined.

4.6.3. Supported templating engines

In the current version, the os connector supports the following template engines:

Template Engine Description

HANDLEBARS

Templating based on the handlebars templating engine, see https://handlebarsjs.com/

Supports simple variable replacement as well as more complex constructs like if-else conditions or even loops.

SIMPLE

Simple template engine implementation that just replaces variables pre-/postfixed by ${…​}.

5. Status and Metadata

5.1. Metadata (Stored per File)

5.1.1. Introduction

The OS Connector stores Metadata for every managed file. Depending on the used Operating System, the Metadata is stored in a different way, see later sections.

The following Metadata is required by the OS Connector:

managedByConfigseeder

Boolean flag which defines if a file is managed by ConfigSeeder, meaning if ConfigSeeder OS Connector is allowed to modify or delete the given file. If a ConfigSeeder managed file shouldn’t be modified or deleted by the OS Connector, this flag can be deleted or set to false.

configseederModule

String value which defines which module of the OS Connector is responsible for managing the file.

contentHash Sha256 Hash of the content. Used by the OS Connector to verify if the content of a file has changed since the last run.

This attribute is set when a file is created and updated when the content of a file is updated by OS Connector.

lastUpdatedInMilliseconds

Timestamp which states at which time the file was last updated in ConfigSeeder. This Flag is used to determine if a File is still up to date or if it must be recreated. If the attribute isn’t available, the file will be recreated. This attribute is set or updated to lastUpdatedInMilliseconds of newest ConfigValue at creation and recreation time.

lastUpdatedInMilliseconds is set to the value of the attribute lastUpdateInMilliseconds of the newest ConfigValue which was used to create the file.

lastUpdatedInMilliseconds is not set to the time at which the file was modified on the os.

5.1.2. Linux

Under Linux, the metadata is stored in the extended file attributes, see https://en.wikipedia.org/wiki/Extended_file_attributes#Linux

Medatada Extended File Attribute

configseeder-Module

user.configseeder-module

contentHash

user.configseeder-contentHash

lastUpdatedInMilliseconds

user.configseeder-lastUpdatedInMs

managedBy-Configseeder

user.configseeder-managed

Manually Read or Modify Metadata

Reading Metadata:

$ getfattr -d /tmp/testfile.txt
getfattr: Removing leading '/' from absolute path names
# file: tmp/testfile.txt
user.configseeder-lastUpdatedInMs=0s4YOs3GcBAAA=
user.configseeder-managed="true"
user.configseeder-module="FILE"

Modifying Metadata:

Do not modify metadata unless you know what you are doing! There should be no reason to modify the metadata other than parhaps set user.configseeder-managed to false if a file should be removed from ConfigSeeder control 
$ setfattr /tmp/testfile.txt -n user.configseeder-managed -v "false"
$ getfattr -d /tmp/testfile.txt
getfattr: Removing leading '/' from absolute path names
# file: tmp/testfile.txt
user.configseeder-contentHash="8a8f264c0f554ad07c2a6248990ebbaa166b3b00404e8a6dd297ca8715a7859a"
user.configseeder-lastUpdatedInMs=0s4YOs3GcBAAA=
user.configseeder-managed="false"
user.configseeder-module="FILE"

5.1.3. Windows

Under Linux, the metadata is stored as json in an alternate data stream, see https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_(ADS)

Modifying and saving a file with an editor like Notepad++ or Ultraedit will remove the Alternate Data Stream and the Metadata.

Manually Read or Modify Metadata

Reading Metadata:

> more < testfile.txt:ConfigseederMetadata
{"ManagedByConfigseeder":true,"ConfigSeederModule":"FILE","LastUpdateInMilliseconds":1545587516835,"ContentHash":"8a8f264c0f554ad07c2a6248990ebbaa166b3b00404e8a6dd297ca8715a7859a"}

Writing Metadata:

Do not modify metadata unless you know what you are doing! There should be no reason to modify the metadata other than perhaps set ManagedByConfigseeder to false if a file should be removed from ConfigSeeder control
Create a File metadata.txt with content
{"ManagedByConfigseeder":false,"ConfigSeederModule":"FILE","LastUpdateInMilliseconds":1545587516835,"ContentHash":"8a8f264c0f554ad07c2a6248990ebbaa166b3b00404e8a6dd297ca8715a7859a"}
Update metadata
> type metadata.txt > testfile.txt:ConfigseederMetadata
> more < testfile.txt:ConfigseederMetadata
{"ManagedByConfigsee...

Appendix A: Running the OS Connector as an Init Container

A.1. Introduction

In some cases, an containerized application requires configuration data which can’t be provided by the Kubernetes Connector.

Reasons for this can be:

  • One of the (configuration) files required by the application is a binary file (license files, …​)

  • The files are too large to be stored by the Kubernetes Connector in a ConfigMap

  • The files are to complex to be created by the Kubernetes Connector

  • The configuration must be reloaded whenever the application / pod restarts

Preconditions:

  • The application will be deployed to a Kubernetes or Openshift Cluster

  • The deployment descriptor of the application must be modifiable

A.2. Setup

A.2.1. Provide the API Key

First of all, a Kubernetes Secret containing the API Key (of type OS_Connector) must be available (in the same Namespace as the OS Connector will run).

This secret can be managed automatically by the Kubernetes Connector or it can be created manually. Either way, the Secret should look like this:

apiVersion: v1
kind: Secret
type: Opaqu
metadata:
  name: os-connector-apikey
data:
  apiKey: ...

If the application also accesses the ConfigSeeder (and therefore also requires an API Key) it is not necessary to have two separate API Keys. One API Key of the type OS_Connector is sufficient. The OS Connector and the application can access the ConfigSeeder with this key. Of course, the key must have permissions to access all relevant Configuration Groups.

A.2.2. Provide OS Connector Configuration

In this example, the OS Connector will be configured with a ConfigMap. This ConfigMap can either be provided automatically with the Kubernetes Connector or you can create it manually. The following key/values should be configured:

apiVersion: v1
kind: ConfigMap
metadata:
  name: os-connector-configuration
data:
  CONNECTOR_CONFIGSEEDER_CONFIGURATIONGROUPKEYS: my-configuration-group
  CONNECTOR_CONFIGSEEDER_CONNECTIONTIMEOUT: "5000"
  CONNECTOR_CONFIGSEEDER_READTIMEOUT: "5000"
  CONNECTOR_CONFIGSEEDER_SERVERURL: https://demo.configseeder.com/
  CONNECTOR_CONFIGSEEDER_TENANTKEY: default
  CONNECTOR_CONFIGSEEDER_ENVIRONMENTKEY: TEST
  CONNECTOR_FILE_PATHPREFIX: /config

The CONNECTOR_FILE_PATHPREFIX ensures that all files with a relative path are written to the /config-Folder.

Of course you don’t need a ConfigMap, it is also possible to manually define the environment variables directly in the deployment.

A.2.3. Add the OS Connector as Init Container

The OS Connector can be embedded in the following way in the deployment descriptor:

apiVersion: apps/v1
kind: Deployment
...
      initContainers:
        - name: os-connector
          image: configseeder/linux-connector:<version>
          imagePullPolicy: Always
          envFrom:
            - configMapRef:
                name: os-connector-configuration
          env:
            - name: CONNECTOR_CONFIGSEEDER_APIKEY
              valueFrom:
                secretKeyRef:
                  name: os-connector-apikey
                  key: apiKey
          volumeMounts:
            - name: config-volume
              mountPath: /config
...
      volumes:
        - name: config-volume
          emptyDir: {}

As you can see, a volume of type emptyDir is mounted to /config. Together with the configuration option CONNECTOR_FILE_PATHPREFIX (see ConfigMap) this ensures, that the application will have a volume where all configuration files will be available.