CAUTION: Reset of kiosk Cluster Roles
Because of the permission rework (see below), Loft will reset the following cluster roles in a connected cluster automatically:
- loft-cluster-space-default
- loft-cluster-extra-space-admin-rules
- loft-cluster-authenticated
If you made changes to these cluster roles, please backup these changes and reapply them as soon as Loft was upgraded.
🚀 kiosk & direct cluster endpoint is now loft-agent
From this version onwards, Loft will deploy Loft agent instead of kiosk into connected clusters. Loft agent bundles kiosk and loft specific functionality into a single pod, which allows us to keep the footprint and complexity of Loft low. If you already have kiosk installed, Loft will automatically migrate the current kiosk installation to Loft agent.
Loft agent is also able to function as direct cluster endpoint, which means there is no separate chart or installation needed anymore for this functionality.
🚀 Permission Rework & Self-Service Clusters, Users, Teams etc.
Each management Loft CRD (such as Users, Teams, Clusters etc.) now has a new property access that allows you to specify which Users or Teams can access the resource. This makes it much easier to define who is able to access what in Loft.
This also allows certain Users or Teams to create new resources such as secrets, clusters, apps, other teams or other users by themself and automatically get access to those without needing to touch any Kubernetes RBAC ClusterRoles or ClusterRoleBindings.
In addition, we added several predefined cluster roles for users and teams, such as cluster creator, cluster admin, apps creator etc. that can be easily assigned through the Loft UI.
🚀 User Impersonation
You are now able to impersonate users through the Loft UI. This is an easy way to debug or explore Loft as another user without actually having to log in as that user. Only users or teams that have the appropriate impersonation rights are allowed to impersonate other users.
🚀 Team Access Keys
You can now create access keys for teams and use them for the Loft CLI as login credentials (loft login ... --access-key TEAM_ACCESS_KEY). This allows you to manage access more broadly and independently of users.
🚀 Access Key Scopes
Access keys for users and teams can now be scoped to certain actions, such as accessing a single cluster, namespace within a cluster or access to a virtual cluster. This can be configured through the Loft UI in Profile > Access Keys, Users > Access Keys or Teams > Access Keys.
🚀 Apps
Apps can now be configured through a new app CRD and managed through the Loft UI. An app can either target an existing Helm chart or be custom defined Kubernetes manifests. These manifests can also include helm syntax and are deployed as helm releases, so you'll get version control for these apps out of the box as well. Furthermore, apps can be shown as predefined for certain users or teams in one of the apps views in Clusters > Overview, Spaces > Apps or Virtual Clusters > apps.
🚀 Space & Virtual Cluster Templates
You are now able to define space or virtual cluster templates, that define how a certain space or virtual cluster should get deployed. In each template you can also define what apps should get automatically deployed on creation which makes it possible to create environment templates for certain use cases.
You can also define default space and virtual cluster templates for connected clusters.
Other changes
- api: user & teams access and memberships are now cleaned up automatically on deletion
- api: virtual cluster persistent volume claims are now cleaned up automatically on deletion
- api: added support for Kubernetes v1.22.0
- api: updated vcluster version to v0.4.0
- api: cluster account templates can now specify single clusters instead of a cluster label selector
- ui: new access to virtual cluster space section to modify virtual cluster access more easily
- ui: you can now manage the access keys of all users via the Users view
- ui: new apps view in virtual clusters
- ui: apps can now be rolled back
- ui: default space and virtual cluster templates can now be defined in the cluster edit drawer
- ui: virtual cluster values do not have to include the vcluster image or service CIDR anymore and this will be filled in automatically by Loft
- ui: improved the responsiveness of the virtual clusters view
- cli: improved output in pipelines
- cli: new flag
--templateforloft create vclusterandloft create spaceto specify a template to use