Insight Point (Helm Chart)

An Insight Point is a lightweight agent that runs in your environment to securely connect Veza to internal data sources, relay webhooks, route Lifecycle Management actions, and support OAA custom integrations. Veza provides a Helm chart to deploy and manage an Insight Point on Kubernetes. Once deployed, the Insight Point can serve any integration that requires private network connectivity, including the Kubernetes integration for cluster RBAC discovery.

Configuration Options

The Insight Point Helm chart accepts the following configuration parameters via --set flags. Typically only key is required. To pull from a different registry, such as a mirror or private registry, or your Veza tenant's own registry domain (a mirror hosted by Veza), set the image parameter to your image reference; see Pulling Insight Point images from your tenant domain for options and prerequisites.

• 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

The Insight Point registration key can be referenced from a pre-existing Kubernetes Secret instead of being passed inline with --set key=<key>. This is useful when your values.yaml file is tracked in source control and cannot contain the registration key directly.

Create the Secret in the target namespace before installing the chart:

Install the chart using --set keySecret.name in place of --set key:

If the Secret stores the key under a field name other than the default key, set keySecret.path to the field name:

Only one of key or keySecret.name can be set. Providing both causes the install to fail.

If your Insight Point needs to trust custom Certificate Authorities (for example, when connecting through a corporate proxy with SSL inspection, or when the control plane uses certificates signed by a private CA), you can provide a custom CA bundle.

The CA bundle should be in PEM format and can contain multiple certificates.

Important: Do not use skipVerify=true in production. Instead, add your custom CA certificates using this feature. The skipVerify option should only be used for testing and development.

Create a file ca-values.yaml with the certificate contents:

Install or upgrade with:

To use an existing ConfigMap containing your CA bundle:

Note: The custom CA bundle is mounted to /etc/ssl/certs/ca-certificates.crt inside the container, which is the standard location for Go applications. This will replace the default system CA bundle, so ensure your custom bundle includes any default certificates you need to trust.

When using an HTTPS inspection proxy:

• Set addr to 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).

You can inject additional environment variables into the Insight Point pod using the env parameter. This is required by integrations that read configuration from the pod environment, such as Active Directory with .

In your values.yaml:

Or using --set flags:

Some integrations require credential files to be present at specific paths on the Insight Point pod. The Helm chart does not support arbitrary volume mounts. The /tmp directory is available as an ephemeral volume inside the container and can be used to place credential files.

Use kubectl cp to copy files to a running pod:

Tags are custom key-value labels that help organize and categorize your Insight Point instances. For an overview of tags, their use cases, and requirements, see in the main Insight Point documentation.

Create or edit your values.yaml:

Then install:

The Insight Point Helm chart supports high availability (HA) deployment to ensure continuous operation and resilience against node failures or pod disruptions. By default, the chart deploys three replicas of the Insight Point. You can customize the HA settings based on your requirements.

For high availability, deploy multiple Insight Point replicas:

• Single Instance: Use replicaCount: 1 for basic deployments

• High Availability: Use replicaCount: 2 or higher for production environments

• Recommended: replicaCount: 3 (default) provides good balance of availability and resource usage

When running multiple replicas, configure pod anti-affinity to distribute pods across nodes or availability zones:

• Soft Anti-Affinity: Kubernetes will try to place pods on different nodes/zones but will allow co-location if necessary

• Hard Anti-Affinity: Kubernetes will never place pods on the same node/zone, which may prevent scheduling if insufficient resources

Control the number of pods that can be disrupted simultaneously during maintenance:

The PodDisruptionBudget ensures that at least one Insight Point remains available during cluster updates, node maintenance, or voluntary pod evictions.

The webhook relay service allows the Insight Point to forward webhook requests to destinations in your private network. For an overview of webhook relay, when to use it, security considerations, and supported host formats, see in the main Insight Point documentation.

The following parameters configure webhook relay behavior:

Configure webhook relay when installing or upgrading the Insight Point:

Or when upgrading an existing deployment:

Create or edit a values.yaml file with webhook relay configuration:

Then install or upgrade with the values file:

To verify webhook relay is configured correctly:

1. Check the Helm values:

