Prioritizing Holistic Security Posture Management to Address Growing Threats to Containers and Kubernetes

Organizations are fighting to mitigate the rising, volatile threats and risks within cloud-native applications, containerized workloads and Kubernetes. The laundry list of challenges – from the risk of bad actors gaining unauthorized access and issues leading to misconfigurations to malware or vulnerabilities in container images – requires organizations to take a proactive approach to security. Security posture management is a broad concept encompassing everything an organization can do to prevent security incidents and is critically important in the world of containers and Kubernetes.

In practice, security posture management can be compared to physical home security: Assessing the physical integrity and security of a property, then working to implement preventative guardrails, locks and fences to keep intruders out. Security posture for containers and Kubernetes is akin to these principles, but the possible attack points are greater than any celebrity mansion.

There are four ways to quantify and measure the security posture of a Kubernetes cluster, based on the following risk types: High-risk images, control failures, namespace isolation and egress access.

Risk Management: High-Risk Images and Control Failures

As misconfigured Kubernetes clusters present attackers with an easy access path to company data, applications and code, it’s no surprise that high-risk images and control failures are a core focus when working to bolster Kubernetes security posture.

Control failures measure the number of misconfigurations within the Kubernetes control plane, nodes and application resources. High-risk images assess the number of running images that contain critical or high vulnerabilities or do not have scan results. With the increased adoption of shift-left approaches, code scanning and scanning images for vulnerabilities are frequently integrated into application development, making it easy to follow these practices. Hence the wide-scale adoption. However, holistic security posture management requires going beyond these practices.

The “Forgotten” Risk Management Practices: Namespace Isolation and Egress Access

Namespace isolation and egress access are often overlooked, despite their critical importance. This is largely because they are dynamic and more challenging, requiring specific expertise. Looking back at the home security analogy, namespace isolation and egress access can be compared to locks: the locks organizations have on their containers and Kubernetes entry points.

As its name suggests, namespace isolation ensures that every namespace is isolated. Think of this as a hotel, where development teams and applications have their own hotel room, a namespace. Hotels utilize key cards to control access to various rooms. In the Kubernetes realm, there are multi-tenant platforms where a container platform or Kubernetes cluster is supporting multiple applications at once. Often, these clusters do not have any relationship with each other and should function as separate entities. Through namespace isolation, organizations can ensure that one application doesn’t inadvertently do anything to impact another. These restrictions also protect organizations against lateral movement if a compromise does occur.

Egress access ensures that communication with endpoints external to a cluster is authorized and explicitly secured. Most organizations fail to consider egress access as part of security posture management. However, it is a key component to securing clusters.

The Inevitable Hurdles With Namespace Isolation and Egress Access

Egress access and namespace isolation practices are more complex aspects of posture management, as both elements require domain expertise with Kubernetes or with a specific area of Kubernetes (i.e. defining network policies). Organizations rarely have this level of expertise in-house. Adding to this, new applications rapidly evolve. As a result, egress access and communications within the cluster changes. Both tasks are exponentially harder to implement and operationalize compared to code or image scanning. Solving the skills gap and navigating the complex nature of modern applications often requires automation to equip organizations with the tools and context to efficiently observe applications for abnormal activity.

Navigating the Challenges

Solution adoption is a common avenue to assist with simplifying and streamlining namespace isolation and egress access. One of the foundational components to implementing namespace isolation and egress access controls is having adequate observability in an organization’s container platform to understand how workloads are communicating within and outside a cluster. This enables platform operators to reconcile network policies with the application workloads that they protect.

For namespace isolation, another key to success is enabling development teams to define their network policies based on the needs of an application. This can be done via a simple Helm chart utilized as a template or form for generating a network policy, which can then live in a Git repository and become part of the build process.

Some tools provide a way to inspect network traffic logs and automatically generate network policies for namespace isolation. This makes things even easier for development teams, and provides operators with an uncomplicated way to define policies for centralized components that may not be owned by a specific application team.

For egress access control, the location of control points for enforcing policies impacts possible approaches. At a minimum, organizations should consider implementing a control point for egress access inside a Kubernetes cluster with a network policy. Utilizing domain-based rules or classless inter-domain routing (CIDR) ranges, versus specific IPs, in network policy can minimize the fragility of a policy and how frequently it needs to be updated.

Some organizations may have a control point outside a cluster that protects secure resources or services such as a database. These external control points could be a firewall, proxy, or another type of allowlist. For this scenario, consider adopting a solution that can assign a fixed, routable IP to application traffic so it can be explicitly authorized by these control points. Several platforms and third-party tools offer the ability to configure an egress IP or egress gateway. This allows users to define more granular access for these external control points without having to authorize the entire podCIDR.

Crucial Need for Holistic Security Posture Management

As the adoption of containers and Kubernetes continues to proliferate, to safeguard against soaring levels of malicious activity, security posture management for Kubernetes and containers must be prioritized. While organizations must continue to uphold their robust image and code scanning practices, achieving the utmost level of Kubernetes security posture requires a broader approach: one that encompasses strict namespace isolation guardrails and egress access controls to protect against all possible risks.