Permission management guide

Effective permission management is key to achieving both security and collaboration efficiency. You can establish a systematic permission management strategy using Alpacon’s IAM (Identity and Access Management) features.

For more details, see IAM overview.

Role-based permission system

Alpacon provides three roles to manage user permissions hierarchically.

Permissions by role

User (regular user)

  • Permission scope: Access and use of assigned resources
  • Key features:
    • Belong to groups and become eligible to request access to their servers
    • Request work sessions to run terminal, file, editor, and command tools
    • Manage their own profile and settings
  • Applicable to: General team members, developers, operators

Staff (administrator)

  • Permission scope: User permissions + user and group management
  • Key features:
    • Invite users and manage accounts
    • Create groups and manage members
    • Register servers and change settings
    • Manage some workspace settings
  • Applicable to: Team leaders, project managers

Superuser (super administrator)

  • Permission scope: Staff permissions + highest system-wide administrative privileges
  • Key features:
    • Manage all users and groups
    • Manage all workspace settings
    • Approve work session requests
    • Manage billing and subscriptions
    • Access audit logs
  • Applicable to: System administrators, CTO, security officers

Setting a user to Staff automatically assigns the RBAC admin role, and setting a user to Superuser automatically assigns the superuser role.

For more details, see User management.

Custom roles

In addition to built-in roles, you can create custom roles to define fine-grained permissions tailored to your organization:

  • Project-scoped admin: Full management access limited to specific server groups
  • Read-only auditor: View-only access for compliance and monitoring
  • Deploy operator: Permission to execute deploy commands without full admin access

Custom roles support object scopes, allowing you to limit permissions to specific resources rather than granting workspace-wide access. For managing roles (Superuser only), see Workspace settings > Roles.

Custom role best practices

  • Clear naming: Use descriptive names that reflect the role’s purpose (e.g., prod-deploy-operator, staging-readonly)
  • Narrow scope: Prefer object-scoped permissions over global permissions
  • Composition over inheritance: Combine multiple focused roles rather than creating broad roles
  • Document purpose: Add descriptions to roles explaining their intended use
  • Regular review: Audit custom roles and their assignments periodically

Group-based permission management

Using groups allows you to efficiently manage permissions by logically separating users and servers. Group membership grants eligibility to request access to a group’s servers—the access itself is exercised through an approved work session, covered below.

Group design strategies

1. Team-based group structure

Create groups based on your organization’s team structure.

Example:

  • Backend Team: Backend server access
  • Frontend Team: Frontend and build server access
  • DevOps Team: All infrastructure server access
  • Data Team: Database and analytics server access

2. Environment-based group structure

Separate access permissions based on server environments.

Example:

  • Production Group: Production servers (restricted access)
  • Staging Group: Staging servers
  • Development Group: Development servers (open access)

3. Project-based group structure

Manage servers and personnel by project.

Example:

  • Project A Team: Project A related servers
  • Project B Team: Project B related servers
  • Shared Infrastructure: Common infrastructure servers

For more details, see Groups overview.

Group roles

Within a group, each member holds a role that determines what they can do with the group itself:

  • Owner: Full control of the group
  • Manager: Manage the group and its members
  • Member: Eligible to request access to the group’s servers

For more details, see Assign users to groups.

Interactive access through work sessions

Interactive access to servers—terminal, file transfer, the code editor, command execution, and port forwarding—runs through work sessions. Group membership makes a user eligible to request access; a work session governs what actually runs, on which servers, and for how long.

For the full walkthrough, see Work sessions overview.

How a session grants access

  1. Request: The user selects the target servers, the features they need (Web terminal, File transfer, Command, Code editor, Tunnel), a purpose, and a duration.
  2. Approval: A user with the Superuser role reviews the request and approves or rejects it. A Superuser’s own sessions activate automatically.
  3. Active: Once approved, the session is time-bound—the user runs only the approved features, only on the approved servers, until it expires.
  4. Audit: Every session and the activity inside it is recorded.

Scoping access with groups

Design groups so that only the right people are eligible to request sessions to sensitive servers.

Protecting production servers

Group: Production-Access
- Members: Senior Engineers, DevOps Team
- Servers: Production Web Server, Production DB Server

Only members of this group are eligible to request sessions to production servers

Separating development environments

Group: Dev-Team-A
- Members: Team A developers
- Servers: Team A dev server, shared dev DB

Group: Dev-Team-B
- Members: Team B developers
- Servers: Team B dev server, shared dev DB

Each team can request sessions only to its own development servers

For more details, see Server connection.

Work session best practices

  • Scope requests narrowly: Request only the servers and features the task needs, not a broad grant
  • Prefer time-boxed sessions: Choose the shortest duration that fits the task over long-lived access
  • Review before approving: As a Superuser, check the purpose, servers, and features on each request before approving
  • Watch session history: Review approved and completed sessions regularly for unusual scope or timing

Automation access with tokens

Automation—CI/CD pipelines, scripts, and integrations—uses API or service tokens instead of work sessions. Tokens bypass session approval, so restrict each one tightly:

  • Scope the token: Grant only the resources and actions the automation needs
  • Limit servers: Use server allowlists (Server ACL) so a token can reach only the servers it must
  • Set expiry and rotation: Give tokens an expiration and rotate them regularly

For more details, see API access tokens and Service tokens.

Principle of least privilege

Enhance security by granting users only the minimum permissions necessary to perform their tasks.

Implementation methods

1. Limit use of default group

  • Only register servers requiring common access in the Alpacon users default group
  • Separate sensitive servers into dedicated groups
  • New users start in the default group, with additional groups assigned as needed

2. Minimize roles

  • Most users should start with the User role
  • Grant Staff role only to those performing actual administrative tasks
  • Restrict Superuser role to a minimal number of people (2-3)

3. Regular permission reviews

  • Review user permissions and group memberships quarterly
  • Immediately revoke permissions for departed employees or role changes
  • Deactivate long-unused accounts

Activity monitoring and auditing

Track user activities to prevent security incidents and support post-incident analysis. Every work session—who requested it, what was approved, and the activity inside it—is recorded alongside these logs.

Monitoring targets

User activity logs

You can check each user’s activity history:

  • Login time and IP address
  • Server access history
  • Configuration change history
  • Task success/failure status

For more details, see User detail - Activity tab.

Server access history

You can check the history of users and groups that accessed each server:

  • Access records by system user
  • Access records by system group

For more details, see Server detail - Access tab.

Command execution history

You can check the record of commands executed on servers:

  • Execution time and user
  • Command content and results

For more details, see Server detail - Activity tab.

Permission management checklist

A checklist for effective permission management.

Initial setup

  • Design and create groups matching your organizational structure
  • Assign appropriate servers to each group
  • Determine roles (User/Staff/Superuser) for each user
  • Place users in appropriate groups

Operations phase

  • Grant minimum permissions when registering new users
  • Assign new servers only to appropriate groups
  • Make only restricted groups eligible for sensitive servers
  • Minimize server list in default group (Alpacon users)
  • Review the purpose and scope of work session requests before approving

Regular reviews

  • Review user permissions quarterly (roles and group memberships)
  • Review approved and completed work sessions for unusual scope or timing
  • Immediately deactivate or delete accounts of departed employees
  • Check and take action on long-unused accounts
  • Review appropriateness of group structures
  • Identify abnormal behavior patterns in activity logs

Security enhancements

  • Make only Senior level and above eligible for production servers
  • Limit Superuser role to 2-3 people
  • Prefer time-boxed work sessions over broad standing grants
  • Consider dual approval process for critical operations
  • Provide regular security training and share guidelines
Last updated: