Vault Credentials Overview

Key vault credentials let rConfig V8 fetch device usernames and passwords from your secret management platform at the moment it connects to a device, instead of storing them in rConfig. Rotate a password in the vault and the next backup uses it, with nothing to change in rConfig.

When to Use This Page

Start here if your organisation already keeps network device credentials in a vault and wants rConfig to read them from there. Use it to decide whether a vault fits your deployment, then follow the setup guide for your provider.

Supported Key Vault Providers

Provider	rConfig V8 Support	Documentation
HashiCorp Vault	✓ Verified	HashiCorp Vault Setup
Palo Alto Networks Idira (CyberArk), Central Credential Provider	Early access, from V8.4.2	Idira (CyberArk) Setup
Delinea Secret Server (formerly Thycotic)	Early access, from V8.4.2	Delinea Secret Server Setup

CyberArk is now part of Palo Alto Networks and is sold as Idira. The Central Credential Provider kept its name and API, so the integration works with existing CyberArk deployments as well as Idira.

Early access

The Idira (CyberArk) and Delinea integrations are built from each vendor’s published API documentation and follow its documented request and response formats. Environments vary, so we’d welcome your feedback as you roll them out. If anything behaves differently in your deployment, contact rConfig support and we’ll work through it with you.

How Key Vault Integration Works

1. You set up each vault once under Platform → Integrations → Device Credentials: its address, how rConfig signs in, and an on/off switch.
2. You create a vault credential set that points at one secret or account in that vault, and assign the set to devices like any other credential set.
3. When rConfig connects to one of those devices, it asks the vault for the secret, maps the returned keys to the device username, password and enable password, and logs in.
4. The credentials are discarded when the operation ends. rConfig does not cache device credentials from a vault, so every backup reads the current values.

Several Vaults at Once

From V8.4.2, more than one vault can be switched on at the same time. Each vault credential set belongs to the vault it was created with, so you can keep core switches in Idira, branch routers in Delinea and lab kit in HashiCorp Vault, all in one rConfig instance. When more than one vault is on, the credential set dialog shows a Vault dropdown.

Turning a vault off stops its credential sets from working until it’s on again. Backups for those devices fail with a message that names the vault and says it’s turned off.

Where the Settings Live

From V8.4.2, vault settings are entered on each provider’s page under Platform → Integrations and stored in the rConfig database. Secrets (tokens, API passwords, private keys) are stored encrypted and are never sent back to the browser. A saved secret shows Saved. Leave blank to keep it.

Installs that set up a vault in .env before V8.4.2 keep working with no changes. Until you save the vault’s page, rConfig reads its settings from .env and the page says so. The first save copies the .env values, including the token or password and any certificate files, into the database. From then on the database settings are used and the .env values for that vault are ignored.

Credential Types in rConfig V8

You can mix these across your inventory, device by device:

• Local credentials: a username and password saved on the device itself. Fine for labs and one-off devices.
• Device credential sets: credentials saved once in rConfig, encrypted at rest, and shared by many devices.
• Vault credential sets: credentials read from a key vault at connection time. Use these when a vault is already the source of truth and passwords rotate there.

Prerequisites

• Administrator access to rConfig V8, with permission to update integrations
• Access to your vault to create a read-only identity for rConfig and grant it access to the device secrets
• HTTPS connectivity from the rConfig server to the vault’s API
• The device credentials already stored in the vault

Security Considerations

Authentication methods: HashiCorp Vault uses a static token (no AppRole). Idira (CyberArk) uses an application ID with allowed machines and, optionally, a client certificate. Delinea Secret Server uses a dedicated API user with the OAuth2 password grant. Each provider’s guide covers what it supports.

Least privilege: give rConfig’s vault identity read access to only the secrets it needs.

Who can change vault settings: viewing a vault’s page needs the integration view permission. Saving or testing needs the integration update permission.

TLS: use HTTPS to the vault. For an internal CA, paste the CA bundle on the provider’s page rather than turning verification off.

Audit: rConfig writes an activity log entry whenever vault settings are saved. Your vault’s own audit log records every credential read.

Related Documentation

• Device Management - assigning credential sets to devices
• Security Hardening - securing your rConfig deployment