2. Check the pod environment variables:

If webhook relay is enabled but not working:

• Verify the allowed hosts are in the correct format

• Check that the destination is included in the allowed hosts list

• Review the Insight Point logs for validation or connection errors:

• Ensure the destination is actually reachable from the Insight Point's network

By default, the Helm chart creates a ClusterRole, ServiceAccount, and ClusterRoleBinding to enable the Insight Point to discover Kubernetes RBAC entities. The ClusterRole grants the following permissions:

When enableSecrets=true is set, the ClusterRole additionally grants list access to secrets across all namespaces.

Disabling RBAC resource creation: If your organization manages RBAC separately, set createClusterRole=false. When disabled, the chart skips all three RBAC resources — the ClusterRole, ClusterRoleBinding, and ServiceAccount. The pod will use the namespace default ServiceAccount. Create your own ServiceAccount, ClusterRole, and ClusterRoleBinding in the veza namespace before deploying.

The Insight Point can retrieve credentials from external secrets vault providers (such as Azure Key Vault) instead of requiring credentials to be passed directly. This is configured using the secretsVaultsConfig parameter or a reference to an existing Kubernetes secret.

If the secrets vault configuration already exists as a Kubernetes secret:

Only one of secretsVaultsConfig or secretsVaultsConfigSecretRef can be set.

The Helm chart supports standard Kubernetes scheduling parameters for controlling pod placement.

Constrain Insight Point pods to nodes with specific labels:

Allow pods to schedule on tainted nodes:

Control how pods are distributed across topology domains:

The Helm chart applies a pod-level that runs the Insight Point as the non-root nonroot user (UID/GID 1001) baked into the container image. The defaults are:

The defaults reproduce the chart's prior hard-coded settings. Existing deployments that do not override this value are unaffected

On OpenShift, assign UID/GID ranges per namespace and reject pods whose IDs fall outside the assigned range. The chart's default IDs (1001) are unlikely to be inside the range, so the pod is rejected at admission.

To let the platform assign IDs, override podSecurityContext and set the ID fields to null. The runAsNonRoot and seccompProfile assertions should be kept:

To omit the pod-level security context entirely and let the platform inject everything (including a default seccomp profile), set the value to null:

The Helm chart sets fixed resource requests and limits of 2 CPU cores and 4 GB RAM per pod. These values match the and cannot be overridden via Helm values. If your workload requires different resource allocation, contact Veza support.

Insight Point pods are configured to pull images on start, but a running pod keeps using the image it started with until it is restarted. The Helm chart includes a CronJob that periodically restarts the Insight Point to pull the latest image to keep it current with bug fixes and security patches.

This job is enabled by default and runs weekly (Sundays at 04:00 in the cluster timezone). The restart is graceful: pods are replaced one at a time, and Kubernetes waits for each replacement to become ready before continuing. In high-availability deployments (replicaCount greater than 1), the Insight Point remains available throughout the restart.

To change the schedule — for example, to refresh daily at 02:00 — set imageRefresh.schedule:

To disable the scheduled refresh entirely:

When enabled, the chart creates a Role, ServiceAccount, and RoleBinding scoped to the install namespace, granting permission to restart only the Insight Point's own workload. These are removed when the feature is disabled.

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

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:

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

OAuth2 client credentials provisioning is available on an Early Access basis. Contact Veza support to enable it for your organization.

Generate the OAuth2 provisioning values from the Veza Integrations > Insight Point > Create page. Create a Kubernetes Secret with the OAuth2 client credentials, then install the chart:

The chart sets AUTH_TYPE automatically when oauth2.enabled=true. Use --set-string for vezaVault.secretContent so Helm preserves the plain:<base64> value as a string.

vezaVault.secretContent appears in the Veza UI at creation time only, and you cannot retrieve it afterward. Include the plain: prefix, or the value fails to parse.

Rotating the client secret: Follow the standard flow at . After creating the new secret in the Veza UI, update the clientSecret key in the veza-ip-oauth2 Secret (kubectl edit secret veza-ip-oauth2 -n veza) and roll the deployment (kubectl rollout restart deployment/veza-insight-point -n veza), then delete the old secret from the UI.