To ensure a smooth onboarding process, configure your environment to allow communication with essential Veza IP addresses and email domains.

Domain Filtering

The following domains should be allowed through email filters, proxies, and firewalls:

• Email notifications: When a Veza local account is created, an email is sent to the user to create their password. This email comes from [email protected].

• Veza tenant domain: The domain for your Veza instance will be *.vezacloud.com, where * represents your Veza tenant name.

• Insight Point: If using an Insight Point, access to public.ecr.aws must be allowed for the Veza Insight Point.

Firewall Rules and Filters

Veza integrations connect to data sources across your on-premise environment, cloud providers, and SaaS applications. Most integrations use API tokens or other credentials to query for authorization metadata.

By default, integrations run on the Veza SaaS platform. If your organization filters inbound connections to applications you want to integrate with Veza, allow traffic from the following Veza NAT Gateway IP addresses in your firewall rules or filters, depending on the region where Veza is deployed:

• North America regions:

  • 18.221.224.60

  • 3.18.38.252

  • 52.14.66.128

• Europe, Middle East, and Africa regions:

  • 18.133.37.58

  • 18.171.45.61

  • 13.42.176.0

Insight Point Connectivity

When configuring an integration, you can choose to use an Insight Point managed by your organization. An Insight Point allows querying authorization metadata within your environment, with no inbound calls from your Veza tenant to integrated data sources.

When using this option, outbound traffic must be enabled, to allow the Insight Point to transmit authorization metadata securely to your Veza tenant. The Insight Point must also be able to pull images from the Veza ECR repository, as detailed in Insight Point: Ports and Connectivity.

Overview

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.

How it works

The Secrets Vaults feature follows a secure retrieval flow:

The integration works as follows:

1. 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.

2. Veza stores only the references (IDs/names) to the secrets in your vault, not the actual secret values themselves.

3. 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.

4. 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.

Current limitations

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

  • Azure

  • LDAP

  • Okta

• 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 start

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

Configure vault access on Insight Point

1. 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.

   Copy

   vaults:
     - name: 'MyVault'
       vault_provider: 'azure_key_vault'
       auth_type: 'client_secret'
       auth_config:
         vault_uri: 'https://my-vault.vault.azure.net/'
         tenant_id: '11111111-2222-3333-4444-555555555555'
         client_id: 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee'
         client_secret: 'my-secret'

2. Set the environment variable for the configuration file path.

   Export the path to your secrets vault configuration file:

   Copy

   export SECRETS_VAULTS_CONFIG_PATH="/dir1/dir2/dir3/secrets_vaults_config.yaml"

   The Insight Point will monitor the file for changes. The file can be updated without requiring an Insight Point restart.

3. Restart your external insight point.

   The insight point will read the vault configuration on startup and establish connectivity to your Azure Key Vault.

Set up Azure AD application

To allow Veza's Insight Point to authenticate with Azure Key Vault, create an application registration in Azure Active Directory:

1. Navigate to Azure Active Directory > App registrations in the Azure portal.

2. Click New registration.

3. Name the application (e.g., "Veza Secrets Vault Access").

4. Select appropriate supported account types (usually single tenant).

5. Click Register.

6. Note the Application (client) ID and Directory (tenant) ID for your configuration.

7. Navigate to Certificates & secrets.

8. Create a new client secret and note the value.

   This value will only be shown once, so copy it immediately.

9. Navigate to your Azure Key Vault resource.

10. Under Access policies, add a policy for your new application with Get and List permissions for secrets.

Create external secrets in Azure Key Vault

1. Navigate to your Azure Key Vault in the Azure portal.

2. Create a new secret for your integration credentials.

   Select Secrets from the left navigation, then click Generate/Import.

3. 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.

4. Format the secret value according to your integration type.

   Active Directory:

   Copy

   {
     "username": "domain\\serviceaccount",
     "password": "secretpassword",
     "ldaps_certificate": "-----BEGIN CERTIFICATE-----\nMIIC...\n-----END CERTIFICATE-----"
   }

   Azure:

   Copy

   {
     "client_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
     "client_secret": "secretclientvalue",
     "auth_certificate": "base64encodedcertificatedata",
     "auth_certificate_password": "certpassword"
   }

   Note: The auth_certificate_password field is optional if the certificate is not secured with a password.

   Okta (OAuth):

   Copy

   {
     "client_id": "0oa1a2b3c4d5e6f7g8h9",
     "private_key_id": "kid_value",
     "private_key": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
   }

   Okta (API Token):

   Copy

   {
     "token": "00A1b2C3d4E5f6G7h8I9j0K1l2M3n4O5p6Q7r8S9"
   }

   LDAP:

   Copy

   {
     "bind_dn_or_user": "cn=serviceaccount,ou=service,dc=example,dc=com",
     "bind_password": "secretpassword",
     "ca_certificate": "-----BEGIN CERTIFICATE-----\nMIIC...\n-----END CERTIFICATE-----"
   }

