Avoiding exposing env variables | Dagger | Page 1

indigo elm Nov 17, 2022, 6:49 PM

#

Hi, what do you mean by "exposed" in this context?

robust abyss Nov 17, 2022, 6:50 PM

#

hey solomon thank you for taking the time. by exposed i mean visible within the code. if you do docker-only build for example (without dagger) you can do that with docker run -e /env-var-here/ and there is no trace of it in any of your scripts whatsoever (as it is entered in CLI only)

#

in my current setup it works but it is entered and visible in the main.go script for example

indigo elm Nov 17, 2022, 7:19 PM

#

If you want to avoid hardcoding the value of the env variable in your code, you could use os.Getenv, for example:

client.Container().WithEnvironmentVariable("VAR", os.Getenv("VAR")

#

This will pass the value of $VAR from your client machine to the container, without leaking the contents into the code

robust abyss Nov 17, 2022, 8:04 PM

#

okay but won't i still have to hardcode it in the main.go file but at different position this way? using this part (see image) of the documentation as reference

indigo elm Nov 17, 2022, 8:05 PM

#

You can remove the two first lines of main. The value of your env variables will be inherited from the system

#

So you can set them in the shell the run your tool

#

so you can use GetEnv without SetEnv

#

you could also read the value from command-line arguments, or from a file… Basically any method of receiving input available in Go, you can use 🙂

#Avoiding exposing env variables