Overview

Kubernetes is the de facto standard for orchestrating containerized workloads. With the growing number of production Kubernetes deployments, continuous security is key to successful execution of applications.

State of the Kubernetes Security Report survey done by RedHat showed 55% of the customers answered security is the gating factor for container adoption. It is very critical to have defense in depth for a meaningful security posture, but proves to be elusive for many cluster administrators. Security can be divided into three categories: Build, Deploy and Runtime. The Industry survey is  overwhelmingly worried about the ‘Runtime’ category.

Complexities in Kubernetes security

While Kubernetes is flexible for quick deployment of application workloads, secure management  of underlying infrastructure to microservices, Kubernetes also introduces many security complexities.

The three common sources of compromise in Kubernetes are:

• supply chain risk
• malicious threat actors
• insider threats

Supply chain risks are often challenging to mitigate and can arise from several injection points; in the container build cycle, 3rd party containers, or infrastructure acquisition. Malicious threat actors can exploit vulnerabilities and misconfiguration in components of the Kubernetes architecture, such as control plane, worker nodes, or containerized applications. Insider threats can be administrators, users, or cloud service providers.

Leveraging Kubernetes constructs

Kubernetes provides provisioning constructs for configuring the cluster with RBAC (Role Based Access Control), namespace (network isolation), resource quotas, Pod Security Standard (PSS), API security (Control Plane), network policy (Network Isolation), and finally audit policy for visibility. In order to configure a kubernetes cluster with a secure environment for teams, applications or enterprises, one must configure many knobs as mentioned above in the deploy and run domain. 

Limitations and Solutions

There are many solutions which scan the application containers deployed in Kubernetes, but there are very few solutions which address Kubernetes infrastructure level security and none for multi-cluster Kubernetes infrastructure deployments.

KubeSlice creates strong security zones in the Kubernetes cluster for development teams  to deploy applications securely.  By combining network, application, Kubernetes, and deployment services in a framework KubeSlice creates a tenancy for teams and extends it to  multi-cluster environments. KubeSlice achieves this by creating logical application “slice” boundaries which allow pods and services to communicate seamlessly across clusters, clouds, edges, and data centers.

Segmentation- A way to reduce the attack surface

The biggest threats making headlines exposing the latest exploits call for protection from every attack vector possible. Typical attack vectors are unsecured access, misconfigured authentication, social engineering, insider threats and vulnerable containers. By reducing the attack surface, no user will have access to the entirety of  cluster resources and decreases complexity. KubeSlice addresses the needs of keeping the cluster environment secure by sharding the clusters into slices (segments – reduced attack surface – all possible ways a system can be attached) and applying the best practices to configure, deploy and runtime domain of Kubernetes cluster. KubeSlice also extends the same blueprint to multiple clusters with  centralized configuration management. By reducing the attack surface, malicious actors' lateral movement is far reduced. Exposure to data or resources is constrained to the segment of the cluster.

Slice Namespace - A way to solve config drift and namespace sprawl

A Slice is a collection of namespaces which can be assigned to a team, application, or an enterprise in a managed service provider domain. Application developers in a team cannot be constrained to a single namespace in a cluster, but once multiple namespaces are assigned to a team or application, one would have to replicate many of the constructs defined for a team or a namespace. This leads to config drift and every change would have to go through operational validation. KubeSlice controls all namespaces attached to a Slice with a custom resource and a controller for RBAC, resources, network isolation and mutating pod security.

Network Policies - A way to control malicious container traffic inside cluster, Denial of Service (DOS)

The container environment inside a namespace and across namespaces is constantly changing within minutes or seconds with stateless workloads. Old models and tools are not suitable for securing container footprints inside Kubernetes. Slice namespaces creation should couple with network policy creation starting with least privilege principle.  Namespaces by default are not isolated.  Also, by default, network policies are not defined on any namespace within a Kubernetes cluster leading to unrestricted ingress and egress traffic. Not all Container Network Interface (CNI) plugins support network policy. Slice splits the network into separate sub-network, or a security zone, improving isolation bringing the benefit of reduced attack surface.

Managing Resources - A way to control denial of service by starvation

Resource Policies are critical for avoiding unintended or malicious saturation of pods (in turn ip network addresses), compute, memory, and storage abuse. KubeSlice can assign a dedicated node(s) virtual or physical machines depending on the cluster implementation. Nodes are often the target for exploitation. If node segmentation is not performed in a cluster, a compromised node would affect the entire cluster.

RBAC - the secure KubeSlice way

Kubernetes assumes that a cluster-independent service manages user authentication. Once authenticated, another area which is important to secure a cluster is utilization of RBAC functionality to a slice and ability to establish access privileges to objects scoped for a slice. Role Based Access Control is the best way to control who has access and what resources can be managed. Slice RBAC will be forbidden to have cluster scoped RoleBindings and only grant access to namespace scoped resources. Slice admin or slice group entity (users) will not have the ability to bind to clusterrolebinding to any cluster scoped resources. Such a scheme protects from external actors and also puts control on internal actors.

Securing the Control Plane with KubeSlice

The control plane is the core of Kubernetes. The API server which is part of the control plane allows users to view pods, container details, list objects like secrets, and execute commands like delete resources in the cluster. API server is a way to access sensitive information of the cluster. The control plane should be highly protected in a tenancy model. Slice admins will have limited and targeted access to designated namespaces.

In conclusion

Security is job number one for KubeSlice architecture. Protecting sensitive cluster infrastructure by sharding the cluster and establishing responsible guardrails help the Slice user secure the environment and still maintain the freedom to deploy applications and realize the full benefit of Kubernetes clusters. KubeSlice helps accelerate CI/CD by securing application zones in a cluster and extending to multi-cluster environments for teams and enterprises with guardrails.