Overview

This guide walks you through the Secret Managers screen in Shift Left Studio exactly as it appears, from enabling the feature to testing that a secret resolves. A secret provider is a connection to an external secret store (HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) so test credentials are fetched at runtime rather than stored in the app. You reference a stored secret in your tests with a secretref:// string.

Explore the capability at secret managers.

Availability: Enterprise.

Before you begin

You must be an administrator with the manage_secret_providers permission. The provider endpoints require it; without it the screen won't load.
Have your provider's connection details ready (address/URL, token or credentials).
Navigate to Settings → Integrations → Secret Managers.
Provider secrets (Vault Token, AWS Secret Access Key, Azure Client Secret) are encrypted at rest and never displayed again — the provider card shows a configured / not set badge per secret field. Keep a copy of any secret before you save.

Step 1 — Enable Secret Managers

On the Secret Managers screen you'll see the subtitle "Connect HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault to resolve test credentials at runtime."
Find the Enable Secret Managers card. When off, the helper text reads "Turn on to resolve test credentials from external secret managers."
Click the toggle switch on the right of that card. It flips to the active (blue) state and shows the notification "Secret managers enabled." The helper text changes to "Secret managers are active. Connect and manage providers below."
If the feature is disabled you'll see the placeholder "Secret managers are currently disabled. Use the switch above to enable them, then add a provider."

Step 2 — Add a provider

Click Add provider (top right). The form header reads Add provider.
Set the two common fields, then the provider-specific fields:

Field	What it does
Provider type	Choose HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. This selection is fixed once created (it's disabled when editing).
Display name	A friendly name (required), e.g. Production Vault. Saving with this blank shows "Display name is required."
Enabled	Checkbox. When checked the provider can resolve secrets.

Step 3 — Fill provider-specific fields

Fields marked * are required. Secret fields render as password inputs and, when editing, show "Leave blank to keep the existing value."

HashiCorp Vault

Field	What it does
Address *	Vault base URL, e.g. `https://vault.example.com:8200`.
Token *	Vault access token, e.g. `hvs.xxxxxxxx`. Secret — encrypted, shown once, then a configured badge.
Namespace (optional)	Vault Enterprise namespace, e.g. `admin`.
Mount (optional)	Secrets-engine mount path, e.g. `secret`.

AWS Secrets Manager

Field	What it does
Region *	AWS region, e.g. `us-east-1`.
Access Key ID (optional)	IAM access key id (e.g. `AKIA…`). Omit both credential fields to use the host's IAM role.
Secret Access Key (optional)	IAM secret access key. Secret — encrypted, shown once, then a configured badge.

Azure Key Vault

Field	What it does
Vault URL *	Key Vault URL, e.g. `https://my-vault.vault.azure.net`.
Tenant ID (optional)	Azure AD tenant GUID.
Client ID (optional)	App registration client id. Omit the credential fields to use a managed identity.
Client Secret (optional)	App registration client secret. Secret — encrypted, shown once, then a configured badge.

Step 4 — Create the provider

Click Create provider (the button reads Save changes when editing). While saving it shows Saving….
On success you'll see "Secret provider created" and the form closes.
The provider appears as a card showing the display name, a provider-type badge, an Enabled/Disabled badge, the generated providerId (monospace), and one badge per secret field reading configured (green) or not set (amber).

Step 5 — Test the connection

Each provider card has a Test connection panel:

In Secret path, enter a path the provider can resolve, e.g. secret/data/myapp. This is required — an empty path shows "Enter a secret path to test."
Optionally enter a Field (optional), e.g. password, to resolve a single key within the secret.
Click Test (it shows Testing… while running).
On success you'll see a green message such as "Connection succeeded. Secret resolved." The secret's value is intentionally not returned. On failure you'll see a red RESOLUTION_FAILED message with the reason.

Step 6 — Reference secrets in tests

Reference a stored secret anywhere credentials are needed using:

secretref://<providerId>/<path>#<field>

<providerId> — the provider id shown on the card.
<path> — the secret path in the provider (e.g. secret/data/myapp).
#<field> — optional; a single key within the secret (e.g. #password).

The value is resolved at execution time and never persisted in the test. The screen shows the same hint: "Reference a stored secret in your tests with secretref://<providerId>/<path>#<field>."

Troubleshooting and notes

MISSING_PATH (400) — you clicked Test without a Secret path. Enter one.
RESOLUTION_FAILED (400) — the provider couldn't resolve the path/field. Recheck the Address/URL, credentials, path, and (for Vault) the Mount/Namespace.
PROVIDER_EXISTS (409) — a provider with that identity already exists.
PROVIDER_NOT_FOUND (404) — the provider was deleted; tests referencing it stop resolving. Deleting prompts "Delete secret provider "…"? Tests referencing it will stop resolving."
Secret fields are encrypted at rest and never displayed — cards show a configured / not set badge. Leave a secret field blank when editing to keep the current value.
Creating and deleting providers is written to the audit log.

Secret Managers