Kubernetes Multi-Tenancy Benchmark

Source: Capsule Documentation | Capsule Overview

Capsule Overview

Kubernetes multi-tenancy made easy

Capsule implements a multi-tenant and policy-based environment in your Kubernetes cluster. It is designed as a micro-services-based ecosystem with the minimalist approach, leveraging only on upstream Kubernetes.

What's the problem with the current status?

Kubernetes introduces the Namespace object type to create logical partitions of the cluster as isolated slices. However, implementing advanced multi-tenancy scenarios, it soon becomes complicated because of the flat structure of Kubernetes namespaces and the impossibility to share resources among namespaces belonging to the same tenant. To overcome this, cluster admins tend to provision a dedicated cluster for each groups of users, teams, or departments. As an organization grows, the number of clusters to manage and keep aligned becomes an operational nightmare, described as the well known phenomena of the clusters sprawl.

Entering Capsule

Capsule takes a different approach. In a single cluster, the Capsule Controller aggregates multiple namespaces in a lightweight abstraction called Tenant, basically a grouping of Kubernetes Namespaces. Within each tenant, users are free to create their namespaces and share all the assigned resources.

On the other side, the Capsule Policy Engine keeps the different tenants isolated from each other. Network and Security Policies, Resource Quota, Limit Ranges, RBAC, and other policies defined at the tenant level are automatically inherited by all the namespaces in the tenant. Then users are free to operate their tenants in autonomy, without the intervention of the cluster administrator.

Kubernetes multi-tenancy benchmark

The Multi-Tenancy Benchmark (MTB) is a Working Group (WG) dedicated to establishing multi-tenancy in Kubernetes. The MTB benchmarks provide guidelines to validate whether a Kubernetes cluster is correctly configured for multi-tenancy.

Capsule, an open-source multi-tenancy operator, is aiming to meet the requirements set by MTB. However, as of now, Capsule is still in development and not yet ready for production use. To clarify, they are not claiming official conformance to MTB at this time, but rather that they strive to adhere to the multi-tenancy requirements and best practices recommended by the MTB.

Conclusions

Source: Implementing EKS Multi-Tenancy Using Capsule, Pt 4 - DZone

• Namespace options, resource quotas, and limit ranges are inherited across all the tenant namespaces.
• Network policies defined at the tenant level are applied across all the tenant namespaces. Capsule also allows to define additional network policies at the namespace level.
• Host isolation features like blocking access to the underlying host infrastructure: host IPC, host PID, host path volumes, host networking and ports, etc. have been verified.
• Control pane isolation features like blocking access to cluster resources, access to multitenant resources, access to other tenant resources, etc. have been verified.
• Data isolation features like avoiding or BLOCKING a tenant to mount existing volumes have been verified.
• Security Policy engines like Kyverno, Gatekeeper, etc., and Network Policy engines like Calico, Cilium, etc. can be integrated with the Capsule framework.
• Capsule allows the addition of internal namespace users and user groups as tenant owners. However, only AWS IAM users can be added as tenant owners and not the service role or IAM user groups. This has been confirmed by the Capsule team here.