Encrypt Secrets before syncing ressources

[Strehk]

I really like Komodo and the way to declaratively define resources via TOML with the whole git-sync-resource feature. We want to use Komodo for our non-profits docker environments, but one thing is currently holding me up: I feel very uneasy committing everything, including plain secrets, to a remote repository. Especially when I want to manage docker environments together with a team, the risk of me or co-workers accidentally spilling the secrets from the repository is currently too high for us to switch to komodo.

If there is already a solution for this problem, please let me know. Otherwise, here are suggestions on how to tackle this:

I would love a feature that allows all envs in the TOML to be encrypted by default – or that it can be activated per resource. In my imagination, the TOML would contain a flag that the env is encrypted and then the encrypted string which komodo can decrypt easily for each resource.

Another approach could be to manage all envs in a different TOML files and utilizing something like git-crypt to encrypt pre-push. That would also have the benefit of manually retrieving the key and therefore being able to decrypt the envs in local clones and therefore being able to fully edit the repository from a local clone.

A last approach could be to include a scripting/hooks feature to manually insert a git-crypt flow pre-push. But that would be quite tricky on my side I think.

[mbecker20]

Yes, you should not commit secrets within the resource tomls. You can use Komodo's variables / secrets features:

First of all, a variable / secret is a key-value pair, where the key is non-secret.

KEY_1 = "value_1"

With this defined, you can interpolate the value into any Environment (and most other user configurable inputs) using the Komodo interpolation syntax:

environment = """
SOME_SECRET_ENV_VAR = [[KEY_1]] # <- wrap the key in double brackets '[[]]'
"""

So, how do you get these variables / secrets into Komodo?

• In the UI, you can go to Settings page, Variables tab. Here, you can create some Variables to store in the Komodo database.

  • There is a "secret" option you can check, this will prevent the value from exposure in any updates / logs, as well as prevent access to any non-admin Komodo users. It can be viewed / updated via the UI / API by any admin user however, and is not stored in database with any different encryption that non-secret variables (you should use system level encryption for the database data).
  • Variables can also be managed in ResourceSyncs (see https://komo.do/docs/sync-resources#deployments for example) but should only be done for things like that example, non-secret things, to avoid committing sensitive data. But since they are managed, a ResourceSync with "Delete Mode" enabled and without any "Match Tags" will want to delete any non-declared variables, which may cause issue (don't worry if this doesn't quite make sense, it depends on your familiarity with the Resource Sync). But anyways, for this reason, I think it is better to manage the sensitive ones using the config file.

• Mount a config file to Core: https://komo.do/docs/setup/advanced#mount-a-config-file

  • In the Komodo Core config file, you can configure secrets using a block like:

    [secrets]
    KEY_1 = "value_1"
    KEY_2 = "value_2"

  • Ref: https://github.com/mbecker20/komodo/blob/main/config/core.config.toml#L446
  • KEY_1 and KEY_2 will be available for interpolation on all your resources, as if they were Variables set up in the UI.
  • They keys show up on the variable page (so you know they are available for use), but the values are not exposed by API for ANY user
  • These do not interact at all with ResourceSync, avoiding any issue with "Delete" mode on the ResourceSync.

• Mount a config file to Periphery agent:

  • In the Komodo Periphery config file, you can also configure secrets using the same syntax as the Core config file.
  • Ref: https://github.com/mbecker20/komodo/blob/main/config/periphery.config.toml#L162
  • The variable WILL NOT be available globally to all Komodo resources, it will only be available to the resources on the associated Server resource on which that single Periphery agent is running.
  • This effectively distributes your secret locations, can be good or bad depending on your security requirements. It does avoid the need to send the secret over network from Core to Periphery, Periphery based secrets are never exposed to the network.

• Use a dedicated secret management tool such as Hashicorp Vault, alongside Komodo

  • Ultimately Komodo does variable / secret features may not fill enterprise level secret management security requirements, however organizations of this level should have the resources to use a dedicated secret management solution. This is par for the course, Komodo is good at docker control / mass configuration management side but is not intended as an enterprise level secret management solution.
  • These solutions do require application level integrations, your applications should only receive credentials to access the secret management API. Your applications will pull the actual secret values from the secret management tool, they stay out of Komodo entirely.

Hopefully this helps to clarify things, secret management is always tough, let me know if you have any questions about this.

[Strehk]

Thanks a lot for this very thorough and helpful explanation! That is exactly what I needed.

Maybe I am just blind, but can that piece of information be found in the docs? If not, I think it would be helpful to provide just such an overview on how to manage Secrets? (I am happy to contribute if you'd like that – but I am not sure I am understanding everything good enough. I'd just take your answer as a blueprint.)

[mbecker20]

Good point, I've added a page: https://komo.do/docs/variables