[Feature Request] External secrets integration #480

New Issue

GiteaMirror · 2025-10-31T15:13:06-05:00

GiteaMirror commented

2025-10-31 15:13:06 -05:00

Originally created by @Deester4x4jr on GitHub (Jul 22, 2025).

Would love to see a way to integrate infiscial into the deployment process.

Originally posted by @ravensorb in #324

I would like to second this comment and officially request a method in Komodo to integrate secrets injection with external secrets management platforms. Whether self-hosted or cloud... I use doppler but I know a lot of people use Infisical. There are obviously many others out there. Would be really cool to have first class support for the most widely used, or maybe a framework for integrating the platform of your choice in a repeatable fashion. Currently, I am using pre/post deploy shell scripts to achieve the desired results, but there are certainly significant drawbacks to this method:

I have to copy that over to each stack I write. I'm guessing I can create a stack template to make this easier, but it still makes it difficult if I need to change that script... all previously created stacks would need to be manually updated.
The secrets are not really treated as secrets, so there is a high likelihood that they show up in logs, or worse case ( like what I am currently doing ) printed in the inspect tab because they are ultimately injected as env vars. Next step for my current flow is to inject them as docker secrets, but it would be cool if this was handled as part of an in-built framework for secrets injection.

Here is my current flow:

Create a local .doppler.env file to be sent in with docker compose ( can pluck individual secrets this way, or just drop the query param and get all of the secrets this token has access to ):

#! /bin/sh
# PRE-DEPLOY Script

# Define secrets we want to get
set -- "SECRET_1" "SECRET_2"

# Join the secrets with commas and remove the trailing comma
SECRETS_PARAM=$(printf '%s,' "$@" | sed 's/\,$//')

# Download the secrets from Doppler
wget -qO- "[[DOPPLER_URL]]?format=docker&secrets=${SECRETS_PARAM}" \
    --header "accept: application/json" \
    --header "authorization: Bearer [[DOPPLER_TOKEN]]" > .doppler.env

Remove the "ephemeral" .doppler.env file that was created

rm -rf .doppler.env

The goal here was to try and create something similar to how doppler ephemeral secrets injection works. This implementation is a bit hacky, but it gets the job done. Again, taking it a step further I should be creating docker secrets with these instead of injecting as env vars.

Ideally, an in-built framework would allow you to either:

Modify the docker compose command to allow you to do things like wrap it: doppler run <args> -- ${DOCKER_COMPOSE_COMMAND_FROM_KOMODO}
- or -
Fetch secrets from an external secrets platform, choose which secrets to get, and automatically inject them as docker secrets for this execution of docker compose.

This is obviously very high level, and I am thinking of it pretty 1-dimensionally to solve my specific need. But it certainly feels like a useful feature that many people could take advantage of.

Hopefully, others agree with me. Either way, I can't thank you enough for building this in the first place. This is a breath of fresh air coming from portainer. Really appreciate the work you are doing.

-Josh

Originally created by @Deester4x4jr on GitHub (Jul 22, 2025). > Would love to see a way to integrate infiscial into the deployment process. _Originally posted by @ravensorb in [#324](https://github.com/moghtech/komodo/issues/324#issuecomment-2867216098)_ I would like to second this comment and officially request a method in Komodo to integrate secrets injection with external secrets management platforms. Whether self-hosted or cloud... I use doppler but I know a lot of people use Infisical. There are obviously many others out there. Would be really cool to have first class support for the most widely used, or maybe a framework for integrating the platform of your choice in a repeatable fashion. Currently, I am using pre/post deploy shell scripts to achieve the desired results, but there are certainly significant drawbacks to this method: 1. I have to copy that over to each stack I write. I'm guessing I can create a stack template to make this easier, but it still makes it difficult if I need to change that script... all previously created stacks would need to be manually updated. 2. The secrets are not really treated as secrets, so there is a high likelihood that they show up in logs, or worse case ( like what I am currently doing ) printed in the inspect tab because they are ultimately injected as env vars. Next step for my current flow is to inject them as docker secrets, but it would be cool if this was handled as part of an in-built framework for secrets injection. Here is my current flow: - Create a local .doppler.env file to be sent in with docker compose ( can pluck individual secrets this way, or just drop the query param and get all of the secrets this token has access to ): ```shell #! /bin/sh # PRE-DEPLOY Script # Define secrets we want to get set -- "SECRET_1" "SECRET_2" # Join the secrets with commas and remove the trailing comma SECRETS_PARAM=$(printf '%s,' "$@" | sed 's/\,$//') # Download the secrets from Doppler wget -qO- "[[DOPPLER_URL]]?format=docker&secrets=${SECRETS_PARAM}" \ --header "accept: application/json" \ --header "authorization: Bearer [[DOPPLER_TOKEN]]" > .doppler.env ``` - Remove the "ephemeral" .doppler.env file that was created ```shell rm -rf .doppler.env ``` The goal here was to try and create something similar to how [doppler ephemeral secrets injection](https://docs.doppler.com/docs/accessing-secrets#mounting) works. This implementation is a bit hacky, but it gets the job done. Again, taking it a step further I should be creating docker secrets with these instead of injecting as env vars. Ideally, an in-built framework would allow you to either: - Modify the docker compose command to allow you to do things like wrap it: `doppler run <args> -- ${DOCKER_COMPOSE_COMMAND_FROM_KOMODO}` - or - - Fetch secrets from an external secrets platform, choose which secrets to get, and automatically inject them as docker secrets for this execution of docker compose. This is obviously very high level, and I am thinking of it pretty 1-dimensionally to solve my specific need. But it certainly feels like a useful feature that many people could take advantage of. Hopefully, others agree with me. Either way, I can't thank you enough for building this in the first place. This is a breath of fresh air coming from portainer. Really appreciate the work you are doing. -Josh

GiteaMirror added the enhancement label 2025-10-31 15:13:06 -05:00

GiteaMirror commented

2025-10-31 15:13:07 -05:00

@mbecker20 commented on GitHub (Jul 22, 2025):

I have considered this as well

@mbecker20 commented on GitHub (Jul 22, 2025): I have considered this as well

GiteaMirror commented

2025-10-31 15:13:08 -05:00

@Deester4x4jr commented on GitHub (Jul 23, 2025):

Awesome to hear! Let me know if I can help in any way. Ive never done any Rust development, but the front-end stack seems to be things I am pretty comfortable with. Or if I can help by just testing things, i can do that too.

@Deester4x4jr commented on GitHub (Jul 23, 2025): Awesome to hear! Let me know if I can help in any way. Ive never done any Rust development, but the front-end stack seems to be things I am pretty comfortable with. Or if I can help by just testing things, i can do that too.

GiteaMirror commented

2025-10-31 15:13:08 -05:00

@adrianipopescu commented on GitHub (Aug 5, 2025):

it's interesting, infisical works pretty much the same way

@adrianipopescu commented on GitHub (Aug 5, 2025): it's interesting, infisical works pretty much the same way