Implement Autogenerated Root Account for Initial Setup #3

New Issue

MrKalzu · 2025-09-12T22:17:12+03:00

MrKalzu commented

2025-09-12 22:17:12 +03:00

When the KVS server starts for the first time with an empty database and no seed nodes configured, there is currently no mechanism to create an initial administrative user. This makes it impossible to interact with authentication-protected endpoints, like /kv.
Currently the api endpoints to create users and groups are not under the authentication midware. This is bad security practice.

Proposed Solution:
Introduce logic in the server initialization (NewServer function) to detect if the database is empty and if the seed_nodes configuration is empty. If both conditions are met, the server should:

Generate a default "root" user: Create a User entry with a server-generated UUID, a hashed nickname (e.g., "root"), and assign it to a default "admin" group (which should also be created if it doesn't exist).
Generate an API token for the root user: Create a APIToken for this root user with a set of predefined administrative scopes (e.g., "admin", "read", "write", "create", "delete").
Securely log the token: Print the generated root user's UUID and the full API token to the console (stdout/stderr) with a prominent warning that it should be saved securely and is only shown once.
Store the root user and token: Persist the created User and APIToken objects in BadgerDB.

This ensures that a new, uninitialized instance of the KVS server can be brought up with a functional administrative account, allowing immediate secure interaction with the API.

Relevant Code Sections:

NewServer function for initialization logic.
User, Group, APIToken structs.
hashUserNickname, hashGroupName, hashToken functions.
userStorageKey, groupStorageKey, tokenStorageKey functions.
generateJWT, storeAPIToken functions.

When the KVS server starts for the first time with an empty database and no seed nodes configured, there is currently no mechanism to create an initial administrative user. This makes it impossible to interact with authentication-protected endpoints, like /kv. Currently the api endpoints to create users and groups are not under the authentication midware. This is bad security practice. **Proposed Solution:** Introduce logic in the server initialization (`NewServer` function) to detect if the database is empty and if the `seed_nodes` configuration is empty. If both conditions are met, the server should: 1. **Generate a default "root" user:** Create a `User` entry with a server-generated UUID, a hashed nickname (e.g., "root"), and assign it to a default "admin" group (which should also be created if it doesn't exist). 2. **Generate an API token for the root user:** Create a `APIToken` for this root user with a set of predefined administrative scopes (e.g., "admin", "read", "write", "create", "delete"). 3. **Securely log the token:** Print the generated root user's UUID and the full API token to the console (stdout/stderr) with a prominent warning that it should be saved securely and is only shown once. 4. **Store the root user and token:** Persist the created `User` and `APIToken` objects in BadgerDB. This ensures that a new, uninitialized instance of the KVS server can be brought up with a functional administrative account, allowing immediate secure interaction with the API. **Relevant Code Sections:** * `NewServer` function for initialization logic. * `User`, `Group`, `APIToken` structs. * `hashUserNickname`, `hashGroupName`, `hashToken` functions. * `userStorageKey`, `groupStorageKey`, `tokenStorageKey` functions. * `generateJWT`, `storeAPIToken` functions.

MrKalzu referenced this issue

2025-09-12 22:24:20 +03:00

Secure User and Group Management Endpoints with Authentication Middleware #4

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ryyst/kalzu-value-store#3