Adding support for organization-level environment variables

Wercker is a Docker-Native CI/CD Automation platform for Kubernetes & Microservice Deployments

Antti Kupila
Antti Kupila
October 24, 2016

You can now have environment variables on organizations, applications and pipelines.

Saving passwords in your repository is not a good idea as anybody who has access to the repo could see them. With environment variables you can have settings and passwords available during the build, for instance setting a database credential or adding an SSH key to fetch dependencies from a private Github repo.

You’ve always been able to add environment variables to applications and pipelines where variables set on the application are available to every pipeline. Now you can also create organization-level environment variables which will be set for every application for that organization. This addition can be useful if you, for instance, want to share a database password to every application in the organization. Keep in mind, though: the environment variables are set for every project — public and private — so you’re probably better off setting highly sensitive data on a more targeted level. At least set the variables protected so they cannot be read back and are only available during the build.

To manage environment variables for your organization head over to settings of your organization.

org-envvars.jpg

Let’s look at an example

Imagine the following scenario:

  • Your company has multiple internal libraries, each hosted on Github in private repositories
  • You’re working on a new Golang service that installs the shared libraries during build
  • You have a production build and a development build with additional debug logging
  • You want to be notified on Slack on any build
  • You want to push your image to Quay and then deploy to Kubernetes without exposing your secrets

As you can see, there is a lot to keep track of and multi-level environment variables are an excellent way to solve this.

Here you could add the Gihub SSH key to the organization since several projects will need it. Every build should notify Slack so put the Slack token as an environment variable on the application. Your production build pipeline ensures debugging is disabled. You push images from several pipelines so set the Quay credentials on the application but the Kubernetes credentials only on the deploy-kubernetes pipeline.

Merging lists of environment variables

Merging the different lists of environment variables in deterministic order is crucial to get the correct values in the run. On Wercker if you define multiple environment variables with the same name the lower level ones will override the higher level ones. This allows you to easily share values when needed but still allows you to override them too as necessary.

envvars-override.png

SSH key management

SSH keys allow the Wercker build to access other servers, for instance, a production server for deployment or a private Github repository for dependencies. Wercker needs to have the private key while you add the public key at the destination.

There was some confusion before about SSH keys, so we’ve simplified this a bit. SSH keys were always environment variables under the hood but separated under a different section of the site. It turns out this was a bit unclear as you still needed to add the ssh key using the add ssh key step. Now SSH keys are first-class entities in the environment variables so you can manage them as any other value.

Wercker can generate a new SSH key-pair for you and then you just need to copy the public key to the destination. The private key is protected which means that nobody can read it through API endpoints or the web interface as it is only available during the build. All of this makes it super easy for the build to have access to external servers without compromising security.

gen-sshkey.png

Of course you’re free to generate your own SSH keys too and add (at least) the private key as an environment variable in Wercker. Just make sure the key ends with _PRIVATE as this is required for the add-ssh-key step to find it.

Secrets without security aren’t really secrets

We understand that you need to store potentially very sensitive data in the environment variables. Behind the scenes, all environment variables (protected and non-protected) are stored in the database using 256bit AES-GCM encryption with a 32 byte key. Protected environment variables and ssh keys are never displayed in the interface and are only available during the run.

We’re happy to answer any further questions you might have about security.

Earn some stickers!

As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using wercker, be sure to tweet out your #greenbuilds and we’ll send you some swag!

Topics: Product, Containers