docker run samples should use --env-file for secrets

We should help our consumers to be secure by default. That means we should not pass secrets via regular environment variables but use --env-file

If we do this, we should also guide them on minimal required config and how to create a file.

Good suggestion by @mabsimms

Examples

Example with Azure Monitor secret in a file

docker run -d -p 8999:80 --name promitor-agent-scraper /
                         --env PROMITOR_AUTH_APPID='<azure-ad-app-id>'   \
                         --env-file C:/Promitor/az-mon-auth.creds /
                         --volume C:/Promitor/metric-config.yaml:/config/metrics-declaration.yaml /
                         tomkerkhove/promitor-agent-scraper:1.0.0-preview-3

Example with all Azure Monitor config in a file

docker run -d -p 8999:80 --name promitor-agent-scraper /
                         --env-file C:/Promitor/az-mon-auth.creds /
                         --volume C:/Promitor/metric-config.yaml:/config/metrics-declaration.yaml /
                         tomkerkhove/promitor-agent-scraper:1.0.0-preview-3

[mabsimms]

If I can retrieve credentials from CLI or the file, I’m inherently authorized to do so (aka, I’m already on the other side of the airtight hatchway). The information exposure risk is more about certain conditions where the process start arguments are available to non-elevated contexts.

For example:

# Run this elevated from user context "A"
sudo docker run -p 8000:8000 --env SECRET=mysecret --name whoami -t jwilder/whoami

# Now as user "B" do a little process check
ps -ax | grep SECRET
209281 pts/1    S+     0:00 sudo docker run -p 8000:8000 --env SECRET=mysecret --name whoami -t jwilder/whoami

[reminders[bot]]

👋 @tomkerkhove, verify the status of this issue