With Kubernetes, companies have the ability to spin up applications with the click of a button or a declarative one-line command statement. As they spin up the services, they are hosting them within clusters, but they do not really want to deploy multiple clusters for each application or service that they’re looking to host within their website or within their application.

That’s why ‘namespace-as-a-service’ is becoming so prevalent as it subdivides and segregates the cluster, isolates the services within the cluster down to their individual namespaces such that you can secure that application within a namespace and only provide users that should have access with access to that service.

Martin Phan, Field CTO at CloudCasa by Catalogic, says that the adoption of ‘namespace-as-a-service’ is still in its early stages because users are still in the process of adopting Kubernetes. Phan believes it will become a very prevalent use case in the future, as users begin to adopt more Kubernetes workloads and look to secure those workloads within namespaces.

CloudCasa has partnered with the Clastix to use their Capsule module and provide namespace-as-a-service, which allows for tenancies to be created within the cluster. It is the ability to segregate that cluster even further and users will only have access to specific namespaces within that cluster.

CloudCasa also brings in its core strength and makes it easy to back up, migrate, and recover namespaces and pods within Kubernetes. That ease could provide some malicious actor the ability to come in and back up an application and then restore it to an entirely separate cluster. Through its own role-based access control, CloudCasa filters those namespaces down to their own component levels and ensures that the user who tried to perform a backup or recovery of the pod or namespace within the cluster actually has access to that namespace.

This integration with Clastix and Capsule provides a granular level of focus. This add-on component basically mirrors the rules and permissions back to CloudCasa and CloudCasa, which does the rest in terms of filtering out those namespaces that users should only see.

This is beneficial for companies who are growing their Kubernetes infrastructure but consolidating applications into one large cluster with many worker nodes.

It requires some setup of the additional pod and installation of the Clastix Capsule module to the cluster so this only affects the Kubernetes cluster administrator and data protection administrator. No change to end-user experience, workflows, infrastructure, or how packs are defined and restored.

The end user has no knowledge of the fact that the namespaces are being filtered. They just see what they see, they can back up what they can back up, and they can restore what they can restore.

CloudCasa integrates natively with the big three cloud providers (Amazon, Microsoft, and Google) to perform discovery and actually build clusters with the click of a button and do full-stack recovery. It collects the underlying metadata, interrogates the cluster, interrogates the actual cloud APIs, what type of back-end storage, what storage classes are made available to that cluster, etc.