This guide explains how to configure external secret vaults to securely store sensitive credentials for Veza integrations. Secret vaults enable customers to store sensitive information, such as usernames, passwords, authentication tokens, and certificates, in their private network environments rather than storing them in Veza.
When using secrets vaults, Veza stores only the secret identifiers (names or IDs) rather than the actual credential values. This approach ensures sensitive information never leaves your private network while allowing Veza's discovery and extraction processes to access required credentials dynamically.
The Secrets Vaults feature follows a secure retrieval flow:
The integration works as follows:
Your organization's vault credentials are stored exclusively on the external Insight Point in your environment. Veza never has access to these credentials outside of the discovery/extractor processes that run in your environment.
Veza stores only the references (IDs/names) to the secrets in your vault, not the actual secret values themselves.
When an integration needs to authenticate during discovery or extraction, Veza uses the vault credentials to dynamically fetch the required secret from your external vault.
After the discovery or extraction process completes, all secrets are discarded from memory. Veza never stores the actual secret values in its database.
You can revoke Veza's access to your secrets at any time by disabling the Insight Point or cutting off its connection to Veza's network.
In the current release, Secrets Vaults has the following limitations:
Requires an external Insight Point
Supports Azure Key Vault as the vault provider type
Supported integrations:
Active Directory
Okta
LDAP
Operates at the provider level only (datasource-level secrets are not yet supported)
Requires all secret fields (username, password, etc.) to be stored as a single external secret in JSON format
Before you configure secrets vaults, ensure:
You have an external insight point deployed and configured
You have an Azure Key Vault instance accessible from your Insight Point
You have appropriate permissions to create and manage secrets in Azure Key Vault
The feature flag INTEG_SECRETS_VAULT_EAC_47720
is enabled for your tenant
Network connectivity exists between your Insight Point and Azure Key Vault
Create a secrets vault configuration file on your external insight point.
The configuration file must be in YAML format and contain the Azure credentials needed to ACCESS your Key Vault. These credentials allow the Insight Point to authenticate with Azure Key Vault to retrieve the actual integration secrets.
Set the environment variable for the configuration file path.
Export the path to your secrets vault configuration file:
The Insight Point will monitor the file for changes. The file can be updated without requiring an Insight Point restart.
Restart your external insight point.
The insight point will read the vault configuration on startup and establish connectivity to your Azure Key Vault.
To allow Veza's Insight Point to authenticate with Azure Key Vault, create an application registration in Azure Active Directory:
Navigate to Azure Active Directory > App registrations in the Azure portal.
Click New registration.
Name the application (e.g., "Veza Secrets Vault Access").
Select appropriate supported account types (usually single tenant).
Click Register.
Note the Application (client) ID and Directory (tenant) ID for your configuration.
Navigate to Certificates & secrets.
Create a new client secret and note the value.
This value will only be shown once, so copy it immediately.
Navigate to your Azure Key Vault resource.
Under Access policies, add a policy for your new application with Get and List permissions for secrets.
Navigate to your Azure Key Vault in the Azure portal.
Create a new secret for your integration credentials.
Select Secrets from the left navigation, then click Generate/Import.
Enter the secret name and value.
The secret name will serve as the identifier for the credentials in Veza. The secret value must be a JSON object containing all required credential fields for your integration type.
Format the secret value according to your integration type.
Active Directory:
Okta (OAuth):
Okta (API Token):
LDAP:
Save the secret.
Azure Key Vault will generate a unique identifier for the secret that you'll reference when configuring your Veza integration.
Navigate to the Veza integrations page.
Create a new integration for your supported provider type.
Secrets vaults are currently supported for Active Directory, Okta, and LDAP integrations.
Select your external insight point.
Choose the insight point where you configured the vault credentials.
Enable secrets vault authentication.
When the Insight Point is configured with external secrets, you'll see a Secrets Vault selection. Select External Secrets Vault instead of Veza Vault.
Configure the vault settings.
Vault Name: Select your vault from the dropdown (e.g., "MyVault")
Secret Name: Enter the name of the secret you created in Azure Key Vault
Standard credential fields (username, password, etc.) will be hidden when the secrets vault is enabled.
Complete the provider configuration and save.
Test the connection.
Initiate a discovery and extraction run to verify that secrets are being fetched correctly from Azure Key Vault and that the provider connects successfully to the target system.
After configuring the provider with Secrets Vault:
Check the extraction logs to ensure the secrets are being fetched correctly from Azure Key Vault.
Verify that the provider connects successfully to the target system.
If connection fails, verify:
Azure Key Vault access policies are correctly configured
The secret JSON format matches the expected structure for your integration type
Network connectivity exists between the Insight Point and Azure Key Vault
The vault configuration file path is set correctly on the Insight Point
Azure Key Vault configuration reference for Veza Secrets Vaults
Azure Key Vault is Microsoft's cloud service for securely storing and accessing secrets. This guide covers the Azure-specific configuration requirements for integrating with Veza's Secrets Vaults feature.
An Azure account with permission to create and manage Key Vaults
A Microsoft Azure subscription with Key Vault service enabled
Access to create and manage application credentials in Azure Active Directory
Navigate to the Azure portal and search for "Key vaults".
Create a new Key Vault or select an existing one.
Ensure the Key Vault is accessible from your network where the Insight Point is deployed.
Note the Vault URI for your configuration.
This will be in the format: https://your-vault-name.vault.azure.net/
Azure Key Vault supports two authorization models: Azure RBAC (recommended) and Access Policies (legacy). Microsoft recommends using Azure RBAC for new deployments.
For new Key Vaults or those migrated to RBAC:
Ensure your Key Vault uses the RBAC permission model:
Navigate to your Key Vault resource.
Select Access control (IAM) from the left navigation.
Click + Add > Add role assignment.
Configure the role assignment:
Role: "Key Vault Secrets User" (for read access to secrets)
Assign access to: "User, group, or service principal"
Select: Choose the Azure AD application you created for Veza
Click Save to apply the role assignment.
For existing Key Vaults using access policies:
Navigate to your Key Vault resource.
Select Access policies from the left navigation.
Click + Add Access Policy.
Configure the following permissions:
Secret permissions: Get, List
Select principal: Choose the Azure AD application you created for Veza
Authorized application: Leave blank unless using specific application restrictions
Click Add and then Save to apply the policy.
For secrets vault access, your app registration needs Key Vault permissions. If you need to create a new app registration specifically for secrets vault access:
Navigate to Azure Active Directory > App registrations.
Click New registration.
Configure the application:
Name: "Veza Secrets Vault Access" (or your preferred name)
Supported account types: Single tenant (recommended)
Redirect URI: Leave blank for this use case
Click Register.
Record the following values from the Overview page:
Application (client) ID
Directory (tenant) ID
From your application registration, navigate to Certificates & secrets.
Click New client secret.
Configure the secret:
Description: "Veza Insight Point Access"
Expires: Choose an appropriate expiration based on your security policies
Click Add.
Important: Copy the secret Value immediately.
This value will only be displayed once and cannot be retrieved later.
Ensure your application has the necessary permissions:
Navigate to API permissions in your application registration.
Verify the application has appropriate Microsoft Graph permissions if needed for your environment.
If using managed identities, ensure the identity has the required Key Vault access policies configured.
For Active Directory integrations, store credentials in this JSON format:
Field requirements:
username
: Domain-qualified service account with appropriate AD permissions
password
: Secure password for the service account
ldaps_certificate
: Base64-encoded LDAPS certificate (optional, for secure LDAP connections)
For Okta integrations using OAuth authentication:
Field requirements:
client_id
: OAuth client ID from Okta application configuration
private_key_id
: Key ID associated with the private key
private_key
: RSA private key in PEM format
For Okta integrations using API token authentication:
Field requirements:
token
: Valid Okta API token with appropriate permissions
For LDAP integrations:
Field requirements:
bind_dn_or_user
: Distinguished name or username for LDAP binding
bind_password
: Password for the bind account
ca_certificate
: CA certificate for secure LDAP connections (optional)
Ensure your Key Vault is accessible from the Insight Point's network
Consider using Azure Private Link for additional network isolation
Implement network security groups (NSGs) to restrict Key Vault access
Follow the principle of least privilege when configuring access policies
Regularly rotate client secrets and API tokens
Monitor Key Vault access logs for unusual activity
Consider using Azure managed identities where possible
Store certificates in PEM format within the JSON secret values
Ensure certificates are properly escaped for JSON formatting
Monitor certificate expiration dates and plan for rotation
Problem: "Access denied" errors when Insight Point attempts to retrieve secrets
Solutions:
Verify the client ID and secret are correct in the vault configuration
Check that access policies include both "Get" and "List" permissions for secrets
Ensure the tenant ID matches your Azure AD tenant
Verify the application registration is in the correct tenant
Problem: Connection timeouts when accessing Key Vault
Solutions:
Verify network connectivity from the Insight Point to Azure Key Vault endpoints
Check firewall rules and network security groups
Confirm the Key Vault URI is correct and accessible
Test connectivity using tools like curl
or wget
from the Insight Point
Problem: Integration fails to authenticate with target systems
Solutions:
Verify JSON formatting is correct (no extra spaces, proper escaping)
Ensure field names match the expected format for your integration type
Validate that certificates are in proper PEM format
Check that credentials are valid for the target system
Problem: Vault configuration not loaded by Insight Point
Solutions:
Verify the SECRETS_VAULTS_CONFIG_PATH
environment variable is set correctly
Check that the YAML file is properly formatted
Ensure the Insight Point process has read permissions for the configuration file
Review Insight Point logs for configuration parsing errors
This reference guide provides detailed steps for configuring Azure Key Vault to support Veza's Secrets Vaults feature. For the complete setup process, see the .
An external deployed in your environment
Note: Microsoft recommends migrating to Azure RBAC for improved security and management. See for details.
If you already have an Azure integration configured with Veza, you can use the existing app registration. Otherwise, follow the steps in the to create an app registration.