5. Save the secret.

   Azure Key Vault will generate a unique identifier for the secret that you'll reference when configuring your Veza integration.

Configure provider with secrets vault

1. Navigate to the Veza integrations page.

2. Create a new integration for your supported provider type.

   Secrets vaults are currently supported for Active Directory, Azure, LDAP, and Okta integrations.

3. Select your external insight point.

   Choose the insight point where you configured the vault credentials.

4. 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.

5. 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.

6. Complete the provider configuration and save.

7. 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.

Verification and troubleshooting

After configuring the provider with Secrets Vault:

1. Check the extraction logs to ensure the secrets are being fetched correctly from Azure Key Vault.

2. Verify that the provider connects successfully to the target system.

3. 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

See also

• Azure Key Vault configuration reference

• Insight Point deployment guide

• Active Directory integration

• Azure integration

• Okta integration

• Azure Key Vault documentation

What is a Veza Insight Point?

An Insight Point is a lightweight connector running in your environment to enable the secure gathering of authorization metadata for resources that Veza cannot access directly. An Insight Point is typically deployed as a Docker container or VM OVA.

Typically, you will want an Insight Point to enable secure discovery of services (such as Active Directory, Oracle Database, or SQL Server) that require connectivity from within your corporate network. The Insight Point will run within your network to query the internal-only data sources for authorization metadata and push that information to Veza securely.

When do I need an Insight Point?

Deploying an Insight Point for Veza is usually not required, but might be necessary:

• When the resources to discover are not exposed publicly.

• To discover databases and other services that do not have cloud-native APIs.

• If your organization prohibits 3rd-party programmatic access to cloud service providers.

• To discover on-premise and .

Installation Options

• Veza provides an to install an Insight Point for common Linux distributions.

• The Insight Point is also available as an suitable for Oracle Virtualbox or VMWare VSphere. This option can be preferable to Docker for Windows-based environments.

• For AWS environments, see for instructions to start an Insight Point on AWS EC2.

After deploying the Insight Point, you can specify it when an integration. Veza will use the Insight Point for secure collection and transmission of entity metadata.

System Requirements

Before deploying an Insight Point, ensure your environment meets the following minimum requirements:

Note: These are minimum requirements for typical deployments. If you experience performance issues or timeouts during data collection, consider increasing CPU and memory allocation. Contact Veza support for guidance on resource scaling for your specific environment.

Generating an Insight Point key

Log in to Veza with an administrator account, and create a registration key by browsing to Integrations > Insight Points:

1. Click Create

2. Enter a Name

3. Click Generate Key

4. Copy the key for use when running the docker image

Save the Insight Point key in a secure location. If lost, there is no way to recover it.

Troubleshooting

• Insufficient Resources: Ensure the Insight Point meets the . The instance must have at least 2 CPU cores and 4 GB RAM allocated.

Refer to specific deployment guides for troubleshooting steps.

Checking connectivity

The Insight Point automatically checks for connectivity on container start. This includes steps to resolve the DNS and verify TCP and HTTP communication. If there are connection problems, the container logs will indicate if a connection was refused, a host could not be found, or there is another issue.

Monitoring Insight Point availability

The Veza platform emits an Insight Point Unavailable event after the Insight Point is unavailable for several minutes. To reduce the number of times this event triggers, the task manager will not re-emit the event for 24h hours. An administrator can configure to get email notifications when connectivity issues impact Veza data collection.

Note: If the Insight Point task manager service is restarted, the event can be emitted sooner than the 24-hour window.

To enable email alerts when an Insight Point is unavailable:

1. Use the Veza navigation menu to open Administration > Event Subscriptions

2. Click Create Subscription

3. On the Details tab, enter a descriptive name to communicate the alert purpose.

4. On the Conditions tab:

   • Set Event Type to "Insight Point Unavailable"

   • Set Severity to "Error"

   • Set Category to "Integrations"

5. On the Action → Send Alert tab, select or create an email Veza Action

6. Click Create to save the subscription

Changing an Insight Point

When modifying the Insight Point associated with an integration — for example, if the registration key is lost — you will need to re-enter the credentials and secrets for that integration configuration.

• Follow the instructions to start another Insight Point with a new deployment key

