Service Hardening Guide

This guide provides recommendations for securing a RADKit Service deployment in production environments. It covers password policies, centralized admin authentication via TACACS+, remote user authentication, and integration with external password vaults for device credential management.

Administrator Users 

Password Policy 

RADKit enforces a configurable password policy for both administrators and remote users. The defaults provide a reasonable baseline, but production deployments should strengthen them according to organizational security requirements.

Recommended production settings (in settings.toml):

[service.password_policy]
minimum_length = 14
minimum_lowercase_letters = 1
minimum_uppercase_letters = 1
minimum_digits = 1
minimum_symbols = 1
expiration_days = 90
expiration_warning_days = 14
reuse_password_changes = 24

Password Policy Settings
Setting	Default	Recommendation
`minimum_length`	8	Increase to 14 or more (NIST SP 800-63B recommends at least 8, but longer passwords provide significantly better entropy)
`minimum_symbols`	0	Set to 1 or more to require special characters
`expiration_days`	0 (disabled)	Set to 90 days (or per organizational policy). Set to 0 if using TACACS+ for admin authentication (password rotation is handled externally)
`reuse_password_changes`	12	Increase to 24 to prevent password reuse across a longer history

Login lockout: RADKit automatically locks an account for 60 seconds after 5 consecutive failed login attempts. This is not configurable but provides baseline brute-force protection.

First login password change: Administrators created by the superadmin are forced to change their password on first login. This behavior is always enforced and cannot be disabled.

The Superadmin account 

The superadmin account is the master system account for the RADKit Service. The superadmin password is used to derive the encryption key for the local secrets database.

Warning

Never store the superadmin password in plain-text configuration files, shell history, or version control systems.

It is the very first administrator account created during setup, and is required to perform initial configuration, create other administrator accounts, and manage critical settings. Protect it with the following best practices:

Administrator accounts and RBAC 

RADKit supports Role-Based Access Control for administrators. Apply the principle of least privilege:

Assign the basic-admin role to operators who only need to manage devices and users.
Reserve the sysadmin role for personnel who need full system access (settings, external sources, role management).
The superadmin account should only be used for initial setup and break-glass scenarios — not for day-to-day operations.

Custom roles can be created via the WebUI or Control API to further restrict permissions. See Administrator Role-Based Access Control (RBAC) for details.

TACACS+ Integration 

For production environments, delegate administrator authentication to a centralized TACACS+ server (e.g., Cisco ISE). This provides:

Centralized credential management and password rotation
Audit trail on the AAA server
Integration with enterprise identity providers

Configuration steps:

Create a TACACS+ external source in the WebUI (External Sources tab, superadmin only):
- Name: any identifier except local (which is reserved)
- Host: TACACS+ server IP or hostname
- Port: 49 (default)
- Secret: shared secret (use a strong, unique value)
- Allow administrator login: enabled (adds ADMIN to authenticationTypes)
Configure the TACACS+ server with the following services:
- service=radkit-admin — returns role=<role_name> AV-pair (e.g., role=sysadmin)
- service=radkit-user — returns connection mode AV-pairs for remote user authorization
Set the default admin password source so administrators can log in without a prefix:
```
[service]
admin_password_source = "ISE34"
```
Replace ISE34 with the name of the TACACS+ external source created in step 1.
Administrators log in by entering just their TACACS+ username. Logins can also be explicitly routed using the <external_source_name>#<username> form.

Important

The TACACS+ server is contacted only once during authentication. Role assignments remain active for the session lifetime. Changes on the TACACS+ server take effect only after re-authentication.

Important

Recovery access: when admin_password_source points to a TACACS+ source, all administrator logins — not only the superadmin account — are routed to TACACS+ when no source prefix is given. The reserved prefix local# always routes the login to the local password database, allowing any local admin to log in as local#<username> (for example local#superadmin or local#alice). Keep the local superadmin password in a secure password vault — it is the recovery path if the TACACS+ server is unreachable.

See TACACS+ for a detailed setup guide with ISE configuration examples.

Session Management 

Adapt session lifetimes to limit the window of exposure from stolen session tokens. The defaults are chosen to meet with industry requirements, but can be adapted as needed.

[service.ui]
session_idle_timeout_minutes = 15
session_absolute_timeout_minutes = 480
password_autocomplete = false

