Why context matters in Kubernetes security

Background

There are things in the world that are absolute, and there are things that are relative. For example, it is an absolute truth that the middle three Star Wars episodes were better than the prequel three. But if we are talking about security, it is mostly accepted to be relative as it is a well-accepted thesis that there is no absolute security. Every system can eventually be broken. Like in the joke about the two folks who are attacked by a lion. One of them starts to run for his life, the other starts to tie his sport shoes. The first ask cynically, “what are you doing? Are you trying to outrun the lion?!” The second answers: “I don’t need to outrun the lion, it is enough if I outrun you!”.

Now that we have established that there is no absolute security, we have to take the context into account in order to understand the security posture of a system. And no, I don’t mean to check on who else is running from a lion! To tell if a vulnerability, or a suboptimal setting can be exploited to breach a system, you need to have a full picture of how the system is put together, and how it’s actually being used. If not, you may find yourself fixing security issues that don’t really matter. Thus wasting two of your most important resources – time and money.

Kubernetes security is inherently complex due to the intricate and dynamic nature of the modern cloud-native environments. As an orchestration platform, Kubernetes manages numerous containers, each running different applications, often across various nodes and logical groupings (namespaces). This decentralized architecture, while offering scalability and flexibility, introduces multiple layers of potential security risks – from the application level down to the infrastructure. Moreover, the constant evolution of cloud-native technologies means that Kubernetes environments are continuously exposed to new security challenges. These challenges are compounded by the need for stringent access controls, network policies, and the secure management of sensitive data like secrets and configuration files. Effective Kubernetes security requires a comprehensive approach that encompasses application, infrastructure, networking, access control and an understanding of the constantly evolving threat landscape.

Kubernetes’ many security features may be deceiving, giving the impression that they cover all bases. While they address most problems related to platform security and offer some extensions around applications and networks (such as Kubernetes Secrets or Native Network Policies), these do not automatically translate to securing everything layered on top or below. Many of these are already included in existing fields such as “AppSec,” “Platform security,” and “Cloud security.” ARMO believes that using their (apps, platform, and cloud) information streams to provide context to Kubernetes security yields the best results. It provides users with a better understanding of the system’s overall security posture.

To put this in perspective, let’s use an example. Think about an application that has a vulnerability that can be exploited by an attacker who has network-level access to the application. If we know that this application can only receive requests from other applications from inside a cluster, that’s one thing. But if it can be accessed from the public internet, then the problem is in a completely different ballpark.

Information streams

In a Kubernetes cluster, security practitioners have access to plenty of information streams that are important for ensuring the security and integrity of the environment. Here’s a breakdown of these key streams:

Kubernetes API

The Kubernetes API is the central nervous system of a Kubernetes cluster, offering comprehensive insight into the state and management of cluster resources. Security practitioners can monitor the state of the cluster using the API, making sure that the configuration is secure and detect unusual patterns in the state of the cluster. This information is also invaluable to put other information streams into context since people are not working with classical constructs like “TCP connections” or “processes” alone but in the context of Kubernetes workloads.

Audit Logs

Kubernetes audit logs are invaluable for security monitoring and forensic analysis. They record a chronological account of requests made to the Kubernetes API, detailing who made the request, what was requested, and the outcome of the request. This data is crucial for detecting and investigating security incidents, ensuring compliance, and understanding the context of operational changes.

RBAC Settings

Role-Based Access Control (RBAC) settings in Kubernetes are fundamental for enforcing the principle of least privilege. By examining RBAC configurations, security practitioners can ensure that users and services have only the permissions necessary for their function, minimizing the risk of privilege escalation and unauthorized access.

Source: ARMO Platform

Image Vulnerability Information

Container images used in Kubernetes typically contain vulnerabilities. Security teams must stay informed about any vulnerabilities within these images to take timely action. Tools that scan container images for known vulnerabilities and provide detailed reports are essential in maintaining a secure container environment.

Node Information

The security of a Kubernetes cluster is heavily dependent on the security of its nodes. This includes understanding the Operating System (OS) details, ensuring they are up-to-date with patches, and validating installation configurations. Monitoring node health and security posture is critical to safeguard the underlying infrastructure that supports the cluster.

eBPF Application Observability Information

eBPF (extended Berkeley Packet Filter) enables detailed observability and security monitoring within a Kubernetes cluster. It provides deep visibility into processes, file activity, network traffic and system calls at the kernel level without modifying the kernel or the applications. This allows for real-time security monitoring and performance troubleshooting, offering security practitioners a powerful tool to observe and secure applications running in the cluster.

By leveraging these information streams, security practitioners in a Kubernetes environment can achieve a comprehensive understanding of the cluster’s security posture or detect security incidents. This information helps pinpoint and quickly counter security risks, keeping the cluster strong against ever-changing threats.

Examples of leveraging multiple streams for use cases

The idea is that cybersecurity subject matter experts, working within recognized organizations create security guidelines that give practitioners a solid foundation. However, when applying them to a variety of business scenarios, they are often found to be too generic. As a result, security professionals must modify the general rules to fit their specific infrastructure and unique application portfolios. By enhancing static security with the data streams mentioned above, ARMO Platform is automating this enrichment process and supporting the following security use cases.

CVE reachability

CVE Reachability is a new approach in container security, leveraging the power of eBPF to enhance the accuracy and efficiency of vulnerability management. This technology focuses on the utilization of eBPF to track file access information within a workload during container runtime. Here’s how it fundamentally changes the security landscape:

At the core of CVE Reachability is the understanding that not all software packages in a container image are actively used when the container is running. Traditional vulnerability scans of container images often flag all known vulnerabilities in every package included in the image, regardless of whether those packages are in use. This approach often results in a large number of false positives, burdening security teams with the task of sifting through these results to identify genuine threats.