• On the Integrations page, edit the integration configuration to re-enter the credentials for each affected integration.

Ports and connectivity

The Insight Point will communicate out from the container VM to the Veza Tenant and targeted systems. Your implementation must enable traffic to and from the host on the required ports.

Also, the host must be able to communicate out to the ECR repository hosting the insight point image.

• The Insight Point must be able to communicate with https://<your-org>.vezacloud.com on outbound port 443. Ensure that firewalls allow outbound traffic to the Veza tenant domain.

• For Active Directory and SQL Server: The Insight Point must be allowed to communicate with Active Directory Domain Controllers on port 636, and SQL Servers on port 1433.

• For AWS RDS and Trino: To discover AWS RDS or Trino instances, you will need to add the Insight Point egress IP to the Security Groups Inbound rules. Do this for each of the instances to discover.

To add an entry for AWS RDS:

1. Log in to the AWS account containing the resources to discover, and go to RDS > Databases

2. Click the DB identifier and go to Connectivity & security > Security > VPC security groups

3. Click Inbound rules > Edit inbound rules to set the IP address entry

4. Click Add rule > Type (MySQL, Aurora or PostgreSQL) > Source (Custom)

5. Enter the Insight Point egress IP

6. Optionally enter a description and click Save rules

To add an entry for Trino:

1. Log in to the AWS account containing the resources to discover, and go to EC2 > Security Groups

2. Click the Security Group associated with your Trino instances and go to 'Inbound rules' > 'Edit inbound rules' to set the IP address entry

3. Click 'Add rule' > Type (Custom TCP) > Port Range (8080 or your custom port) > Source (Custom) > enter the Insight Point egress IP

4. Optionally enter a description, and save the rules

Generating Key Pairs for Workday Integration

To ensure secure communication between Veza and Workday, we adopt an authentication mechanism using public-private key pairs. This approach uses SSL (Secure Socket Layer) technology, which establishes encrypted links between servers and clients, ensuring that all data transmitted remains private and secure. x509 certificates are a standard format for public key certificates, verifying the ownership of a cryptographic public key for secure communication.

Why is this necessary?

1. Security: Public-private key pairs are the foundation of many cryptographic protocols, ensuring the confidentiality, authenticity, and integrity of data.

2. Authentication: Workday can verify that data received is genuinely from Veza, ensuring trusted communication.

3. Non-repudiation: Transactions signed with the private key can be proven to come from Veza.

Installation

Linux

1. Most Linux distributions include OpenSSL by default. If not:

   • Debian or Ubuntu: sudo apt update && sudo apt install openssl

   • Red Hat: sudo yum install openssl

   • Fedora: sudo dnf install openssl

Mac

1. OpenSSL is included with macOS by default. If you need a specific version or updates:

   • Use Homebrew: brew install openssl

Windows

• OpenSSL Binary:

  • Download and install from OpenSSL Binaries.

  • Add OpenSSL's bin directory to your system's PATH.

• Windows Subsystem for Linux (WSL):

  • Install WSL.

  • Run the Linux distribution and install OpenSSL using its package manager (e.g., sudo apt install openssl for Ubuntu).

• Git Bash for Windows:

  • Install Git for Windows, which includes Git Bash.

  • Use OpenSSL directly from the Git Bash terminal.

• Package Manager for PowerShell:

  • Use a package manager like Chocolatey. After installing Chocolatey, run: choco install openssl

Alternately, you can use the Microsoft Management Console (MMC):

• Use the built-in MMC snap-in to manage certificates:

  1. Press Win + R, type mmc, and press Enter.

  2. File > Add/Remove Snap-in > Certificates > Add.

  3. Follow the wizard to manage personal certificates and trusted root certificates.

Generate Key Pairs with OpenSSL

1. Generate a Private Key:

• The private key is the foundation of your security protocol. Ensure it is secure and never exposed.

  Generate it with OpenSSL in PEM format:

  Copy

  openssl genpkey -algorithm RSA -out private_key.pem

  If you need additional security, encrypt the key file with a passphrase. Save the passphrase in a secure location:

  Copy

  openssl rsa -aes256 -in private_key.pem -out encrypted_private_key.pem

  During Veza integration configuration, you will upload this private key file and, if encrypted, enter its passphrase.

2. Generate a Certificate Signing Request (CSR):

