Authentication, Authorization, & RBAC
Relevant source files
The following files were used as context for generating this wiki page:
- docker/README.md
- apps/dashboard/src/pages/Onboarding.tsx
- libs/api-client/src/api/api-keys-api.ts
- libs/api-client-ruby/lib/daytona_api_client/models/organization_role.rb
- libs/api-client-ruby/lib/daytona_api_client/models/organization_user.rb
- libs/api-client-ruby/lib/daytona_api_client/models/api_key_list.rb
- libs/sdk-typescript/README.md
Daytona utilizes a multi-layered security architecture combining OpenID Connect (OIDC) for identity management, API Key-based authentication for programmatic access, and a Role-Based Access Control (RBAC) system organized around Organizations. This framework ensures that both human users interacting with the Dashboard and automated agents using the SDKs operate within strictly defined permission boundaries.
The system is designed to support multi-tenancy through Organizations, where users are assigned specific roles and permissions. Access control is enforced at the API level using organizational guards and scoped API keys, providing isolation for sensitive resources like sandboxes and registries.
Identity & Authentication Architecture
Daytona supports authentication via OIDC providers (such as Auth0 or Dex). The architecture distinguishes between user-facing authentication (Single Page Applications) and service-to-service communication (Machine-to-Machine).
OIDC Integration
Authentication for the Dashboard and CLI is managed through OIDC. For local development, Dex acts as the OIDC provider, while production environments typically utilize external providers like Auth0. The configuration requires several key parameters:
- OIDC_CLIENT_ID: The identifier for the application.
- OIDC_ISSUER_BASE_URL: The URL of the identity provider.
- OIDC_AUDIENCE: The target API identifier for which the token is valid.
Sources: docker/README.md:12-19, docker/README.md:139-147
API Key Management
Programmatic access via the SDKs or CLI is authenticated using API keys. These keys are associated with a specific user and can be scoped to specific organization resource permissions.
The diagram above illustrates the lifecycle of an API key from creation to SDK utilization.
Sources: apps/dashboard/src/pages/Onboarding.tsx:189-210, libs/sdk-typescript/README.md:31-45
Role-Based Access Control (RBAC)
Authorization in Daytona is structured around the Organization entity. Permissions are not assigned directly to users but are bundled into roles, which are then assigned to users within the context of an organization.
Organization Roles and Users
Users within an organization are represented by the OrganizationUser model, which links a user ID to an organization ID and defines their primary role (e.g., owner, member).
| Component | Description |
|---|---|
| OrganizationUser | Tracks a user's membership, role, and assigned roles within a specific organization. |
| OrganizationRole | A collection of permissions with a name, description, and an isGlobal flag. |
| Permissions | Granular strings (e.g., read:users, write:sandbox) that authorize specific actions. |
Sources: libs/api-client-ruby/lib/daytona_api_client/models/organization_user.rb:14-25, libs/api-client-ruby/lib/daytona_api_client/models/organization_role.rb:14-25
Permission Scopes
The system defines granular permissions that control access to various subsystems. These are used to validate requests to the API and to restrict the capabilities of generated API keys.
| Permission | Description |
|---|---|
read:workspaces | Read access to user workspaces. |
create:sandbox | Permission to provision new isolated environments. |
read:registries | Access to Docker registry authentication records. |
regenerate-key-pair:users | Ability to rotate SSH key-pairs for users. |
Sources: docker/README.md:113-125, apps/dashboard/src/pages/Onboarding.tsx:50-60
Programmatic Access Security
API Keys serve as the primary authentication mechanism for the Daytona SDKs (Python, TypeScript, Ruby). Security is maintained through masking and expiration policies.
API Key Metadata
When listing or retrieving API keys, the actual value is masked to prevent exposure. The system tracks usage metadata to audit security.
- Masked Value: Only the last few characters of a key are shown in the UI.
- Last Used: Timestamp of the most recent request made with the key.
- Expiration: Optional
expiresAtfield for temporary access.
Sources: libs/api-client-ruby/lib/daytona_api_client/models/api_key_list.rb:14-34, apps/dashboard/src/pages/Onboarding.tsx:162-170
Multi-Tenancy Enforcement
Every API request made with a JWT or API Key can include an X-Daytona-Organization-ID header. This allows the backend to verify that the authenticated entity has sufficient permissions within the specific organization context being accessed.
The flow represents how the API validates the organization context for every request.
Sources: libs/api-client/src/api/api-keys-api.ts:38-50, apps/dashboard/src/pages/Onboarding.tsx:62-75
Security Policies & Vulnerability Management
Daytona maintains a strict security policy regarding sandbox isolation. While users are granted full root access within their sandboxes by design (using user-namespace isolation), any escape to the host or cross-tenant access is considered a critical vulnerability.
The security perimeter includes:
- Sandbox Runtime: Isolation between the sandbox and the runner host.
- Secrets Management: Prevention of secret leakage across sandbox boundaries.
- Authentication: Secure session handling and OIDC token validation.
Sources: SECURITY.md:25-35, SECURITY.md:40-45
Daytona's security architecture provides a robust foundation for running AI-generated code by isolating execution environments and enforcing strict access controls through OIDC and a granular RBAC system.