Decrypt declared sops files before rendering template

[hurui200320]

Hi, I noticed that currently, sops files are only applied to secrets. To provide encrypted env vars, we can use sops encrypted .env file, but that only applies to environment section, and doesn't behave like docker compose, where you can use the value from an .env file in the whole compose file.

I noticed in the code that there is a stage to render the template before using it as a stack file. But the values file cannot be encrypted. So I made a few changes to first decrypt the declared sops files, which will include the values file for rendering the template. Then we render the template using the decrypted values file, and finally discover sops file and decrypt them before deploying the stack.

The modified version has been tested and used in my workflow, and it works as intended:

And if you want to test, the image is hurui200320/swarm-cd:1.7.1-sops

[sanzoghenzo]

To provide encrypted env vars, we can use sops encrypted .env file

The correct way to handle sensitive data in swarm is to pass the env file as secret and make the service read that file (with a custom entrypoint if the service doesn't provide a way to read the file directly).
Decrypting secrets to put them in the stack file is not secure.

Do you have a real world scenario in which you need the template values to be encrypted?
I'm not against this pr per se, it's that I fail to see its real value

[hurui200320]

Hi, sorry for the late reply. One use case from our side is to fill in credentials with only one file. Like I said, for docker stack, .env file can be only applied to one service at a time. For different services, the same credential need to be fed into different env vars. Either we have to use multiple env files, or we write multiple times of env_file section. It's not a big deal, but I still want to improve it since it's really not that hard (with changes from this PR). By using the template, we could write credentials in one file, and compose them in the env vars. And with this PR, we could use encrypted value files for the template.

[sanzoghenzo]

Let me reiterate: passing sensitive data as environment variables is a bad practice and should be handled by secrets.

If the services are of your own making, consider using the _FILE way: accept an environment variable with that suffix and read the file at the path contained in the variable.

I'll leave to @m-adawi the decision to include this or not

[sanzoghenzo]

Please edit the README.md to reflect the changes made.

• explicitly state that you can also encrypt values files
• the last line in the secrets detection isn't true anymore, since you could in theory have both sops files specified and the autodiscovery enabled. To this point, what happens if you do that? have you tested it?