• A CSR is a request for a certificate authority (CA) to validate and certify your public key. The CSR includes information such as your organization and domain.

  Generate the CSR:

  Copy

  openssl req -new -key private_key.pem -out signing_request.csr

  During the process, you'll be prompted to enter details like your organization and common name (CN). These are optional depending on your integration requirements.

  Post generation, you can either:

  • Submit the CSR to a trusted Certificate Authority for a signed certificate.

  • Create a self-signed certificate, which might not be trusted universally but is sufficient for testing or internal use.

3. Generate a Self-Signed Certificate:

• Using the CSR and private key, generate the certificate:

  Copy

  openssl x509 -req -days 365 -in signing_request.csr -signkey private_key.pem -out your_cert.crt

  In this example, days sets the length of time the certificate is valid for.

Paste the contents of this certificate, which includes the public key, when configuring the API client registration in Workday.

You can run an Insight Point on the virtual machine service of your choice with a Veza-provided OVA image. The file includes a full Linux environment within a single file that can run on VMWare vSphere, Oracle Virtualbox, or another VM manager.

Compatibility

• The virtual appliance supports VMware vSphere 6.5+, and as Oracle VM Virtualbox 6.0+.

• The virtual appliance runs Alpine Linux.

Deploying the Virtual Appliance

Download the current Insight Point build from https://veza-releases.s3.us-east-1.amazonaws.com/veza_insight_point_v2.ova

Note: The virtual appliance is preconfigured to meet the Insight Point system requirements with minimum CPU (2 cores), RAM (4 GB), and storage values. Unless instructed otherwise by Veza support, do not adjust the default values.

VMware

From the VMware Host Client Inventory screen, follow these steps to import the virtual appliance:

1. Right-click Host in the VMware Host client inventory and select Create/Register VM

2. In the New Virtual Machine window that appears, on the Select creation type page, select Deploy a virtual machine from an OVF or OVA and click Next

3. On the Select OVF and VMDK files page, provide a unique name for the virtual machine (ex: veza_insight_point)

4. Click the blue pane to begin browsing to the location of the veza_insight_point_v2.ova file on your local system storage

5. Browse to and select the veza_insight_point_v2.ova file, then click Open

6. The file appears in the blue pane in the New Virtual Machine wizard; click Next

7. On the Select storage page, select the storage type (Standard) and choose a datastore for the virtual machine, then click Next

8. On the Deployment options page, select network mappings, disk provisioning, and power-on settings, then click Next

9. On the Ready to complete page, review the virtual machine details and click Finish

Oracle VM Virtualbox

In the Oracle VM VirtualBox Manager, follow these steps to import the virtual appliance:

1. In the File menu, click Import Appliance

2. In the Appliance Import Wizard window that appears, click Choose to select the location of the veza_insight_point_v2.ova file

3. Browse to the location of the veza_insight_point_v2.ova file and click Open

4. Review the Appliance Import Settings displayed in the window and click Import

Generate an Insight Point Registration Key

The Insight Point requires a registration key to authenticate with the Veza platform. To generate an Insight Point registration key, follow these steps:

1. Browse to your Veza Instance and log in as an administrative user.

2. In the left navigation pane, locate Configuration, then click Insight Point in the subpane.

3. Click Generate New Key in the upper-right corner of the main pane.

4. Provide a name for the new Insight Point and set an expiration date and time.

5. Click Generate Key

6. Make note of the key value that is returned; this will be required for configuring the Insight Point below

Configuring the Virtual Appliance

Once the virtual appliance is deployed and powered on, complete the initial configuration from the hypervisor console or using SSH.

Default Credentials

Log in to the virtual appliance with the root account. This account has no password when initially deployed.

Configuration

From the shell prompt, run setup-veza to configure the system. The Message of the Day banner refers to this command when logging in.

After invoking the setup-veza command, follow the prompts:

1. Set the timezone for the virtual machine

   Note: Communication between the Insight Point and the Veza SaaS platform is sensitive to time drift. Ensure that the virtual machine's clock matches the local time.

2. Set an appropriate hostname for the virtual appliance

3. Configure the eth0 interface to use DHCP or static values

4. If using static interface values, configure DNS settings

5. Set a password for the root account

6. Enter the Insight Point Registration Key

   Note: This value is a long base64-encoded string; copy it from the Veza platform and paste the value here

7. The docker daemon will pull the most recent Insight Point image; this might take several seconds to initialize without screen output

8. The command will return to the shell prompt after the Insight Point deploys.

Operation and Troubleshooting

After the Insight Point deploys, verify that it has successfully connected to the Veza platform. Log in to the Veza platform and follow these steps:

1. On the left navigation pane, under Configuration, click Insight Point

2. Verify that a new Insight Point has registered with the platform.

Note: One Insight Point will be named "Veza Insight Point" by default. Ensure at least two are present.

