Access Control List (ACL)
The Access Control List (ACL) is Rakaard's core security mechanism for controlling who can establish console or terminal sessions with your machine. It determines whether an incoming connection request from another user should be allowed or denied.
Without proper ACL configuration, access may be either unrestricted or unavailable. ACL provides fine-grained control by user, server, and session type.
Core Concepts
Before diving into commands, understand these three building blocks:
Policy
The policy determines the ACL's overall behavior. Only one policy is active at any given time. Rakaard supports three main policies:
- RULES — fine-grained, explicit allow/deny per target
- ALLOWLIST — deny-by-default; only listed targets can connect
- DENYLIST — allow-by-default; only listed targets are blocked
Rules
Rules are used exclusively when the RULES policy is active. Each rule explicitly allows or denies a specific combination of server, target ID, and session type.
Lists
Lists (allow list and deny list) are used by the ALLOWLIST and DENYLIST policies respectively. They contain targets that should either be permitted or blocked.
Switching between policies does not delete saved rules or lists. They remain stored and become active again when their corresponding policy is selected.
The Three Policies Explained
RULES Policy
Under the RULES policy, you define explicit allow/deny rules for each target. Any target without a matching rule is automatically denied.
Best for: Environments where you need precise, per-target control.
Example scenario: Allow user alice-123 to use the console while denying terminal access, and explicitly deny all access to user bob-456.
acl policy rules
ALLOWLIST Policy
Under the ALLOWLIST policy, everyone is denied by default. Only targets you explicitly add to the allow list can connect.
Best for: High-security environments where you trust only a small, known set of users.
Activating ALLOWLIST with an empty list prevents all users from connecting. Add at least one entry before enabling this policy.
acl policy allowlist
DENYLIST Policy
Under the DENYLIST policy, everyone is allowed by default. Only targets you explicitly add to the deny list are blocked.
Best for: Open environments where only specific unauthorized users need to be blocked.
acl policy denylist
Viewing Current ACL State
To see the current policy and all associated rules or list entries, run:
acl show
Or simply:
acl
The output includes:
- The active policy with a short description
- The number of rules or list entries
- A table showing each entry with an index number for reference
acl show has several aliases: acl get, acl list, acl view, acl ls. All produce the same output.
Sample Output
ACL
Policy: RULES
Each rule explicitly allows or denies a target. Unmatched targets are denied.
Entries: 2 (allow 1, deny 1)
Rules (2)
┌───┬────────┬──────────┬───────────┬──────────┐
│ # │ Action │ Type │ Target │ Server │
├───┼────────┼──────────┼───────────┼──────────┤
│ 1 │ allow │ console │ alice-123 │ rakaard │
│ 2 │ deny │ terminal │ bob-456 │ rakaard │
└───┴────────┴──────────┴───────────┴──────────┘
The # column shows the index number you use in edit and remove commands.
Managing Policies
Changing the Active Policy
acl policy <rules|allowlist|denylist>
Examples:
acl policy rules
acl policy allowlist
acl policy denylist
To skip the confirmation prompt (useful in scripts):
acl policy denylist --yes
Accepted Policy Aliases
You can use any of these when specifying a policy:
| You type | Interpreted as |
|---|---|
rules, rule, enable | RULES |
allowlist, allow-list, whitelist | ALLOWLIST |
denylist, deny-list, blocklist | DENYLIST |
Managing Rules (RULES Policy)
Rules are managed under the acl rule command group. They only take effect when the RULES policy is active.
Adding a Rule
You can add a rule three different ways:
Full examples:
acl rule add rakaard alice-123 console allow
acl rule add --server rakaard --target bob-456 --type terminal --deny
acl rule add
Editing a Rule
First, find the rule's index with acl show, then:
acl rule edit <index> [flags]
Only the fields you specify via flags change; everything else stays the same.
Examples:
acl rule edit 3 --target new-user-id
acl rule edit 1 --type terminal
acl rule edit 2 --deny
acl rule edit 2 --allow --server backup-server
Removing a Rule
acl rule remove <index>
The command requests confirmation. To skip confirmation, run:
acl rule remove 3 --yes
acl rule remove also works as acl rule rm, acl rule delete, or acl rule del.
Managing the Allow List (ALLOWLIST Policy)
The allow list is managed under acl allowlist. Entries here only take effect when the ALLOWLIST policy is active.
Adding an Entry
Unlike rules, allowlist entries do not require an allow/deny action; they implicitly allow access.
acl allowlist add <server> <target> <console|terminal>
Examples:
acl allowlist add rakaard alice-123 console
acl allowlist add --server rakaard --target alice-123 --type terminal
acl allowlist add
Editing an Entry
acl allowlist edit <index> [flags]
Example:
acl allowlist edit 1 --target new-alice-id
Removing an Entry
acl allowlist remove <index>
acl allowlist also works as acl allow-list or acl whitelist.
Managing the Deny List (DENYLIST Policy)
The deny list is managed under acl denylist. Entries here only take effect when the DENYLIST policy is active.
Adding an Entry
acl denylist add <server> <target> <console|terminal>
Examples:
acl denylist add rakaard spammer-999 console
acl denylist add --server rakaard --target spammer-999 --type terminal
acl denylist add
Editing and Removing
Same pattern as the allow list:
acl denylist edit <index> [flags]
acl denylist remove <index>
acl denylist also works as acl deny-list, acl blocklist, or acl block-list.
Session Types
Each rule and list entry targets a specific session type:
| Type | Meaning |
|---|---|
console | GUI-based remote desktop sessions (VNC) |
terminal | Text-based shell sessions |
You can have separate rules for the same target — for example, allow console but deny terminal.
Interactive Wizard Walkthrough
When you run any add or edit command without full arguments, Rakaard launches an interactive wizard that asks for missing values:
rakaard> acl rule add
i Interactive wizard — fill in the missing values.
? Server (name/key/id) [rakaard]: rakaard
? Target ID: alice-123
? Type [console] (console/terminal): console
? Action [allow] (allow/deny): allow
OK Added rule: allow console target=alice-123 server=rakaard
Provide all required arguments up front (or use --flags) to bypass the wizard entirely.
Common Workflows
Workflow 1: Restrict access to trusted users
Workflow 2: Allow open access while blocking specific users
Workflow 3: Fine-grained per-user control
Best Practices
- Start with DENYLIST for initial testing when unrestricted access is required.
- Switch to ALLOWLIST or RULES for production or sensitive environments.
- Always run
acl showbefore making changes so you know the current state. - Combine ACL with a password (
password set) for double-layer protection. - Review your ACL periodically to remove stale entries.
Troubleshooting
Command Reference
| Command | Purpose |
|---|---|
acl or acl show | Display current ACL state |
acl policy rules | Activate RULES policy |
acl policy allowlist | Activate ALLOWLIST policy |
acl policy denylist | Activate DENYLIST policy |
acl rule add | Add a rule (RULES policy) |
acl rule edit <index> | Edit a rule |
acl rule remove <index> | Remove a rule |
acl allowlist add | Add entry to allow list |
acl allowlist edit <index> | Edit an allow list entry |
acl allowlist remove <index> | Remove an allow list entry |
acl denylist add | Add entry to deny list |
acl denylist edit <index> | Edit a deny list entry |
acl denylist remove <index> | Remove a deny list entry |