Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

User Secrets Not Compatible with Visual Studio Docker Support #659

Closed
chrisoverzero opened this issue May 4, 2017 · 9 comments
Closed
Labels

Comments

@chrisoverzero
Copy link

chrisoverzero commented May 4, 2017

Summary: User secrets cannot (easily, portably) be used with Visual Studio's "Docker Support" feature for ASP.NET Core projects.

Hi! I've been using User Secrets for a while in several ASP.NET Core projects. My company is evaluating a move to Docker for deployments, and – as part of that evaluation – I activated the Docker Support feature in Visual Studio. After this, the application completely failed to reference my secrets.

I've worked around this for my own support by bind-mounting (in docker-compose.override.yml) the secrets.json file on my development box to the correct location in the Linux container, but this seems to violate Microsoft's advice:

You should not write code that depends on the location or format of the data saved
with the Secret Manager tool, as these implementation details might change.

...in addition to not being portable between our Windows and Linux developers.

Versions of things

  • Microsoft.Extensions.Configuration.UserSecrets: 1.1.1
  • Microsoft.Extensions.SecretManager.Tools: 1.0.0
  • Visual Studio: 15.1 (26403.7)
@shirhatti
Copy link

ping @natemcmaster

@natemcmaster
Copy link
Contributor

The advice was written with authors of third-party class libraries and tools in mind. The location of the files is not "under contract" so your docker-compose file might break in future versions. However, until that happens, volume mounting the user secrets location for development environments is fine, and seems like something Docker Tooling could consider doing by default. cc @dazhao-msft

That said, mounting UserSecrets for production is not recommended. For production secrets, checkout https://github.com/aspnet/Configuration/tree/dev/src/Microsoft.Extensions.Configuration.DockerSecrets

@chrisoverzero
Copy link
Author

[...] mounting UserSecrets for production is not recommended.

Right on, no worries there.

[...] volume mounting the user secrets location for development environments is fine [...]

To say things that I'm sure you know, only to get them on the written record:

This solution moves a little backwards from (what I perceive to be) the design of User Secrets, as this means we have a file in source control (docker-compose.override.yml) that some of our developers will have to "forget" to commit their change to. Though, thanks to User Secrets, that change is only a Windows vs. Linux path. Additionally, this requires us to copy and paste the magic value of the user secrets ID – which is otherwise system-managed – into this file, twice.

That said, operating like that will certainly be OK for now. It doesn't not work. 😛 And the feature is valuable enough to get over the inconvenient ergonomics.

Thanks for the assist, @natemcmaster. Would it be better for me to close this now, as the workaround still works, or wait for @dazhao-msft to chime in?

@dazhao-msft
Copy link

I know ASP.NET team is working on something to resolve this issue for runtime. Check this out:

https://github.com/aspnet/Configuration/tree/dev/src/Microsoft.Extensions.Configuration.DockerSecrets

@glennc has more context about it.

@natemcmaster
Copy link
Contributor

@dazhao-msft the DockerSecrets config provider is about loading configuration from "docker secrets" - a Docker feature for swarm mode. UserSecrets is a separate feature, not related to Docker.

The request here is to flow the UserSecrets data into containers when running in development mode (e.g. launching container debugging in VS). Docker Tools for VS already volume mount some folders -- such as the NuGet cache -- to preserve the context of the host machine inside the container. Adding the user secrets folder to that list seems reasonable to me.

@HaoK
Copy link
Member

HaoK commented Jun 6, 2017

@natemcmaster does this issue belong in a tooling repo/issue, can you route this appropriately/close if there isn't anything for us to do in Configuration

@natemcmaster
Copy link
Contributor

This issue belongs to the tooling team. There are no actionable items from the runtime.

@mlorbetske or @dazhao-msft - where should we move issues for Web / Docker Tooling in VS? TFS, https://developercommunity.visualstudio.com/, or some other GitHub repo?

@sgreenmsft
Copy link

@natemcmaster - Thanks for bringing this to our attention. David has moved on from the Docker Tools team, but @yanchenw and I are good contacts going forward. I'd suggest that GitHub issues for Docker Tools be moved here: https://github.com/microsoft/dockertools/issues

@natemcmaster
Copy link
Contributor

Thanks @sgreenmsft. Let's move this to microsoft/DockerTools#24

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants