To understand how to secure cloud-native applications, it is imperative to know how to protect the underlying Kubernetes environment and its relevant attack surface. The attack surface within a Kubernetes cluster consists of three main areas:

• The software supply chain for building the immutable artifacts used to deploy and run containers
• Infrastructure components that must be provisioned and configured to run Kubernetes
• Deployed and running containers that make up individual Kubernetes applications 

Nearly all Kubernetes threat vectors can be mapped into one of these three categories. This Refcard utilizes these categories as a framework to describe key security concepts that comprehensively span the Kubernetes infrastructure and applications.

In Kubernetes environments, the software supply chain is a centralized place to make any software changes for propagation into production environments. It also serves as a bottleneck where users can incorporate security measures that impact the rest of the application lifecycle.

Container images constitute the standard application delivery format in Kubernetes environments. Building these images is the primary goal of a cloud-native software supply chain, so securing the supply chain should primarily focus on image security. The wide distribution and deployment of these container images requires a well-thought-out strategy for ensuring their security.

Figure 1: Software supply chain

Base Images 

Security of container images often starts with the base operating system (OS) images. Consider using the official language-specific base image from a reputable provider (e.g., OpenJDK) over installing the package on a generic Linux image. Opt for alpine or distroless images from official image registries to keep the base image small. Finally, the base images that are used should also be updated frequently to address any newly disclosed vulnerabilities or other security concerns. 

Image Components 

Any container images that are built should be kept as minimal as possible. To avoid additional avenues of exploitation, utilize multistage builds in the containerized application for binaries, libraries, and configuration files only. In particular, the following should be avoided in production environments whenever possible:

Secrets should not be embedded in images since anyone with access to the image — either by downloading it from a registry or once it is built — would be able to view them in plain text, and because it provides unnecessary exposure prior to when the secret needs to be used. In Kubernetes clusters, you can use Kubernetes secrets or tools like Vault or external-secrets to pass this sensitive data to pods.

Another way to manage image components is to utilize the software bill of materials (SBOM), as recommended in the President’s Executive Order on Improving the Nation’s Cybersecurity. SBOMs are critical to securing the supply chain, particularly in augmenting dependency and OS package information, with additional attributes such as licensing, network data, and usage information. Common pitfalls such as using restrictive open-source licenses (e.g., GPL) and end-of-life (EOL) packages can be avoided by maintaining an SBOM.

Image Scanning

Once images are built, they must be scanned to avoid introducing vulnerabilities into your running Kubernetes clusters. Image scanners are available as standalone tools (e.g., trivy, anchore, clair), or in some cases, are integrated with image registries. It is critical to utilize an image scanner with several or all of the capabilities listed here:

Image scanning should be a requirement for passing image builds. Results can be used to implement policies that determine whether a build should pass or fail based on the number, severity, and type of vulnerabilities detected in a given image. As the last line of defense, Kubernetes admission controllers can be configured to implement an ImagePolicyWebhook to scan all images before it is deployed to the cluster to prevent manual deployments that circumvent CI/CD pipelines.

Build Systems 

The infrastructure, namely build and CI systems and pipelines, used to create these images must also be secured. As the number of tools used to deploy infrastructure and cloud-native applications onto Kubernetes grows, remember to secure the entire CI/CD pipeline.

Below are essential security measures to take:

• Limit administrative access to the build infrastructure
• Allow only required network ingress
• Manage any necessary secrets carefully, granting only minimal required permissions
• Use network firewalls to allow access only from trusted sites used to retrieve sources or other files
• Automate vulnerability scanning, license management, and static code analysis for potential security issues in the pipeline

Container Registry

Once an image has been built, it must also be stored securely in an appropriate image registry. A private, internal registry can provide greater security but imposes the added operational overhead of managing registry infrastructure and relevant access controls. An alternative is to use a registry managed by a cloud platform or other provider. Finally, configure alerts and reports for license violations and vulnerabilities to remediate issues on new and existing images. 

