Title: Containers are the New Black, but What About Security?

---

June 17, 2013. A day like any other in tech-land where Docker’s release was just starting to make ripples. I remember thinking, “Well, containers must be the next big thing.” After all, microservices were taking off, and this seemed like a natural fit.

I had been working on our application for quite some time—back then it was still in a monolithic state. We were looking at ways to break down the monolith into smaller services, but containerization hadn’t really hit us yet. It felt like we could continue doing things the way we were accustomed to until Docker and friends came knocking.

At work, I had a few projects on my plate: one was a simple web application that needed a quick turnaround, another was a complex data processing pipeline. Both seemed perfect candidates for containerization. But as someone who has been down this road before with virtual machines (VMs), there were some concerns swirling around in my head.

First off, security. With VMs, I had always treated them like they were isolated islands. With containers, it was a bit different. They shared the kernel and the same network stack, which meant we needed to be extra careful about what apps ran where. We had been bitten by security holes before, and I wasn’t willing to let that happen again.

I spent a few days researching Docker’s security model. It was still in its early stages, but the documentation hinted at some promising features: namespaces for process isolation, cgroups for resource limits, and SELinux policies (though they were more experimental back then). But it wasn’t enough. I needed to understand how these worked together and whether they could truly protect our applications.

I set up a small test environment on my local machine. I tried running some basic services like a web server and a database in containers. The setup was relatively straightforward, but as soon as I tried to harden the security, things got complicated. SELinux policies didn’t play nicely with Docker’s containerization, and we had to tweak firewall rules manually every time we deployed new containers.

One evening, I found myself arguing this point with a colleague. He was advocating for using Docker for all our services because of its ease of deployment and the promise of faster development cycles. “Sure, it’s easy,” he said, “but have you thought about security?” His words echoed in my head as I stared at my monitor.

The next morning, I decided to push back harder. We spent an entire day discussing different approaches—using namespaces for isolation, implementing container-specific SELinux policies, and even looking into other container technologies like LXC or OpenVZ that might offer better security out of the box. By the end of it, we agreed on a plan: let’s use Docker as a proof-of-concept, but don’t rush to adopt it in production without thorough testing.

Fast forward a few months, and we did deploy our first containerized application using Docker. It was a small project, just a web service serving some basic API endpoints. We followed best practices—used namespaces for process isolation, limited resources with cgroups, and carefully managed network access. To my relief, the security issues we had feared didn’t materialize.

But as time went on, I couldn’t shake off the feeling that there was more to containers than just ease of deployment. The tools were still evolving, and best practices hadn’t yet solidified. We needed a way to ensure that when someone deployed a container, they weren’t inadvertently exposing themselves to security risks.

That’s where the real work started. I began writing scripts to automate some of these security checks—checking for SELinux policies, verifying cgroup configurations, and ensuring proper network settings. It wasn’t glamorous, but it was necessary if we were going to trust containers with our data processing pipeline.

In retrospect, Docker’s release in 2013 marked the beginning of a new era in software development. Containers offered incredible flexibility and ease of deployment, but they also came with their own set of challenges. Security had always been at the forefront of my mind, and I knew we couldn’t ignore it as we moved forward.

The tech world was changing fast back then—just look at some of those headlines from Hacker News. But in our day-to-day work, we still had to worry about the basics: making sure our applications were secure, reliable, and scalable. Docker taught us a lot, but it also showed us that no technology is perfect without careful consideration and rigorous testing.

So here’s to containers—let’s hope they bring as many benefits as challenges in the years ahead.