Set permissions
Manage server access permissions for users and groups in Alpacon.
Permission model
Alpacon permissions work at two levels:
1. User roles (Workspace level)
| Role | Permissions |
|---|---|
| User | Access assigned servers, edit own profile |
| Staff | Manage users/groups, some workspace settings |
| Superuser | All permissions, full workspace control |
2. Server access permissions (Group-based)
- Assign groups to servers
- All group members can access the server
- Users can belong to multiple groups
Role-based access control (RBAC)
Workspace-level permissions (user roles described above) are managed through RBAC. Built-in RBAC roles correspond to the user role levels, while server access remains group-based. You can also create custom roles for fine-grained permission control.
Built-in roles
Built-in roles map to the user role levels and are automatically assigned:
| Role | Auto-assigned when | Permissions |
|---|---|---|
| member | Default for all users | Access assigned servers, edit own profile |
| admin | User is set to Staff | Manage users/groups, some workspace settings |
| superuser | User is set to Superuser | All permissions, full workspace control |
Built-in roles are automatically assigned and managed by the system.
Custom roles
Create custom roles to define fine-grained permissions tailored to your organization’s needs. Custom roles support two scope levels:
- Global scope: The permission applies to all objects of the resource type
- Object scope: The permission is limited to specific resource types and objects
RBAC permissions
Permissions follow the resource:action format (e.g., server:read, server:write). Assign permissions to roles, then assign roles to users or groups.
Permission inheritance is additive—a user’s effective permissions are the union of all permissions from all assigned roles, including roles inherited through group membership.
To manage roles (Superuser only), go to Workspace settings > Roles.
Set user roles
How to change:
- Select user in IAM > Users
- Click Edit
- Change Role
- Click Save
Required permission: Staff or Superuser
Details: Manage users
Configure server access
Access control via groups
Step 1: Create groups
Step 2: Add users to groups
Step 3: Assign groups to servers
Set individual server permissions
- Select server in Servers page
- Click Edit
- Select Assigned groups
- Click Save
All members of selected groups can access the server.
Feature permissions
Websh (Terminal)
Terminal access to servers assigned to group:
- Login as IAM username
- sudo access available
WebFTP (File management)
File upload/download to servers assigned to group:
- Access user home directory
- Access other directories based on permissions
MFA required actions
Configure MFA for these actions in workspace settings:
- Use Websh with sudo privilege
- Use WebFTP with sudo privilege
- Execute deploy shell
Configure: Workspace settings - Authentication
Permission examples
Example 1: Development team server access
Group: developers
Members: user1 (User), user2 (User), user3 (Staff)
Servers: dev-server-01, dev-server-02
Assigned groups: developers
Result: user1, user2, user3 all access both servers
Example 2: Production server restriction
Group: senior-engineers
Members: user3 (Staff), user4 (Superuser)
Server: prod-server-01
Assigned groups: senior-engineers
Result: Only user3, user4 access production server
Permission inheritance
Multiple group membership:
- If user belongs to groups A and B
- Can access all servers assigned to A and B
Roles and groups:
- Superuser (RBAC
superuser) members access all servers without group assignment - Staff (RBAC
admin) members access only servers assigned to their groups
Role inheritance through groups:
- When a role is assigned to a group, all members of that group inherit the role’s permissions
- A user’s effective permissions are the union of all directly assigned roles and group-inherited roles
Security best practices
Principle of least privilege:
- Grant minimum required permissions
- Regularly review and adjust permissions
Use groups:
- Manage permissions via groups rather than individual users
- Separate groups by environment, project
Limit Superusers:
- Keep Superuser role to minimum
- Grant only to trusted administrators
Audit logs
All permission changes are logged:
- Who changed permissions and when
- Which user/group permissions were changed