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
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog
CVE-2018-1002105: Critical K8s VulnerabilityRead the Blog
Advanced runc Debugging for Fun and ProfitRead the Blog
Introducing Twistlock Support for AWS Lambda LayersRead the Blog
Cloud Native Security Intelligence: Integrating with AWS Security HubRead the Blog