By employing eBPF, CVE Reachability discerns which software packages are actually used during container runtime. It monitors and records the file accesses made by the container, providing precise data on which parts of the container image are active. With this information, security practitioners can then filter the results of vulnerability scans to focus solely on the vulnerabilities present in the active packages.

Source: ARMO Platform

This targeted approach has several significant benefits:

Reduction of False Positives – By eliminating dormant packages from vulnerability scan results, CVE Reachability can reduce false positives by up to 80%. This guides the security teams to focus on vulnerabilities that pose a real threat..

Enhanced Security Posture – With a more accurate understanding of the active attack surface, organizations can prioritize patching and mitigation efforts more effectively. This leads to a stronger and more resilient security posture.

Operational Efficiency – Security practitioners can allocate their time and resources more efficiently, as they no longer need to investigate vulnerabilities in unused packages. This not only saves time but also reduces the complexity involved in securing containerized applications.

In conclusion , CVE Reachability represents a significant advancement in container security. By leveraging eBPF for real-time analysis of container workloads, it offers a more precise and efficient method for managing vulnerabilities, significantly reducing the burden on security teams and enhancing the overall security of Kubernetes environments.

Hardening cloud workloads

Implementing the least privilege principle for Kubernetes-based workloads is a challenging yet important aspect of securing containerized environments. The principle of least privilege requires that applications and processes operate with the minimum levels of permissions necessary to perform their functions. Achieving this in Kubernetes, just as in other complex systems, is not straightforward due to its complexity and the variability of application behaviors. To effectively tighten an application’s privileges, it’s crucial to have a deep understanding of its behavior. This includes knowing which resources it accesses, what operations it performs, and how it interacts with the system and network. Without this knowledge, defining the minimum necessary privileges is largely a guesswork. Here are some examples of how eBPF can be instrumental in hardening workload configurations.

Let’s take for example Linux capabilities. eBPF can be used to monitor a workload’s runtime behavior, specifically tracking the Linux capabilities it uses. Linux capabilities are a fine-grained access control mechanism that divide the privileges traditionally associated with superuser access into distinct units. By observing which capabilities a workload actually utilizes, security teams can tailor the permissions to fit the workload’s specific needs, ensuring that only necessary capabilities are enabled.

Limiting System Calls with Seccomp Profiles

System calls are how a program requests a service from the operating system’s kernel. eBPF can monitor the system calls made by a workload, providing exact insight into its interaction with the OS. With this data, security teams can create seccomp (Linux Secure Computing Mode) profiles that precisely define which system calls are permitted for a given workload. This level of control is typically hard to achieve manually due to the vast number of potential system calls and the difficulty in predicting which ones an application will require.

Source: ARMO Platform

Network Policies

eBPF’s observability capabilities extend to network interactions as well. By monitoring which external entities a workload communicates with, eBPF can help in creating accurate network policies. These policies can restrict network access to only those communications that are necessary for the workload’s operation, thereby reducing the attack surface and preventing potential lateral movement of threats within the network.

Source: ARMO Platform

Detecting attack paths

The concept of attack paths in a Kubernetes environment revolves around the identification and analysis of potential routes an attacker could potentially exploit to compromise the system or its assets. Detecting these attack paths requires a multi-dimensional approach, considering various aspects of the cluster’s configuration and state. To effectively identify potential attack paths, it’s necessary to integrate and analyze information from multiple sources within the Kubernetes ecosystem. This includes data from network configurations, workload behaviors, security vulnerabilities, access controls, and more.

Consider a Kubernetes workload that is configured to receive traffic from the public internet. This configuration detail can be gleaned from the Kubernetes settings, such as ingress rules or service types.

Suppose this same workload is identified by a vulnerability scanner as having critical security vulnerabilities. This information adds another layer to the security assessment. Combining this information results in flagging a heightened risk for this particular workload.

Furthermore, let’s say the workload has a mounted secret, which could be sensitive data or credentials necessary for its operation. This aspect introduces the potential for data exposure or unauthorized access if the workload is compromised.

By looking at this information collectively – the public internet exposure, the identified vulnerabilities, and the access to sensitive data – a comprehensive security system can deduce that the mounted secret is at risk of being compromised by external threats. This realization forms the basis of an attack path: an external actor could potentially exploit the vulnerabilities to gain unauthorized access to the secret.

This method of combining multiple data sources to identify attack paths can be applied to various other scenarios in a Kubernetes environment. Each scenario will have its own unique configurations, vulnerabilities, and access controls, which collectively indicate potential attack vectors.

Source: ARMO Platform

This approach underscores the importance of holistic security analysis in Kubernetes. By integrating data from multiple sources, security systems can map out possible attack paths Thus, enabling security teams to preemptively address vulnerabilities, tighten configurations, and safeguard sensitive data. Such proactive measures are vital in mitigating the risk of attacks and maintaining the integrity and security of Kubernetes clusters.

Conclusion

Looking at Kubernetes through various information sources, such as the Kubernetes API and audit logs, provides an understanding of the system’s security posture in context. By leveraging technologies like CVE Reachability and eBPF, container security can be enhanced. This leads to more accurate vulnerability management and workload configuration hardening. Integrating data from multiple sources allows security systems to identify potential attack paths and take proactive measures to address vulnerabilities. A holistic security analysis is crucial for maintaining the integrity and security of Kubernetes clusters. If you’re seeking to improve your Kubernetes security, try ARMO Platform today.

The post Why context matters in Kubernetes security appeared first on ARMO.