Verifying Container Status

If the newly deployed Insight Point does not appear on the Veza platform, verify the status of the container on the virtual machine:

1. Log into the virtual machine console or use SSH

2. List running Docker processes with the command: docker ps -a --filter="name=veza-insight-point"

3. Examine the output

The Insight Point's container ID should include a Status column showing Running.

Accessing Insight Point Logs

If the Insight Point does not appear to be running, or if requested by Veza support, follow these steps to access the Insight Point logs:

1. Log into the virtual machine console or use SSH

2. Run the following command to output the Insight Point logs: docker logs veza-insight-point

3. The logs are in JSON format and can be output to a file or copied from the terminal for debugging

Operation and Troubleshooting

After the Insight Point deploys, verify that it has successfully connected to the Veza platform. Log in to the Veza platform and follow these steps:

1. On the left navigation pane, under Configuration, click Insight Point

2. Verify that a new Insight Point has registered with the platform.

Note: One Insight Point will exist by default, named "Veza Insight Point".

Verifying Container Status

If the newly deployed Insight Point does not appear on the Veza platform, verify the status of the container on the virtual machine:

1. Log into the virtual machine console or use SSH

2. List running Docker processes with the command: docker ps -a

3. Examine the output

The Insight Point's container ID should include a Status column showing Running.

Accessing Insight Point Logs

If the Insight Point does not appear to be in a running state, or if requested by Veza support, follow these steps to access the Insight Point logs:

1. Log into the virtual machine console or use SSH

2. Run the following command: docker ps -a

3. Note the value in the Container ID field

4. Run the following command to output the Insight Point logs: docker logs <container_id>, substituting the actual container ID

5. The logs are in JSON format and can be output to a file or copied from the terminal for debugging

Veza recommends deploying an Insight Point within Microsoft Azure for a secure connection to resources. This document includes instructions to run an Insight Point with an Azure Container Instance.

Step 1: Create a Container Instance resource

Log in to your Azure Tenant and go to . Create a new resource:

Step 2: Configure the container specifications

In the creation wizard, configure the container to meet the :

1. Size: Ensure the container instance has at least 2 CPU cores and 4 GB memory allocated

2. Image Source: Select Other registry and add the path to Insight Point image: public.ecr.aws/veza/insight_point:latest

Step 3: Assign an appropriate virtual network

Add the Insight Point to the virtual network. Choose Private and enter the virtual network assigned to other resources the Insight Point will connect to:

Step 4: Configure the Registration Key

In the advanced settings, configure the Insight Point registration key:

1. Navigate to the Advanced tab.

2. In the Environment Variables section, add the Insight Point provisioning key to the DP_REGISTER_KEY variable.

3. To generate a new registration key, visit the Integrations -> Insight Point page in the Veza console.

Confirm your settings by clicking Review + create, then deploy the container by selecting Create.

Step 5: Update the Azure integration to use the Insight Point

Finally, update the integration configuration in Veza so that the connection is made using the new Insight Point, instead of the Veza SaaS platform:

1. Log in to Veza, go to the Integrations page, and find the Azure integration on the list of providers.

2. Click Edit to open the configuration.

3. Change the Insight Point from (default) to the one you created.

4. Save the integration.

This document provides instructions to start an AWS EC2 virtual machine and run an as a Docker image. For generic instructions for Docker (suitable for Azure VMs), see or .

Installation

Follow the instructions to launch a new AWS EC2 instance, install prerequisites, and download and run the Insight Point. You can opt to use an existing EC2 instance, provided that the docker version is 19.09 or later.

• • Open the

  • Ensure that the region where you want to initialize the instance is selected

  • Click Launch Instance

  • Add a name for the instance ("Veza Insight Point")

  • Choose Amazon Linux 2023 OS image

  • Configure instance size to meet the (minimum: 2 CPU cores, 4 GB RAM)

  • Choose an existing key pair or create a new one

• To discover standalone RDS or Trino databases, ensure that allow communication to and from the Insight Point's outbound IP address.

The Kubernetes integration requires an Insight Point running within the cluster to discover RBAC entities. When adding the integration, you will specify the cluster details and the Insight Point to use. Veza provides a helm chart to simplify the process of deploying and managing the Insight Point.

Configuration Options

The Insight Point Helm chart accepts the following configuration parameters via --set flags. Typically only key is required.

• key is your unique Insight Point registration key, generated in the Veza UI.

  • Create a key in Veza: Integrations > Insight Points > Create

  • Store this value securely as it cannot be recovered if lost

