Skip to main content
Version: 1.19.x

Access Control

Concepts

ReductStore provides straightforward access management based on token authentication and permissions.

Token Authentication

ReductStore uses token-based authentication to secure the HTTP API. A client must send a valid token in the Authorization header in order to access it. A ReductStore instance must have an initial token to enable authentication and access management. The initial token is configured using the RS_API_TOKEN environment variable and has full access permissions.

Tokens are identified by name and have a set of permissions. The token value (secret) is generated by the server and is returned only when the token is created or rotated. Store it securely; it cannot be retrieved later.

If you need to change a token's permissions, create a new token. If you only need to replace the secret value (for example, after an accidental leak), rotate the token value without changing the token name or permissions. See Rotate a Token for the HTTP API.

info

If you don't need access control, you can disable token authentication by leaving RS_API_TOKEN unset.

Permissions and Access Control

Each token has a set of permissions that define what actions can be performed with the token:

  • full_access: Allows a client to perform any action on the API without any restrictions.

  • read: Allows a client to read data from specific buckets. The list of buckets that can be accessed for reading is defined when the token is created.

  • write: Allows a client to write data to specific buckets, which includes adding new entries or deleting existing ones. The list of buckets that can be accessed for writing is defined when the token is created.

The table below shows the list of operations that can be performed for different permissions:

OperationAnonymousNo permissionsReadWriteFull Access
Alive check
Server Status
List Buckets
Get Bucket
Create Bucket
Update Bucket Settings
Rename Bucket
Remove Bucket
Read Data
Update Data
Write Data
Rename Entry
Remove Entry
Manage Tokens
Manage Replication Tasks
Access Audit Log
note

Anonymous refers to clients that don't send an access token in the Authorization header.

Managing Tokens

Here you will find examples of how to create, browse, retrieve, and delete access tokens using the ReductStore SDKs, REST API, CLI and Web Console.

Note that all the examples are written for a local ReductStore instance available at http://127.0.0.1:8383 with the API token my-token.

For more information on setting up a local ReductStore instance, see the Getting Started guide.

Creating a Token

An access token can be created using the SDKs, CLI client, Web Console, or REST API. The token name must be unique within the store, and a client must have full access permission. You can also provision a token using environment variables. See the examples below:

reduct-cli alias add local -L http://localhost:8383 -t "my-token"
reduct-cli token create local/new-token --read-bucket "example-bucket" --write-bucket "example-bucket"
info

The token value is generated when the token is created and is only available at that time.

Browsing Tokens

You can list all the access tokens available in the store using the SDKs, CLI client, Web Console, or REST API. The client must have full access permission. See the examples below:

reduct-cli alias add local -L http://localhost:8383 -t "my-token"
reduct-cli token ls local
reduct-cli token show local/init-token

Removing a Token

You can remove an access token using the SDKs, CLI client, Web Console, or REST API. The token name must exist in the store, and a client must have full access permission. Refer to the following examples:

reduct-cli alias add local -L http://localhost:8383 -t "my-token"
reduct-cli token rm local/token-to-remove --yes

Audit Log

ReductStore provides an audit log that records HTTP API requests, including successful and failed requests. The audit log is stored in a separate bucket and can be accessed using the standard API.

The audit bucket $audit has the following structure:

$audit
|-- <instance-name>
|-- <token-name>
|-- <UNIX-timestamp>-<JSON record>

Audit log records contain aggregated information about API requests, grouped by endpoint and time interval. Each record includes:

  • Request timestamp
  • Client IP address
  • HTTP method and path
  • Response HTTP status code
  • Error message (if the request failed)
  • Call count for the endpoint
  • Total duration of the requests (seconds)

Example:

{
"timestamp": 1775270571819933,
"instance": "reductstore",
"token_name": "init-token",
"method": "POST",
"path": "/api/v1/io/ros_data/write",
"status": 200,
"message": "",
"client_ip": "10.100.99.1",
"call_count": 762,
"duration": 59.03624846999997
}

Audit logging is controlled by the RS_AUDIT_ENABLED environment variable. If RS_AUDIT_ENABLED is unset, audit defaults to true when RS_API_TOKEN is set, otherwise false. Setting RS_AUDIT_ENABLED explicitly overrides that default.

Read-only Replica Behavior

Read-only replicas do not have write access. Instead, they forward audit logs to a primary or secondary instance.

To enable auditing on a read-only replica, configure:

  • RS_PRIMARY_URL (required)
  • RS_SECONDARY_URL (optional, for failover)
info

To access the audit log, the relevant token must include exact permissions for the $audit bucket, either for reading or writing (wildcards do not apply to system buckets).

info

Zenoh API operations are not currently recorded in the audit log (you will not see Zenoh calls in $audit).