Any way to use Komodo with encrypted .env via SOPS?

[nahnotnathan]

Currently running one large docker compose file for all my containers that stores sensitive data (database passwords, bypass keys, etc) in an encrypted .env file using SOPS.

When I run my compose file, i use the following command:
sops exec-file --no-fifo .env "docker compose --env-file {} up -d"

Overall this works great for me, but I'm interested in Komodo and I'd like to be able to maintain keeping my secrets encrypted via SOPS. I don't want to deploy a Hashicorp / OpenBao vault as it is extremely overkill for this purpose.

Is there a way for me to use SOPS and Komodo together? Does anyone have a similar setup?

[OKok-3]

I was just going to propose this idea as well. My solution right now is to simply extend the Komodo image and install SOPS and age, and attach the age key to the Komodo container in read only mode. Then for each compose stack I add a pre-deploy command to:

1. touch a .env if it doesn't exist (Komodo doesn't like no env file when you've specified one)
2. copy over the sops.yaml file to the current directory and decrypt it

and deploy the stack in Komodo as usual.

This is the Dockerbuild file I'm using:

FROM ghcr.io/moghtech/komodo-periphery:latest

# Install age
RUN apt-get update \ 
  && apt-get install -y --no-install-recommends age

# Clean up
RUN apt-get clean \
  && rm -rf /var/lib/apt/lists/*

# Install sops
RUN curl -LO https://github.com/getsops/sops/releases/download/v3.11.0/sops-v3.11.0.linux.amd64 \
  && chmod +x sops-v3.11.0.linux.amd64 \
  && mv sops-v3.11.0.linux.amd64 /usr/local/bin/sops

# Create the sops directory
RUN mkdir -p $HOME/.config/sops/age

The only tedious part is keeping up with both Komodo and SOPS development to make sure everything is up to date.

[Blacks-Army]

I just looked it up a few days ago if anyone proposed something like that lol

I also would love to see this implemented!

[cavazos-apps]

Would love to see this as well, trying to set up something similar and for a project so integration into GitOps, this seems like a no brainer.

[smoochy]

I've created an image, which contains Komodo-Periphery, SOPS and age so you don't have to do it yourselves. Every night CET it's being checked, if an update of Komodo, SOPS or age has been released. If that's the case, a new image is being built automatically. You can use a :latest or specific :<komodo-version> tag starting with 1.19.5.

I'm encrypting the .env file locally in VSC and only push the encrypted file to git. Then Komodo is picking up Compose and encrypted .env file. I run a pre-deploy command in Komodo so the file is decrypted and usable for deployment.

You can find more information here: https://github.com/smoochy/komodo-periphery-sops-age/

Hope that helps.

[Nikhil-Gohil]

Created a pull request to add sops and age to the periphery and core images:

#1053

If it gets merged should be easy to implement this kind of workflow.

[fdisamuel]

I’ve ended up with a working Komodo + SOPS + AGE setup that is deploy-time only, and it’s been stable so far. From Komodo’s side, the important part is that the stack definition does not store plaintext secrets; it just tells Komodo how to resolve an encrypted env file at deploy time.

git repo tree

root/
|- komodo/
|  |- resources/
|     |- main.toml
|
|- stacks/
   |- example-host/
      |- example-stack/
         |- compose.yaml
         |- config.toml.tpl
         |- enc.env
      |
      |- example-proxy/
         |- compose.yaml
         |- config/
            |- config.yml
            |- proxyprotocol.yml

Sanitized version of what I’m using:

[[server]]
name = "example-host"
tags = ["resource-synced"]

[server.config]
address = "example-host:8120"
external_address = "example-host.example.org"
enabled = true

[[stack]]
name = "example-stack"
deploy = true
tags = ["resource-synced"]

[stack.config]
server = "example-host.example.org"
linked_repo = "my-repo"
run_directory = "stacks/example-host/example-stack"
config_files = ["enc.env"]
compose_cmd_wrapper = "SOPS_AGE_KEY=\"[[SOPS_AGE_KEY]]\" sops exec-env enc.env '[[COMPOSE_COMMAND]]'"
compose_cmd_wrapper_include = ["config", "build", "pull", "up"]

The workflow is:

• keep enc.env encrypted with SOPS in git
• have Komodo resolve it at deploy time through the wrapper
• keep the AGE key as Komodo secret variable
• let Komodo run docker compose with the decrypted environment only for the lifetime of the deploy action

My remaining questions are from the Komodo product side:

• Is there currently any supported way to have encrypted env files decrypted inside the Komodo UI for live editing, or to manage them as an additional env/config file in the UI?
• If not, is that a planned feature area, or is the intended model strictly deploy-time secret resolution?
• The “additional env files” concept feels under-documented. I had to experiment to understand how config_files and the compose wrapper are meant to fit together with SOPS.

Thanks for any insight on this topic!

[hexsm]

Does the command SOPS_AGE_KEY="[[SOPS_AGE_KEY]]" sops exec-env enc.env '[[COMPOSE_COMMAND]]' work natively in the official image, or are you using a custom image?

[Nikhil-Gohil]

It will not work with the official image. The 3 options are:

1. Use a custom image like the one I have above
2. Install the periphery as a systemd agent and install sops on the system
3. Bind mount sops to the periphery docker image

I also don't believe opening encrypted files natively in komodo to edit them is the best way, this probably means I have to pass my keys to the komodo core as well. But that's up to the devs I guess.

I also agree that documentation around env files and variables is a little lacking, took me a bit to understand what's going on. However, I'm pretty new to docker and secrets so it could just be a me thing.

[bakrhaso]

Does this compose_cmd_wrapper = "SOPS_AGE_KEY=\"[[SOPS_AGE_KEY]]\" sops exec-env enc.env '[[COMPOSE_COMMAND]]'" not expose the age key in the process tree?

Thanks for the example! I'll probably do almost exactly the same, but with SOPS_AGE_KEY_FILE=/path/to/key in the env somewhere instead.

[nathandaven]

@bakrhaso @Nikhil-Gohil My solution below uses docker run via the official sops image, and is working well for me, if you don't want to manage a custom image.

[nathandaven]

Here's what I've figured out, and allows for not needing a custom image at all. These both use docker run via the official sops container (only a 10mb image on alpine), and use a defined [[SOPS_AGE_KEY]] variable set in Komodo variables as a secret. I then just use decryption in place via a compose.env, with options to send that in as shell exported variables, or by decrypting the env var in place and resetting. (You could also do this via compose.env.enc and do it that way, but I'm using a precommit hook to encrypt all env files in place before commits. I also host this on an internal git server, so this is easier to manage for me.)

Two options via compose_cmd_wrapper:

Option A, export variables at runtime out of docker:

eval "$(docker run --rm -e SOPS_AGE_KEY="[[SOPS_AGE_KEY]]" -v "$(pwd):/app" -w /app \
  ghcr.io/getsops/sops:v3.13.0-alpine -d compose.env | sed 's/^/export /')" && [[COMPOSE_COMMAND]]

Problem here, is you need to define your env variables form shell in all compose files. So I am using option B:

# decrypt
docker run --rm -e SOPS_AGE_KEY="[[SOPS_AGE_KEY]]" -v "$(pwd)/compose.env:/compose.env" \
  ghcr.io/getsops/sops:v3.13.0-alpine -d -i /compose.env
# run compose
[[COMPOSE_COMMAND]]
# reset
git checkout -- compose.env
# make sure you set a `env_file_path` to `compose.env` for this option

This decrypts in place with the docker container and then resets it afterwards with git so no secrets are left on disk. All in all, seems to be working decently for me, and doesn't create an attack vector of a custom docker image like above, or require me to build my own image, and manage that.

If anyone improves this idea even further lmk, I would rather just export variables in shell with option B, but due to the way [[COMPOSE_COMMAND]] injects is flags, I am not able to use <() to run this command inline.