Build, Deploy, Runtime: The 3 Stages of Kubernetes Security

Kubernetes security is an issue for many organizations. In a 2020 report covered by TechRepublic, 94% of respondents revealed that their organizations had weathered a security incident involving their Kubernetes and container environments in the past 12 months. Nearly half (44%) of organizations responded to these events by delaying their applications’ deployment into production.

These findings indicate that security is and needs to continue to be a priority for organizations seeking to deploy containers and Kubernetes applications into production. To make deployment run as smoothly as possible, organizations must understand the security and compliance requirements of the entire application development life cycle. That means integrating security into the three stages of the container lifecycle: build, deploy and runtime.

Phase 1: Build

Vulnerabilities that exist in the build phase of the application development lifecycle could become more difficult and costly to fix during runtime. That’s why it’s important for organizations to focus on container securing during the build phase. They can do so by following a couple of security best practices:

• Build secure images: The important thing to remember here is to keep containers as simple as possible. Organizations should avoid using container images that have OS package managers or shells. Those types of resources could include vulnerabilities, thereby giving attackers a possibly entry vector. They should also endeavor to remove debugging tools and other unnecessary components from a container; flaws in those programs could also open the door to malicious actors.
• Minimize your attack surface: Organizations need to take a close look at the necessary elements of their containers. Towards that end, they should make sure they’re running the most up-to-date version of their containers. Doing so will help to minimize the presence of vulnerabilities. Additionally, they should leverage an image scanner to scan their containers for potential security flaws. This tool should be capable of scanning for bugs in OS packages and third-party runtime libraries for the types of languages employed by containerized apps. In the event that the tool detects a bug, organizations should use their vulnerability management tool to prioritize an appropriate fix. They also have the option of using whitelist rules to make sure the bug doesn’t disrupt their security teams if they deem that a certain vulnerability doesn’t warrant an (immediate) fix.

Phase 2: Deploy

Organizations need to secure their Kubernetes infrastructure before it’s deployed. This effort should begin by making sure that organizations have sufficient visibility over their networks. Help Net Security clarifies the importance of visibility for ensuring container security:

Securing the network through deep visibility and protections is crucial because the network serves as the first layer of defense for keeping malicious actors from reaching the workload. At the same time, the network is the last line of defense, protecting data from being exposed. Between those first and last lines of defense, network visibility and proper network controls can prevent attacks from escalating within internal east-west traffic.

In terms of visibility, organizations need to specifically know what, where and how each resource is being deployed as well as what it can access. They can then leverage networking policies to shape the traffic that flows between pods and clusters. As noted by Kubernetes on its website, pods are non-isolated by default and can, therefore, accept traffic from any source. Fortunately, organizations can restrict these communication flows by creating network policies.

Organizations should also not forget to scan images in the deploy phase. Once they have the results of those scans, they must take action with them. For instance, they can use those scans’ findings in tandem with an admission controller to reject the deployment of an application if the container images lack scanning results or if they suffer from known vulnerabilities.

Phase 3: Runtime

Last but not least, organizations need to invest in containers security during the runtime phase. Visibility and image scanning are still important for this stage. But there are some important differences that organizations need to keep in mind. StackRox identifies how the process image scanning differs between the build and runtime phases:

The build tools you use to generate and compile your applications can be exploited when run on production systems. Remember, containers should be treated as temporary, ephemeral entities. Never plan on “patching” or altering a running container. Build a new image and replace the outdated container deployments. Use multistage Dockerfiles to keep software compilation out of runtime images.

Along those same lines, the only way organizations can ensure their runtime container security is by making sure that anomalous behavior on the network can’t hide. Help Net Security explains that organizations, therefore, require the ability to examine network packets at layer 7. In so doing, organizations will also be able to avail themselves of deep packet inspection (DPI) and other types of technologies that can help to detect more sophisticated attacks.

Additional Tips Abound

Organizations can use the tips provided above to begin securing their containers during the build, deploy and runtime phases of the application development lifecycle. By no means is this article exhaustive in its recommendations, however. Additional security tips can be found here.

Feature image via Pixabay.

At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.