Disclaimer: All changes that you might do are your own responsibility! Please backup your configuration files before changing them. I am not liable for any damages you might create following this blog post!

I do not describe the installation of CSE in detail. For a detailed describtion how to install CSE on RedHat Enterprise Linux or similar Linux systems, see: http://www.virtualizationteam.com/cloud/vmware-container-service-extension-2-6-1-installation-step-by-step.html.

With CSE2.6 an encryption of configuration files was introduced to protect confidential information like RabbitMQ, vCenter and VMware Cloud director password.

If you want to execute the Container Service extension as a Service you need to ensure the highest level of security possible, particularly in production, so let´s start at the beginning 

The CSE configuration file

You should not leave any configuration information not encrypted, otherwise your server maybe more openly accessibly .

See below an example of a config.yaml.

amqp:
  exchange: cse-ext
  host: amqp.vmware.com
  password: guest
  port: 5672
  prefix: vcd
  routing_key: cse
  ssl: false
  ssl_accept_all: false
  username: guest
  vhost: /

vcd:
  api_version: '33.0'
  host: vcd.vmware.com
  log: true
  password: MySecretPassword
  port: 443
  username: administrator
  verify: true

vcs:
- name: vc1
  password: MySecretPassword
  username: cse_user@vsphere.local
  verify: true
- name: vc2
  password: MySecretPassword
  username: cse_user@vsphere.local
  verify: true

service:
  enforce_authorization: false
  listeners: 10
  log_wire: false
  telemetry:
    enable: true

broker:
  catalog: cse
  default_template_name: my_template
  default_template_revision: 0
  ip_allocation_mode: pool
  network: mynetwork
  org: myorg
  remote_template_cookbook_url: https://raw.githubusercontent.com/vmware/container-service-extension-templates/master/template.yaml
  storage_profile: '*'
  vdc: myorgvdc

By default CSE expects an encrypted config.yaml unless you use –skip-config-decryption.

To encrypt a config file use:

cse encrypt config.yaml --output encrypted-config.yaml

During the encryption of the file you are asked to define a password. This password is needed whenever you are using the configuration file.

You have to keep in mind that CSE does not have an internal possibility to store information like connections, credentials for needed connections or even for a state.

This means that CSE is completely stateless, with all advantages and disadvantages. One of the advantages is that you can redeploy CSE on any server as long as CSE is installed and you have the configuration file. One of the disadvantages is that you need to provide the configuration file and the password during startup of the service. This means you have to find a way to provide the password during the boot time.

To start CSE you will be prompted during the startup of the service to provide the password for the encrypted configuration file:

In a real world installation of CSE you do not want to start CSE manually, whenever your server reboots or during startup of a server. Therefore you need to have a systemd unit file to automatically start CSE. If you followed my post carefully, you might have an idea what the challenge might be: You have to provide a password during the boot time of the server.
You have to provide the password during boot time of the server in an environment variable $CSE_CONFIG_PASSWORD.
There are two ways to declare this variable:

• in the init script
• in an environment script referenced in the startup script
• directly defined in the systemd unit file
  

Excursion: Systemd unit file

To understand how to define the variable it is useful to understand the structure of a systemd unit file. For more detail see: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

The init script contains of several sections. I will just explain section relevant for CSE that are the absolute basis:

• Unit
• Service

The Unit section looks like follows:

[Unit]
Description=Container Service Extension for VMware vCloud Director
Wants=network-online.target
After=network-online.target

In the Unit section you describe the service itself as well as dependencies that need to be fulfilled to start your service successfully.
Wants means that the network service is a soft requirement meaning that the network service should be started but the init script will be executed even if the service was not started successfully.
After means that the service will be started after the network service was started.

The Service section looks like follows:

[Service]
[Environment=CSE_CONFIG_PASSWORD='mysecretpassword'] optional
ExecStart=/home/stefan/cse.sh
User=stefan
WorkingDirectory=/home/stefan
Type=simple
Restart=always
[EnvironmentFile=/path/to/file] optional

In the section service you define the startup of the service like which executable should be started, which user to use for the startup of the service and which WorkingDirectory.
In our example of CSE,you will execute a shell script to start CSE.
ExecStart defines the executable which to use and how to call the executable.
User defines the user under which the service will be started.
WorkingDirectory defines which directory to use to store temporary information like log files.
EnviromentFile defines a file, in which you can set the environment that is used when the service is started.
Environment defines variables that are available during execution of the script. In our usecase you need either Environment, EnvironmentFile or none of them.

Define the variable in the init script

You can define CSE_CONFIG_PASSWORD directly in the shell script that is called to start CSE. You have to add export CSE_CONFIG_PASSWORD=’mysecretpassword’ to the shell script like:

export CSE_CONFIG_PASSWORD='mysecretpassword'
/home/stefan/.local/bin/cse run -c /home/stefan/encrypted-config.yaml

To ensure that that only and only the service user has read/write and execute permission ont the file because you have to store the password in clear text!

The environment variable is just valid for the time of execution and cannot be read by other users than the service user and root if somebody has unauthorized root access, you have another problem.

Define CSE_CONFIG_PASSWORD in the environment script

To define the config in the init script, you need to add EnvironmentFile=/path/to/file to the cse.service systemd unit file.
A systemd unit file could look like follows:

[Unit]
Description=Container Service Extension for VMware vCloud Director
Wants=network-online.target
After=network-online.target

[Service]
ExecStart=/home/stefan/cse.sh
User=stefan
WorkingDirectory=/home/stefan
EnvironmentFile=/path/to/file
Type=simple
Restart=always

[Install]
WantedBy=default.target

Please be aware if the EnvironemntFile is not available during execution of the script, your script will fail and CSe will not start.
The environment file is quite easy:

CSE_CONFIG_PASSWORD='MySecretPassword'

You have to ensure that that only and only the service user has read/write and execute permission on the file because you have to store the password in clear text!

Definition in systemd unit file

To define the environment variable in the systemd unit file you just have to add Environment=CSE_CONFIG_PASSWORD='Mysecretpassword' to the systemd unit file that defines the CSE startup.
You can find several examples of the unit file above.

You have to ensure that that only and only the service user has read/write and execute permission on the file because you have to store the password in clear text!

Sources

During the creation of this Blog entry I used several sources, that might be interested for further reading:

Systemd unifiles: https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
systemd environments: https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html
CSE documentation: https://vmware.github.io/container-service-extension/INSTALLATION.html

And many discussion with colleagues like Eiad Al-Aqqad (see http://www.virtualizationteam.com/about)

We are working on a daily basis on so many topics that would be interesting for a broader audience. Therefore, I thought that it would be a great idea to start a blog.

So stay tuned, there will be a lot of interesting material posted in the next days.