Policy behind how DCSM injects env variables

[Aetherinox]

In short, I have Portainer. So I can visually go in and view all of the env variables assigned to my container, and the newest env var I added using DCSM doesn't show up in my env var list within Portainer.

Is this part of the expected behavior for DCSM? I mean if it is and it's functioning properly, great.

I've loaded up everything as the documentation has mentioned,

---

Setup

services:
  gotify-dcsm:
    container_name: ${GOTIFY_CONTAINER_NAME:-gotify}-dcsm
    image: ghcr.io/igor47/dcsm:latest
    environment:
      - DCSM_KEYFILE=/secrets/key.private
      - DCSM_SECRETS_FILE=/secrets/secrets.encrypted
      - DCSM_SOURCE_FILE=/secrets/secrets.yml
      - DCSM_TEMPLATE_DIR=/config
    volumes:
      - ./secrets:/secrets
      - ./config:/config
    networks:
      traefik:

  gotify:
    container_name: ${GOTIFY_CONTAINER_NAME:-gotify}
    image: ${GOTIFY_IMAGE:-gotify/server}:${GOTIFY_TAG:-latest}
    restart: unless-stopped
    depends_on:
      gotify-dcsm:
        condition: service_completed_successfully
    env_file:
      - gotify.env
    volumes:
      - ./data:/app/data
      - ./gotify/config/config.yml:/etc/gotify/config.yml
      - ./config/gotify:/config
    networks:
      traefik:
        ipv4_address: '${GOTIFY_IP}'

Structure

/docker/gotify/
    ├── secrets
        ├── key.private
        ├── secrets.encrypted
        └── secrets.yml
    ├── config
        └── gotify
            └── gotify.env.template
    ├── docker-compose.yaml

In secrets.yml I've added:

ADMIN_PASSWORD: MYPASS

In gotify.env.template I've tested with

GOTIFY_DEFAULTUSER_PASS: $DCSM{ADMIN_PASSWORD}

When I bring the container up, I can see:

gotify-dcsm  | successfully processed 1 template files
gotify-dcsm exited with code 0

Physically bashing into the container and attempting to do

echo $GOTIFY_DEFAULTUSER_PASS

However, if I do

cat /config/gotify.yml

I do see the env variable set in the file

---

Another question because it's not clear in the docs. Is it acceptable to break up the env vars between different files.

What I mean is

• I create a gotify.yml.template file which contains all of the env vars I need to be kept secret
• I also have an .env file which has all of the regular env vars which don't matter if they're seen or not.

---

And finally, I noticed when I bring the docker container up, it takes the gotify.env.template file, and creates an additional file on the host machine placed within /config/gotify/gotify.env, and in that file is the plain-text secret password.

Is that normal behavior? Because it seems odd that the objective would be to not have plaintext passwords in a file, and dcsm just takes all of the secrets and decides to create a plaintext file on the host machine. Or is the objective here to just allow a secrets file to be hosted on Github, but doesn't do anything to secure the secrets on the host machine.

[igor47]

Or is the objective here to just allow a secrets file to be hosted on Github, but doesn't do anything to secure the secrets on the host machine.

yes, the goal is to allow the secrets file to be hosted on github. on the host machine, the secrets have to be stored in plaintext, but you should avoid checking those files into the repo.

DCSM is useful for .env files, but is especially helpful with config files that contain a mix of secret and non-secret configuration.

sorry, i don't use portainer so i'm not sure about the portainer-related questions

[igor47]

Another question because it's not clear in the docs. Is it acceptable to break up the env vars between different files.

yes, feel free to break up your environment config into multiple files. you can tell compose to include all files in the environment of the container.

[igor47]

env_file:

• gotify.env

i think this is the issue. compose treats relative paths as relative to the compose.yml file. looks like you should be specifying config/gotify/gotify.env there to get the env in your environment