Setting	Default	Recommendation
`session_idle_timeout_minutes`	30	Reduce to 15 minutes (or less for high-security environments)
`session_absolute_timeout_minutes`	720 (12h)	Reduce to 480 (8h) or match shift length
`password_autocomplete`	false	Keep disabled (prevents browser from caching credentials)

Remote Users 

Remote users access network devices through the RADKit Service. Harden their access with the controls below.

RBAC Labels 

Enable per-device access control (enabled by default):

[service.rbac]
device_access_control = true

Assign labels to devices and restrict each remote user to only the labels they need. This prevents lateral access to devices outside a user’s scope.

End-to-End Encryption (E2EE)

E2EE is enabled by default and ensures that traffic between the client and service is encrypted end-to-end, even when transiting the RADKit Cloud relay:

[service.e2ee]
require_e2ee = true

Do not disable E2EE in production. If a legacy client does not support E2EE, upgrade the client rather than lowering this setting.

End to End Validation 

RADKit supports two authentication paths for remote users. Both are mutually compatible and can be deployed simultaneously.

Local Token

By default, remote users authenticate with a short-lived access token issued by the RADKit Service. The token is scoped to the user’s identity and allowed connection modes (cloud, direct, direct-sso).

For high-security environments, bind the access token to a specific E2EE session fingerprint so that a stolen token cannot be replayed from a different client:

[service.e2ee]
require_e2ee = true
require_e2ee_session_verification = true

With require_e2ee_session_verification = true, the service rejects connections where the presented token does not match the E2EE fingerprint registered at authentication time.

See End-to-end encryption and session verification for details on E2EE configuration and session verification.

TACACS+ Authentication

Remote users can authenticate via a TACACS+ external source instead of (or in addition to) local credentials. The TACACS+ server validates credentials and returns the authorized connection modes as AV-pairs:

service=radkit-user
cloud=allow
direct=allow

Configuration steps:

Create a TACACS+ external source in the WebUI (External Sources tab, superadmin only).
When creating a remote user, set their authentication source to the TACACS+ external source.
Users log in using the format: <external_source_name>#<username>

Important

Connection mode authorization (cloud, direct, direct-sso) is evaluated at authentication time and cached for the session. Changes on the TACACS+ server take effect only after re-authentication.

See TACACS+ for a full setup guide.

Vaults (HashiCorp Vault, CyberArk)

RADKit stores device credentials in an encrypted local database. For most deployments this is sufficient — the Control API provides efficient credential management and rotation without additional infrastructure. If your organization’s security policy mandates an external credential store, RADKit supports the following integrations.

HashiCorp Vault

