Role-Based Access Control - rizset Docs

Role-Based Access Control (RBAC) in Virex allows you to define exactly who can do what across your organization. Enterprise plans include advanced RBAC features like custom roles, approval workflows, and IP restrictions.

Permission Model

Virex uses a hierarchical permission model:

Organization
├── Organization-level permissions
│   ├── Billing
│   ├── SSO configuration
│   └── Member management
│
├── Team-level permissions
│   ├── Team settings
│   └── Team membership
│
└── Project-level permissions
    ├── Deployments
    ├── Environment variables
    ├── Domains
    └── Logs

Permissions can be granted at any level and cascade down.

Built-in Roles

Virex includes four built-in roles:

Role	Description
Owner	Full control, including billing and organization deletion
Admin	Manage teams, projects, and members
Developer	Deploy and manage project resources
Viewer	Read-only access

See Team Collaboration for the full permission matrix.

Custom Roles

Enterprise plans can create custom roles tailored to your organization:

Creating a Custom Role

Go to Settings → Roles → Create Role
Name your role (e.g., “QA Engineer”, “Release Manager”)
Select permissions from the available list
Save the role

Example: QA Engineer Role

{
  "name": "QA Engineer",
  "description": "Can deploy to staging and view production",
  "permissions": [
    "projects:read",
    "deployments:read",
    "deployments:create:preview",
    "deployments:create:staging",
    "logs:read",
    "analytics:read"
  ]
}

This role can:

View all projects
Create preview and staging deployments
View logs and analytics

This role cannot:

Deploy to production
Modify environment variables
Manage domains

Example: Release Manager Role

{
  "name": "Release Manager",
  "description": "Can promote deployments to production",
  "permissions": [
    "projects:read",
    "deployments:read",
    "deployments:promote:production",
    "deployments:rollback",
    "logs:read",
    "analytics:read",
    "notifications:manage"
  ]
}

Permission Reference

Organization Permissions

Permission	Description
`org:read`	View organization settings
`org:update`	Modify organization settings
`org:delete`	Delete the organization
`billing:read`	View billing information
`billing:manage`	Manage subscription and payment
`members:read`	View organization members
`members:invite`	Invite new members
`members:remove`	Remove members
`members:update-role`	Change member roles
`sso:manage`	Configure SSO settings
`audit:read`	View audit logs

Project Permissions

Permission	Description
`projects:read`	View project details
`projects:create`	Create new projects
`projects:update`	Modify project settings
`projects:delete`	Delete projects
`deployments:read`	View deployments
`deployments:create:preview`	Create preview deployments
`deployments:create:staging`	Deploy to staging
`deployments:create:production`	Deploy to production
`deployments:promote:production`	Promote to production
`deployments:rollback`	Roll back deployments
`env:read`	View environment variables
`env:update`	Modify environment variables
`domains:read`	View domain configuration
`domains:manage`	Add/remove domains
`logs:read`	View application logs
`analytics:read`	View analytics data

Environment-Specific Permissions

Restrict actions to specific environments:

{
  "name": "Staging Developer",
  "permissions": [
    "deployments:create:preview",
    "deployments:create:staging",
    "env:update:preview",
    "env:update:staging"
  ],
  "restrictions": {
    "environments": ["preview", "staging"]
  }
}

This user can deploy to preview and staging but not production.

Approval Workflows

Require approval for sensitive actions:

Configuring Approval Workflows

Go to Settings → Security → Approval Workflows
Click Create Workflow
Configure the workflow:

{
  "name": "Production Deployment Approval",
  "trigger": "deployments:create:production",
  "approvers": {
    "type": "role",
    "roles": ["admin", "release-manager"],
    "required": 1
  },
  "timeout": "4h",
  "autoReject": true
}

Approval Flow

Developer initiates production deployment
Deployment enters “Pending Approval” state
Approvers receive notification
Approver reviews and approves/rejects
If approved, deployment proceeds
If rejected or timeout, deployment is cancelled

Approval via CLI

# Request deployment (enters pending state)
virex deploy --production

# Approver approves
virex approve deployment-abc123

# Or rejects with reason
virex reject deployment-abc123 --reason "Missing changelog"

Approval via Slack

If Slack integration is enabled, approvers can approve directly from Slack:

🚀 Deployment Approval Request

Project: my-app
Environment: production
Requested by: developer@example.com
Commit: abc1234 - "Add new feature"

[Approve] [Reject] [View Details]

IP Restrictions

Limit access based on IP address:

Organization-Wide IP Allowlist

{
  "ipAllowlist": {
    "enabled": true,
    "addresses": [
      "203.0.113.0/24",
      "198.51.100.50"
    ],
    "enforceFor": ["dashboard", "api", "cli"]
  }
}

Project-Specific Restrictions

{
  "project": "sensitive-app",
  "ipAllowlist": {
    "production": ["203.0.113.0/24"],
    "staging": ["0.0.0.0/0"]
  }
}

Bypass for CI/CD

Allow CI/CD systems to bypass IP restrictions:

# Create a token with IP bypass
virex tokens create --name "GitHub Actions" --bypass-ip

Time-Based Access

Grant temporary elevated access:

# Grant admin access for 4 hours
virex access grant user@example.com --role admin --duration 4h --reason "Production incident"

Time-based access:

Automatically expires after the specified duration
Is logged in the audit trail
Can be revoked early if needed

Audit Trail

All RBAC changes are logged:

virex audit-log --filter rbac

TIMESTAMP            USER                ACTION                  DETAILS
2024-01-15 10:30    admin@example.com   role.create             "QA Engineer"
2024-01-15 10:25    admin@example.com   member.role-change      john@... → developer
2024-01-15 09:00    system              access.expire           temp admin access

Best Practices

Principle of least privilege — Start with minimal permissions and add as needed
Use custom roles — Create roles that match your team structure
Require approval for production — Add a human checkpoint for critical deployments
Enable IP restrictions — Limit access to known networks
Review permissions regularly — Audit who has access to what
Use time-based access — Grant temporary elevated access instead of permanent

Troubleshooting

”Permission denied” errors

Check the user’s effective permissions:

virex access check user@example.com --action deployments:create:production

Approval workflow not triggering

Verify the workflow is enabled and matches the action:

virex workflows list
virex workflows test production-approval --action deployments:create:production

IP restriction blocking legitimate access

Check if the IP is in the allowlist:

virex ip check 203.0.113.50

Add the IP if needed:

virex ip add 203.0.113.50 --reason "New office IP"