# Secret Managers

> Connect HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault so test credentials are resolved at runtime with a secretref:// reference instead of being stored in the app.

Source: https://totalshiftleft.ai/help-center/product-documentation/secret-managers

## 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](/features/collaboration-security/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

1. 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."*
2. Find the **Enable Secret Managers** card. When off, the helper text reads *"Turn on to resolve test credentials from external secret managers."*
3. 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."*
4. 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

1. Click **Add provider** (top right). The form header reads **Add provider**.
2. 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

1. Click **Create provider** (the button reads **Save changes** when editing). While saving it shows **Saving…**.
2. On success you'll see **"Secret provider created"** and the form closes.
3. 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:

1. 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."**
2. Optionally enter a **Field (optional)**, e.g. `password`, to resolve a single key within the secret.
3. Click **Test** (it shows **Testing…** while running).
4. 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](/help-center/product-documentation/audit-logs).

## Related articles

- [API keys](/help-center/product-documentation/api-keys)
- [Data sources](/help-center/product-documentation/data-sources)
- [Single Sign-On (SSO)](/help-center/product-documentation/single-sign-on)
- [Audit Logs](/help-center/product-documentation/audit-logs)