Security breaches hinder development agility

Teams working on digital transformations aspire to deliver and deploy apps faster. Adopting containers, Kubernetes, and cloud-native architectures were supposed to ensure that teams get the speed and agility they need to meet customer demands. The reality, however, can be different — deployments get delayed oftentimes due to security breaches, vulnerability attacks, or simply human errors. In these times, the main promise of cloud-native falters — the ability to deliver a faster time to market for apps and services.

Defense in Depth

Security in Kubernetes is of primal importance. The best practice in cloud-native postulates that security is enforced in each of the 4C’s layer — Code, Container, Cluster and Cloud. KubeSlice enhances Kubernetes run-time security in the Cluster layer — let’s explore how.

Are large clusters more vulnerable?

In a Kubernetes cluster, all pods talk directly to any other pods within the cluster. If there is one giant cluster for many teams and applications, that’s a huge surface area vulnerable to any attack. If a malicious software infiltrates into one pod it can affect all other pods in the cluster.

Solution? Reduce the attack surface.

How does KubeSlice do it?

1. Isolate with Network Policies per Slice

Create an application slice with KubeSlice and set “isolate with network policy:” flag to isolate services/pod traffic logically within a cluster. The traffic within a Slice is completely isolated from other communications within the cluster. It’s like if Larry, Moe, or Curly were their own Slices, they would never collide and bang their heads against each other!

2. Isolate with RBAC per Slice

Using KubeSlice, you can easily assign users to a Slice giving access to only a portion of the cluster at a time. Yet another way to reduce the blast radius by restricting access privileges defining role based access controls.

3. Isolate by allocating resources per Slice

Using KubeSlice, you can assign specific resources to a Slice (nodes, CPU, memory) based on service needs. This ensures there are no chatty neighbors and each set of pods and services within a Slice boundary get their fair share of allocated resources as demand scales up or down.

For development agility security is key and for enhanced security, microservices isolation is key

It’s important for teams not to be slowed down by security incidents. For securing your Kubernetes clusters, isolating applications (i.e. isolating microservices) is key. An easy way to isolate critical applications (ie. isolating microservices) and reduce the attack surface is to put them on a Slice using KubeSlice. Using security features such as traffic segregation based on network policy, RBAC, and Resource Allocation are easy, yet powerful ways to reduce your cluster security risks of increased exposure to cluster-wide malicious attacks

If this sounds interesting, check out the KubeSlice project on GitHub. Even better, we have a sample script that creates a KiND cluster & installs KubeSlice that you can directly use by navigating to our GitHub repo named examples!

Should you get stuck or require assistance, we hang out on the #kubeslice Slack channel in the Kubernetes Slack. Feel free to hop on & get those doubts answered!