!! BREAKING CHANGES !!

• Older Loft CLI versions are incompatible with Loft backends >= v2.0.0. Newer Loft CLI versions are also incompatible with older Loft backends < v2.0.0.
• Access Keys that use scopes either need to be recreated or the scope has to be deleted first and then readded.

Deprecation of Accounts, ClusterAccountTemplates & Security Templates

We felt the account system to give users or team access to a cluster was too complicated and error prone due to the account concept that each user needed an additional account for each cluster in order to access it. Especially cluster account templates were difficult to understand and cumbersome to assign to new users or teams.

Instead of having accounts and cluster account templates for each user and team, you can now create a cluster access object which defines access for multiple users or teams across one or more clusters at once. This makes it easier to define and reuse access for multiple users without the need of an extra resource like cluster account templates. You just define which user, team or user that is part of a team should have access to which cluster within a single object.

We deprecated templates and template instances for a new concept called space constraints, which allows you to define resources that should get deployed into a space as well as enforced space metadata and permissions in a single object. This makes it a lot easier than defining multiple separate templates that are then assigned to accounts. Instead you define a space constraints object and assign it to a cluster access object and those space constraints are applied automatically for new spaces. For spaces that were already created, space constraints can be switched, deleted or applied later on and changes to space constraints can be synced to the spaces that use the space constraints object. Only a single space constraints object can be applied to a space.

Loft still supports Accounts, Cluster Account Templates, Templates (Instances) and migrates those automatically.

🚀 App Parameters & Improvements 🚀

We greatly improved apps in Loft. It is now possible to define parameters for apps that will be prompted to the user. You are able to define parameters that are required, can be selected from a set of options or many other types. These parameters can be defined in the apps view and are then displayed upon space, virtual cluster or app creation. Parameters also work if a user is creating a space through the Loft CLI and will be prompted there. You can also fill the parameters automatically by using the Loft CLI with a parameters file.

There is now also a new app type called 'Bash App' that allows you to define a bash script that deploys your application instead of pure Kubernetes manifests or a helm chart. Loft will spin up a pod in the target cluster, space or virtual cluster that will execute this bash script. This allows you to install more complex applications or setup custom environments. This new type will be deployed internally as a helm chart and can be managed like any other app.

Loft will now also show the app Readme and more app information than before.

🚀 Sleep Mode Schedule 🚀

It is now possible to define schedules for automatic wakeup or sleeping of spaces or virtual clusters. This can be either configured in the space template, space constraints or space itself. This allows you to put a space to sleep or wake it up at certain times automatically. We also greatly improved the sleep mode display, which now shows a lot more information than before and allows you to see the last activity within the space as well as projected sleeping times based on the sleep mode configuration.

🚀 Activity 🚀

Auditing is now enabled by default in Loft and activity of Loft users or teams is shown in spaces, clusters, virtual clusters or the audit view. This allows you to track exactly what your users or teams are doing in the management instance or any of the connected clusters or virtual clusters. These logs are by default written to a local sqlite database, but can be either persisted with a persistent volume or written to an external MySQL database. Like before, audit logs can be also streamed to the console or with a new option propagated to a sidecar container that will stream the audit logs.

🚀 Cluster & Management Roles 🚀

We added views for cluster roles that define permissions for users or teams within connected clusters or spaces. These roles can now be managed globally across multiple clusters and are then synced to actual Kubernetes cluster roles. Such cluster roles include for example Space Admin, vcluster Admin, Cluster Admin etc. In addition to roles that define access to connected clusters, there are now also management roles that define permissions for users or teams inside the management instance, like apps or cluster creator, which makes it easier to manage those roles in the management instance.

🚀 Display names and descriptions 🚀

One limiting factor of self-service was name collision of management resource objects, such as apps, shared secrets, clusters etc. In order to overcome this problem and allow users to actually change names of already created objects, we added display names and descriptions to all objects. The Kubernetes name now acts as an ID, but is usually not shown in the Loft UI or CLI at all, which makes it easier for teams and users to create their own objects in Loft.

📦 Other Changes 📦

• Added button to open a terminal to pod within the Loft UI
• Logs are now followed in the Loft UI and searchable
• New yaml editor where managedFields and status sections are folded automatically
• Many tables are now refreshing automatically to show status updates or to remove deleted entries
• Loft will now execute space, virtual cluster or app instantiations as well as some other actions in a small container. These actions are called tasks and output is now streamed to the Loft UI instead of executed within the Loft container. Old task logs can be viewed in the Audit > Tasks view
• Added descriptions to most tables in Loft UI
• New apply manifests button to apply any manifest to either the management instance or a connected cluster
• Improved virtual clusters view that now shows if the virtual cluster is unavailable
• Simplified shared secrets view
• New cli command loft reset password to easily reset forgotten or changed password
• Loft will now deploy some example resources upon installation such as example space templates, virtual cluster templates and apps
• Improved Users > Assigned Cluster Roles view
• Greatly improved loft start to be easier to use and more stable
• New restore license key button in the Loft UI
• Fixed several problems with user impersonation in virtual clusters and connected clusters
• Improved sso flow if user loses access to the backing identity provider
• Spaces now have a reference to the Loft user or team instead of account
• Spaces do not have an ownerreference anymore and are not automatically deleted if a user or team is deleted or loses access to the cluster