Implement Multi-tenant Authentication & Authorization

[sameehj]

Currently, ebpf-mcp uses a single system-wide bearer token stored in /etc/ebpf-mcp-token. This approach has several limitations for production deployments:

No multi-tenancy: All clients share the same token and permissions
No role separation: Can't differentiate between read-only vs full-control users
No audit trail: Can't track which user/agent performed which actions
Token rotation challenges: Replacing the token affects all clients simultaneously
Enterprise adoption blocker: Organizations need granular access controls

Solution
Implement a proper authentication and authorization system with:

JWT-based authentication with scoped permissions
Role-based access control (RBAC) with predefined roles:

observer: Read-only access (info, inspect_state, stream_events, trace_errors)
operator: Add program loading (load_program)
admin: Full access including attach operations (attach_program)

Per-user resource quotas and rate limiting
Audit logging for all privileged operations

Implementation Plan
Phase 1: JWT Authentication

Replace single token with JWT-based auth
Add token validation middleware to all tool endpoints
Implement token refresh mechanism
Add CLI commands for token management: ebpf-mcp auth login, ebpf-mcp auth whoami

Phase 2: RBAC System

Define permission schemas for each tool
Implement role validation in tool handlers
Add role assignment management (config file or API)
Update tool schemas to include permission requirements

Phase 3: Resource Controls

Add per-user resource quotas (max programs, max streams, etc.)
Implement rate limiting per user/role
Add resource usage tracking and reporting

Phase 4: Audit & Monitoring

Add structured audit logging for all operations
Include user context in all log entries
Add metrics for auth failures, permission denials
Create audit log analysis tools

Technical Details
JWT Token Structure:
json{
"sub": "user123",
"role": "operator",
"permissions": ["info", "inspect_state", "load_program"],
"quotas": {
"max_programs": 10,
"max_streams": 5,
"requests_per_minute": 60
},
"exp": 1735689600
}
Configuration Example:
yamlauth:
jwt_secret: "${JWT_SECRET}"
token_expiry: "24h"

roles:
observer:
permissions: ["info", "inspect_state", "stream_events", "trace_errors"]
quotas:
requests_per_minute: 30
max_concurrent_streams: 2

operator:
permissions: ["info", "inspect_state", "stream_events", "trace_errors", "load_program"]
quotas:
requests_per_minute: 60
max_programs: 10
max_concurrent_streams: 5

admin:
permissions: ["*"]
quotas:
requests_per_minute: 120
max_programs: 50
max_concurrent_streams: 10

users:

• username: "ai-agent-1"
  role: "observer"
• username: "dev-team"
  role: "operator"
• username: "sre-admin"
  role: "admin"
  Testing Requirements

Unit tests for JWT validation and role checking
Integration tests for multi-user scenarios
Security tests for privilege escalation attempts
Performance tests with multiple concurrent authenticated users

Documentation Updates

Update installation guide with auth setup
Add authentication configuration examples
Document role permissions and quotas
Create user management howto guide

Backward Compatibility

Provide migration path from single-token to JWT
Support both auth methods during transition period
Clear deprecation timeline for single-token approach

This was generated by claude and needs review with our current implementation