Runtime Security for Kubernetes

Runtime Security for Kubernetes

Runtime security can be a broad and ambiguous term. It includes various key elements to ensure optimal performance, ranging from periodic vulnerability scanning to detecting runtime anomalies like privilege escalation and unauthorized access. Kubernetes enables additional runtime security capabilities. However, whether security teams understand the additional runtime security primitives Kubernetes enables, and their importance, is unclear.

Many enterprises don’t invest enough resources in runtime security optimization or completely underrate its importance as a part of their Kubernetes security strategy. Kubernetes undoubtedly has its complexities as it features several native tools to access privileges while separating workloads. But, Kubernetes is also extensible, offering some unique capabilities for runtime security that enable a “shift-left” mindset and focus on prevention rather than detection.

Adding clarity and flexibility to a complex runtime security process must be prioritized. I believe it’s necessary to use native tools to adequately secure Kubernetes. The need for more modern security systems utilizing open-source software is clear to optimize runtime security performance.

Traditional vs. Modern Runtime Security Approaches 

Traditional runtime security approaches focus mainly on detection and enforcement. Many closed systems which provide abstractions on Kubernetes simplify the deployment of containers, providing ease of use for developers. However, they don’t allow extensibility using powerful features like admission controls and aren’t designed to be composable, meaning new security policies can’t be plugged in to check for things like container image signing and verification. With a closed system, there is no easy way to add custom policies and check if container images are signed by your private keys. 

By contrast, modern runtime security systems are designed for extensibility. Using a better and Kubernetes-native approach successfully complements detection with prevention by making developers aware of issues that have taken place earlier within the pipeline and in familiar tools. Cloud-native and open-source systems facilitate the ability to check container image signing and verification, using pluggable admission controls to introduce features on the fly and program the control plane. These cloud-native systems prove the kind of necessary flexibility for runtime security. 

Additionally, cloud-native and open-source systems change the focus of who should access runtime security tools. In my opinion, if runtime security tools are only meant for a central security team, that’s a big concern. The focus should be to provide relevant security information to developers in tools they already use when and where they need it rather than a central security team identifying alerts and trying to understand them before reaching out to developers for assistance. 

A more modern approach facilitates the move from DevOps to DevSecOps, preventing the mismatching of tools and ensuring runtime security tools are being controlled by the right people for overall stronger Kubernetes security. Policy engines like Kyverno enable runtime protection by using admissions controls and background scanning to ensure the functionality of various features, including pulling build and image data from OCI registries such as vulnerability scan reports and a software bill of materials (SBOMs).

Why is a More Modern Approach to Runtime Security Necessary?


https://images.pexels.com/photos/34600/pexels-photo.jpg?auto=compress&cs=tinysrgb&dpr=2&h=650&w=940
Runtime security needs more automation to function optimally in modern times

When looking at vendors and solutions from companies that sell runtime security tools, their typical messaging is that runtime security is overlooked, with a strong emphasis on increasing investment and requiring more scanning to detect issues at runtime. However, at Nirmata, we believe that message must be more nuanced to advance runtime security to where it needs to be.

Kubernetes has well-defined extensibility points for runtime security, with admission controls being key. With runtime security, prevention is better than a cure. Running runtime security measures after inputs have been administered in the cluster is a doomed strategy as potential threats can already enter the cluster and compromise the security system. Admission controllers should be the starting point of a well-thought runtime security strategy that handles the various complexities of Kubernetes security.

The need for a more modern approach is obvious. The Cloud Native Computing Foundation (CNCF) conducted a study last fall to determine how well organizations are managing their cloud-native security. Organizations overwhelmingly see the value in opting for a more modern approach to runtime security as 85% of survey respondents stated that modernizing their framework is highly important to improving their cloud-native deployment.

With that said, less than 10% of organizations had fully documented procedures that could be automatically implemented for their teams. And, just 12% of the organizations surveyed expressed that their processes for securing their third-party software don’t exist, leaving them vulnerable to all sorts of threats. Despite understanding the importance of having these policies and executing them consistently, mass adoption is still a long way from being achieved.

From what I have seen engaging with clients and handling their runtime security quandaries, there needs to be greater clarity about how tools function best and who should be using them. Putting more control in the hands of developers by using a cloud-native approach to runtime security measures makes the security process timelier and more transparent, while also reducing costs.

Why are Admission Controls So Important?

Admission controllers are pieces of code that consistently intercept requests made to the Kubernetes API server before the persistence of an object becomes a threat, but only when the request has been validated. The controllers can only be configured by the cluster administrator.  Nearly 60% of security issues related to Kubernetes security can be attributed to misconfigurations.

Different admission controllers will either validate or mutate, with mutating controllers modifying related objects to their admitted requests. Admission controllers also limit requests to create and modify objects or connect to a proxy. Any API server that isn’t aptly configured with the appropriate set of admission controllers is incomplete and won’t accommodate certain features. There are several types of admission controllers that Kubernetes uses.

Providing Agility and Optimization with a Cloud-Native Approach to Security

A cloud-native system for runtime security provides the sort of robustness that organizations need to respond to security threats quickly. Moving the focus to admissions controls provides strategic value and maximizes productivity, allowing developers to address issues earlier in the pipeline. With admission controls utilized through policy engines like Kyverno, developers can access information right away and be aware of threats ahead of time.

Using a cloud-native and open-source security system provides more autonomy for different roles, ensuring a secure collaboration between developers, security teams, and operations while properly aligning these roles. Using policy managers that take data from several Kyverno clusters provides feedback and value while enabling the secure collaboration to optimize the process of runtime security in Kubernetes.

Policy management and policy-based operations across CI/CD, admission controls, as well as runtime, will shape the future of runtime security. I believe that there must be consistent and managed policies for runtime security, with tools like Kyverno enforcing these policies. Having a flexible and consistent policy manager in conjunction with Kyverno brings in collaboration workloads while efficiently distributing important information throughout an enterprise. The way forward is using policy-based operations to ensure the right enforcement points, notifications, and reporting while ensuring a secure and productive loop involving developers, central security teams, and operations. Providing intelligent and adaptive guardrails for these roles prevents errors while adding a layer of strength to security systems.

At Nirmata, we offer complete policy management for Kubernetes. Our cloud native policy management solution, powered by Kyverno, facilitates the autonomy, agility, and alignment necessary for runtime security, automating the creation, deployment, and lifecycle management of policy-based intelligent guardrails.

Our solution delivers policy insights, reports, alerts, and team collaboration by integrating with DevSecOps tools, processes, and workflows. Learn more about our Kubernetes cloud-native solution today. Please reach us here if you have specific questions or topics you would like to discuss.


Enforce and Automate Policies for Kubernetes Data Protection with Kyverno
Kyverno v1.6.0: More Kubernetes Security and Governance Use Cases Through Policy
No Comments

Sorry, the comment form is closed at this time.