Understanding Container Security – Part Two: Security Recommendations
In part one of this series, we discussed the rise in container security threats. As containers have gained in popularity, they’ve also provided an expanding attack surface. We explored why so many teams lack a strong container security posture; now, we’re sharing advice for securing containerized applications and data.
From Fundamentals to Fault Tolerance
Container security may be uncharted territory to many engineers, but they can start by locking down some basic practices. That includes good authentication and authorization control, behavioral analysis, auditing and updating dependencies and ensuring visibility over their environment. They can take another step forward by using automated tools that scan containers, as well as open source or paid tools like kube-hunter, kubeaudit or Clair, which are specifically built to reduce exploitable flaws in the Kubernetes ecosystem.
Dan Moore, Solutions Architect at FusionAuth, pointed out the benefits of honoring security fundamentals. “Ship as little software as possible for the required functionality,” he said. “Don’t run as a privileged user. Lock down the network to which the container code has access. Don’t allow unescaped user input.”
At the same time, he pointed out, containers do offer unique security opportunities. “You can use a service mesh to enforce mutual TLS and/or token authentication and authorization, often with configuration rather than code,” he explained. “Locking down access to containers by other containers within the larger application can decrease the blast radius.”
Robert Brennan, vice president of product development at Fairwinds, pointed out that the chief mantra of cloud-native container orchestration—fault tolerance—applies to security as much as it does to reliability. Beyond configuring a fault-tolerant environment, practices like static analysis and penetration testing can root out application-level bugs.
“Successful cloud-native security strategies focus on limiting the blast radius of any hypothetical attack,” he said. “There’s no foolproof way to prevent developers from shipping code with a subtle security flaw, but you can utilize concepts like secure containerization, network policy and role-based access control to ensure that when an attacker exploits some vulnerable code, they can’t do much more than inspect the local filesystem, let alone escalate their attack to other applications running in the same infrastructure.”
Safety and Speed
Many teams treat security as an afterthought in the effort to accelerate the development life cycle, worried it will slow down application development. Brennan differentiated between short-term speed and long-term speed to explain why that’s a fallacy.
“It’s easy to see where this misconception comes from. If we spend a day tightening down security, then the feature ships a day later,” he said. “The real tradeoff here is not between speed and security, but between short-term speed and long-term speed. Yes, you can get a short-term boost in speed by neglecting to write tests or do a security review, but it’s important to recognize that you’re accumulating debt. And many organizations run with a structural deficit until a massive incident forces them to address their tech debt.”
Mark Nunnikhoven, distinguished cloud strategist at Lacework, advises teams to build flexibility into security standards, such as only scanning when necessary. “If a container image hasn’t changed since the last scan, there’s no need to scan it again. If only part of an app has changed, focus on those changes. These optimizations sound obvious, but some security tooling still struggles with it.”
Injecting Nuance into Shift Left Security
When it comes to the shift left approach, Brennan advises that incorporating some security controls early on offers easy wins. “If the tooling is built-in from the start, you can slowly turn the knob towards tighter security as your organization grows.”
But an effective shift left approach isn’t just about moving existing security controls to an earlier point in the development cycle—it’s about building security strategy into configuration from the beginning. By analyzing how configuration might influence performance and security, developers can enjoy more autonomy in the way their application is deployed. But in a world that rewards developers for moving fast, it’s critical to also reward them for spending time on that analysis—and give regular feedback on their effectiveness.
“It’s always a good idea to bring security earlier into the app development life cycle,” says Moore. “But you also need to spend time educating developers about the benefits of security. Adding security as a KPI to be tracked the same as other feature-focused KPIs can help shift security thinking to earlier in the software development life cycle.”
Nunnikhoven cautions that this shift “should take on a form that makes sense for development. This is where security testing—like container image scanning—and other rapid checks in the CI/CD pipeline work well. Ensuring that secrets and sensitive data are processed and stored with sufficient controls all benefit from consideration much earlier in the development life cycle.”
Building a Security-Conscious Culture in Containerization
Building secure and resilient containers ultimately requires a culture of security awareness—something that can be easier said than done. Building security into day-to-day containerization practices may begin as something new and unwieldy for development teams eager to move quickly. But by taking the time to align configuration with security, engineers can reduce vulnerabilities and build secure container environments that are better defended against future attacks.