Add support for rendering templates

[dividedmind]

Many software packages read secret from configuration files and would have to be modified to source them from the environment instead. This makes it cumbersome to use them with summon; the usual solution is to write a wrapper script which seds the secrets into place before handing off to target command and use summon to call that script instead.

Not only is this inconvenient, but also risks introducing security problems: the script author needs to remember to clean up the files afterwards, give them correct permissions to limit exposure, etc. This would much better be handled by summon itself, at the small cost of not being agnostic about templating engine.

I propose thus to design and implement functionality in summon that would allow using file templates into which the secrets would get substituted. The templates would be rendered into temporary files as with !file entries currently, to be cleaned up after exiting; additionally these temp files could be symlinked into a required place before calling the target process so that the target can find them (on the assumption that it cannot use environment variables for that), or alternatively we could provide a mechanism to substitute the temp file path into the command line.

Note this functionality would replace the obsolete conjur env command of https://github.com/cyberark/conjur-cli.

[awhitford]

According to Secrets: Best Practices, Environment Variables are discouraged because:

• Accessible by any process in the container, thus easily "leaked"
• Preserved in intermediate layers of an image, and visible in docker inspect
• Shared with any container linked to the container

So providing a way to fill a template with secrets (much like consul-template) sounds like a wise addition.

[kgilpin]

However, the use of environment variables described in that document is not the same as what Summon does. That document describes the use of the Dockerfile ENV feature, which builds environment variables into images. Summon builds an environment at runtime and launches the docker command with that environment, or runs as the entrypoint of the container and launches a child process within the container with the modified environment.

Using Summon is not subject to any of those vulnerabilities.

[kgilpin]

Summon is not subject to these issues because the secrets are placed in an environment that is internal to the container. The article is referring to Docker ENV directive.

…

On Tue, Dec 26, 2017 at 7:48 PM Anthony Whitford ***@***.***> wrote: According to Secrets: Best Practices <moby/moby#13490>, *Environment Variables are discouraged* because: - Accessible by any process in the container, thus easily "leaked" - Preserved in intermediate layers of an image, and visible in docker inspect - Shared with any container linked to the container So providing a way to fill a template with secrets (much like consul-template <https://github.com/hashicorp/consul-template>) sounds like a wise addition. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFRe0KKmlXPSyJAfKdzwJMUCDCqaXExks5tEZPWgaJpZM4PaIK0> .

[clofresh]

So the interface might look like this?

summon \
  --envvars false \
  --template MYCONFIG=path/to/template1 \
  --template OTHERCONFIG=path/to/template2 \
  myapp --config @MYCONFIG --otherconfig @OTHERCONFIG

--envvars could optionally turn off environment variable injection if you're already getting the data from a file.

--template could be passed in multiple times to define references to multiple templates

If we had a secrets.yml like:

DbPassword: !var my-secrets/dbpassword.txt

The template file might be a go template:

{
  "db": {
    "user": "web",
    "password": "{{ .DbPassword }}"
  }
}

Does that look about right?