Highly Automated and Secured Multi-Tenancy Using SUSE CaaS Platform 4

I notice that when it comes to using a XaaS solution, clients and solution architects are typically concerned about multi-tenancy. This post attempts to decipher why that is and how SUSE CaaS Platform helps make this a reality.

What is XaaS?

XaaS is anything as a service; it is a generic grouping of anything that is designed and delivered as a service – so this means an IaaS, CaaS, PaaS and SaaS are all XaaS as they are designed and delivering Infrastructure, containers, platform and software as a service respectively. The main requirements for any XaaS solution are that it must support serving multiple clients concurrently and deliver:

• Isolation and security for each client
• A service as pay-as- you-go model
• Auto-scaling
• Self-healing capabilities
• High SLA for operation activities

What is a tenant, and what is meant by multi-tenancy?

A tenant, represents a space dedicated for a client. A client can be an organization, a department, an enterprise, or a single user, who is receiving the service delivery from the XaaS solution. A tenant is defined by the dedicated set of resources and services running for the tenant client, it is also defined by the data owned by the tenant client and the eligible roles and users that can access service/data and all configurations set by the tenant client (owner).

Multi-tenancy is the ability to support different tenants in a secured and isolated manner. There are two ways of implementing multi-tenancy:

• Physically isolated tenant, in which the tenant is built on isolated and dedicated runtime and hardware; there are no shared resources with other tenants – even on the level of hardware and physical network.
• Virtually isolated tenant, in which tenants are built on shared hardware and may or may not share runtime.

Usually in XaaS, both approaches are offered to enable the flexibility of service offering.

Why is multi-tenancy a big concern?

Multi-tenancy is a big concern for security reasons. Usually clients gravitate toward  a virtually isolated tenant because of the cost prohibitive aspects of a physically isolated tenant. The problem with this is typically is how they can secure their apps, data and APIs. In another words, how to avoid hacking on their applications and data – especially if runtime is shared with other apps.

How does SUSE CaaS Platform support the concept of XaaS and multi-tenancy?

SUSE CaaS Platform is a Container-as-a-Service (CaaS) offering. It can be considered a XaaS solution as it delivers all the main requirements of XaaS and is both a PaaS and a CaaS.

A lot of new additions to SUSE CaaS Platform 4 are related to multi-tenancy, so before we go any further, let’s check out some of the new features in SUSE CaaS Platform 4 that catch my eye:

• SUSE CaaS Platform 4 removed architecture blockers that were in SUSE CaaS Platform 3 , like Velum, HAProxy, & embedded OpenLDAP
• By utilizing kubeadm for both bootstapping clusters and joining and removing nodes to the clusters, SUSE CaaS Platform 4 utilizes industry standards.
• SUSE CaaS Platform 4 also introduces CRI-O its default container runtime. To me, the use of CRI-O represents a success in being simpler and cleaner with tools like podman and buildah, and in being standard and secured.
• SUSE CaaS Platform 4 is the first enterprise Kubernetes platform to utilize Cilium in place of flannel. This is  a great step toward multi-tenancy as I will explain in the rest of my blog.
• In tech preview, SUSE CaaS Platform 4 enables SUSE Stratos as the SUSE Application Delivery console. SUSE Application Delivery console is a great console that can be used by developers and operators in development, troubleshooting, monitoring, and managing both workloads and K8s clusters (AKS, EKS, SUSE CaaS Platform, GKE or upstream K8s).
• SUSE CaaS Platform 4 introduces the Skuba CLI tool which is a simple, clean and nice command line tool that can be used to provision and operate multiple SUSE CaaS Platform clusters
• SUSE CaaS Platform 4 more closely follows K8s upstream movements and design principles. As a solution architect, this is really one of the points that I value in SUSE CaaS Platform 4
• SUSE CaaS Platform 4 enables  ease of K8s version upgrades, without disrupting the running workloads.
• SUSE CaaS Platform 4 is currently running K8s version 1.15, which is higher than EKS and AKS by the time of the release. I truly believe this is a good step forward for SUSE CaaS Platform as it demonstrates that SUSE is brave enough to keep up with Kubernetes advancements.
• SUSE CaaS Platform 4 has containerized its control plane along with parts of the worker services which make SUSE CaaS Platform  of a much smaller footprint, faster and more granular
• Finally, SUSE CaaS Platform 4 manages upgrades and patches in a simpler way than its predecessor. SUSE CaaS Platform 4 now  has a service to inquire and apply patches and updates in conjunction with Kured (which is k8s standard) to manage restarts of the nodes.

In SUSE CaaS Platform 4, the combination of K8s, Cilium and CRI-O enables multitenancy. Let’s assume that we have a customer who wants to use SUSE CaaS Platform 4 to build and deliver a Container-as-a-Service solution to their end clients. The below list depicts the customer key requirements:

• A virtually isolated tenant for each end client.
• Enable and control the communication between some of the tenants (clients) – like building a trust relationship.
• Automate the provisioning of the tenant. They also want to control and govern the tenant as well as having the ability to report on it.
• Automate the provisioning of pipeline to enable devops capabilities for each client.
• Services and tenant activities governance, monitoring and reporting capabilities.

SUSE CaaS Platform 4 can deliver the set of demands of the customer in this use case using a few simple configurations in a clean and automated fashion. Let’s check out the main design principles used in the target solution:

• For each client/tenant , one or more namespaces are created.
• A tenant admin user is then created and given all privileges on all tenant’s namespaces created in the previous step (e.g. deploy pod, create secrets, …)
• A default Cilium policy is created to enable communication between all pods and services running in any of the client namespaces
• A space is then created in the Image/Chart repos and in the configuration management with administrative security privilege for the tenant admin user. In the target solution GITLab is used as the Configuration Management tool, Chart Museum is used as the charts repo while Harbor is used as the container Images repo.
• For each tenant/client, a pipeline for the development/deployment process is created using Concourse-CI.
• In SUSE CaaS Platform 4, tenant admin user can request adding a user to the tenant which automatically creates assigns the proper privileges to them on the tenant namespaces and resources (configuration management repo and chart and image repos)
• The tenant admin user is able to define a set of trusted tenants or assign/define a set of trusted workloads using labels to communicate with his tenant
• Prometheus, Grafana together with SUSE Stratos are used to implement the monitoring and logging of SUSE CaaS Platform 4 and all running workloads.

The following diagrams depicts a sample to the tenant provisioning process and the development process which can be implemented using SUSE CaaS Platform 4:

The following figure depicts the high level solution used in implementing the discussed usecase.

SUSE CaaS Platform 4 enables secured multi-tenancy using Cilium and CRI-O. It also highly enables automation via the standard and secured implemented architecture of SUSE CaaS Platform 4 and its ecosystem. SUSE CaaS Platform 4 also enables auto scaling and the  building of an End to End (E2E) PaaS solution offering for secured containers and devops as a service pipelines.

Conclusion:

In the world XaaS, multi-tenancy is a big concern for security reasons. SUSE CaaS Platform is a XaaS as it delivers all XaaS main requirements and is considered as a CaaS and a PaaS. SUSE CaaS Platform 4 enables and supports delivering multi-tenancy in a secured manner using CRI-O and Cilium. SUSE CaaS Platform 4 can be used to deliver a highly automated and secured multi-tenant CaaS with the help with a well defined ecosystem, such as concourse-ci, GIT-Lab, Chart Museum and Harbor.