Author: Michael Neale

One of the benefits of a shiny new Kubernetes setup is that you have more freedom to ship rapid changes to applications. Weekly deploys become daily, daily service updates become hourly, and it’s eventually running continuously. The gap in time between someone merging a change and it starting to roll out moves closer and closer to real-time delivery. To achieve rapid continuous delivery (CD), teams have invested a lot of time and money into automated unit and regression tests.

So, where does security fit in? What about the security aspects of each application? Traditionally, application level security would involve code audits, reviews, perhaps runtime penetration testing, approvals, code scanning and so on. The idea is to find problems in code long before they become an even larger problem. With the accelerated velocity of application deployment, these tools need to be woven into the pipeline that takes the code to production, capturing problems specific to your app as early as possible. This is what is meant by “shifting left” in security practices. The “left” and “right” implied here is the pipeline of software from ideas/source code (left) to production (right).

Continuous security aspects can be broken into two areas:

1. Static security of your application composition (sometimes known as SAST); and
2. Dynamic security of our running application (sometimes known as DAST).

The first is where things like source code scanners, and software component analysis kick in. A common practice here is to look at how your application brings in libraries, especially open source libraries, as some of those may have vulnerabilities and need to be updated or patched.

The second security type, dynamic security, involves possibly probing the running application for problems, monitoring for faults, or even deliberately trying to break it.

While shifting left means ideally catching problems before applications are deployed, some dynamic security requires applications to be running. While this may seem like a problem, there are some handy security (and open source) tools that can help before a change is merged or promoted.

First, the Open Web Application Security Project publishes a helpful tool called ZAP. ZAP stands for Zed Attack Proxy. This is a project that can be used to simulate attacks on web apps, probe for weaknesses and allow new or updated features to be added. It’s published in many forms and there is one command in particular I’d like to mention called “zap-baseline.” This can be used to scan a web app for a base set of problems, and report on serious problems or warnings. This is available as a Docker image that is published and updated very often. This tool is complementary for dynamic security testing.

For image and component (static) type security, Anchore published the Anchore Engine. The Anchore Engine (which is also helpfully published as Docker images) works at the container level, looking for vulnerabilities that have made their way into your containers. This is very useful in a Kubernetes world, as containers are the unit of deployment. One of the key features of Anchore is that it looks from the lowest level in the image to the highest for problems, versus just looking at libraries that the application depends on. Typically, applications built on images depend on other images that have many layers, which in turn depend on other images, and so on.

This tool can apply to images before they make it to production, but can also be used on applications that are already running, in case there are new problems discovered that weren’t known at the time that version of the application was promoted. Additionally, (and most importantly) Anchore has the all-important nautical theme that seems to surround tools in the Kubernetes and Docker ecosystems!

What’s Next for Continuous Security?

There is clearly so much that can be done using Kubernetes through the wealth of commercial and open source tools. The Cloud Native Computing Foundation is considering a proposal for runtime security called “Falco.” Runtime security is another security measure that is closer to monitoring: Watching for abnormal behavior (which also means learning what normal app behavior is). This will be a great project to watch, as it looks like it can add another layer of continuous security which has traditionally been considered quite exotic (but will hopefully be easy to apply with Kubernetes) for the benefit of all.