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)

RolePermissions
UserAccess assigned servers, edit own profile
StaffManage users/groups, some workspace settings
SuperuserAll 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:

RoleAuto-assigned whenPermissions
memberDefault for all usersAccess assigned servers, edit own profile
adminUser is set to StaffManage users/groups, some workspace settings
superuserUser is set to SuperuserAll 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:

  1. Select user in IAM > Users
  2. Click Edit
  3. Change Role
  4. 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

  1. Select server in Servers page
  2. Click Edit
  3. Select Assigned groups
  4. 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
Last updated: