Loft lets you create an internal Kubernetes offering that enables developers to create isolated namespaces in shared development clusters.
Loft works with all major Kubernetes distributions. Once you connect a cluster, Loft will install a lightweight control plane into the cluster which provides everything you need to create isolated development sandboxes.
Loft lets you build a self-service Kubernetes platform that enables developer teams to create isolated Kubernetes namespaces called Spaces. While creating a Space, Loft takes care of setting up the required RBAC rules, network policies, resource quotas, security policies etc.
Run the connect cluster command and choose the kube-context of the cluster you want to connect.
In the admin UI of Loft, you can create invite links, manage users and set user permissions.
Cluster users can now create spaces whenever they need them, as long as they stay within their limits.
Loft ensures that everyone stays within their limits and no one breaks out of their spaces.
Instead of provisioning separate clusters for developers, DevSpace Cloud allows you to share Kubernetes clusters. After connecting a cluster to Loft, admins can add cluster users and configure their limits. Within these limits, cluster users can now create spaces on-demand whenever they need them.
With Loft, namespace provisioning becomes self-service for developers.
During the 'create space' command, the CLI configures a kube-context for every newly created namespace, so developers can use tools like kubectl and helm.
Every namespace created through Loft is by default completely isolated from the rest of the cluster.
While users interact directly with the Kubernetes clusters, Loft creates and manages the access tokens for cluster users that work within isolated Spaces.
When running a kubectl command in the kube-context of a Space, kubectl will retrieve an auth token from DevSpace which is by default configured as auth plugin for the context.
Loft supports oAuth, so users can sign in with their GitHub account (SASL is coming soon).
Loft sets up service accounts and Role-Based Access Control (RBAC) rules to ensure that cluster users cannot break out of their namespaces.
To ensure that users cannot break out of their Spaces, Loft creates a separate service account for each user of a Space.
By default, Loft sets up RBAC rules that make sure developers cannot run operations outside of their namespaces.
To make sure that developers can work within their namespaces without issues, Loft isolates the network traffic for each Space.
By default, containers in different Spaces cannot communicate with each other unless the cluster admins configures this explicitly.
Loft can automatically provision unique ingress hostnames for developers (if needed). Admins configure which other hostnames can be used by developers and Loft will ensure these rules using hostname validation.
Loft installs Open Policy Agent (OPA) into connected clusters to check every resource that a user creates using kubectl or other tools. This allows DevSpaceCloud to allow, reject or modify resources according to the admission policies defined by the cluster admins.
Loft provides a variety of best-practice admission policies for high security standards.
Loft allows admins to define their own admission checks using custom rules enforced by OPA.
Check the cluster status, install, configure or upgrade cluster services (e.g. ingress controller, cert manager, OPA Gatekeeper etc.) with just a click.
View users, their permissions, their Spaces as well as the utilization of these Spaces.
Create and send invite links to add new users.
Add or remove Spaces for cluster users. View all Spaces of cluster users (including log streaming for all pods). Pause Spaces to reduce cluster cost.
Configure user permissions and Space limits for individual cluster users or groups of them (using bulk operations).
We know that every team has their own compliance rules and security guidelines. Loft is built for customization and provides over 50 different configuration options for restricting cluster access and for limiting users and Spaces. And for additional customization, Loft lets you define admission control rules using Open Policy Agent and even allows you to modify the entire control logic of Loft, which is written in admission control policies as well.
Here are some of the rules which most users might want to use or customize:
Adds annotations to each ingress that is being created.
Restricts the user to a list or pattern of allowed hostnames.
Rejects privileged pods, hostNetwork access and more.
Sets default resource limits for pods without limits and makes sure users do not exceed their resource limits.
Because Loft is involved during the token exchange when a user runs any kubectl command, it knows when users have not been sending any requests for a while. Loft provides a sleep mode option, which pauses namespaces after a certain period of time.
Loft scales down the replica sets within a namespace if it detects that the user has not been working for a while (inactivity detection).
If a Space is paused, the entire configuration is still there, only the replica number is set to 0. If Loft receives the first request again, it resumes the Space by restoring the old number of replicas.
Loft allows you to configure how inactivity will be detected. This can even be configured differently on a per-user or on a per-Space basis.
We host Loft and the Kubernetes clusters for you.
We sponsor free Kubernetes namespaces in our managed clusters, so you can evaluate Loft.
We host Loft and you connect your own clusters to it.
Not sure about connecting your cluster?
For more information about features and pricing, see www.loft.sh.
loft offers the same features as loft but additionally lets you customize everything with Kubernetes CRDs and provides virtual clusters as well as enterprise authentication integrations with GitLab, GitHub, SAML 2.0, LDAP and more.
Do you have any questions about loft / Loft on-premise?
