Spaces are virtual objects which represent namespaces in a Kubernetes cluster. The advantage of letting engineers work with spaces is that you can give them the permission to list/get/create/delete spaces without having to give them the permission to list/get/create/delete namespaces.
While engineers work with spaces, loft handles the underlying operations on the actual namespaces and enforces the restrictions that admins define for users, e.g. limting the number of spaces/namespaces.
Creating spaces in the UI is easy but to actually use the space, a cluster user needs a valid kube-context which most non-admin users do not have by default. To get a kube-context limited to a certain space, run the following command using the CLI:
How does it work?
To provide access to a space/namespace, loft creates a ServiceAccount and configures RBAC in a way that this ServiceAccount can only access objects within this namespace. Then, loft generates a kube-context using the ServiceAccount token and adds it to the
~/.kube/config file on the user's computer.
No Kube-Context Cleanup
This will not clean up the local kube-context you may have for this space. Only when removing a space using the loft CLI, the local kube-context will also be removed from your
Sometimes it may be useful to give others access to one of your spaces. Because loft's authorization system is based on Kubernetes RBAC, you can simply create a RoleBinding to give other users access. Allowing them to view and edit a namespace and/or resources within this namespace will enable them to see a corresponding space in the UI and also to run
loft use space to configure a kube-context for accessing the space using
helm and other tools.