The cloud transition has been a fast growing market due to its merits as a more elastic, flexible and agile OpEx model that can all be summed up in convenience and ease. In 2020, the Covid-19 pandemic added fuel to the fire, accelerating cloud technology consumption with a shift towards greater dependency on the cloud.
Cloud services provide efficient infrastructure that can be consumed by multiple end users. Those end users can belong to different organizations, companies, industries; the subscribers to the cloud services. Those subscribers are billed separately, have their own view of the infrastructure they’re consuming, access to their own data and are isolated from other tenants.
A tenant may be using a VM, physical machine or a container based application. Each has access to storage they need and there is no correlation between how much each tenant needs (performance, storage, number of cores, …) or how the infrastructure is deployed. This makes the case for disaggregated infrastructure to provide agility and efficiency.
To round out the product and market fit in this case, LightOS 2.1 release introduces the ability to isolate the storage control and data paths with a flexible and scalable multi-tenancy solution that provides the key capabilities, such as
The key to multi-tenancy: Logical Separation of Tenants into “Projects”
A “Project” is a tenant-specific sandbox that will be created for each tenant. LightOS control plane actions of a given tenant are contained within the corresponding Project, limiting both the API-level visibility and the ability to carry out modifications using the LightOS management API.
Strict Authentication (authN) and Authorization (authZ)
Every action in the system, both on behalf of tenants and administrators, is carried out only after the entity requesting it has been authenticated and authorized. LightOS management API servers require a JSON Web Token (JWT) bearer token with every API request.
LightOS Policy Engine introduces the concept of “roles” where each role shall have a list of operations that its grantee shall be entitled to carry out in the system.
The JWT token is cryptographically signed with a private key for which a corresponding public key has been previously “deployed” to the LightOS cluster and every JWT carries a “roles” claim.
LightOS supports three roles, these roles will come predefined with the system:
a. “Administrator” – granted full privileges in the system, including the ability to carry out operations with cluster-wide impact, as well as operations on entities within all projects.
b. “Project Manager” – granted privileges to carry out all operations on entities within a given project.
c. “Project Viewer” – granted privileges to carry-out read-only operations on entities within a given project.
Extending Multi-tenancy into Kubernetes
LightOS multi-tenancy is integrated with Kubernetes through the Lightbits CSI plugin. Tenant JWTs are stored as Kubernetes “secrets” and per-tenant/project Kubernetes StorageClass objects are configured to refer to the corresponding Kubernetes secrets holding the relevant JWTs, ensuring the Lightbits CSI plugin will have access to those JWTs as necessary and will be able to use them to authenticate against the LightOS management API servers.
All this comes with no impact to reliability, availability, scalability while keeping the promise of high performance and low latency. Some enhancements that you should expect to see from us are flexible BW and IOPS allocations that will allow our customers to offer a broad range of service tiers to their end customers based on a single storage infrastructure vs. today’s crude “Low vs. High” performance tiers that are available from most providers.
We are happy to share with you this milestone in LightOS’ continued evolution to meet the ever changing and sometimes unpredictable market needs. Our introduction of LightOS 2.1 is a proof point that NVMe-oF as a storage fabric is maturing probably faster than expected given what is going on in the world.
