JWT Access Permissions

AI Tools

This article outlines the access permissions and API capabilities for two types of JWT tokens, based on the Lightbits RBAC configuration:

  • system_jwt: Associated with the "system" project and cluster-admin role. This role has full system-wide access, including cluster management, infrastructure control, security administration, and cross-project operations.

  • default_admin_jwt: Associated with the "default" project and admin role. This role is limited to the "default" project only, with no cluster management capabilities.

The article includes detailed permission tables, API call examples, and security considerations to help you understand when and how to use each JWT type.

Note

The system_jwt role has significantly broader privileges and should be used sparingly for system administration tasks, while the default admin_jwt role is suitable for day-to-day project management within the default project.

System-Wide Resources (system_jwt Only)

The following resources are exclusively accessible to system_jwt:

Cluster Management

  • clusterConfigs: get, update, list

  • featureFlags: get, enable, disable, list

  • versions: get

  • clusters: get

  • clusterInfos: get

Infrastructure Management

  • servers: create, get, list, delete, enable, disable, upgrade

  • nvmeDevices: get, list, update, add, manage

  • nodes: get, list, replace

  • hosts: get, list

  • adminEndpoints: create, delete, get, list, update

Security and Authentication

  • encryptions: enable, manage, get

  • authentications: enable, disable

  • idpConfigurations: create, delete, get, update, list

  • idpClientConfs: create, delete, get, update, list

  • authMapEntrys: create, delete, get, update, list

  • inBandAuths: enable, disable

Cross-Project Access

  • projects:* (all projects): create, update, delete, get, list

  • credentials:* (all projects): create, delete, get, list

  • volumes:* (all projects): create, delete, get, list, update, rollback

  • snapshots:* (all projects): create, delete, get, list

  • resourcePolicys:* (all projects): create, update, delete, get, list

  • qosPolicys:* (all projects): create, update, delete, get, list

  • roles:* (all projects): get, list

  • events:* (all projects): list

  • trustedHosts:* (all projects): create, delete, get, list, update

  • hostSecrets:* (all projects): manage, get

System Operations

  • logs: fetch

  • nles: manage

Project-Scoped Resources (Both JWTs)

Both JWT types can access these resources, but with different scopes:

Resource

system_jwt Access

default_admin_jwt Access

projects

All projects (projects:*)

Default project only (projects:default)

credentials

All projects (credentials:*)

Default project only (credentials:default)

volumes

All projects (volumes:*)

Default project only (volumes:default)

snapshots

All projects (snapshots:*)

Default project only (snapshots:default)

resourcePolicys

All projects (resourcePolicys:*)

Default project only (resourcePolicys:default)

qosPolicys

All projects (qosPolicys:*)

Default project only (qosPolicys:default) - READ ONLY

roles

All projects (roles:*)

Default project only (roles:default)

events

All projects (events:*)

Default project only (events:default)

trustedHosts

All projects (trustedHosts:*)

Default project only (trustedHosts:default)

Both JWT types have read-only access to:

  • versions: get

  • clusterInfos: get

  • nodes: get, list

Key Differences

system_jwt Advantages:

  1. Full cluster administration - Can manage servers, nodes, hosts, and cluster-wide settings.

  2. Security management - Can configure authentication, encryption, and IDP settings.

  3. Cross-project access - Can manage resources across all projects.

  4. Infrastructure control - Can manage NVMe devices, admin endpoints, and system logs.

  5. Project lifecycle - Can create, delete, and manage projects themselves.

default_admin_jwt Limitations:

  1. Project-scoped only - Limited to "default" project resources.

  2. No cluster management - Cannot access cluster-wide configuration or infrastructure.

  3. No security administration - Cannot manage authentication or encryption settings.

  4. Read-only QoS policies - Can view but not modify QoS policies.

  5. No project creation - Cannot create or manage other projects.

API Call Examples

system_jwt Exclusive Calls:

# Cluster management GET /api/clusters PUT /api/clusterConfigs/{id} POST /api/servers # Cross-project operations GET /api/projects POST /api/projects/{project-id}/volumes DELETE /api/projects/{other-project}/snapshots/{id} # Security configuration POST /api/idpConfigurations PUT /api/encryptions/enable

default_admin_jwt Calls:

# Default project operations only GET /api/projects/default POST /api/projects/default/volumes GET /api/projects/default/credentials PUT /api/projects/default/resourcePolicys/{id} # Read-only cluster info GET /api/versions GET /api/nodes

Rejected Calls for default_admin_jwt:

# These would return 403 Forbidden GET /api/clusters POST /api/servers GET /api/projects/other-project/volumes PUT /api/clusterConfigs/{id} POST /api/idpConfigurations

Security Considerations

  • system_jwt should be used sparingly and only for system administration tasks.

  • default_admin_jwt provides sufficient permissions for most day-to-day project management activities.

  • The principle of least privilege suggests using default_admin_jwt unless system-wide access is specifically required.

  • Consider implementing additional project-specific admin JWTs for multi-tenant environments.


On This Page