• skipVerify (TLS_INSECURE_SKIP_VERIFY) should only be set to true to disable certificate validation for testing/troubleshooting.

Configuring Proxy CA Certificates

When using an HTTPS inspection proxy:

• Set to addrto your proxy's address if different from the Veza endpoint. This value overrides the default request authority.

• Ensure your proxy can connect to your Veza deployment.

• authority specifies the domain name to use for TLS certificate validation and is only required when addr points to a proxy instead of directly to Veza. Must be a specific domain (wildcards not supported).

To trust an HTTPS proxy, you will need to modify the Helm chart to add a volume for the proxy's CA certificate, mount it into the container, and configure the certificate path:

spec:
  template:
    spec:
      volumes:
        - name: proxy-ca-certs
          secret:
            secretName: proxy-ca-cert
      containers:
        - name: {{ .Chart.Name }}
          volumeMounts:
            - name: proxy-ca-certs
              mountPath: /etc/ssl/certs/proxy
              readOnly: true

Requirements

A Kubernetes Helm chart is a package format used to define, install, and upgrade applications in Kubernetes. Helm is often referred to as a package manager for Kubernetes. To install the chart, you will need:

• System Resources: Ensure your Kubernetes cluster has sufficient resources to meet the Insight Point system requirements (minimum: 2 CPU cores, 4 GB RAM per Insight Point pod).

• Insight Point Key: You will need to generate a secret key for the Insight Point. To create one, go to Veza Integrations > Insight Point > Create.

• Insight Point Version: Note the most recent Insight Point version (e.g. 2024.8.12-9) from Veza's OCI repository.

• Access to the Kubernetes Cluster: Ensure you have the necessary permissions and access credentials to interact with the target Kubernetes cluster.

• Helm Installed: Ensure Helm version 3.8 or greater is installed on your local machine. You can install Helm by following the official documentation: Helm Installation.

• Your organization security policies must allow chart installation from the VEZA ECR public.ecr.aws/veza

Install Insight Point (Helm Chart)

1. Customize Values and Install the Insight Point:

   Use the helm install command to install the Insight Point into the Kubernetes cluster. Replace <NAME>, <VERSION>, <KEY>, and key with your specific values:

   Copy

   helm install <NAME> oci://public.ecr.aws/veza/helm-chart/insight-point --version <VERSION> --namespace <NAMESPACE> --create-namespace  --set key=<KEY>

   • --namespace <NAMESPACE>: required if installing the Insight Point into a different namespace than the default.

   • --create-namespace: required if the namespace does not exist yet.

   • --set enableSecrets=true: optional field, required to enable Kubernetes Secrets extraction. Secrets will not be extracted by default.

   An Veza Insight Point Key must be provided. To do this, you can specify the value with the --set key=<registration-key> option when installing the chart.

   Example:

   Copy

   helm install veza-insight-point oci://public.ecr.aws/veza/helm-chart/insight-point --version 2024.1.29-1 --namespace veza --create-namespace --set enableSecrets=true --set key=key

2. Verify Installation:

   Verify the status of the installation by running:

   Copy

   helm list -n <NAMESPACE>

   This command will return a list of Helm releases, including the Insight Point you just installed. Ensure the STATUS is "DEPLOYED."

3. Get Insight Point Logs:

   If the Insight Point fails to initialize or can't connect to Veza, you can get more details by reviewing the container logs. You can retrieve this using the terminal:

   Copy

   kubectl logs -l app=<veza-insight-point> -n <NAMESPACE>

4. Upgrade and Maintain:

   Over time, you may need to upgrade the Insight Point to newer versions or adjust its configuration. Use the helm upgrade command to make these changes.

   Example:

   Copy

   helm upgrade <veza-insight-point> oci://public.ecr.aws/veza/helm-chart/insight-point --version <VERSION> --namespace <NAMESPACE>

5. Uninstall the Insight Point:

   If you need to uninstall the Insight Point, you can do so using the helm uninstall command:

   Copy

   helm uninstall <veza-insight-point> --namespace <NAMESPACE>

Veza maintains a script you can use to quickly install and run an Insight Point with Docker. Follow these steps to set up your environment, run the latest install script, and manage the deployment.

Prerequisites

• Systemd

• Docker (or Podman with Docker compatibility)

• System resources meeting the Insight Point requirements (minimum: 2 CPU cores, 4 GB RAM)

Install Docker

Install

Generate an Insight Point key from the Veza Integrations > Insight Point page. Store it as an environment variable before downloading and executing the script:

