When you think of cyber security, one of the first things that should come to mind is protecting important data. There are many approaches and best practices depending on where your data resides and how you want to protect it. This is true for containers as well. Containers will sometimes need access to sensitive information such as database passwords, api tokens, ssh keys, tls certificates; so a key consideration should be how you give containers access to this sensitive data.
There are lots of options available including baking them into the image, passing them in as environment variables, putting them on a mounted volume, etc. All of these options may work, but they each have their flaws with regards to maintaining the security of the sensitive data.
The best practice that we recommend at Twistlock is to store your sensitive data in a secrets store and then inject the encrypted secrets into the containers that need access to that data (and only those). One advantage to this approach compared to baking them into the image is that the sensitive data is not readily available to anyone who has access to the image. Also since the secrets are encrypted during injection, it prevents users from accessing those secrets by using docker inspect or docker ps.
There are number of secrets stores available to store your sensitive data, but two of the most common are HashiCorp Vault and CyberArk. With Twistlock’s new secrets manager, we integrate with both of these solutions. The setup process involves configuring Twistlock with the necessary information to connect to your store and then creating rules to give the appropriate containers access to the secrets they require. I’ll walk through the steps here.
The first step is to choose Access from the settings menu:
Then, go to the Secrets tab at the top:
Now, specify the connection information:
The last step is to create your rules for injecting the secrets. Go to the Defend -> Access page on the navigation menu on the left and click the Secrets tab at the top. Click Add new secrets rule.
In the dialog box that opens, you will have a couple of options. The first being injection type. You may choose to inject the secrets as either environment variables of as a file. If you choose to inject the secrets as a file, the file will be created in the container’s in-memory filesystem under the path /run/secrets. Be aware that whatever name you choose for the secret in the Add Secret section will be used for the environment variable or file, so avoid using spaces and other special characters. Also, as a best practice, it is advised against injecting secrets into all containers. Use the filters at the bottom of the dialog to specify which containers will receive the secrets for the rule that you are creating.
Once the rules have been created, you can verify that they are being injected upon creation:
Injected as an environment variable (dbpass was the value I gave the secret):
Injected as a file:
In summary, there are many new aspects of cyber security to consider when working with containers and this article highlights just one of them. It’s always important to consider all of the ramifications of the decision making process that goes along with securing your environment. Since sensitive data such as database passwords and certificates are keys to the rest of your sensitive data, it should be of utmost importance when you decide how to protect them.
Stay tuned to our blog and Twitter account to get the hands on updates on Twistlock functionality and best practices like this.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Cryptomining Malware Emerges
I have been watching for the spread of malware that, primarily, uses c...
Calling the Twistlock API from PowerShell
The Problem This morning, a colleague was looking for situations where...
What Makes Distributed Security ‘Cloud Native’: Podcast Overview
I caught up with Scott Fulton III on this edition of The New Stack Mak...
Reflections on the 20th Anniversary of Open Source Technology
Exactly twenty years ago in February 1998, the term “open source” ...
Enhanced Syslog Data Streams: 2.3 Deep Dive
In each of our Twistlock releases, we publish some truly remarkable fe...