Radiator Server Documentation — v10.34.0

Management API privilege levels

Explain the different privilege levels of the Management API and UI

Table of Contents
  • Management API Privileges
  • Quick Reference
  • Privilege Levels
  • none
  • any
  • monitor
  • read
  • install
  • write
  • all
  • Updating configuration
  • Privilege Hierarchy

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
Navigation
  • Application log message index

  • Architecture Overview

  • Backend Load Balancing

  • Basic Installation

  • Built-in Environment Variables

  • Byte Size Units

  • Certificate Revocation Lists

  • Comparison Operators

  • Configuration Editor

  • Configuration Import and Export

  • Containers

  • Cron and interval timers

  • Data Types

  • Duration Units

  • Environment Variables

  • Execution Context

  • Execution Pipelines

  • Filters

  • Getting a Radiator License

  • Health check /live and /ready

  • High Availability and Load Balancing

  • High availability identifiers

  • HTTP Basic Authentication

  • Introduction

  • Linux systemd support

  • Local AAA Backends

  • Logging

  • Management API privilege levels

  • Namespaces

  • Password Hashing

  • Password Rehashing During Login

  • Probabilistic Sampling

  • Prometheus and OpenMetrics scraping

  • PROXY Protocol Support

  • Radiator server health and boot up logic

  • Radiator sizing

  • Radiator software releases

  • Radiator software security and dependency compliance

  • RadiatorDB

  • RadiatorDB Backup

  • RadiatorDB CLI

  • RadiatorDB Installation

  • RadiatorDB PostgreSQL 10k TPS example

  • RadiatorDB REST API

  • RadiatorDB sizing

  • Rate Limiting

  • Rate Limiting Algorithms

  • Reverse Dynamic Authorization

  • Service Level Objective

  • TACACS+ Authentication, Authorization, and Accounting

  • Template Rendering CLI

  • Timestamps

  • Tools radiator-client

  • TOTP/HOTP Authentication

  • What is Radiator?

  • YubiKey Authentication

  • YubiKey Context Variables