Ever since virtualization support went mainstream, developers have started to embrace containerization as a means of enhancing app security. And when used well, it’s an excellent approach. Unfortunately, countless things can destroy the security benefits of containerization when overlooked.
But, short of taking some additional coursework on the subject, there aren’t many places you can go to learn about the best practices of containerization. And since Docker is the most popular containerization option in the world right now, that seems like a natural place to start. Here are five simple containerization security tips to help you keep your Dockerized apps secure.
Select Base Images Wisely
The main security benefit of containerization is that it helps to isolate your app from anything else running on the same hardware or bare-metal OS. But that doesn’t mean you don’t have to worry about the internal security of the container itself. For that reason, the first thing you’ll always have to do when developing a Dockerized application is to choose your base image with care.
The easiest way to do that is to rely on images that come from verified publishers. Doing so helps to prevent the inadvertent use of altered or otherwise tainted base images. And when you choose the image you’re going to work with, it’s best to go with the most recent version available, and to carefully scrutinize any vulnerability list that pertains to it.
Choose Minimal Bases Whenever Possible
Another thing to consider when choosing a base image is to try and go with the most stripped-down base that will support your needs. Internal container security is all about attack vectors, so minimal bases with only the libraries you require are best. That will give you less to defend and less to update during your app’s lifecycle.
And, if your app will allow for it, you may wish to build your own distroless image to base your container on. It’s another way you can do away with extraneous files and other bloat in your application. And while some developers will argue that distroless images aren’t always inherently more secure, they certainly won’t hurt — and will at least give an attacker fewer potential avenues of attack.
Don’t Include Sensitive Data
Although it should be obvious, one of the best ways to enhance the security of a containerized app is to avoid storing sensitive data within it. Of course, if you’re building something like a transaction processing application, there are limits to that. But what you can do is make certain that you don’t store anything like passwords, tokens, or private keys inside your container.
The reason for that is simple — it’s that anyone with access to your image will have access to that sensitive data. And that means if you leave that kind of information inside, you’re building a major security flaw into your app. And if you do that in something like the aforementioned transaction processing application, your app will be easy prey for an attacker and you’ll be shelling out for identity theft mitigation services in no time.
Use Multistage Builds to Streamline Your Apps
If you’re building an especially complex application, you may find that you need more than a single image to assemble the tools and services you need. And there are a few ways to accomplish that. You can either incorporate multiple images into your eventual container build. Or, you can opt for a multistage build that grabs only what you need from each to assemble your container. The latter not only leads to a smaller container in most instances but reduces the potential vulnerabilities you’ll inherit from the images you’re using.
Choose COPY Instead of ADD
Last but not least, it’s a good idea to try to stick to using the COPY command wherever rather than the ADD command possible during your build. The reason is that the ADD command can pull from remote sources, and that creates vulnerabilities at build time. Docker itself even advises against using ADD unless you’re using it to perform local tar file auto-extraction into your image.
In situations where you need to pull down remote files, it’s a better idea to use curl or wget instead. Then you can perform whatever preprocessing you need and dispose of the original files. If you were to use ADD instead, you’d be including the entire source file in your image — along with anything embedded in it.
The Bottom Line
At the end of the day, it’s impossible to guarantee that a given container will be totally secure. But, as any experienced developer can tell you, it’s not necessary to achieve perfect security. What you need to do is eliminate as many attack vectors as you can, give your app the lowest profile possible, and make efforts to eliminate any pre-existing vulnerabilities you’re aware of. By doing that, you’ll reduce the odds of anyone finding a usable exploit and produce a containerized app that’s as secure as possible.