Kubernetes is the critical foundation for how cloud-native applications are deployed and managed. Therefore, security measures to protect the components that make up Kubernetes itself, including remediating vulnerabilities or preventing misconfigurations, are essential to protecting your clusters. Every Kubernetes cluster contains a set of infrastructure components needed to run the platform and applications on it. These components may require administrator or user configuration when provisioning clusters, and understanding them can help focus efforts on valuable security mitigations.

They can be categorized as:

• Control plane components – manage operations throughout the cluster.
• Worker node components – run containerized applications in pods.

The Kubernetes control plane makes global decisions regarding a cluster’s operations. As a result, guarding against threats to its components is paramount since these could compromise the entire cluster environment. The two tables below list the control plane and worker node components with corresponding threat vectors and security measures to implement.

Once the software supply chain (including the images that are built using it) and Kubernetes cluster infrastructure are adequately secured, the remaining focus is on security controls for the Kubernetes pods that are deployed and run. Pods are the smallest units deployed into clusters and collectively form Kubernetes applications, so they are ultimately the targets subject to individual exploits. Securing pods and their containers requires substantial attention — doing so enables more granular security controls that better scope the requirements of individual application components.

Deploy-time and runtime security involve separate security measures but are related in that they should primarily focus on first setting parameters that restrict what containerized applications can do, and then subsequently monitor for any deviations (or attempts to deviate) from those restrictions. 

Admission Controllers 

The primary mechanisms for restricting the deployment of pods in Kubernetes are called admission controllers.

Security Contexts 

The main Kubernetes controls that allow pod restrictions to be applied at runtime are referred to as security contexts. They form an important aspect of how pod runtime security works in Kubernetes.

Kubernetes Network Policies 

Additionally, network segmentation of pod-to-pod traffic is another substantial security measure that is required to ensure Kubernetes applications are adequately protected. It limits the impact of an attacker that is able to gain access to any particular group of deployed and running containers, including restricting the ability to move throughout a cluster laterally.

RBAC and Service Accounts 

Kubernetes uses role-based access control (RBAC) to authorize access to resources within the cluster. By default, Kubernetes mounts the default service account to every pod upon creation. Depending on its permissions, the pod may be granted more permission than required. If the application does not heed to Kubernetes roles, set automountServiceAccountToken to false. Otherwise, exercise the principle of least privilege to only give the set of permissions the application needs to interact with Kubernetes or external components (e.g., cloud-specific services through service account mapping).

Runtime Threat Detection 

Finally, the security concepts outlined above must still be complemented with runtime threat detection since no security controls can be considered foolproof. System-level activity such as process execution and network communication can be monitored at the level of individual containers to determine potential indicators of compromise. 

Tools such as Falco can monitor syscalls and Kubernetes API logs to trigger alerts. Such tools can be configured to alert when privilege escalation occurs or when write events are detected on protected directories. For example, Falco can be configured to detect and produce a warning when non-device files are written in /dev:

- rule: create_files_below_dev
  desc: creating any files below /dev other than known programs that manage devices. Some rootkits hide files in /dev.
  condition: (evt.type = creat or evt.arg.flags contains O_CREAT) and proc.name != blkid and fd.directory = /dev and fd.name != /dev/null
  output: "File created below /dev by untrusted program (user=%user.name command=%proc.cmdline file=%fd.name)"
  priority: WARNING

Kubernetes is a powerful yet complex system that is rapidly transforming how organizations build, ship, and run modern software applications. Its benefits come with associated security demands that must be addressed with a multitude of open source and commercial tools to minimize risks and threats to your business. An effective approach to securing Kubernetes environments and the applications running inside is based on applying controls to secure the following key areas:

• Software supply chain used to build container images, including base images and image components
• Infrastructure components needed to run Kubernetes clusters, including its control plane and worker nodes
• Deployed and running containerized workloads made up of individual pods

In short, the entire software supply chain — from the application code to the deployed containers as well as the Kubernetes cluster — must be secured. Due to the complex nature of cloud-native applications, every single attack vector must be considered to securely deploy applications to Kubernetes. By implementing a multi-layered approach to security, organizations can scale their production usage of Kubernetes with confidence.