It’s been long since we are asking programmers “not to push connection strings and API Keys” to the source code. And also, set them as environment variables for production. But you still here and there you can find sensitive information on both repository and config files on production server! GitHub Codespaces gives you the solution for this enterprise problem.
Environment Variables
So you put information related to external integrations in environmental variables. Traditialy in dotnet world you put information like connection strings and API keys in a web.config or appsettings.json. Similarly in a JavaScript project you can make a .env file. For a long time, people use to check in these files to the code base, and at release time, they made sure not to include these files on the release files. Otherwise this would override the production configuration files.
Traditional approach introduced two complexities : first people did not have the same settings on their local setups, so updated config files caused a headache each time they fetched the code base. Secondly, sometimes they missed to exclude config files on the release bundle and it replaced the production settings.
A troublemaker called hacker!
Well, it also turned out that hackers are really interested in our test environments too. They can get a lot of useful information that can help them to hack our production environment. So, we as an industry, we decided not to check in our secretes, and even not put them on the dev and test environment.
furthermore, for production environments, we decided to put these information somewhere safer than a file. therefore, lots of alternative emerged for every different approaches; like keeping those secrets safe in a ‘azure key vault’. But at the end of the day, most of practical approaches end up serving our configuration secrets as environmental variables.
How to share development secrets with your team?
So , If you are not supposed to push your connection strings, api keys, and other secrets to your repository, how can you share it with your teammates? Well, it seems that either you need to become creative or each teammate gets a personal credentials. I like neither of those ideas really, both are making problems in long-term. There is a third way and that is using github codespaces !
What is GitHub Codespaces
GitHub Codespaces is linux based container instance, running on the cloud that includes a web based visual studio code and runtimes that you need to run your code (like Node.Js , Detnet, Python, and…), so you you can use the terminal of your ‘web based visual studio code’ to run command like npm run
, dotnet build
, or … It also gives you a url that you can use instead of localhost when you want to run and test your webapp. So, Instead of cloning your code locally, you make an instance of codespaces directly on github and get your workspace ready. Image below shows you how to start code space on GitHub :
Then you launch a new code space from your repository, you need to wait a few seconds, then you are going to literally see a fully fledged ‘visual studio code’ on your web browser. Looks like this:
You see! It is like a real ‘visual studio code’ with the terminal and everything. Even extension part is there and working. As a matter of of fact, you don’t need to run web-based, you can connect it to your local visual studio code! In that case, you don’t need to clone the code anymore and your terminal will be connected to codespaces instance, but you are using visual studio code locally.
Unfortunately, Codespaces is not available for free github and is available for organizations using GitHub Team or GitHub Enterprise Cloud. But the fact how cool it is aside, sharing dev secrets with a team is kind of an enterprise problem. If you are in a small team, you probably don’t care about these stuff as much.
How to share environmental variables as codespaces secrets
Well if you are going for codespaces you can just put your secrets in Settings>Secrets>Codespaces
Then you can use it as if you had it in your configuration files. in case of Node.js for example:
process.env.MY_CONNECTION_STRING
We discussed about a Environment Variables as Codespaces Secret earlear. This is also not flawless, anyone with access to the repository and codespaces can actually retrieve the environmental variable in the console using echo $Envronmental_variable
echo $MY_CONNECTION_STRING
# returns : MySecretConnectionString
Leave a Reply