Running on a Windows Server 2019 I have Docker. I have created an image using a very simple dotnet core app that simply prints env variable vales to the console. The idea is to prove that the summon-conjur provider has successfully retrieved the secrets from Conjur and that summon has successfully injected them into a docker container.
If I run the code outside of Docker using summon, everything works as expected:
I am running out of ideas - is there anyway to see the contents of the @SUMMONENVFILE variable passed into Docker?
This is WINDOWS so I am struggling to find any non Linux/Mac examples
If somebody has this working or can point me in the correct direction it would be most appreciated
@SUMMONENVFILE is a flag recognized by Summon to where, if present in the command string, it will create a temp file in memory (using Go’s ability to handle memory pointers) to which the path is then given to the command in place of @SUMMONENVFILE. Since this is just a memory pointer, it cannot be displayed.
From the source code comments for the function:
// scans arguments for the magic string; if found,
// creates a tempfile to which all the environment mappings are dumped
// and replaces the magic string with its path.
// Returns the path if so, returns an empty string otherwise.
My recommendation would be to change to using docker run -e KEY=value to set the environment variables on the container.
In the newest version of Docker, it will mask non-standard environment variables from being able to be displayed in docker inspect <container_name> after it has been launched.
Please let us know here if this works for you or not and we can help you with other methods, if needed.
Many thanks for the response Joe - I didn’t realise that I could inspect the environment variables of the container using ‘docker inspect’. Before you replied I managed to achieve the same result using:
which showed me that summon was indeed setting the environment variables correctly. Running my code interactively within the container also failed to retrieve the variables, which lead me to my dockerfile. Here I found the issue, I was testing with summon outside of the container using a Debug build of my code but building my docker image with the Release version that was out of date. Rebuilding the image with the Debug version of the code has resolved the issue and I can now resolve the environment variables within the container.
So a very big thanks for your help. I have an additional question regarding best practise. If I deploy a container, say through Jenkins, and then use host factory to generate an identity for the container.
Is it best to pass the username/APIKey for the host only via summon and then get the code running within the container to use API calls to authenticate using those summon provided secrets and retrieve the required secrets that it needs - OR - pass everything that the code needs via summon in one go?
This makes an assumption that the code is being developed or can be easily amended of course!
Our recommendation in this scenario would be to provide the Host Identity to the container so that secrets needed can be retrieved just-in-time to allow rotation to occur without breaking the container’s application. If you provide all secrets using Summon to the container, this is only an “init” action and the container would need to be restarted using Summon to refresh the secrets after they are changed/rotated.
