Launch a dev container using current process' environment

[jamesthurley]

We have many devcontainers for many different projects, and these projects use environment variables to access secrets.

Our current strategy to manage this is having all the secrets for all the projects set in Windows, with the variables listed in WSLENV, and then we use remoteEnv in the devcontainer.json files to make the appropriate subset of variables available inside each devcontainer.

To tidy this up, I wanted to store the secrets in 1Password, store references to them in a .env file in each repository, and then use the 1Password CLI to launch the devcontainer using the appropriate .env file.

The way this works is that the .env file for each repo contains entries like:

BATCH_ACCOUNT_KEY="op://dev/azure-batch/account-key"

And you launch VSCode with the 1Password CLI like so:

op run --env-file .env -- code .

The 1Password CLI parses the .env file, resolves the references, and launches VSCode with those resolved variables set in the process' environment.

The above works perfectly when running VSCode in Windows and in Remote: WSL, but I can't seem to get the environment variables to pass through into a devcontainer.

To launch the devcontainer I am doing the following:

mypath="$(wslpath -w $PWD)" && p=$(printf "%s" "$mypath" | hexdump -v -e '/1 "%02x"') && op run --env-file .env -- code --folder-uri "vscode-remote://dev-container+${p}/workspaces/$(basename $PWD)"

This uses one of the solutions from here to launch VSCode directly into a devcontainer, with op run inserted at the appropriate point to launch VSCode. However, currently the dev container doesn't seem to get its environment from the process that launched it.

The simple test of this is just to export FOO=BAR in a shell and then try and launch a VSCode devcontainer from the same shell and have that local FOO envionment variable available in the devcontainer.

Would it be possible to support this scenario?

[DavidS-ovm]

Hey, I'm running into the same issue on Windows and WSL2, while others on the team on Linux and OS-X have exactly the same use-case working just fine (op run --env-file=... code into devcontainer).

@jamesthurley did you find any workaround?

[tphoney]

The work around we came up with was to use WSLENV https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/ its been working well so far.

[jamesthurley]

@DavidS-ovm I detailed my workaround at the end of this other issue I created:

https://github.com/microsoft/vscode-remote-release/issues/9446

Basically I put the following in my devcontainer.json:

  // Use the 1Password CLI to generate a .env.tmp file with secrets.
  "initializeCommand": "op inject --force --in-file .env --out-file .env.tmp",
 
  // Load the env file generated by the 1Password CLI.
  "runArgs": [
    "--env-file",
    ".env.tmp"
  ],

  // Clean up env file generated by the 1Password CLI.
  "postStartCommand": "rm .env.tmp",

The issue above is a request to support unix pipes in the dev container's runArgs, which would eliminate the need for a temp file. Please upvote the issue if you feel it would help you as well.

[vs-code-engineering[bot]]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vs-code-engineering[bot]]

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[PieterjanDeClippel]

What prevents you from selectively passing env variables like this?

{
	...
	"runArgs": [
		"--env", "aaa=${localEnv:aaa}",
		"--env", "bbb=${localEnv:bbb}",
		"--env", "ccc=${localEnv:ccc}"
	],
	"containerEnv": {
		"IS_DEVCONTAINER": "true"
	},
	...
}

[DavidS-ovm]

What prevents you from selectively passing env variables like this?

1. We're doing that already through remoteEnv and it is a pain to maintain (it's a duplication of the 1password env file, and my devcontainer currently has 140 vars)
2. your suggestion does not read the values from 1password