> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point/insight-point-kubernetes.md). # Deploy with Kubernetes (Helm) Deploy an Insight Point to a Kubernetes cluster An [Insight Point](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md) 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. After deployment, the Insight Point can serve any integration that requires private network connectivity, including the optional [Kubernetes integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/kubernetes.md) for cluster RBAC discovery. The sections below cover requirements, installation, and the configuration options available through the Helm chart's `values.yaml`. ## 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](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#system-requirements) (minimum: 2 CPU cores, 4 GB RAM per Insight Point pod). * **Kubernetes version**: Running more than one replica requires Kubernetes 1.28 or later. The chart runs three replicas by default. See [Replica count](#replica-count). * **Insight Point credentials**: The OAuth2 values that Veza generates when you create the Insight Point (**Integrations** > **Insight Points** > **Create Insight Point**), or the registration key of an existing Insight Point. See [Authentication](#authentication). * **Chart version**: Every `helm install` and `helm upgrade` command on this page passes `--version`. Chart versions use the form `YYYY.M.D-N`, for example `2026.9.28-2`. Published versions are listed in [Veza's OCI repository](https://gallery.ecr.aws/veza/helm-chart/insight-point). There is no `latest` chart version. The Helm command that Veza displays during OAuth2 provisioning includes the version for your Veza release. * **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](https://helm.sh/docs/intro/install/). * Your organization security policies must allow chart installation from the VEZA ECR `public.ecr.aws/veza` ## Installation Decide the following before you run `helm install`. Some choices require Kubernetes objects to exist before installation: * **Namespace**: the installation steps create the namespace first, because any Secret or ConfigMap that the chart references must exist in the release namespace before you install. * **Authentication method to Veza**: OAuth2 client credentials, or the registration key of an existing Insight Point. See [Authentication](#authentication). * **Image source**: the default image `public.ecr.aws/veza/insight_point:latest`, or a private registry, a mirror, or your tenant's registry domain. To use a different image, set the `image` value. See [Pulling Insight Point images from your tenant domain](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point/insight-point-tenant-registry.md). * **TLS trust path**: direct connection to Veza, or through an inspection proxy. Proxies may require additional certificate authority (CA) configuration. See [Networking and TLS](#networking-and-tls). * **RBAC ownership**: by default, the chart creates the ClusterRole, ServiceAccount, and ClusterRoleBinding that the optional [Kubernetes integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/kubernetes.md) uses. If you do not use the Kubernetes integration, or your organization manages RBAC separately, see [RBAC and Kubernetes permissions](#rbac-and-kubernetes-permissions). * **Platform type**: standard Kubernetes, or OpenShift/another SCC-managed platform, where the default pod security context must be overridden or the pod is rejected at admission. See [OpenShift and other SCC-managed platforms](#openshift-and-other-scc-managed-platforms). * **Secrets vault**: whether integrations retrieve credentials from an external secrets vault. See [Secrets vault configuration](#secrets-vault-configuration). You can set other options, such as tags, replica count and HA tuning, scheduling constraints, webhook relay, and environment variables, at install time or add them later. To change values on an existing installation, see [Upgrade the Insight Point](#upgrade-the-insight-point). The examples on this page use the namespace `veza` and the release name `veza-insight-point`. If you use different names, substitute them in each command. ### Install the Insight Point Follow the steps for your authentication method. #### Install with a registration key 1. Create the namespace (skip if it already exists): ```bash kubectl create namespace veza ``` 2. Create a Secret that contains your registration key: ```bash kubectl create secret generic veza-ip-key \ --namespace veza \ --from-literal=key="" ``` 3. Create `values.yaml`: ```yaml keySecret: name: veza-ip-key ``` 4. Install the chart: ```shell helm install veza-insight-point oci://public.ecr.aws/veza/helm-chart/insight-point --version "" --namespace veza -f values.yaml ``` #### Install with OAuth2 client credentials To reconfigure an Insight Point that already runs with a registration key, see [Migrate an Insight Point to OAuth2](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point/oauth2-migration.md). When you create the Insight Point, Veza displays the values that the following steps use: the Insight Point ID, the Veza host, the OAuth2 client ID and client secret, and the vault secret. Veza displays the client secret and the vault secret only once. 1. Create the namespace (skip if it already exists): ```bash kubectl create namespace veza ``` 2. Create a Secret with your OAuth2 client credentials: ```bash kubectl create secret generic veza-ip-oauth2 \ --namespace veza \ --from-literal=clientId="" \ --from-literal=clientSecret="" ``` 3. Create a Secret with the vault secret. Copy the value exactly as Veza displays it, including the `plain:` prefix: ```bash kubectl create secret generic veza-ip-vault \ --namespace veza \ --from-literal=vaultSecret='' ``` 4. Create `values.yaml`: ```yaml insightPointId: addr: oauth2: enabled: true secretName: veza-ip-oauth2 vezaVault: secretName: veza-ip-vault ``` 5. Install the chart: ```shell helm install veza-insight-point oci://public.ecr.aws/veza/helm-chart/insight-point --version "" --namespace veza -f values.yaml ``` The Helm command that Veza displays during provisioning passes the vault secret inline with `vezaVault.secretContent`. The steps above store it in a Secret instead, so that it does not appear in the Helm release values. {% hint style="info" %} The chart validates values when it renders, so `helm template` with the same values file reports invalid combinations before you install. See [Value rules](#value-rules). You can also pass individual values with `--set` instead of a `values.yaml` file, for example `--set keySecret.name=veza-ip-key`. For list values, use an index, for example `--set 'webhookRelay.allowedHosts[0]=*.example.com'`. {% endhint %} ### Verify the installation 1. Verify the status of the installation: ```shell helm list -n veza ``` This command returns a list of Helm releases, including the Insight Point you just installed. Confirm that the STATUS column shows `deployed`. 2. If the Insight Point fails to initialize or can't connect to Veza, review the container logs: ```shell kubectl logs -l app=insight-point -n veza ``` ### Upgrade the Insight Point To upgrade to a newer chart version or change the configuration, edit `values.yaml` and run `helm upgrade` with the same file: ```shell helm upgrade veza-insight-point oci://public.ecr.aws/veza/helm-chart/insight-point --version "" --namespace veza -f values.yaml ``` Newer versions can introduce breaking changes (for example, replacing Kubernetes resources with others), which can cause a brief unavailability of the Insight Point. {% hint style="info" %} Pass your values file on every upgrade instead of `--reuse-values`. The `--reuse-values` flag keeps the values of the previous release and ignores default values that a newer chart version adds. {% endhint %} ### Uninstall the Insight Point To uninstall the Insight Point, run `helm uninstall`: ```shell helm uninstall veza-insight-point --namespace veza ``` ## Authentication New Insight Points authenticate to Veza with OAuth2 client credentials. An existing Insight Point can continue to use its registration key. ### Registration key * The Veza UI no longer creates registration keys. An existing key keeps working, and each key is unique to one Insight Point deployment. * Store the key in a Kubernetes Secret and reference it with `keySecret.name`, so that the key does not appear in the Helm release values. * If the Secret stores the key under a field other than `key`, set `keySecret.path` to that field name. * The `key` value passes the key inline, and the chart stores it in a Secret named `insight-point-key`. Use `key` only in test environments, because the key is stored in the Helm release values. ### OAuth2 client credentials Generate the provisioning values from the Veza **Integrations** > **Insight Point** > **Create** page. See [Install with OAuth2 client credentials](#install-with-oauth2-client-credentials) for the full setup. The chart sets `AUTH_TYPE` automatically when `oauth2.enabled=true`. The Veza Vault secret contains the private key that the Insight Point uses to decrypt the integration credentials stored in Veza. Veza displays it one time, when you create the Insight Point, and does not store a copy. If you lose it, create a new Insight Point and re-enter the credentials for each integration assigned to the old one. For the encryption model, see [Data encryption](/4yItIzMvkpAvMVFAamTf/security.md#data-encryption). Keep the `plain:` prefix, or the value fails to parse. If you pass the value inline with `vezaVault.secretContent`, quote it in `values.yaml` (or use `--set-string` on the command line) so it's preserved as a string rather than reinterpreted by Helm. If you set neither `vezaVault.secretName` nor `vezaVault.secretContent`, the Insight Point runs in external-vault-only mode. It cannot decrypt credentials stored in Veza, so every integration that uses the Insight Point must retrieve its credentials from an [external secrets vault](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults.md). **Rotating the client secret:** Follow the standard flow at [Manage client secrets](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-clients.md#manage-client-secrets). 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 StatefulSet (`kubectl rollout restart statefulset/veza-insight-point -n veza`), then delete the old secret from the UI. | Parameter | Description | Default | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- | | `key` | Registration key, passed inline. The chart stores it in a Secret named `insight-point-key`. For test environments only, because the value is stored in the Helm release values | `""` | | `keySecret.name` | Name of an existing Kubernetes Secret that contains the registration key | `""` | | `keySecret.path` | Field in the `keySecret.name` Secret that contains the registration key | `"key"` | | `addr` | Address for Veza API connection. Optional with a registration key (overrides the key's default); required when `insightPointId` is set | `""` | | `insightPointId` | Insight Point identifier from OAuth2 provisioning in the Veza UI | `""` | | `oauth2.enabled` | Enable OAuth2 client credentials authentication | `false` | | `oauth2.secretName` | Name of an existing Kubernetes Secret with `clientId` and `clientSecret` keys. If unset, the chart uses `insight-point-oauth2` | `""` | | `vezaVault.secretName` | Name of an existing Kubernetes Secret with a `vaultSecret` key | `""` | | `vezaVault.secretContent` | Vault secret, passed inline. The chart stores it in a Secret named `insight-point-vault-secret` | `""` | {% hint style="info" %} The referenced Secret values must exist in the same namespace as the Helm release before the chart is installed. If the Secret is missing, the Insight Point pod fails to start with a Kubernetes `secret not found` error. {% endhint %} ## Networking and TLS When deploying the Insight Point behind a network proxy or inspector it may be necessary to include additional trusted certificate authority bundles. | Parameter | Description | Default | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------- | | `skipVerify` | Disable TLS certificate validation | `false` | | `authority` | Overrides the request authority for certificate validation | `""` | | `caBundle` | Custom CA certificate bundle in PEM format (inline). See [Custom CA certificate bundle](#custom-ca-certificate-bundle) | `""` | | `caBundleConfigMapRef` | Reference to existing ConfigMap containing CA bundle | `""` | `addr` (see [Authentication](#authentication)) can also be used to point the Insight Point at a proxy address; see [Proxy configuration](#proxy-configuration) below. `skipVerify` (`TLS_INSECURE_SKIP_VERIFY`) should only be set to `true` to disable certificate validation for testing/troubleshooting. ### Custom CA certificate bundle 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. #### Option 1: Inline CA bundle Add the certificate contents to `values.yaml`. The chart creates the ConfigMap: ```yaml caBundle: | -----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAKZ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAKZ... -----END CERTIFICATE----- ``` Then install or upgrade with your values file. #### Option 2: Reference to existing ConfigMap To use an existing ConfigMap, create it in the release namespace before you install. The ConfigMap must store the bundle under the key `ca-certificates.crt`: ```bash kubectl create configmap custom-ca-bundle \ --from-file=ca-certificates.crt=/path/to/your/ca-bundle.crt \ -n veza ``` Then reference it in `values.yaml`: ```yaml caBundleConfigMapRef: custom-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. #### Proxy configuration 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). * Use the custom CA bundle feature (above) to trust your proxy's CA certificate. ## High availability and scheduling The Insight Point Helm chart supports high availability (HA) deployment to ensure continuous operation and resilience against node failures or pod disruptions, and standard Kubernetes scheduling parameters for controlling pod placement. | Parameter | Description | Default | | --------------------------- | ------------------------------------------------------ | ------- | | `replicaCount` | Number of Insight Point replicas for high availability | `3` | | `nodeSelector` | Constrain pods to nodes with specific labels | `{}` | | `tolerations` | Allow pods to schedule on tainted nodes | `[]` | | `topologySpreadConstraints` | Control pod distribution across topology domains | `[]` | ### Replica count 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 * **Default**: `replicaCount: 3` balances availability and resource usage Running more than one replica requires Kubernetes 1.28 or later. `replicaCount` must be between 1 and 10. ### Pod anti-affinity When running multiple replicas, configure pod anti-affinity to distribute pods across nodes or availability zones: | Parameter | Description | Values | Default | | ----------------------------- | ------------------------- | ------------------------------------------------------------------------- | ------------------------ | | `podAntiAffinity.type` | Anti-affinity enforcement | `soft` (preferred) or `hard` (required) | `soft` | | `podAntiAffinity.topologyKey` | Distribution topology | `kubernetes.io/hostname` (nodes) or `topology.kubernetes.io/zone` (zones) | `kubernetes.io/hostname` | * **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 ### Pod disruption budget Control the number of pods that can be disrupted simultaneously during maintenance: | Parameter | Description | Default | | ---------------------------------- | ------------------------------------------------------------------------- | ------- | | `podDisruptionBudget.enabled` | Enable PodDisruptionBudget | `true` | | `podDisruptionBudget.minAvailable` | Minimum pods that must remain available. Must be less than `replicaCount` | `1` | The PodDisruptionBudget ensures that at least one Insight Point remains available during cluster updates, node maintenance, or voluntary pod evictions. The chart creates it only when `replicaCount` is greater than 1. ### Node selector Constrain Insight Point pods to nodes with specific labels: ```yaml nodeSelector: disktype: ssd node-role.kubernetes.io/compute: "true" ``` ### Tolerations Allow pods to schedule on tainted nodes: ```yaml tolerations: - key: dedicated operator: Equal value: insight-point effect: NoSchedule ``` ### Topology spread constraints Control how pods are distributed across topology domains: ```yaml topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: insight-point ``` ## RBAC and Kubernetes permissions When the Insight Point is deployed in a Kubernetes Cluster the [Veza Kubernetes Integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/kubernetes.md) can be configured to discover identity and authorization data for the Kubernetes Cluster. This integration is optional. | Parameter | Description | Default | | ------------------- | --------------------------------------------------------------------------------------------------- | -------------------- | | `createClusterRole` | Create the ClusterRole, ServiceAccount, and ClusterRoleBinding that the Kubernetes integration uses | `true` | | `roleName` | Name of the ClusterRole created when `createClusterRole` is enabled | `veza-insight-point` | | `enableSecrets` | Enable Kubernetes Secrets extraction via ClusterRole permissions | `false` | By default, the Helm chart creates a ClusterRole, a ServiceAccount named `veza-insight-point`, and a ClusterRoleBinding, and runs the pod as that ServiceAccount. Only the Kubernetes integration uses these permissions. The ClusterRole grants the following permissions: | Resource | API Group | Verbs | Purpose | | --------------------- | --------------------------- | ------ | ------------------------------------------ | | `namespaces` | `""` | `list` | Discover cluster namespaces | | `configmaps` | `""` | `get` | Read configuration | | `clusterroles` | `rbac.authorization.k8s.io` | `list` | Discover RBAC roles | | `clusterrolebindings` | `rbac.authorization.k8s.io` | `list` | Discover role assignments | | `roles` | `rbac.authorization.k8s.io` | `list` | Discover namespace-scoped roles | | `rolebindings` | `rbac.authorization.k8s.io` | `list` | Discover namespace-scoped role assignments | Kubernetes Secrets are not extracted by default. To extract them, add the following to `values.yaml`. The ClusterRole then also grants `list` access to `secrets` across all namespaces: ```yaml enableSecrets: true ``` **Disabling RBAC resource creation:** If you do not use the Kubernetes integration, or your organization manages RBAC separately, set `createClusterRole=false`. When disabled, the chart skips all three RBAC resources: the ClusterRole, ClusterRoleBinding, and ServiceAccount. The pod then runs as the `default` ServiceAccount of the release namespace, because the chart provides no value for naming a different ServiceAccount. To use the Kubernetes integration with chart-managed RBAC disabled, create a ClusterRole with the permissions above and a ClusterRoleBinding that binds it to the `default` ServiceAccount in the release namespace before deploying. When the [scheduled image refresh](#scheduled-image-refresh) is enabled (the default), the chart also creates a namespaced Role, RoleBinding, and ServiceAccount named `veza-insight-point-restart`, regardless of `createClusterRole`. ## Secrets and credentials | Parameter | Description | Default | | ------------------------------ | -------------------------------------------------------------------------------------------------- | ------- | | `env` | List of additional environment variables to inject into the pod | `[]` | | `secretsVaultsConfig` | Inline YAML configuration for secrets vault providers | `{}` | | `secretsVaultsConfigSecretRef` | Reference to an existing Kubernetes secret with vault config | `""` | | `filesystemVaultSecrets` | Existing Kubernetes Secrets to mount for the [filesystem secrets vault](#filesystem-vault-secrets) | `[]` | ### Custom environment variables 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 [Kerberos Token Authentication](/4yItIzMvkpAvMVFAamTf/integrations/integrations/active-directory.md#kerberos-token-authentication). In your `values.yaml`: ```yaml env: - name: KRB5_CONFIG value: /tmp/krb5.conf - name: KRB5CCNAME value: /tmp/krb5cc_go - name: LDAP_CERTIFICATE value: /tmp/ldap_cert.pem ``` Then install or upgrade with your values file. Set each variable to the path where the file is available in the container. ### Placing credential files on the pod Some integrations require credential files, such as a Kerberos configuration, a Kerberos credential cache, or an LDAP certificate, at the paths named by their environment variables. Before the integration can connect, each file must be: * Readable inside the Insight Point container at the path its environment variable names. * Present on every replica (three by default). * Kept across pod restarts, including the [scheduled image refresh](#scheduled-image-refresh), which restarts every pod weekly by default. The chart has no general volume-mount value, and `/tmp` is an ephemeral volume that is empty each time a pod starts. Make the files available with your own deployment tools, for example by mounting them from a Kubernetes Secret. {% hint style="info" %} The Insight Point container uses a minimal base image, and tools such as `kinit` are not available inside it. Generate Kerberos credential caches on an external host. Plan a process to renew the credential cache, and update the file on every replica before tickets expire. The default lifetime is 5 days, subject to the maximum configured on your domain controller. {% endhint %} ### Secrets vault configuration The Insight Point can retrieve credentials from an external [secrets vault](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults.md) instead of requiring credentials to be passed directly. The providers are [Azure Key Vault](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults/azure-key-vault.md), [HashiCorp Vault](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults/hashicorp-vault.md), and the [filesystem provider](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults/kubernetes-secrets.md), which reads Kubernetes Secrets mounted on the pod. This is configured using the `secretsVaultsConfig` parameter or a reference to an existing Kubernetes secret. #### Inline configuration Add the configuration to `values.yaml`. The chart stores it in a Secret: ```yaml secretsVaultsConfig: vaults: - name: example-vault vault_provider: azure_key_vault auth_type: client_secret auth_config: vault_uri: https://my-vault.vault.azure.net tenant_id: client_id: client_secret: ``` #### Reference to existing secret If the secrets vault configuration already exists as a Kubernetes secret in the release namespace, reference it in `values.yaml`. The Secret must store the configuration under the key `config.yaml`: ```yaml secretsVaultsConfigSecretRef: my-vault-config ``` Only one of `secretsVaultsConfig` or `secretsVaultsConfigSecretRef` can be set. #### Filesystem vault secrets The [filesystem secrets vault](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults/kubernetes-secrets.md) reads credentials from Kubernetes Secrets mounted on the Insight Point pod, for example Secrets that the HashiCorp [Vault Secrets Operator](https://developer.hashicorp.com/vault/docs/platform/k8s/vso) keeps in sync. It requires Insight Point v2026.9.28 or later. The `filesystemVaultSecrets` value mounts each existing Secret as its own read-only volume. The files are readable only through the pod's `fsGroup`, so if you override the [pod security context](#pod-security-context), keep an `fsGroup` set or let the platform assign one: | Parameter | Description | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | `filesystemVaultSecrets[].name` | Used to name the pod volume, `fsvault-`. Need not match `secretName`. See the rules after this table. | | `filesystemVaultSecrets[].secretName` | Name of an existing Kubernetes Secret in the release namespace | | `filesystemVaultSecrets[].mountPath` | Absolute path in the Insight Point container where the Secret is mounted | The chart validates none of these fields, so a mistake surfaces only when Kubernetes applies the manifest or when an integration fetches a secret: * `fsvault-` must be a valid volume name of 63 characters or fewer. Keep `name` to 55 characters or fewer, using lowercase letters, digits, and `-`, and unique across entries. * `mountPath` must be an absolute path. The chart passes it to the volume mount unchanged. * Each entry takes only these three fields. The chart has no option to mount a single key with `subPath`. Pair the entries with a `filesystem` vault in `secretsVaultsConfig`. How `mountPath` relates to the vault's `auth_config.mount_path` depends on the vault's `mode`: * **`directory` mode:** `mount_path` is the **parent** directory. Mount each Secret one level under it, so that `mountPath` is `mount_path` plus `/` plus a directory name. The directory name is the **Secret Path** you enter on the integration. * **`file` mode:** `mount_path` is the **same** as the Secret's `mountPath`. The Secret Path is the name of one key, whose file holds a JSON object. {% hint style="warning" %} The comment for `filesystemVaultSecrets` in the chart's `values.yaml` says to set `mount_path` to match each entry's `mountPath`. That applies only to `file` mode. In `directory` mode, setting `mount_path` to a Secret's own `mountPath` makes every secret fetch fail with `failed to list secret directory`. {% endhint %} This example serves two Secrets from one `directory` vault: ```yaml filesystemVaultSecrets: - name: prod-ad-credentials secretName: prod-ad-credentials mountPath: /etc/veza/filesystem-vault/prod-ad-credentials - name: prod-okta-credentials secretName: prod-okta-credentials mountPath: /etc/veza/filesystem-vault/prod-okta-credentials secretsVaultsConfig: vaults: - name: Kubernetes Secrets vault_provider: filesystem auth_type: none auth_config: mount_path: /etc/veza/filesystem-vault mode: directory ``` On each integration, select **Kubernetes Secrets** as the **External Vault**, and enter `prod-ad-credentials` or `prod-okta-credentials` as the **Secret Path**. To add a Secret, add an entry under the same parent directory. You don't need another vault. For a Secret with one key that holds the credentials as JSON, add a `file` mode vault whose `mount_path` is that Secret's `mountPath`: ```yaml filesystemVaultSecrets: - name: prod-okta-json secretName: prod-okta-json mountPath: /etc/veza/filesystem-vault-json/prod-okta-json secretsVaultsConfig: vaults: - name: Okta JSON credentials vault_provider: filesystem auth_type: none auth_config: mount_path: /etc/veza/filesystem-vault-json/prod-okta-json mode: file ``` Here the Secret Path is the key's name, such as `credentials.json`. For how the provider reads each mode, which Secret keys it accepts, and the errors for a wrong path, see [Filesystem secrets vault (Kubernetes Secrets)](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/secrets-vaults/kubernetes-secrets.md). ## Configuring tags Tags are custom key-value labels for your Insight Point instances. For their use cases and requirements, see [Tags](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#tags). Add tags to your `values.yaml`: ```yaml tags: environment: production datacenter: us-west-1 team: platform-engineering owner: ops-team@example.com ``` Then install or upgrade with your values file. To change tags on an existing deployment, edit them in `values.yaml` and [upgrade the Insight Point](#upgrade-the-insight-point). ## Webhook relay configuration Webhook relay forwards webhook requests to destinations in your private network. For when to use it, security considerations, and supported host formats, see [Webhook Relay](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#webhook-relay). ### Configuration options The following parameters configure webhook relay behavior: | Parameter | Description | Default | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | `webhookRelay.enabled` | Enable the webhook relay service | `false` | | `webhookRelay.allowedHosts` | A list of allowed destinations (supports multiple formats as documented in [Webhook Relay](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#webhook-relay)) | `[]` | ### Configuration via values.yaml Add the webhook relay configuration to your `values.yaml`: ```yaml webhookRelay: enabled: true allowedHosts: - "webhook.site" - "*.example.com" # Wildcard domain - "172.17.0.100" # IP address - "10.0.0.0/8" # CIDR range - "172.16.*" # Wildcard IP ``` Then install or upgrade with your values file. ### Verifying webhook relay configuration To verify webhook relay is configured correctly: 1. Check the Helm values: ```bash helm get values veza-insight-point -n veza ``` 2. Check the pod environment variables: ```bash kubectl get pods -n veza -l app=insight-point -o jsonpath='{.items[0].spec.containers[0].env}' | jq ``` 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: ```bash kubectl logs -l app=insight-point -n veza ``` * Ensure the destination is actually reachable from the Insight Point's network ## Pod security context The Helm chart applies a pod-level [`PodSecurityContext`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSecurityContext) that runs the Insight Point as the non-root `nonroot` user (UID/GID `1001`) baked into the container image. The defaults are: ```yaml podSecurityContext: fsGroup: 1001 runAsNonRoot: true runAsUser: 1001 runAsGroup: 1001 seccompProfile: type: RuntimeDefault ``` | Parameter | Description | Default | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- | | `podSecurityContext.fsGroup` | Group ID applied to files in mounted volumes so the container process can write to them; matches the `nonroot` user in the image | `1001` | | `podSecurityContext.runAsNonRoot` | Prevents the pod from running as root even if the image is misconfigured to do so | `true` | | `podSecurityContext.runAsUser` | User ID the container process runs as; matches the `nonroot` user in the image | `1001` | | `podSecurityContext.runAsGroup` | Primary group ID for the container process; matches the `nonroot` user in the image | `1001` | | `podSecurityContext.seccompProfile.type` | Seccomp profile applied to the container; `RuntimeDefault` uses the container runtime's default, restricting the syscalls the container can make | `RuntimeDefault` | The defaults reproduce the chart's prior hard-coded settings. Existing deployments that do not override this value are unaffected. {% hint style="info" %} The container-level security context (`readOnlyRootFilesystem: true`, non-root, dropped Linux capabilities, and the seccomp profile) is enforced by the chart independently and is not affected by `podSecurityContext`. {% endhint %} ### OpenShift and other SCC-managed platforms On OpenShift, [Security Context Constraints](https://docs.openshift.com/container-platform/latest/authentication/managing-security-context-constraints.html) 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: ```yaml podSecurityContext: fsGroup: null runAsUser: null runAsGroup: null runAsNonRoot: true seccompProfile: type: RuntimeDefault ``` {% hint style="warning" %} Helm merges the `podSecurityContext` value with the chart defaults field-by-field. A partial override (for example, setting only `runAsNonRoot: true`) does not remove the default IDs. They remain in place, and the pod is still rejected. You must explicitly set each ID field to `null` to clear it. {% endhint %} To omit the pod-level security context entirely and let the platform inject everything (including a default seccomp profile), set the value to `null`: ```yaml podSecurityContext: null ``` ## Resource allocation The Helm chart sets fixed resource requests and limits of **2 CPU cores** and **4 GB RAM** per pod. These values match the [system requirements](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md#system-requirements) and cannot be overridden via Helm values. If your workload requires different resource allocation, contact Veza support. ## Maintenance ### Scheduled image refresh 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 time zone). 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. {% hint style="info" %} The Insight Point continuously checks for and applies updates to its core agent independently of the cron operation. The scheduled image refresh is intended for updating the underlying container image (for example, operating-system security patches), which the in-place update does not change. The refresh job runs the Insight Point's own image and does not pull any additional images, so it works in air-gapped environments and registry mirrors without extra configuration. {% endhint %} | Parameter | Description | Default | | ----------------------- | ------------------------------------------------- | ----------- | | `imageRefresh.enabled` | Enable the scheduled image refresh | `true` | | `imageRefresh.schedule` | Cron schedule for the refresh (cluster time zone) | `0 4 * * 0` | To change the schedule, for example to refresh daily at 02:00, set `imageRefresh.schedule` in `values.yaml`: ```yaml imageRefresh: schedule: "0 2 * * *" ``` To disable the scheduled refresh entirely: ```yaml imageRefresh: enabled: false ``` Then [upgrade the Insight Point](#upgrade-the-insight-point) with your values file. 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. ## Value rules The chart checks values when it renders and stops with an error if any of these rules is broken: * Set exactly one of `key`, `keySecret.name`, or `insightPointId`. * When `insightPointId` is set, `addr` must also be set. * When `keySecret.name` is set, `keySecret.path` cannot be empty. With an inline `key`, `keySecret.path` must stay `key`. * `vezaVault.secretName` and `vezaVault.secretContent` cannot be combined with `key` or `keySecret.name`. Set at most one of the two. * Set at most one of `caBundle` and `caBundleConfigMapRef`. * Set at most one of `secretsVaultsConfig` and `secretsVaultsConfigSecretRef`. * `replicaCount` must be between 1 and 10. * With more than one replica, `podAntiAffinity.type` must be `soft` or `hard`, and when the PodDisruptionBudget is enabled, `podDisruptionBudget.minAvailable` must be less than `replicaCount`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point/insight-point-kubernetes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.