INSIGHT_POINT_KEY="<key>" bash -c "$(curl -fsSL https://veza-releases.s3.us-east-1.amazonaws.com/insightpoint/install.sh)"

or

export INSIGHT_POINT_KEY="<key>"
bash -c "$(curl -fsSL https://veza-releases.s3.us-east-1.amazonaws.com/insightpoint/install.sh)"

Remove

Uninstall

Uninstall will remove all components of the Insight Point but will not remove the configuration in /etc/veza-insight-point.

bash -c "$(curl -fsSL https://veza-releases.s3.us-east-1.amazonaws.com/insightpoint/install.sh)" -- uninstall

Remove

Remove will remove all components of the Insight Point and the configuration in /etc/veza-insight-point. The Insight Point Key will be lost (if not backed up).

bash -c "$(curl -fsSL https://veza-releases.s3.us-east-1.amazonaws.com/insightpoint/install.sh)" -- remove

Tips & Tricks

Pull from a different registry

The Insight Point image must be pulled from a pull-through cache or private registry (where the image is mirrored). You can override the image repository with the IMAGE_REPOSITORY config setting.

Create or edit the configuration in /etc/veza-insight-point/service.env to set the IMAGE_REPOSITORY configuration:

IMAGE_REPOSITORY="registry.example.com/veza/insight-point"

If pulling some other image version than the default image tag (latest), you need to configure the override using the IMAGE_TAG option:

IMAGE_TAG="myversion1"

After the changes have been made and saved, restart the Insight Point service:

sudo systemctl restart veza-insight-point

Check that the service has started successfully by running the following command:

systemctl status veza-insight-point

Using a proxy server

If you need to use a proxy server, add the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY lines to the Insight Point service configuration.

Create or edit the configuration file /etc/veza-insight-point/config.env to include the proxy server details:

HTTP_PROXY=http://proxy.local:8080
HTTPS_PROXY=http://proxy.local:8080
NO_PROXY=*.domain.local,*.domain2.local

To configure custom certificates, see the Using custom certificates section.

After the changes have been made and saved, restart the Insight Point service:

sudo systemctl restart veza-insight-point

Check that the service has started successfully by running the following command:

systemctl status veza-insight-point

Configuring Insight Point to forward connections to Veza (early access)

An Insight Point can proxy connections to Veza, allowing you to send Open Authorization API (OAA) payloads to a locally accessible server within a VPC instead of directly over the internet.

When a proxy port is enabled in the configuration, applications can push to the Insight Point's internal network address (e.g., http://localhost:8080/api/v1/providers/custom/...), instead of making API calls directly to Veza's cloud service (https://$VEZA_URL/api/v1/providers/custom/...).

Create or edit the configuration file /etc/veza-insight-point/service.env to set the proxy port:

PROXY_PORT=8080

Save the changes. Then, restart the Insight Point service:

sudo systemctl restart veza-insight-point

Proxy server is supported since Veza release 2025.5.x. For older Insight Points, you will need to reinstall before you can enable a proxy port:

bash -c "$(curl -fsSL https://veza-releases.s3.us-east-1.amazonaws.com/insightpoint/install.sh)" -- reinstall

Using custom certificates

Create or edit the configuration file /etc/veza-insight-point/service.env to mount the custom certificates to the Insight Point container:

CONTAINER_FLAGS="-v /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt"

After the changes have been made and saved, restart the Insight Point service:

sudo systemctl restart veza-insight-point

Check that the service has started successfully by running the following command:

systemctl status veza-insight-point

Troubleshooting

Status

Retrieve the status of the Insight Point systemd service:

systemctl status veza-insight-point.service

Logs

Retrieve last 500 log lines for the Insight Point service:

journalctl -n 500 -u veza-insight-point.service

Follow logs for the Insight Point service:

journalctl -u veza-insight-point.service -f

Reinstall

Reinstall will remove the currently installed Insight Point service and install it again. All configuration in /etc/veza-insight-point will be preserved.

bash -c "$(curl -fsSL https://veza-releases.s3.us-east-1.amazonaws.com/insightpoint/install.sh)" -- reinstall

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 main Secrets Vaults guide.

Overview

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.

Prerequisites

• 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

• An external Insight Point deployed in your environment

Azure Key Vault setup

Create or configure Key Vault

1. Navigate to the Azure portal and search for "Key vaults".

2. 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.

3. Note the Vault URI for your configuration.

   This will be in the format: https://your-vault-name.vault.azure.net/

Configure access control

Azure Key Vault supports two authorization models: Azure RBAC (recommended) and Access Policies (legacy). Microsoft recommends using Azure RBAC for new deployments.

Option 1: Azure RBAC (Recommended)

For new Key Vaults or those migrated to RBAC:

1. Ensure your Key Vault uses the RBAC permission model:

   Copy

   az keyvault update --name <vault-name> --resource-group <resource-group-name> --enable-rbac-authorization true

2. Navigate to your Key Vault resource.

3. Select Access control (IAM) from the left navigation.

4. Click + Add > Add role assignment.

5. 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

6. Click Save to apply the role assignment.

Option 2: Access Policies (Legacy)

For existing Key Vaults using access policies:

1. Navigate to your Key Vault resource.

2. Select Access policies from the left navigation.

3. Click + Add Access Policy.

4. 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

5. Click Add and then Save to apply the policy.

Note: Microsoft recommends migrating to Azure RBAC for improved security and management. See Microsoft's migration guide for details.

Azure Active Directory application setup

Set up Azure AD application

If you already have an Azure integration configured with Veza, you can use the existing app registration. Otherwise, follow the steps in the Azure integration guide to create an app registration.

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:

1. Navigate to Azure Active Directory > App registrations.

2. Click New registration.

3. 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

4. Click Register.

5. Record the following values from the Overview page:

   • Application (client) ID

   • Directory (tenant) ID

Generate client secret

1. From your application registration, navigate to Certificates & secrets.

2. Click New client secret.

3. Configure the secret:

   • Description: "Veza Insight Point Access"

   • Expires: Choose an appropriate expiration based on your security policies

4. Click Add.

5. Important: Copy the secret Value immediately.

   This value will only be displayed once and cannot be retrieved later.

Verify permissions

Ensure your application has the necessary permissions:

1. Navigate to API permissions in your application registration.

2. Verify the application has appropriate Microsoft Graph permissions if needed for your environment.

3. If using managed identities, ensure the identity has the required Key Vault access policies configured.

Secret format specifications

Active Directory secrets

For Active Directory integrations, store credentials in this JSON format:

{
  "username": "DOMAIN\\serviceaccount",
  "password": "your_secure_password",
  "ldaps_certificate": "-----BEGIN CERTIFICATE-----\nMIIEXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n-----END CERTIFICATE-----"
}

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)

