↪ ./kvs help
KVS - Distributed Key-Value Store
Usage:
kvs [config.yaml] Run in foreground (default: ./config.yaml)
kvs start <config> Start as daemon (.yaml extension optional)
kvs stop <config> Stop daemon (.yaml extension optional)
kvs restart <config> Restart daemon (.yaml extension optional)
kvs status [config] Show status (all instances if no config given)
kvs help Show this help
Examples:
kvs # Run with ./config.yaml in foreground
kvs node1.yaml # Run with node1.yaml in foreground
kvs start node1 # Start node1.yaml as daemon
kvs start node1.yaml # Same as above
kvs stop node1 # Stop node1 daemon
kvs status # Show all running instances
kvs status node1 # Show status of node1
```
↪ ./kvs help
KVS - Distributed Key-Value Store
Usage:
kvs [config.yaml] Run in foreground (default: ./config.yaml)
kvs start <config> Start as daemon (.yaml extension optional)
kvs stop <config> Stop daemon (.yaml extension optional)
kvs restart <config> Restart daemon (.yaml extension optional)
kvs status [config] Show status (all instances if no config given)
kvs help Show this help
Examples:
kvs # Run with ./config.yaml in foreground
kvs node1.yaml # Run with node1.yaml in foreground
kvs start node1 # Start node1.yaml as daemon
kvs start node1.yaml # Same as above
kvs stop node1 # Stop node1 daemon
kvs status # Show all running instances
kvs status node1 # Show status of node1
```
Implemented a comprehensive secure authentication mechanism for inter-node
cluster communication with the following features:
1. Global Cluster Secret (GCS)
- Auto-generated cryptographically secure random secret (256-bit)
- Configurable via YAML config file
- Shared across all cluster nodes for authentication
2. Cluster Authentication Middleware
- Validates X-Cluster-Secret and X-Node-ID headers
- Applied to all cluster endpoints (/members/*, /merkle_tree/*, /kv_range)
- Comprehensive logging of authentication attempts
3. Authenticated HTTP Client
- Custom HTTP client with cluster auth headers
- TLS support with configurable certificate verification
- Protocol-aware (http/https based on TLS settings)
4. Secure Bootstrap Endpoint
- New /auth/cluster-bootstrap endpoint
- Protected by JWT authentication with admin scope
- Allows new nodes to securely obtain cluster secret
5. Updated Cluster Communication
- All gossip protocol requests include auth headers
- All Merkle tree sync requests include auth headers
- All data replication requests include auth headers
6. Configuration
- cluster_secret: Shared secret (auto-generated if not provided)
- cluster_tls_enabled: Enable TLS for inter-node communication
- cluster_tls_cert_file: Path to TLS certificate
- cluster_tls_key_file: Path to TLS private key
- cluster_tls_skip_verify: Skip TLS verification (testing only)
This implementation addresses the security vulnerability of unprotected
cluster endpoints and provides a flexible, secure approach to protecting
internal cluster communication while allowing for automated node bootstrapping.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Updated bootstrap service to use authenticated HTTP client with cluster auth headers
- Made GET /members/ endpoint unprotected for monitoring/inspection purposes
- All other cluster communication endpoints remain protected by cluster auth middleware
This ensures proper cluster formation while maintaining security for inter-node communication.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add API endpoints to manage ResourceMetadata (ownership, groups, permissions)
for KV resources. This enables administrators to configure granular access
control for stored data.
Changes:
- Add GetResourceMetadataResponse and UpdateResourceMetadataRequest types
- Add GetResourceMetadata and SetResourceMetadata methods to AuthService
- Add GET /kv/{path}/metadata endpoint (requires admin:users:read)
- Add PUT /kv/{path}/metadata endpoint (requires admin:users:update)
- Both endpoints protected by JWT authentication
- Metadata routes registered before general KV routes to prevent pattern conflicts
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add systemd-style subcommands for managing KVS instances:
- start <config> - Daemonize and run in background
- stop <config> - Gracefully stop daemon
- restart <config> - Restart daemon
- status [config] - Show status of all or specific instances
Key features:
- PID files stored in ~/.kvs/pids/ (global across all directories)
- Logs stored in ~/.kvs/logs/
- Config names support both 'node1' and 'node1.yaml' formats
- Backward compatible: 'kvs config.yaml' still runs in foreground
- Proper stale PID detection and cleanup
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Update integration_test.sh to use new daemon management commands
instead of manual background processes and PIDs:
- Replace `kvs config.yaml &` with `kvs start config.yaml`
- Replace `kill $pid` with `kvs stop config.yaml`
- Update log file paths to use ~/.kvs/logs/
- Add integration_test/ directory to gitignore
All tests now use clean daemon lifecycle management.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Update README.md and CLAUDE.md to document new process management:
- Add "Process Management" section with daemon commands
- Update all examples to use `./kvs start/stop/status` instead of `&` and `pkill`
- Document global PID/log directories (~/.kvs/)
- Update cluster setup examples
- Update development workflow
- Add daemon package to project structure
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
You are not authorized to merge this pull request.
This pull request can be merged automatically.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Add API endpoints to manage ResourceMetadata (ownership, groups, permissions) for KV resources. This enables administrators to configure granular access control for stored data. Changes: - Add GetResourceMetadataResponse and UpdateResourceMetadataRequest types - Add GetResourceMetadata and SetResourceMetadata methods to AuthService - Add GET /kv/{path}/metadata endpoint (requires admin:users:read) - Add PUT /kv/{path}/metadata endpoint (requires admin:users:update) - Both endpoints protected by JWT authentication - Metadata routes registered before general KV routes to prevent pattern conflicts 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.