Your code needs secrets in order to do its job--things like passwords, access tokens, and API keys. It's critical that these secrets don't fall into the wrong hands, so managing those secrets is an essential part of your overall security strategy.
At DevSecCon I'm speaking about best practices for secrets management with containers. Here are four key actions that you can take today, regardless of the tooling and orchestration you're using.
Don't build secrets into the container image
If you have a piece of code that needs a secret, and you're running that code inside a container, somehow you have to get the secret to that container. You could build the secret value into the code itself, or into the container image by defining it in the Docker file, but this is a bad idea for a couple of reasons.
First, it means that anyone who can see the source code also has access to the secret value. The more people who can read a secret value, the more likely it is to get compromised--perhaps by a bad actor deliberately abusing or revealing the secret, but more likely simply through human error. It's therefore good practice to restrict access to a secret to the set of people who really need it.
The second reason not to build secrets into the code or the container image is that this would couple the secret life cycle to your deployment process. If you want to change a password or rotate a key, you need to rebuild and re-deploy the code.
Use volume mounts to pass secrets to a container at runtime
If secrets aren't built into the container image, there needs to be a way of passing them to containerized code at runtime. There are two mechanisms for doing this: Environment variables and volume mounts.
The danger of using environment variables is that it's easy for the secrets to be accidentally leaked through logging, as it's common for software to log its entire environment. The set of people who have access to logs is often much bigger than the people who need production key values.
For this reason, many security experts recommend using the volume-mount approach, where your code reads the secret value from a file in a well-known location. Most orchestrators support this method of passing secrets into a container.
Have a plan for rotating secrets
Rotating a secret simply means creating a new value for it, and making the old value inactive--just like changing a password. It's good practice to rotate your secrets on a regular schedule.
The longer a secret exists, the more likely it is that it has been compromised, but you might not know about it when it happens. By rotating secrets, you invalidate any values that a bad actor might have managed to obtain, limiting the damage they can do.
Regular secret rotation can also act like a fire drill, ensuring that your process for updating passwords and keys works correctly.
Make sure your secrets are encrypted
Secrets need to be stored somewhere, and, as each container starts, it needs to be passed any secrets that it requires. Where will you store your secrets? Some orchestrators have built-in secrets-storage support. If you're using this, you should double-check that your setup is configured to use encryption, as it's often not the default.
For Kubernetes this currently requires the --experimental-encryption-provider-config flag to be set on the API server, along with a corresponding encryption configuration file. Docker Swarm uses encryption out-of-the-box, but you should make sure you have locked your swarm.
You may also choose to use a separate component for secrets storage. If you're running on a public cloud service like Amazon AWS, Google GCP, or Microsoft Azure, you can use the built-in key-storage tools. As well as providing an encrypted store for your secrets, these provide ready-made user access control for secrets, tied into identity management that you may already be using on these platforms. Another popular solution for holding secrets is HashiCorp's Vault.
As I write this, there is a limited set of integrations between these third-party storage options and the popular orchestrators. Security tools can provide a way to bridge this gap.
Here's your next step
Protecting secrets is just one aspect of securing your containerized deployment, but it is often overlooked. If you take only one action as a result of reading this article, make sure you're not including any production secrets in your Docker files or source code--especially if your code is open source.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