Create a HashiCorp Vault external source in the WebUI:
- Base URL: Vault server address (e.g., https://vault.example.com:8200)
- Secret Engine: kv-v2 (recommended)
- Engine Path: mount path (e.g., secret)
- Auth Method: AppRole (recommended for service accounts) or Token
- Verify TLS Certificate: Always enabled in production

Reference secrets in device templates:

terminal:
  password: !external
    name: my-hashicorp-vault
    use: password
    values:
      path: network-devices/router01

Warning

Never disable TLS verification (verify = false) in production. If using a private CA, add the CA certificate to the system trust store or configure the ca_certificate parameter.

CyberArk (CCP and Conjur)

For CyberArk CCP (Central Credential Provider):

Use mutual TLS (client certificate authentication) to authenticate the RADKit Service to the CCP server.
Configure app_id and safe to scope credential access.

For CyberArk Conjur:

Use an API key with minimal privileges scoped to the secrets RADKit needs.
Set verify = true to validate the Conjur server certificate.

General vault recommendations:

Rotate vault credentials (tokens, API keys, AppRole secrets) on a regular schedule.
Use short-lived tokens where possible (HashiCorp Vault AppRole with secret_id_ttl).
Scope vault access to only the secrets RADKit needs — avoid broad read policies.
Enable vault audit logging to track credential access.

Global RADKit Settings 

These settings span the entire service and should be reviewed before production deployment.

Certificate Management 

RADKit automatically renews its cloud identity certificate before expiry. Keep automatic renewal enabled:

[cloud_client]
automatic_certificate_renewal_enabled = true
# Begin renewal attempts this many days before expiry (default: 30)
certificate_renewal_remaining_lifetime = 30

For certificate validity checks, RADKit can use the local OS clock or a cloud-provided time source. Use the OS clock (default) unless you have a specific reason to override it:

[cloud_client]
certificate_validation_time_source = "OS"

Warning

Setting certificate_validation_time_source = "CLOUD" makes certificate validation dependent on a remote service. Keep the OS clock synchronized via NTP to ensure reliable local validation.

System Management 

Network Exposure 

Minimize the attack surface by restricting network listeners:

[service.ui]
# Bind WebUI to localhost if accessed only via reverse proxy or locally
listen_addresses = ["127.0.0.1"]
port_https = 8081

[service.connectivity]
# Disable direct RPC if only cloud connectivity is needed
enable_direct = false

# Or restrict direct RPC to specific interfaces
listen_addresses_direct_rpc = ["10.0.0.5"]
port_direct_rpc = 8181

Firewall recommendations:

Port	Protocol	Direction	Purpose
8081	TCP/HTTPS	Inbound	WebUI and REST API — restrict to admin networks
8181	TCP/HTTPS	Inbound	Direct RPC — restrict to trusted client networks
443	TCP/HTTPS	Outbound	RADKit Cloud (`prod.radkit-cloud.cisco.com`) — TLS 1.3

If the RADKit Service only needs cloud connectivity (no direct RPC), block inbound port 8181 entirely. If WebUI access is only needed from a management VLAN, scope port 8081 accordingly.

TLS Configuration 

WebUI/API TLS certificates:

Replace the default self-signed certificate with a CA-signed certificate using the radkit-service webserver-certificate import command:

❯ radkit-service webserver-certificate import --help
Usage: radkit-service webserver-certificate import [OPTIONS]

Options:
  --certificate PATH             Path to the certificate in PEM format.  [required]
  --private-key PATH             Path to the private key file.  [required]
  --issuer-chain PATH            Path to the issuer chain in PEM format.  [required]
  --private-key-passphrase PATH
  --help                         Show this message and exit.

Warning

The private-key MUST be encrypted. An unencrypted private key will not be accepted by the CLI. If the private key password is not provided, the CLI will prompt for it interactively. This is to ensure that the private key is protected at rest and in transit.

Cloud and device connections:

RADKit enforces TLS 1.3 for cloud connections (TLS_AES_128_GCM_SHA256).
Device connections use TLS 1.2+ with the CSDL-recommended cipher suite by default.
Avoid enabling use_obsolete_ciphers on external source connections unless absolutely required for legacy device compatibility.

OCSP (certificate revocation):

RADKit checks network device certificate revocation via OCSP. The default configuration uses the OCSP stapler — a RADKit Cloud proxy that consolidates outbound OCSP requests to internet-accessible CA responders:

[service.devices.ocsp]
methods = ["STAPLER", "PASS"]

If your devices use certificates issued by an enterprise CA whose OCSP responder is not reachable from the internet, replace STAPLER with DIRECT so that the RADKit Service contacts the responder directly:

[service.devices.ocsp]
methods = ["DIRECT", "PASS"]

PASS is a fallback that allows the connection to proceed if all preceding OCSP methods fail. Remove it to enforce strict revocation checking.

Logging and Auditing 

Enable centralized logging for security monitoring, incident response, and compliance:

[service.logging]
level = "INFO"
format = "JSON"
session_logging = true
session_log_max_age = 90

# Centralized syslog (recommended)
syslog_enabled = true
syslog_host = "siem.example.com"
syslog_port = 514
syslog_json = true

# Cryptographic logging for security audits
cryptographic_logging_enabled = true

Recommendations:

Enable syslog forwarding to a SIEM for real-time alerting on authentication failures, privilege escalation, and configuration changes.
Use JSON format (syslog_json = true) for structured log ingestion.
Set session_log_max_age to at least 90 days to support incident investigations.
Enable cryptographic_logging_enabled to log TLS connection setup/teardown events.
Syslog messages include [AUDIT] and [SYSTEM] tags for filtering.

Note

Syslog uses RFC 3164 over UDP. The implementation is non-blocking — syslog failures do not affect service operation.

Service Deployment 

Linux (systemd):

The RADKit installer creates a systemd unit that runs the service under a dedicated non-root user.

It is strongly recommended to keep the systemd configuration as installed by the RADKit Linux installer.

The installer will set up everything with the best security practices when the following conditions are met: - Deploy RADKit on a dedicated host or VM with minimal additional software to reduce the attack surface. - Deploy on a modern Linux distribution with up-to-date security patches. - Deploy RADKit on a machine with systemd-encrypt enabled to protect secrets at rest. - Deploy RADKit on a machine with a TPM 2.0 module to enable hardware-bound encryption of secrets. - Run the service as a dedicated non-root user and group (e.g., radkit:radkit), with no shell access.

Docker:

Mount the data volume (/radkit) from a host path with restrictive permissions.
Run the container as a non-root user.
Disable unnecessary capabilities.
Use --read-only filesystem where possible.

General:

Keep RADKit updated to receive security patches. Subscribe to Cisco security advisories for RADKit.

Cloud Connectivity 

If the RADKit Service connects to RADKit Cloud:

Ensure outbound HTTPS (port 443) to prod.radkit-cloud.cisco.com is allowed.

Use a forward proxy if required by network policy:

[cloud_client.proxy]
url = "http://proxy.example.com:3128"

Restrict upload destinations to known-good hosts:

[cloud_client]
upload_allowed_hosts = ["^.*\\.cisco\\.com$"]

If cloud connectivity is not needed, disable it entirely:
```
[service.connectivity]
enable_cloud = false
```

Operating System Security 

RADKit Installation 

Use the official installers rather than installing from a Python wheel or source. On Linux, RADKit is distributed as a self-extracting shell script; on Windows, as a native installer. Both:

Install the service under a dedicated system account with minimal privileges.
On systems with a TPM 2.0 module, the secrets database encryption key is sealed to the TPM, binding it to the hardware and protecting it against offline extraction.

Important

On Linux, do not move the data directory (/opt/radkit) to a filesystem that is mounted with noexec or to a network share. The TPM binding and file permission model rely on the directory remaining on a local, trusted filesystem.

On Windows, the installer registers RADKit Service as a Windows service running under a dedicated local account. The data directory is created under %ProgramData%\RADKit with ACLs that restrict access to that account and local administrators.

Firewall Settings 

Apply host-based firewall rules to enforce the port restrictions described in Network Exposure. The table below maps each port to the recommended rule:

Port	Direction	Host firewall rule
8081/tcp	Inbound	Allow from management VLAN only; deny all others
8181/tcp	Inbound	Allow from trusted client networks; deny if direct RPC is disabled
443/tcp	Outbound	Allow to `prod.radkit-cloud.cisco.com`; deny if cloud is disabled

Linux (firewalld):

# Allow WebUI only from management network
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \
  source address="10.0.1.0/24" port port="8081" protocol="tcp" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \
  port port="8081" protocol="tcp" drop'
firewall-cmd --reload

Linux (iptables):

iptables -A INPUT -p tcp --dport 8081 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8081 -j DROP

Windows (PowerShell):

New-NetFirewallRule -DisplayName "RADKit WebUI" -Direction Inbound `
  -Protocol TCP -LocalPort 8081 `
  -RemoteAddress "10.0.1.0/24" -Action Allow
New-NetFirewallRule -DisplayName "RADKit WebUI Block" -Direction Inbound `
  -Protocol TCP -LocalPort 8081 -Action Block

Hardening Checklist 

Use this checklist to verify your deployment meets hardening requirements:

#	Item	Reference
1	Superadmin password stored securely (password file, `chmod 600`)	The Superadmin account
2	Password policy strengthened (length ≥ 14, symbols required, expiration set)	Password Policy
3	Admin authentication delegated to TACACS+ or external IdP	TACACS+ Integration
4	Administrator roles follow least-privilege (basic-admin for operators)	Administrator accounts and RBAC
5	External vault configured if required by organizational security policy	Vaults (HashiCorp Vault, CyberArk)
6	Device RBAC enabled with labels restricting user access	RBAC Labels
7	E2EE enforced (`require_e2ee = true`)	End-to-End Encryption (E2EE)
8	WebUI bound to management network only	Network Exposure
9	Self-signed TLS WebUI certificate replaced with CA-signed certificate	TLS Configuration
10	Session timeouts reduced from defaults	Session Management
11	Syslog forwarding enabled to SIEM	Logging and Auditing
12	Service running as non-root dedicated user	Service Deployment
13	Unused connectivity modes disabled (direct RPC or cloud)	Network Exposure
14	RADKit updated to latest version	Service Deployment
15	Installed via official installer (not from wheel/source) to enable TPM2 DB protection	RADKit Installation
16	Host firewall rules applied to restrict ports 8081 and 8181	Firewall Settings
17	Certificate auto-renewal enabled; OS clock synchronized via NTP	Certificate Management