Skip to main content
Version: Next

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 System Events
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. Audit log records are stored in the $system bucket under the audit/<instance>/<token-name> entry. For example, audit records for token init-token on instance reductstore are stored in $system/audit/reductstore/init-token.

API audit logs are written as api_call system events. The stored JSON record contains these fields:

FieldDescription
timestampEvent timestamp in Unix microseconds.
instanceReductStore instance name that emitted the audit record.
statusHTTP response status code for the aggregated API calls.
messageError message for failed calls, or an empty string on success.
token_nameToken name used for the API calls.
methodHTTP method.
pathHTTP API path.
client_ipClient IP address, or null when the client IP is unavailable.
call_countNumber of matching API calls aggregated into this record.
durationTotal duration in seconds for the aggregated API calls.

The record also has a status label with the same value as the status field, so you can filter audit logs by result code. Consecutive API calls with the same instance, token, method, path, status, message, and client IP are aggregated and flushed when the aggregation window becomes idle or reaches its time cap.

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_SYSTEM_EVENTS_ENABLED environment variable and enabled by 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 $system 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 $system/audit).