Files

ryyst 3aff0ab5ef feat: implement issue #3 - autogenerated root account for initial setup

- Add HasUsers() method to AuthService to check for existing users
- Add setupRootAccount() logic that only triggers when:
  - No users exist in database AND no seed nodes are configured
  - AuthEnabled is true (respects feature toggle)
- Create root user with UUID, admin group, and comprehensive scopes
- Generate 24-hour JWT token with full administrative permissions
- Display token prominently on console for initial setup
- Prevent duplicate root account creation on subsequent starts
- Skip root account creation in cluster mode (with seed nodes)

Root account includes all administrative scopes:
- admin:users:*, admin:groups:*, admin:tokens:*
- Standard read/write/delete permissions

This resolves the bootstrap problem for authentication-enabled deployments
and provides secure initial access for administrative operations.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

2025-09-21 00:06:31 +03:00

2.4 KiB

Raw Blame History

Issue #3: Implement Autogenerated Root Account for Initial Setup

Status: ✅ COMPLETED
Author: MrKalzu
Created: 2025-09-12 22:17:12 +03:00
Repository: ryyst/kalzu-value-store#3

Problem Statement

The KVS server lacks a mechanism to create an initial administrative user when starting with an empty database and no seed nodes. This makes it impossible to interact with authentication-protected endpoints during initial setup.

Current Challenge

Empty database + no seed nodes = no way to authenticate
No existing users means no way to create API tokens
Authentication-protected endpoints become inaccessible
Manual database seeding required for initial setup

Proposed Solution

1. Detection Logic

Detect empty database condition
Verify no seed nodes are configured
Only trigger on initial startup with empty state

2. Root Account Generation

Create a default "root" user with:

Server-generated UUID
Hashed nickname (e.g., "root")
Assigned to default "admin" group
Full administrative privileges

3. API Token Creation

Generate API token with administrative scopes
Include all necessary permissions for initial setup
Set reasonable expiration time

4. Secure Token Distribution

Securely log the token to console (one-time display)
Persist user and token in BadgerDB
Clear token from memory after logging

Implementation Details

Relevant Code Sections

NewServer function - Add initialization logic
User, Group, APIToken structs - Use existing data structures
Hashing and storage key functions - Leverage existing auth system

Proposed Changes (from MrKalzu's comment)

Added HasUsers() (bool, error) to auth/auth.go
Added "Initial root account setup for empty DB with no seeds" to server/server.go
Diff file attached with implementation details

Security Considerations

Token should be displayed only once during startup
Token should have reasonable expiration
Root account should be clearly identified in logs
Consider forcing password change on first use (future enhancement)

Benefits

Enables zero-configuration initial setup
Provides secure bootstrap process
Eliminates manual database seeding
Supports automated deployment scenarios

Dependencies

This issue blocks Issue #4 (securing administrative endpoints), as it provides the mechanism for initial administrative access.

2.4 KiB Raw Blame History