Skip to main content
Version: 2.0 (Latest)

Managing Cluster Access in Loft

The core feature of Loft is to enable users to get self-service access to Kubernetes and allow them to create isolated namespaces and virtual clusters whenever they need them.

flowchart LR; CLI(Loft CLI / UI) --> Loft kubectl(kubectl, helm, ...) --> Loft Loft("<img src='/docs/media/loft-logo.svg' width='60' height='30' />") Loft -- uses --> ClusterAccess(Cluster Access) ClusterAccess --> ClusterA(Kubernetes Cluster A) ClusterAccess --> ClusterB(Kubernetes Cluster B) ClusterAccess --> ClusterC(Kubernetes Cluster ...) class Loft loft

Working with Cluster Access

Create Cluster Access For Individual Users
  1. If you are still impersonating, click
  2. Go to the Clusters view using the main menu on the left
  3. Switch to the tab Cluster Access
  4. Click on the button
  5. Use the field Display Name and enter a Name for the cluster access
  6. In the Users & Teams section, make sure the Users tab is selected because we want to give an individual user access to a cluster
  7. Use the field Select Individual Users and select the User(s) you want to create this cluster access for
  8. In the Clusters section, either select All Clusters or the specific cluster that you want to make accessible for the user(s) you selected in the previous step
  9. Click the button at the bottom of the drawer
Single Sign-On + Cluster Access

You can connect a variety of SSO providers to Loft. To automatically give users access to clusters based on their SSO user groups, you can switch to the

Team Members
tab to grant cluster access for each member of a team (e.g. for each member of a group in Active Directory, Okta, SAML, etc.)

Configuration

Metadata

Display Name

JSONPath in ClusterAccess CRD:
 spec.displayName (type: string)

Kubernetes Name

JSONPath in ClusterAccess CRD:
 metadata.name (type: string)

Description

JSONPath in ClusterAccess CRD:
 spec.description (type: string)

Labels

JSONPath in ClusterAccess CRD:
 metadata.labels (type: map[string]string)

Annotations

JSONPath in ClusterAccess CRD:
 metadata.annotations (type: map[string]string)

Users & Teams

Individual Users

JSONPath in ClusterAccess CRD:
 spec.users[].user (type: string)

Users In Teams

JSONPath in ClusterAccess CRD:
 spec.users[].team (type: string)

Teams

JSONPath in ClusterAccess CRD:
 spec.teams (type: string[])

Clusters

JSONPath in ClusterAccess CRD:
 spec.clusters (type: string[])

Enforce Restrictions

Space Constraints

JSONPath in ClusterAccess CRD:
 spec.spaceConstraintsRef (type: string)

Quotas

JSONPath in ClusterAccess CRD:
 spec.quota (type: AccessQuota)

Advanded Options

Priority

JSONPath in ClusterAccess CRD:
 spec.priority (type: integer)

Extra Cluster Roles

JSONPath in ClusterAccess CRD:
 spec.clusterRoles[].name (type: string)

Access To Cluster Access

JSONPath in ClusterAccess CRD:
 spec.access (type: Access[])

CRDs

ClusterAccess

apiVersion
string

APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind
string

Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

object (io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta)

ObjectMeta is metadata that all persisted resources must have, which includes all objects users must create.

object (com.github.loft-sh.api.pkg.apis.management.v1.ClusterAccessSpec)

ClusterAccessSpec holds the specification

object (com.github.loft-sh.api.pkg.apis.management.v1.ClusterAccessStatus)

ClusterAccessStatus holds the status

{
  • "apiVersion": "string",
  • "kind": "string",
  • "metadata": {
    },
  • "spec": {
    },
  • "status": {
    }
}