Roles
User roles define permissions and access levels within the platform.
Role Types
Admin
Full platform access and administrative capabilities
Permissions:
- Manage all users, teams, and roles
- View and modify all resources (apps, workflows, data sources)
- Access platform infrastructure and Kubernetes resources
- Configure billing and cost settings
- Create and enforce governance policies
- View audit logs and compliance reports
- Manage integrations and settings
Use Cases:
- Platform administrators
- IT managers
- DevOps leads
- Security officers
Developer
Create and manage platform resources
Permissions:
- Deploy and manage applications
- Create and execute workflows
- Manage workspaces and projects
- Connect to data sources
- Deploy and manage AI models
- View cost and usage data
- Access own namespace in Kubernetes
Restrictions:
- Cannot manage other users
- Cannot access billing settings
- Cannot modify platform infrastructure
- Cannot view other users' private resources
Use Cases:
- Software engineers
- DevOps engineers
- Data scientists
- ML engineers
App (Viewer)
Read-only access to applications and reports
Permissions:
- View deployed applications
- View workflow execution logs
- Access dashboards and reports
- View documentation
- View own user profile
Restrictions:
- Cannot create or modify any resources
- Cannot deploy applications
- Cannot execute workflows
- Cannot access data sources
- Cannot view cost data
- Cannot access platform infrastructure
Use Cases:
- Business stakeholders
- Product managers
- Auditors
- Report consumers
Permission Matrix
| Feature | Admin | Developer | Viewer |
|---|---|---|---|
| View Applications | Yes | Yes | Yes |
| Deploy Applications | Yes | Yes | No |
| Modify Applications | Yes | Own only | No |
| Delete Applications | Yes | Own only | No |
| Create Workflows | Yes | Yes | No |
| Execute Workflows | Yes | Yes | No |
| View Workflow Logs | Yes | Yes | Yes (shared) |
| Manage Data Sources | Yes | Yes | No |
| Create Projects | Yes | Yes | No |
| Manage Workspaces | Yes | Yes (own) | No |
| Deploy Models | Yes | Yes | No |
| View FinOps | Yes | Yes | No |
| Manage Billing | Yes | No | No |
| Manage Users | Yes | No | No |
| Create Teams | Yes | No | No |
| Governance Policies | Yes | View only | No |
| Platform Access | Yes | Limited | No |
| Audit Logs | Yes | Own only | No |
Role Assignment
Assigning Roles to Users
During User Invitation:
- Click Invite User
- Select role from dropdown
- Send invitation
For Existing Users:
- Go to Settings → Users
- Click user name
- Select new role
- Click Update Role
Role Changes
- Role changes take effect immediately
- User must re-login for some permissions
- Previous access is revoked automatically
- Resources owned by user are not affected
Custom Roles (Enterprise Feature)
Create custom roles with specific permissions:
Creating Custom Role
- Go to Settings → Roles
- Click Create Custom Role
- Enter role name and description
- Select permissions from categories:
- Applications
- Workflows
- Data Sources
- Projects & Workspaces
- Models
- Governance
- Platform
- Users & Teams
- Save custom role
Permission Granularity
Customize permissions at detailed level:
- View: Read-only access
- Create: Can create new resources
- Update: Can modify existing resources
- Delete: Can remove resources
- Execute: Can run workflows/apps
- Share: Can share with other users
Best Practices
Role Assignment Guidelines
- Principle of Least Privilege: Give users minimum permissions needed
- Regular Reviews: Audit user roles quarterly
- Temporary Elevated Access: Use time-limited admin access for temporary needs
- Separation of Duties: Don't give all permissions to one person
Admin Role
- Limit number of admin users
- Require MFA for all admins
- Document why each user needs admin access
- Review admin list monthly
Developer Role
- Default role for technical team members
- Provides balance of access and security
- Can work independently without admin intervention
- Resources are isolated between developers
Viewer Role
- Default role for non-technical stakeholders
- Provides visibility without risk of changes
- Useful for compliance and audit requirements
- Can be expanded to specific apps/dashboards
Role-Based Access Control (RBAC)
How RBAC Works
- User authenticates and logs in
- System retrieves user's role(s)
- Each request checks user's permissions
- Allow or deny based on role permissions
- Audit log records access attempts
Resource Ownership
- Users can always access resources they created
- Ownership can be transferred to another user
- Team resources are accessible to all team members
- Admins can access all resources
Namespace Isolation
For platform/Kubernetes access:
- Each developer gets own namespace
- Developers can only access own namespace
- Admins can access all namespaces
- Service accounts tied to user roles
tip
Start new users as Viewer, upgrade to Developer as they get comfortable, only grant Admin when absolutely necessary.