March 5, 2024

Last Updated on March 5, 2024

Do containers and Kubernetes fundamentally change application security? Or just put a different spin on it?

In this post, you’ll get a business-class overview of container/Kubernetes security implications.

 

What are containers, Kubernetes, and microservices versus traditional “monolithic” applications?

Containers are the next level of virtualization beyond virtual machines (VMs). Many containers can run within the same VM, each effectively isolated from the others except for a common communication protocol. While a container can run any size application, in modern software architectures each container often contains a small application chunk, aka a microservice.

Kubernetes is an open-source container orchestration platform that largely automates the process of deploying, managing, and scaling containerized applications. By solving many of the problems associated with using containers in production, Kubernetes has come to dominate the realm of microservices deployments.

Thanks in no small part to Kubernetes, containers and microservices are “the new normal” in web application development. The biggest advantages of microservice architectures include:

  • Reduced development time. Working on small, independent units of code reduces interdependencies and roadblocks between developers or teams.
  • Improved scalability and efficiency. With Kubernetes you can spin up/down exactly the microservices you need right now—all within a single VM. That saves considerable compute overhead versus running multiple instances of a monolithic application in separate VMs.

 

How do containers, Kubernetes, and microservices impact web application security?

By paving the way to microservice-based application architectures developed in accelerated timeframes, containers up the ante on DevSecOps. Visibility on what’s running and why it’s running becomes much more complex.

Which, in turn, makes securing the code and its interactions across hundreds of tiny components much more complex and dynamic. Application security must be fully automated to avoid extending development lead times.

But you can only automate what you can manage. This is especially true with DevSecOps—which effectively is a “shared responsibility” model for application security between security and development.

In the last few years, more and more teams have come to include Kubernetes security specialists. The same trends have also empowered developers to put more focus on application security.

In DevSecOps environments, developers often care a great deal about security and are eager to collaborate with security and compliance teams. But they want security tools and techniques that works the way they work, not traditional “end of the pipeline” security.

 

What security challenges get harder with containers?

The distributed aspect of microservice-based applications compounds several traditional security challenges, such as:

  • Securing communication to and from the application. With potentially hundreds of distributed microservices passing data back and forth, often via third-party APIs, any vulnerabilities in the APIs could compromise the entire solution. Similarly, writing and following network security policies for microservice-based or cloud-native applications can be exponentially more difficult.
  • Scanning the code for vulnerabilities. With distributed architectures and an increased reliance on open source/third-party APIs and DLLs, automated security scans can be more challenging and less effective at the same time. For example, one vulnerable chunk of code in a monolithic application could be duplicated dozens of times through sharing code or API calls in a microservices application.
  • Risk prioritization. If dozens of microservices shared across multiple applications call the same faulty API code, how do you prioritize fixing them? How can you measure or compare the risk they present?
  • Software composition analysis and Software Bill of Materials (SBOM) requirements. Customers like the US government are increasingly likely to ask for an SBOM for your distributed microservices application/service. How do you provide that data when the components involved—in-house code, third-party libraries, and all their dependencies—may be amorphous?
  • Authentication and authorization. Authentication and authorization challenges are compounded when multiple microservices that individually require authentication need to work together as one system. A centralized approach to managing access controls, user credentials, etc. is key.

While these and other microservices-centric security challenges are not insurmountable, they require careful attention to best practices from start to finish across the software development lifecycle (SDLC). It is much more difficult to secure a microservices-based application “after the fact” or at the end of the SDLC compared with a traditional application.

 

What’s next?

For more guidance on this topic, listen to Episode 133 of The Virtual CISO Podcast with guest Shauli Rozen, CEO and co-founder at ARMO.