CloudContributory Expert VoicesDevelopersDevOpsSecurity

Kubernetes Security: Taking a Phased Approach 


Continuous integration and delivery (CI/CD) in the cloud is a kind of nirvana state for developers. The idea that application development is an on-going process resonates with them because inherent in this idea is the removal of traditional roadblocks, including “final mile”  doesn’t disappear for cloud-native developers. Nor is it as easy to integrate into the DevOps process as “DevSecOps” would suggest. It’s more complicated than simply putting security in the middle, especially when cloud-native architectures and Kubernetes are considered.

Kubernetes is great for orchestrating microservices. The departure from the monolith architecture offers multiple advantages for building applications and securing them, but from our experience, it seems like many Kubernetes users are not taking full advantage of its security capabilities. For example, we found that many clusters have excess container and pod privileges and overly permissive network policies (if any at all).

What is the root cause? We can’t tell for sure, but it seems to be related to an inherent problem with security: Ownership. If you let developers control security, they will create overly permissive policies, while if you give it to security managers, they may enforce too many restrictions which may impact velocity.

Kubernetes’ security features are still evolving too. Pod-level security policies, for example, was recently abandoned and there are on-going efforts to enhance network policies.

Meanwhile, to address this gap, many organizations do what they always have, taking a perimeter-first, outside-inside approach. Unfortunately, this leaves vast sections of the environment’s surface exposed to various cyberattacks.

A Modern Maturity Model for Kubernetes Security

At Tufin, we see four necessary phases to achieving an aggressive security posture within a Kubernetes environment. Why four phases? Because most organizations are already starting at a disadvantage. Kubernetes lacks native visibility into network traffic. It doesn’t generate traffic logs, and so developers as well as security teams have little insight into which services are talking to each-other, inside the cluster and also externally: ingress and egress.

In phase one of our Kubernetes security maturity model, the focus should be on gaining visibility into and monitoring both incoming and outgoing traffic and connections at the cluster level. This allows organizations to block risky or unnecessary traffic at a macro level for each cluster.

In phase two, we need to go a level deeper: to the domain or, in Kubernetes parlance, the namespace level. In the traditional networking world, network teams enforce domain-level security using assigned IP addresses. The network teams more or less own the naming convention of these IP addresses and can organize them according to their security policies. In Kubernetes, however, namespaces are often created by the developers with little or no regard for security policies. And so, organizations may have multiple namespaces: for various applications, business units, or teams, each with their own security policies that must be reviewed, updated, etc. as needed.

Gaining visibility into the configurations governing traffic within and between namespaces is essential and applying policies to ensure only authorized traffic among namespaces is critical.  Designing and deploying these policies manually, however, is very complex and time intensive. Not surprisingly, many organizations never make it to phase two for this reason. But, by automating the creation and management of security policies, organizations can enforce security at the namespace-level without sacrificing the simplicity and agility that made Kubernetes attractive in the first place.

In phase three, organizations will want to go a level deeper still and develop security policies to manage access and connectivity at the service and pod levels. In this third phase, the goal is microsegmentation: establishing policies and permissions so that hackers cannot move laterally between pods to gain access to sensitive information. Creating pod-level security policies manually using native Kubernetes tools can become quite complex. Utilizing a solution to automate the design of Kubernetes security policies makes this process much easier.

Finally, in phase four, organizations are ready to implement a process to effectively manage the lifecycle of their Kubernetes security policies—including those at the cluster, namespace, service, and pod levels. This involves regularly re-evaluating and re-certifying existing policies, identifying new traffic and connections in the context of existing policies, and deploying new policies as appropriate. Here again, automation has a critical role to play, as trying to manually identify new connections and update security policies would be time-consuming and prone to human error.


The growing popularity of Kubernetes is understandable, given the greater agility and portability it makes possible for application developers. Yet ensuring Kubernetes is managed and deployed securely requires a thoughtful, sophisticated approach. Creating the appropriate Kubernetes security policies is an iterative process that requires organizations to move from a macro to a micro level of visibility, analysis, and control. Given the inherent dynamism of the Kubernetes architecture, using tools that can automate this process is recommended to avoid human error and oversight.

This phased, automated approach to Kubernetes security provides all stakeholders with the visibility they need to understand how their environments are behaving at every level, identify potential risks, and deploy policies across their builds and DevOps pipelines to ensure they remain secure and compliant.

Author: Reuven Harrison, chief technology officer and co-founder, Tufin
Bio: Reuven Harrison is CTO and Co-Founder of Tufin. He led all development efforts during the company’s initial fast-paced growth period, and is focused on Tufin’s product leadership. Reuven is responsible for the company’s future vision, product innovation and market strategy. Under Reuven’s leadership, Tufin’s products have received numerous technology awards and wide industry recognition.

Reuven brings more than 20 years of software development experience, holding two key senior developer positions at Check Point Software, as well other key positions at Capsule Technologies and ECS. He received a Bachelor’s degree in Mathematics and Philosophy from Tel Aviv University.

To hear more about cloud native topics, join the Cloud Native Computing Foundation and cloud native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021

Don't miss out great stories, subscribe to our newsletter.

Navigating Space and Society with Robotics and SLAMcore | Owen Nicholson, SLAMcore

Previous article

Netlify Adds New Team Governance Features And Jira Integration

Next article
Login/Sign up