Security guides

rConfig holds device credentials and the full running configuration of every device it manages, so its security controls sit in several layers: who can sign in, what they can see, where device secrets live, how stored data is protected, and how the server itself is locked down. This page explains how those layers fit together and the trade-offs at each one. The step-by-step procedures stay in the main docs, starting with the security hardening guide.

The layers at a glance

Layer	Question it answers	Main controls
Authentication	Who is this user?	Local accounts, LDAP, RADIUS, SSO (SAML 2.0 and OAuth)
Authorisation	What can they see and do?	Roles, per-entity permissions, device, snippet and tag scoping
Device credentials	Where do device secrets come from?	Local credentials, credential sets, key vaults
Data at rest	What if storage or a backup leaks?	System encryption key, config file encryption
Data on screen	What if the wrong person sees a config?	Config obfuscation
Platform	What if a process on the server is abused?	Worker privilege, Redis authentication
Transport	What if traffic is intercepted?	HTTPS, database TLS, LDAPS, HTTPS to vaults

rConfig can authenticate users locally, against a directory over LDAP, against a RADIUS server, or through an identity provider with SSO. They differ in how accounts are created, how roles are assigned, and what happens when the external service is down.

	LDAP	RADIUS	SSO
Directories or providers	Active Directory, FreeIPA	Any RADIUS server	Microsoft Entra ID, Okta, Google Workspace, Shibboleth, generic SAML 2.0
Account creation	Automatic on first login, for members of the authorised group	Automatic on first login, with a default role	Created on first login, then approved by an admin by default
Roles from the external source	Yes, from directory groups (V8.4.0+)	No, roles are assigned in rConfig	Yes for SAML2 and Shibboleth (V8.3.3+), not for the Microsoft, Okta or Google OAuth providers

rConfig tries LDAP first, then RADIUS, then local passwords. Enabling both LDAP and RADIUS works, but a failed sign-in then waits for each to give up in turn, which is roughly 27 seconds with default timeouts.

Plan for the external service being down. With LDAP, rConfig falls back to the synchronised password, but only for users who logged in successfully while password sync was on. RADIUS users never get a usable local password, so they cannot sign in at all during an outage. Keep at least one administrator with a local password stored outside rConfig.

Existing accounts are not linked by username. An account that existed before RADIUS was turned on is not picked up automatically, because matching on username alone would let anyone who can authenticate to RADIUS take over a local administrator of the same name. Linking is an explicit per-user switch.

Role mapping: the source becomes authoritative

LDAP role mapping and SAML role mapping both replace a user’s roles at every login. Any role set by hand in Users is overwritten, and local users are unaffected. The two differ in how they match:

LDAP includes nested groups and never matches on role names, so a directory group called Admin grants nothing unless it is listed on a role. A user whose groups match nothing gets the default role. A plain group name matches a group of that name in any OU, so use the full distinguished name for admin roles.
SAML falls back to the role name, and a user whose groups match no active role is refused.

Pick mapping when the directory or identity provider is where access is really decided. Leave it off when rConfig admins need to adjust roles by hand.

Authorisation: roles and scope

Roles are named sets of permissions. Each permission is one of View, Create, Read, Update or Delete on an entity such as Device, Config or DeviceCredentials. Roles are additive: a user with several roles gets the union of their permissions. Admin, User and Guest ship as system roles, and role templates give starting points for custom ones.

Permissions say what a user can do. Scoping says which objects they can do it to:

Device and snippet roles limit a role to the devices or snippets it is assigned to. Admin bypasses this.
Tag-scoped roles limit a role to devices carrying given tags, plus their backups and change history. This suits a team or auditor who should see one slice of the estate.
Credential set visibility (V8.2.2+) hides a credential set from roles not listed on it. It is visibility only: a device that uses a restricted set still backs up and receives snippets.

Device credentials: where secrets live

Type	Stored where	Fits
Local credentials	On the device record in rConfig	Labs and one-off devices
Credential sets	Once in rConfig, encrypted at rest, shared by many devices	Most estates
Vault credential sets	In your key vault, read at connection time	Teams whose vault is already the source of truth and rotates passwords there

With a vault, rConfig asks for the secret when it connects, maps the returned keys to username, password and enable password, and discards them when the operation ends. Nothing is cached, so the next backup after a rotation uses the new password. The trade-off is a runtime dependency on the vault: turn a vault off in rConfig and backups for its devices fail, with a message naming the vault, until it is on again.

HashiCorp Vault is verified. Palo Alto Networks Idira (CyberArk) Central Credential Provider and Delinea Secret Server are early access from V8.4.2. From V8.4.2 several vaults can be on at once, with each vault credential set tied to the vault it was created with.

Data at rest and on screen

Three features are easy to confuse. They protect different things:

Feature	Protects	Against	Notes
System encryption key (`APP_KEY`)	Device credentials (always), sessions, and config files when config encryption is on	Database exports, backups or unauthorised database access	Lose the key without a backup and encrypted data cannot be recovered
Config file encryption	Config file content on disk	Compromised storage, decommissioned disks, stolen backups	Metadata stays unencrypted so search and listings keep working. Adds CPU cost on access
Config obfuscation	Secrets inside config text, diffs and API output	Casual exposure to read-only users, screen shares	Masks at render time only. Stored files are unchanged. Chosen roles can see unmasked output

Config encryption and the system key are linked: rotating the key with config encryption on means re-encrypting every stored config, and the docs advise contacting rConfig support first. Back up the .env file that holds the key as carefully as the database.

Platform hardening

Two health checks cover risks inside the server itself:

Worker privilege. Horizon runs every queued job, including device connections, and the scheduler starts all scheduled work. If either runs as root, a flaw in any job runs with full control of the server. From V8.4.1, Horizon, the scheduler and the SNMP trap receiver all run as the web server user.
Redis authentication. Redis carries the job queue, cache and sessions, so anything that can write to it can make a worker run code. Binding Redis to loopback is not enough on its own, because any local process can reach it. A password is the control.

Transport

Link	What to know
Browser and API to rConfig	New installs serve plain HTTP. From V8.4.1 rConfig reminds admins until `APP_URL` is HTTPS. Self-signed suits internal and air-gapped networks; Let’s Encrypt needs a public domain. In Docker, terminate TLS on a reverse proxy.
rConfig to its database	TLS is available from V8.3.2. It matters when the database is on another host across a network you do not fully trust, and adds little over `localhost` or a socket.
rConfig to LDAP	LDAPS with a private CA in Docker needs the CA mounted into the container so trust survives recreates and upgrades.
rConfig to a key vault	Use HTTPS, and paste an internal CA bundle rather than turning verification off.