[GH-ISSUE #677] [Feature Request] External secrets integration #7429

New Issue

GiteaMirror · 2026-04-27T21:05:43-05:00

GiteaMirror commented

2026-04-27 21:05:43 -05:00

Originally created by @Deester4x4jr on GitHub (Jul 22, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/677

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). Original GitHub issue: https://github.com/moghtech/komodo/issues/677 > 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 2026-04-27 21:05:43 -05:00

GiteaMirror commented

2026-04-27 21:05:44 -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

2026-04-27 21:05:45 -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

2026-04-27 21:05:47 -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

GiteaMirror commented

2026-04-27 21:05:48 -05:00

@Deester4x4jr commented on GitHub (Jan 21, 2026):

@mbecker20 is this being worked on as part of V2 or is that wishful thinking?

@Deester4x4jr commented on GitHub (Jan 21, 2026): @mbecker20 is this being worked on as part of V2 or is that wishful thinking?

GiteaMirror commented

2026-04-27 21:05:50 -05:00

@adrianipopescu commented on GitHub (Jan 22, 2026):

@Deester4x4jr do note, you can always set up a pre-authenticated container to pull secrets, and inside the deployments pre and post actions you have access to the host's docker if you passed through your docker socket, so nothing's stopping you from doing a docker exec -i secrets_provider secprov dump format=env > .env and in post to chmod .env to 600

@adrianipopescu commented on GitHub (Jan 22, 2026): @Deester4x4jr do note, you can always set up a pre-authenticated container to pull secrets, and inside the deployments pre and post actions you have access to the host's docker if you passed through your docker socket, so nothing's stopping you from doing a docker exec -i secrets_provider secprov dump format=env > .env and in post to chmod .env to 600

GiteaMirror commented

2026-04-27 21:05:52 -05:00

@sippeangelo commented on GitHub (Apr 14, 2026):

This is direly needed. The comments in the Komodo docs about dedicated secret management tools and that "Komodo is not intended as an enterprise level secret management solution" misses the point entirely, as secrets are very commonly needed when deploying and building images. Komodo doesn't have to commit to managing these secrets, but currently there is no way to manage them myself either!

Just the ability to wrap the Docker commands with a different executable like this issue suggests would already make it compatible with most secret management tools. Another option could be to let exported env vars be passed down from the pre-script into the Docker command somehow.

There is also no way to manage SSH keys that I can find? A secret variable in Komodo doesn't seem to be able to contain newlines, and there is no "file secret" concept. There also doesn't seem to be support for Docker build SSH secrets. The only way to achieve this seems to be to have a pre-script that downloads a file and leaves it on disk, and then pray that it gets cleaned up afterwards, which is far from ideal 😕

@sippeangelo commented on GitHub (Apr 14, 2026): This is direly needed. The comments in the Komodo docs about dedicated secret management tools and that "Komodo is not intended as an enterprise level secret management solution" misses the point entirely, as secrets are very commonly needed when deploying and building images. Komodo doesn't have to commit to managing these secrets, but currently there is no way to manage them myself either! Just the ability to wrap the Docker commands with a different executable like this issue suggests would already make it compatible with most secret management tools. Another option could be to let exported env vars be passed down from the pre-script into the Docker command somehow. There is also no way to manage SSH keys that I can find? A secret variable in Komodo doesn't seem to be able to contain newlines, and there is no "file secret" concept. There also doesn't seem to be support for [Docker build SSH secrets](https://docs.docker.com/reference/cli/docker/buildx/build/#ssh). The only way to achieve this seems to be to have a pre-script that downloads a file and leaves it on disk, and then pray that it gets cleaned up afterwards, which is far from ideal 😕

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#7429