Radiator Server Documentation — v10.34.1

Management API Privileges

The Radiator HTTP Management API uses a hierarchical privilege system to control access to different operations. Each authenticated user or credential is assigned a privilege level that determines which API endpoints and operations they can access. The detailed information of each API endpoint is available under the API documentation.

The Management API is not designed to be exposed to the internet.

Quick Reference

Privilege LevelIntended ForKey Capabilities
noneHealth checksUnauthenticated health/liveness/readiness endpoints only
monitorMonitoring toolsView statistics, metrics, logs, and runtime status (read-only)
readRead-only usersView logs, operational dashboards, and configuration files (no modifications)
writeConfiguration administratorsManage configuration files, stored data, and server status
allSystem administratorsFull access to management operations: Prefer this over write for administrators.

Privilege Levels

The following privilege levels are available, ordered from least to most permissive:

none

  • Value: none
  • Description: No privileges. The user cannot access any authenticated management API endpoints.
  • Use case: Used as a default value or to explicitly deny access.
  • Note: Some endpoints like /api/v1/health, /live and /ready do not require authentication and can be accessed without credentials.

any

Used only for internal use cases.

  • Value: any
  • Description: Basic authenticated access. Can access endpoints that only require proof of authentication.
  • Use case: Used for endpoints that need to verify the user is authenticated but don't require specific permissions.

monitor

  • Value: monitor
  • Description: Read-only access to monitoring and runtime data. Can view statistics, status, logs, and metrics.
  • Use case: For monitoring systems and users who need to observe server health and performance without making changes.

read

  • Value: read
  • Description: Read access to configuration files and stored data. Includes all Monitor privileges plus ability to read configuration files.
  • Use case: For users who need to inspect server configuration files but should not modify them.

install

Used only for internal use cases.

  • Value: install
  • Description: Reserved for internal installation operations.

write

  • Value: write
  • Description: Read and write access to configuration files and managed data.
  • Use case: For administrators who need to update textual configuration and deploy it through the configuration file API.

all

  • Value: all
  • Description: Represents all possible privileges (maximum privilege level).
  • Use case: Currently equivalent to Write. This is recommended as the access method for administrators over write.

Updating configuration

Runtime configuration objects are not created, updated, or deleted through resource-specific API endpoints. Update the textual configuration on disk or through the /api/v1/configuration file APIs, then deploy the pending configuration. Operational endpoints such as backend file reload, dictionary reload, server reload, cache data operations, and logging configuration remain available where a full configuration deployment is not required.

Privilege Hierarchy

The privileges are ordered hierarchically:

none (0) < any (1) < monitor (2) < read (3) < install (4) < write (5) < all (255)

When checking authorization, if an endpoint requires a specific privilege level, any equal or higher privilege will be accepted. For example:

  • An endpoint requiring read accepts users with read, install, write, or all privileges
  • An endpoint requiring monitor accepts users with monitor, read, install, write, or all privileges