Okta OAuth secrets

For Okta integrations using OAuth authentication:

{
  "client_id": "0oa1a2b3c4d5e6f7g8h9",
  "private_key_id": "your_key_id",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n-----END PRIVATE KEY-----"
}

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

Okta API Token secrets

For Okta integrations using API token authentication:

{
  "token": "00A1b2C3d4E5f6G7h8I9j0K1l2M3n4O5p6Q7r8S9"
}

Field requirements:

• token: Valid Okta API token with appropriate permissions

LDAP secrets

For LDAP integrations:

{
  "bind_dn_or_user": "cn=serviceaccount,ou=service,dc=example,dc=com",
  "bind_password": "your_secure_password",
  "ca_certificate": "-----BEGIN CERTIFICATE-----\nMIIEXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\nXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\n-----END CERTIFICATE-----"
}

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)

Security considerations

Network isolation

• 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

Access control

• 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

Certificate management

• 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

Troubleshooting

Authentication issues

Problem: "Access denied" errors when Insight Point attempts to retrieve secrets

Solutions:

1. Verify the client ID and secret are correct in the vault configuration

2. Check that access policies include both "Get" and "List" permissions for secrets

3. Ensure the tenant ID matches your Azure AD tenant

4. Verify the application registration is in the correct tenant

Network connectivity issues

Problem: Connection timeouts when accessing Key Vault

Solutions:

1. Verify network connectivity from the Insight Point to Azure Key Vault endpoints

2. Check firewall rules and network security groups

3. Confirm the Key Vault URI is correct and accessible

4. Test connectivity using tools like curl or wget from the Insight Point

Secret format issues

Problem: Integration fails to authenticate with target systems

Solutions:

1. Verify JSON formatting is correct (no extra spaces, proper escaping)

2. Ensure field names match the expected format for your integration type

3. Validate that certificates are in proper PEM format

4. Check that credentials are valid for the target system

Configuration file issues

Problem: Vault configuration not loaded by Insight Point

Solutions:

1. Verify the SECRETS_VAULTS_CONFIG_PATH environment variable is set correctly

2. Check that the YAML file is properly formatted

3. Ensure the Insight Point process has read permissions for the configuration file

4. Review Insight Point logs for configuration parsing errors

See also

• Main Secrets Vaults configuration guide

• Insight Point deployment guide

• Azure Key Vault documentation

• Azure Active Directory app registrations