Closed artisticcheese closed 7 years ago
Yes, you could do that - I take that same approach (using environment variables, but the same idea) in the bootstrap script in chapter 3. The other advantage is that the bootstrap script runs as admin so it has access to the secrets files, and you don't need to run the website in an elevated account (which is a limitation as of 17.06).
But I think there's a point where you need to decide if the benefits of the platform are worth investing in code changes, and secrets is one feature which I think is worth it.
If you use secure secret management outside of the container, but then persist the secret in plaintext inside the container, you're relying on the security of your app to keep it protected. If you use secrets as intended, then you can rely on the security of the platform.
Do you know if manually copying file into C:\ProgramData\docker\secrets\app-db.connectionstring
inside DockerFile via Add
command will be overwritten by file with the name when container will be run swarm mode? I think this will allow entire configuration be testable/debuggable in dev environment without need to resort for volume mapping and complex docker run
commands. I will try to test it later but I thought you might know already if you tried it.
I think this might be the easiest way to introduce developers to containers without complexity of explaining of volume mapping etc. This way container can be run with straight up docker run
without nothing else both in DEV and PRODUCTION with no code changes required. Just in production secrets
location will be overwritten by swarm.
I haven't tried but I can't say I like that idea. With secrets you can build your app to be secure by default. If you provide an insecure mode, it should be explicit so you don't accidentally run it insecurely. To do that you just need Docker Compose files with different settings for dev and prod - it's simple but explicit (I describe that in my blog post on Windows Docker secrets).
I tried it. It does not work. Problem is that when you run this in swarm mode and docker tries to mount swarm secret in that location it fails since there is already a file there, so I went back to your method of environment variables and bootstrap file instead. Still not doing any sort of modifications to any other parts of the system though, just do all the transforms neccessary inside bootstrap.
Do you think it will be good/viable solution instead of modifying code to accomodate for docker secrets instead have all secret management as part of
Entrypoint
dockerfile reference. That is to have logic in Entrypoint to import/modify secrets at container start and update relevant web.config, configuration references. ThisRunAs
or any other security aspects of running application sinceEntryPoint
is executed as ContainerAdmin