Skip to content

Conversation

@nfebe
Copy link
Contributor

@nfebe nfebe commented Jan 26, 2026

Implement role-based access control system with three roles:

  • admin: Full access to all deployments and user management
  • operator: Manage assigned deployments only
  • viewer: Read-only access to assigned deployments

Key features:

  • SQLite auth database at .flatrun/auth.db
  • User management with bcrypt password hashing
  • API key generation with SHA-256 hashing
  • Per-deployment access levels (read/write/admin)
  • JWT tokens with user/session claims
  • Permission-based middleware for route protection
  • Backwards compatible with legacy config API keys

New endpoints:

  • /api/users - User CRUD operations
  • /api/apikeys - API key management
  • /api/users/:id/deployments - Deployment access control

Implement role-based access control system with three roles:
- admin: Full access to all deployments and user management
- operator: Manage assigned deployments only
- viewer: Read-only access to assigned deployments

Key features:
- SQLite auth database at .flatrun/auth.db
- User management with bcrypt password hashing
- API key generation with SHA-256 hashing
- Per-deployment access levels (read/write/admin)
- JWT tokens with user/session claims
- Permission-based middleware for route protection
- Backwards compatible with legacy config API keys

New endpoints:
- /api/users - User CRUD operations
- /api/apikeys - API key management
- /api/users/:id/deployments - Deployment access control

Signed-off-by: nfebe <fenn25.fn@gmail.com>
@sourceant
Copy link

sourceant bot commented Jan 26, 2026

Code Review Summary

This pull request introduces a comprehensive and robust authentication and authorization system to the Flatrun agent. It replaces a basic token-based system with a full-fledged Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) model, including user management, dynamic API key generation with granular permissions, persistent sessions, and deployment-specific access controls. This is a critical upgrade that significantly enhances the security, manageability, and scalability of the agent's API.

🚀 Key Improvements

  • Implemented full user CRUD operations and user-specific authentication.
  • Introduced dynamic API key generation, management, and revocation with configurable roles, permissions, and deployment scopes.
  • Established persistent sessions for JWTs, allowing for immediate session revocation.
  • Developed granular permission checks (RequirePermission and RequireDeploymentAccess) enforced via Gin middleware across almost all API endpoints.
  • Designed a robust ActorContext to encapsulate authenticated user/API key details, simplifying authorization logic.
  • Added extensive unit tests for all new authentication and authorization components, ensuring reliability and security.

💡 Minor Suggestions

  • Ensure API key expiration time is clearly communicated to API users.
  • Consider using structured logging for warnings and errors in the internal/auth package for better observability.

Copy link

@sourceant sourceant bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review complete. See the overview comment for a summary.

Copy link

@sourceant sourceant bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review complete. See the overview comment for a summary.

Add per-route permission enforcement for containers, images,
volumes, databases, infrastructure, scheduler, system, dns,
registries, templates, and traffic (33 new permission constants).
Routes previously only required authentication.

Add per-user custom permission overrides stored in the users
table. Update role defaults so admins get all permissions,
operators get read/write, and viewers get read-only.

Filter deployment stats in /api/stats by user access and strip
stats from the public /api/health endpoint to prevent leaking
global deployment counts to unauthorized users.

Signed-off-by: nfebe <fenn25.fn@gmail.com>
@nfebe nfebe force-pushed the feat/api-key-rbac branch from 5ab64e2 to edb65e4 Compare January 28, 2026 21:33
Copy link

@sourceant sourceant bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review complete. No specific code suggestions were generated. See the overview comment for a summary.

@nfebe nfebe merged commit 3efe0ed into main Jan 28, 2026
5 checks passed
@nfebe nfebe deleted the feat/api-key-rbac branch January 28, 2026 21:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants