Immuta helps you achieve the following outcomes in your data platform:

How does Immuta do it?

Immuta provides three modules to create a full data security platform suite.

Discover sensitive data from millions of fields without manual effort. With over 60 pre-built and domain-specific identifiers, you can tailor data classification to your unique business needs based on your desired confidence level.

Leverage timely insights into data access and user activity with anomaly indicators for faster analysis and proactive actions.

Immuta’s attribute-based access control (ABAC) delivers scalable data access without role explosion, and dynamic data masking ensures the right users can access the right data.

This is a guide on how to deploy Immuta on Kubernetes in the following managed public cloud providers:

• Amazon Web Services (AWS)

• Microsoft Azure

• Google Cloud Platform (GCP)

Prerequisites

Checklist

This checklist outlines the necessary prerequisites for successfully deploying Immuta.

Credentials

PostgreSQL

• You have a PostgreSQL user account with the necessary privileges to create databases, extensions, and roles.

Elasticsearch

Setup

Helm

Authenticate with OCI registry

echo <token> | helm registry login --password-stdin --username <username> ocir.immuta.com

Kubernetes

Create namespace

1. Create a Kubernetes namespace named immuta.

   Copy

   kubectl create namespace immuta

2. Switch to namespace immuta. All subsequent kubectl commands will default to this namespace.

   Copy

   kubectl config set-context --current --namespace=immuta

Create registry secret

kubectl create secret docker-registry immuta-oci-registry \
    --docker-server=https://ocir.immuta.com \
    --docker-username="<username>" \
    --docker-password="<token>" \
    --docker-email=support@immuta.com

PostgreSQL

Connect to the database

Connect to the database as an admin (e.g., postgres) by creating an ephemeral container inside the Kubernetes cluster. A shell prompt will not be displayed after executing the kubectl run command outlined below. Wait 5 seconds, and then proceed by entering a password.

kubectl run pgclient \
    --stdin \
    --tty \
    --rm \
    --image docker.io/bitnami/postgresql -- \
    psql --host <postgres-fqdn> --username <postgres-user> --port 5432 --password

Create role

1. Create the immuta role.

   Copy

   CREATE ROLE immuta with LOGIN ENCRYPTED PASSWORD '<postgres-password>';
   ALTER ROLE immuta SET search_path TO bometadata,public;

2. Grant administrator privileges to the immuta role. Upon successfully completing this installation guide, you can optionally revoke this role grant.

   Copy

   GRANT <admin-role> TO immuta;

3. Grant the immuta role to the current user. Upon successfully completing this installation guide, you can optionally revoke this role grant.

   Copy

   GRANT immuta TO CURRENT_USER;

Create databases

1. Create databases.

   Copy

   CREATE DATABASE immuta OWNER immuta;
   CREATE DATABASE temporal OWNER immuta;
   CREATE DATABASE temporal_visibility OWNER immuta;

2. Copy

   GRANT ALL ON DATABASE immuta TO immuta;
   GRANT ALL ON DATABASE temporal TO immuta;
   GRANT ALL ON DATABASE temporal_visibility TO immuta;

3. Configure the immuta database.

   Copy

   \c immuta
   CREATE EXTENSION pgcrypto;

4. Configure the temporal database.

   Copy

   \c temporal
   GRANT CREATE ON SCHEMA public TO immuta;

5. Configure the temporal_visibility database.

   Copy

   \c temporal_visibility
   GRANT CREATE ON SCHEMA public TO immuta;
   CREATE EXTENSION btree_gin;

6. Exit the interactive prompt. Type \q, and then press Enter.

Install Immuta

This section demonstrates how to deploy Immuta using the Immuta Enterprise Helm chart once the prerequisite cloud-managed services are configured.

global:
  imageRegistry: ocir.immuta.com
  imagePullSecrets:
    - name: immuta-oci-registry
  postgresql:
    host: <postgres-fqdn>
    port: 5432
    username: immuta
    password: <postgres-password>

audit:
  config:
    elasticsearchEndpoint: <elasticsearch-endpoint>
    elasticsearchUsername: <elasticsearch-username>
    elasticsearchPassword: <elasticsearch-password>
  postgresql:
    database: immuta

secure:
  postgresql:
    database: immuta
    ssl: true

temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls: 
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true

global:
  imageRegistry: ocir.immuta.com
  imagePullSecrets:
    - name: immuta-oci-registry
  featureFlags:
    AuditService: false
    detect: false
    auditLegacyViewHide: false
  postgresql:
    host: <postgres-fqdn>
    port: 5432
    username: immuta
    password: <postgres-password>

audit:
  enabled: false

secure:
  postgresql:
    database: immuta
    ssl: true
    
temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls: 
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true

2. Deploy Immuta.

   Copy

   helm install immuta oci://ocir.immuta.com/stable/immuta-enterprise \
       --values immuta-values.yaml \
       --version 2024.3.9

3. Wait for all pods to become ready.

   Copy

   kubectl wait --for=condition=Ready pods --all

Validation

1. Determine the name of the Secure service.

   Copy

   kubectl get service --selector "app.kubernetes.io/component=secure" --output name

2. Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.

   Copy

   kubectl port-forward <service-name> 8080:http

4. Press Control+C to stop port forwarding.

Next steps

Immuta comprises three core services: Secure, Discover, and Detect. These services rely on PostgreSQL and Elasticsearch to store their states, a caching layer, and Temporal for job execution. The illustration below shows the relationships among these services.

The Immuta Enterprise Helm chart (IEHC) does not include the deployment of PostgreSQL or Elasticsearch, so you must deploy them separately.

Although Immuta recommends using Elasticsearch because it supports several new Immuta features and services, you can deploy Immuta without Elasticsearch. The table below outlines the Immuta features supported with and without Elasticsearch and the dependencies you must deploy and manage yourself.

Version requirements

Kubernetes versions

• Kubernetes 1.29 to 1.32

Metadata database (PostgreSQL)

• PostgreSQL 15.0 or newer

• The pgcrypto, btree_gin extensions must be enabled

Elasticsearch

• Elasticsearch v7 API or newer

• OpenSearch compatible with Elasticsearch v7 API or newer

OpenSearch user

• cluster:monitor/health

• indices:data/write/bulk*

• indices:data/write/bulk

• indices:data/read/search

• indices:admin/exists

• indices:admin/create

• indices:admin/delete

• indices:admin/settings/update

• indices:admin/get

• indices:data/write/delete/byquery

• indices:data/write/index

• indices:admin/mapping/put

• indices:data/write/bulk

• indices:data/write/bulk*

Cache (Redis/Memcached)

• Redis 7.0 or newer

• Memcached 1.6 or newer

Temporal

• Temporal 1.24.2 or newer

Infrastructure recommendations

Legacy features and services

Some legacy services and features are no longer enabled in the recommended configuration of the IEHC. The table below lists these features and provides links to documentation that outlines how to enable them in Immuta.

This guide demonstrates how to upgrade an existing Immuta deployment installed with the older Immuta Helm chart (IHC) to v2024.2 LTS using the Immuta Enterprise Helm chart (IEHC).

Prerequisites

Create a PostgreSQL database

1. The PostgreSQL instance has been provisioned and is actively running.

For additional information, consult the Deployment requirements.

Validate the Helm release

1. Fetch the metadata for the Helm release associated with Immuta.

   Copy

   helm get metadata --output yaml <helm-release-name>

2. Review the output from the previous step and verify the following:

   • The Immuta version (appVersion) is

     • The last LTS (2022.5.x) or 2024.1 or newer

     • Less than 2024.2

   • The Immuta Helm chart (version) is greater than or equal to 4.13.5

   • The Immuta Helm chart name (chart) is immuta

3. If any of the criteria is not met, it's first necessary to perform a Helm upgrade using the IHC. Contact your Immuta representative for guidance.

Metadata database

The new IEHC no longer supports deploying a Metadata database (PostgreSQL) inside the Kubernetes cluster. Before transitioning to the new IEHC, it's first necessary to externalize the Metadata database.

Built-in

The following demonstrates how to take a database backup and import the data into each cloud provider's managed PostgreSQL service.

Create backup of old database

1. Get the metadata database pod name.

   Copy

   kubectl get pod --selector "app.kubernetes.io/component=database" --output name

2. Spawn a shell inside the running metadata database pod.

   Copy

   kubectl exec --stdin --tty <metadata-database-pod-name> -- sh

3. Perform a database backup.

   Copy

   pg_dump --dbname=bometadata --file=/tmp/bometadata.dump --format=custom --no-owner --no-privileges

4. Type exit, and then press Enter to exit the shell prompt.

5. Copy file bometadata.dump from the pod to the host's working directory.

   Copy

   kubectl cp <metadata-database-pod-name>:/tmp/bometadata.dump .

Setup new database

1. Create a pod named immuta-setup-db and spawn a shell.

   Copy

   kubectl run immuta-setup-db --stdin --tty --rm --image docker.io/bitnami/postgresql:latest -- sh

2. Connect to the new PostgreSQL database as a superuser. Depending on the cloud provider, the default superuser name (postgres) might differ.

   Copy

   psql --host <postgres-fqdn> --username postgres --port 5432 --password

3. Create immuta, temporal, and temporal_visiblity databases and an immuta role.

   Copy

   CREATE ROLE immuta with login encrypted password '<postgres-password>';
   GRANT immuta TO CURRENT_USER;
   
   CREATE DATABASE immuta OWNER immuta;
   CREATE DATABASE temporal OWNER immuta;
   CREATE DATABASE temporal_visibility OWNER immuta;
   
   GRANT all ON DATABASE immuta TO immuta;
   GRANT all ON DATABASE temporal TO immuta;
   GRANT all ON DATABASE temporal_visibility TO immuta;
   ALTER ROLE immuta SET search_path TO bometadata,public;
   REVOKE immuta FROM CURRENT_USER;

4. Type \q, and then press Enter to exit the psql prompt.

5. Authenticate as the immuta user and create the pgcrypto extension.

   Copy

   psql --host <postgres-fqdn> --username immuta --port 5432 --password
   CREATE EXTENSION pgcrypto;

6. Type \q, and then press Enter to exit the psql prompt.

Restore backup to new database

1. Create a pod named immuta-restore-db and spawn a shell.

   Copy

   kubectl run immuta-restore-db --image docker.io/bitnami/postgresql:latest -- sleep infinity

2. Copy file bometadata.dump from the host's working directory to pod immuta-restore-db.

   Copy

   kubectl cp bometadata.dump immuta-restore-db:/tmp

3. Spawn a shell inside pod immuta-restore-db.

   Copy

   kubectl exec immuta-restore-db --stdin --tty -- sh

4. Perform a database restore while authenticated as role immuta. Refer to the value substituted for <postgres-password> when prompted to enter a password.

   Copy

   pg_restore --host=<postgres-fqdn> --port=5432 --username=immuta --password --dbname=immuta --no-owner --role=immuta < /tmp/bometadata.dump

5. Type exit, and then press Enter to exit the shell prompt.

6. Delete pod immuta-restore-db that was previously created.

   Copy

   kubectl delete pod/immuta-restore-db

External

No additional work is required. The existing database can be reused with the new IEHC.

Helm values

1. Rename the existing immuta-values.yaml Helm values file used by the IHC.

   Copy

   mv immuta-values.yaml immuta-values.ihc.yaml

This guide demonstrates how to upgrade an existing Immuta deployment installed with the Immuta Helm chart (IHC) to v2024.3.

Prerequisites

Checklist

• The Immuta Helm chart (IHC) has been updated to the latest version.

Upgrade Immuta

1. Edit immuta-values.yaml to include the following Helm values.

Introduced in 2024.2, the Immuta Enterprise Helm chart (IEHC) is an entirely new Helm chart used to deploy Immuta. Unlike the previous Immuta Helm chart (IHC), the IEHC shares the same version as the Immuta product. Each version of the chart supports a singular version of Immuta. Upgrading the Immuta version now entails upgrading the underlying Helm chart. Failure to do so will lead to an unsupported configuration.

Recommended

Legacy

Download public key

The provided key is used to sign the Helm chart and container images.

Identify container images

A DIGESTS.md markdown file comes bundled in the Helm chart and contains a comprehensive list of images and digests referenced. To view the file, follow these steps:

1. Download and extract the Helm chart into the working directory.
2. Open file immuta-enterprise/DIGESTS.md

Verify signature

Verify an artifact's signature by referencing Immuta's public key.

This guide demonstrates how to upgrade an existing 2024.2 Immuta deployment installed with the Immuta Enterprise Helm chart (IEHC) to the latest 2024.3 Immuta release.

Introduced in v2024.3

Temporal

Requirements

Starting in IEHC 2024.3, a Temporal server is included in the chart and requires two databases to store state. You can expand the existing PostgreSQL database in use for Immuta by creating Temporal databases like so:

1. Grant administrator privileges to the Postgres database role. Upon successfully completing this installation guide, you can optionally revoke this role grant:
2. Grant the Postgres user role to the current user. Upon successfully completing this installation guide, you can optionally revoke this role grant:
3. Create the new temporal databases and additional privileges for the Postgres user specified:
4. Connect to the new Temporal databases and run the following GRANT statements:

Enabling Temporal

To enable the Temporal deployment, set the following values. Include the tls settings if using a Cloud database that requires TLS:

Helm values

To improve the experience using the IEHC, two Helm value changes have been introduced. Before deploying the IEHC 2024.3.x, you must perform the following Helm value changes:

PostgreSQL configuration

IEHC 2024.3.x adds support for global and component-level PostgreSQL connection details. This means you only need to specify the PostgreSQL connection information once in the global scope and apply overrides (if necessary) at a component level.

If you installed IEHC 2024.2 LTS using our install guides, your immuta-values.yaml file probably looks something like this to configure your PostgreSQL connection for multiple components:

Now, with PostgreSQL configuration in the global scope, your immuta-values.yaml file can look like this to specify the PostgreSQL connection:

Feature flags

Feature flags have moved from environment variables IEHC 2024.3.x as well. You may now set feature flags globally, and then the IEHC will properly configure all applications for you. Migrate all feature flags from secure.extraEnvVars to global.featureFlags.

Additionally, if you use conditional tags, you must add the discoverDeprecateLegacyTags feature flag when upgrading. Otherwise the conditional tags will be removed from Immuta next time SDD runs.

If you fail to migrate the values from secure.extraEnvVars to global.featureFlags , then Helm will display warnings similar to below:

Upgrade Immuta

After updating your immuta-values.yaml file to include any of the changes for the updates above, you can upgrade Immuta with the following command:

The guides in this section illustrate how to install and deploy Immuta in your Kubernetes environment.

Prerequisites

Checklist

Quickstart

1. Complete the guide that corresponds with your Kubernetes cluster's distribution.

   • • Amazon Elastic Kubernetes Service (EKS)

     • Google Kubernetes Engine (GKE)

     • Microsoft Azure Kubernetes Service (AKS)

The following guides offer practical guidance for handling common challenges and configurations.

Configure TLS termination for an Ingress resource.

Verify artifacts hosted on the ocir.immuta.com OCI registry.

Follow these best practices when deploying Immuta in your production environment.

Update the credentials referenced in the Immuta Enterprise Helm chart.

Configure an external key-value cache (such as Redis or Memcached) with the Immuta Enterprise Helm chart.

Enable these legacy services for your deployment if they are required for your business use case:

• If you are using any of the data platforms below, you must enable the query engine:

  • Amazon Redshift

  • Azure Synapse Analytics

  • Google BigQuery
• If you are using the legacy sensitive data discovery (SDD) feature, you must enable the query engine and fingerprint services.

Configure pulling images from a private registry.

Tips when installing Immuta without internet access.

The Immuta web service listens on the following ports:

1. Edit the immuta-values.yaml file to include the following Helm values.

1. Edit immuta-values.yaml to include the following Helm values.
2. Create a file named frontendconfig.yaml with the following content.
3. Apply the FrontendConfig CRD.

1. Edit immuta-values.yaml to include the following Helm values.

1. Edit immuta-values.yaml to include the following Helm values.

1. Edit immuta-values.yaml to include the following Helm values.
2. Create a file named middleware.yaml with the following content.
3. Apply the Middleware CRD.

1. Edit immuta-values.yaml to include the following Helm values. Because the Ingress resource will be managed by the OpenShift route you create and not the Immuta Enterprise Helm chart, ingress is set to false below.
2. Get the service name for Secure.
4. Apply the Route CRD.

Prerequisite

1. Edit immuta-values.yaml to include the following Helm values.

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       annotations:
         nginx.ingress.kubernetes.io/auth-tls-secret: <namespace>/<secret-name>

2. Copy

   kubectl create secret tls <secret-name> --cert=path/to/tls.cert --key=path/to/tls.key

3. Copy

   helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

1. Edit immuta-values.yaml to include the following Helm values.

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       annotations:
         ingress.gcp.kubernetes.io/pre-shared-cert: <certificate-name>

2. Copy

   helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

1. Edit immuta-values.yaml to include the following Helm values.

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       annotations:
         alb.ingress.kubernetes.io/certificate-arn: <certificate-arn>

2. Copy

   helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

1. Edit immuta-values.yaml to include the following Helm values.

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       annotations:
         appgw.ingress.kubernetes.io/appgw-ssl-certificate: <certificate-name>

2. Copy

   helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

1. Edit immuta-values.yaml to include the following Helm values.

   Copy

   secure:
     ingress:
       annotations:
         traefik.ingress.kubernetes.io/router.tls: "true"
       hostname: <immuta-fqdn>
       tls: true
       # If left unset the TLS secret name defaults to <hostname>-tls
       secretName: <secret-name>

2. Copy

   kubectl create secret tls <secret-name> --cert=path/to/tls.cert --key=path/to/tls.key

3. Copy

   helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

This guide demonstrates how to configure an external key-value cache (such as Redis or Memcached) with the Immuta Enterprise Helm chart (IEHC).

Prerequisite

Redis

1. Copy

   kubectl edit secret/immuta-secret

2. Add key-value IMMUTA_SERVER_CACHE_PROVIDER_OPTIONS_PASSWORD=<cache-password>.

Edit Helm values

Redis

cache:
  enabled: false

secure:
  extraConfig:
    server:
      cache:
        provider:
          constructor: catbox-redis
          options:
            host: <redis-fqdn>
            port: <port>
            # Setting options.tls to an empty dict enables TLS without configuring any other options.
            tls: {}

            # Dict representation of TLS config options json-object for package ioredis
            # https://github.com/redis/ioredis
            #
            # tls:
            #   ca:
            #   key:
            #   cert:

  extraEnvVars:
  - name: IMMUTA_SERVER_CACHE_PROVIDER_OPTIONS_PASSWORD
    valueFrom:
      secretKeyRef:
        key: IMMUTA_SERVER_CACHE_PROVIDER_OPTIONS_PASSWORD
        name: immuta-secret

Memcached

cache:
  enabled: false

secure:
  extraConfig:
    server:
      cache:
        provider:
          constructor: catbox-memcached
          options:
            host: <memcached-fqdn>
            port: <port>

Apply Helm values

helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

This guide demonstrates how to download and package the Immuta Enterprise Helm chart and its dependencies for consumption on a separate network with no internet access.

Prerequisite

Checklist

Skopeo

• Skopeo is authenticated with Immuta's registry on the networked machine.

• Skopeo is authenticated with the private registry on the air-gapped machine.

Helm

• Helm is authenticated with Immuta's registry on the networked machine.

Download artifacts

This section demonstrates how to download the Helm chart and container images to your local machine. These artifacts will be packaged and transferred to the air-gapped environment later.

1. Create a directory named offline-kit.

   Copy

   mkdir ./offline-kit

2. Download the Helm chart into directory offline-kit.

   Copy

   helm pull oci://ocir.immuta.com/stable/immuta-enterprise --destination ./offline-kit --version 2024.3.9

3. Extract file DIGESTS.md from the Helm chart archive.

   Copy

   tar --extract --gzip --strip-components=1 --directory=./offline-kit --file=./immuta-enterprise-*.tgz immuta-enterprise/DIGESTS.md

4. Open file ./offline-kit/DIGESTS.md. This file includes the name and digest of every container image referenced by the Helm chart.

5. Copy

   read -r -p "Enter the container image to download (e.g., docker.io/hello-world:latest):" image && \
   skopeo copy docker://"$image" docker-archive:"offline-kit/$(sed 's#.*/##; s#:#-#g' <<< "$image").tar"

Transfer artifacts

This section demonstrates how to push the previously archived container images to a private registry that's accessible from within your air-gapped environment.

1. Transfer directory offline-kit (created in the previous section) onto a machine that's within your air-gapped environment.

2. Copy

   skopeo copy docker-archive:offline-kit/<name>-<tag>.tar docker://<private-registry-fqdn>/immuta/<name>:<tag>

Chart installation

The query engine and fingerprint services are no longer installed by default. This guide demonstrates how to enable the query engine and fingerprint services using the Immuta Enterprise Helm chart (IEHC).

If you are using any of the data platforms below, you must enable the query engine:

• Amazon Redshift

• Azure Synapse Analytics

• Google BigQuery

If you are using the legacy sensitive data discovery (SDD) feature, you must enable the query engine and fingerprint services.

Prerequisites

• Validate that secret immuta-secret exists in the current namespace.

  Copy

  kubectl get secret/immuta-secret

Create Kubernetes secret

1. Create a file named secret-data.env with the following content.

   Copy

   # query-engine
   IMMUTA_FEATURE_PASSWORD=<immuta-feature-password>
   PATRONI_SUPERUSER_PASSWORD=<patroni-superuser-password>
   PATRONI_REPLICATION_PASSWORD=<patroni-replication-password>
   PATRONI_RESTAPI_PASSWORD=<patroni-api-password>

2. Create secret named immuta-legacy-secret from file secret-data.env

   Copy

   kubectl create secret generic immuta-legacy-secret --from-env-file=secret-data.env

3. Delete file secret-data.env, as it's no longer needed.

   Copy

   rm -i secret-data.env

Edit Helm values

1. Edit the immuta-values.yaml file to include the following Helm values.

   Copy

   legacy:
     enabled: true
   
     queryEngine:
       statefulset:
         extraEnvVars:
         - name: IMMUTA_FEATURE_PASSWORD
           valueFrom:
             secretKeyRef:
               name: immuta-legacy-secret
               key: IMMUTA_FEATURE_PASSWORD
         - name: PATRONI_SUPERUSER_PASSWORD
           valueFrom:
             secretKeyRef:
               name: immuta-legacy-secret
               key: PATRONI_SUPERUSER_PASSWORD
         - name: PATRONI_REPLICATION_PASSWORD
           valueFrom:
             secretKeyRef:
               name: immuta-legacy-secret
               key: PATRONI_REPLICATION_PASSWORD
         - name: PATRONI_RESTAPI_PASSWORD
           valueFrom:
             secretKeyRef:
               name: immuta-legacy-secret
               key: PATRONI_RESTAPI_PASSWORD
   
       postgres:
         # Query Engine feature user
         # Instead use queryEngine.statefulset.extraEnvVars[].name[IMMUTA_FEATURE_PASSWORD]
         # password: <immuta-feature-password>
   
         # Query Engine superuser user
         # Instead use queryEngine.statefulset.extraEnvVars[].name[PATRONI_SUPERUSER_PASSWORD]
         # superuserPassword: <patroni-superuser-password>
   
         # Query Engine replication user
         # Instead use queryEngine.statefulset.extraEnvVars[].name[PATRONI_REPLICATION_PASSWORD]
         # replicationPassword: <patroni-replication-password>
   
         # Query Engine patroni api user
         # Instead use queryEngine.statefulset.extraEnvVars[].name[PATRONI_RESTAPI_PASSWORD]
         # patroniApiPassword: <patroni-api-password>
       immutaSecurity:
         # Each Kubernetes Service has a DNS record associated with it. See: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
         # The anatomy of a domain name is as followed:
         #   <service>.<namespace>.svc.<cluster-domain>
         #
         # Where the default cluster domain is: cluster.local
         authEndpoint: "http://immuta-secure.immuta.svc.cluster.local:8823"
   
   secure:
     extraEnvVars:
     - name: IMMUTA_DATABASES_IMMUTA_CONNECTIONS_FEATURESTOREDB_PASSWORD
       valueFrom:
         secretKeyRef:
           name: immuta-legacy-secret
           key: IMMUTA_FEATURE_PASSWORD
   
     extraConfig:
       disableFeatureStore: false
       queryEngineRehydration:
         enabled: true
       databases:
         immuta:
           connections:
             featureStoreDb:
               # Each Kubernetes Service has a DNS record associated with it. See: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
               # The anatomy of a domain name is as followed:
               #   <service>.<namespace>.svc.<cluster-domain>
               #
               # Where the default cluster domain is: cluster.local
               host: "immuta-legacy-query-engine-service.immuta.svc.cluster.local"
               port: 5432
               ssl: false
               # Query Engine feature user
               # Instead use secure.extraEnvVars[].name[IMMUTA_DATABASES_IMMUTA_CONNECTIONS_FEATURESTOREDB_PASSWORD]
               # password: <immuta-feature-password>
       fingerprints:
         # Each Kubernetes Service has a DNS record associated with it. See: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
         # The anatomy of a domain name is as follows:
         #   <service>.<namespace>.svc.<cluster-domain>
         #
         # Where the default cluster domain is: cluster.local
         uri: "http://immuta-legacy-fingerprint-service.immuta.svc.cluster.local:5001/"
         queryEngineHost: "immuta-legacy-query-engine-service.immuta.svc.cluster.local"
         queryEnginePort: 5432

Apply Helm values

helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

This guide demonstrates how to configure a private container registry with the Immuta Enterprise Helm chart (IEHC).

Helm values

1. Examine the default Helm values in the chart; this will include all relevant values required to override the registry and images.

   Copy

   helm show values oci://ocir.immuta.com/stable/immuta-enterprise --version 2024.3.9

2. Copy

   global:
     imageRegistry: <private-registry-fqdn>
   secure:
     backgroundWorker:
       image:
         repository: <prefix>/immuta-service
     web:
       image:
         repository: <prefix>/immuta-service

This guide highlights best practices when deploying Immuta in a production environment.

Database sizing recommendations

Provisioning an appropriately resourced PostgreSQL database for Immuta is critical to application performance. The recommendations below are based on the number of data sources registered multiplied (*) by the number of users on the deployment:

Elasticsearch/OpenSearch sizing recommendations

This recommendation assumes approximately 1 million events per day with a 90-day data retention policy:

• 2 nodes

• 2 CPUs/node

• 4GB RAM/node

• Storage 100GB SSD/node

Helm values

Back up or source control your immuta-values.yaml Helm values file.

Kubernetes resource requests and limits

Edit Helm values

Edit immuta-values.yaml to include the following recommended resource requests and limits for most Immuta deployments.

audit:
  worker:
    replicaCount: 1
    resources:
      requests:
        cpu: 1000m
        memory: 1024Mi
      limits:
        cpu: 1000m
        memory: 2048Mi  
  deployment:
    replicaCount: 1
    resources:
      requests:
        cpu: 1000m
        memory: 4096Mi
      limits:
        cpu: 3000m
        memory: 8192Mi
secure:
  backgroundWorker:
    replicaCount: 2
    resources:
      requests:
        cpu: 1000m
        memory: 4096Mi
      limits:
        cpu: 4000m
        memory: 4096Mi  
  web:
    replicaCount: 2 
    resources:
      requests:
        cpu: 1000m
        memory: 4096Mi
      limits:
        cpu: 4000m
        memory: 4096Mi
discover:
  deployment:
    replicaCount: 1
    resources:
      requests:
        cpu: 500m
        memory: 4096Mi
      limits:
        cpu: 3000m
        memory: 4096Mi
cache:
  deployment:
    replicaCount: 1
    resources:
      requests:
        cpu: 500m
        memory: 512Mi
      limits:
        cpu: 1000m
        memory: 512Mi

Kubernetes secrets

Create secret

1. Create a file named secret-data.env with the following content.

   Copy

   # audit
   ELASTICSEARCH_USERNAME=<elasticsearch-username>
   ELASTICSEARCH_PASSWORD=<elasticsearch-password>
   
   # PostgreSQL connection string used by audit for the metadata database
   #   postgresql://<user>:<password>@<postgres-fqdn>:5432/<database>?schema=audit
   #
   # More info
   #   https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING
   DATABASE_CONNECTION_STRING=postgresql://immuta:<postgres-password>@<postgres-fqdn>:5432/immuta?schema=audit
   
   # secure
   IMMUTA_DATABASES_IMMUTA_CONNECTIONS_IMMUTADB_PASSWORD=<postgres-password>

2. Create secret named immuta-secret from file secret-data.env.

   Copy

   kubectl create secret generic immuta-secret --from-env-file=secret-data.env

3. Delete file secret-data.env, as it's no longer needed.

   Copy

   rm -i secret-data.env

Edit Helm values

1. Edit immuta-values.yaml to include the following Helm values.

   Copy

   audit:
     deployment:
       existingSecret: immuta-secret
     export:
       cronJob:
         existingSecret: immuta-secret
   
   secure:
     existingSecret:
       name: immuta-secret
       # Optional. Map expected keys with keys in existing secret
       # keyMapping: {}

2. Remove any sensitive key-value pairs from the immuta-values.yaml Helm values that were made redundant after the secret was created.

Apply Helm values

helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

This is a guide on how to deploy Immuta on OpenShift.

Prerequisites

• PostgreSQL

• (Optional) Elasticsearch/OpenSearch

Checklist

This checklist outlines the necessary prerequisites for successfully deploying Immuta.

Credentials

PostgreSQL

• You have a PostgreSQL user account with the necessary privileges to create databases, extensions, and roles.

Elasticsearch

Setup

Helm

Authenticate with OCI registry

echo <token> | helm registry login --password-stdin --username <username> ocir.immuta.com

Kubernetes

Create project

1. Create an OpenShift project named immuta.

   Copy

   oc new-project immuta

2. Get the UID range allocated to the project. Each running container's UID must fall within this range. This value will be referenced later on.

   Copy

   oc get project immuta --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'

3. Get the GID range allocated to the project. Each running container's GID must fall within this range. This value will be referenced later on.

   Copy

   oc get project immuta --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'

4. Switch to project immuta.

   Copy

   oc project immuta

Create registry secret

oc create secret docker-registry immuta-oci-registry \
    --docker-server=https://ocir.immuta.com \
    --docker-username="<username>" \
    --docker-password="<token>" \
    --docker-email=support@immuta.com

PostgreSQL

Connect to the database

Connect to the database as an admin (e.g., postgres) by creating an ephemeral container inside the Kubernetes cluster. A shell prompt will not be displayed after executing the kubectl run command outlined below. Wait 5 seconds, and then proceed by entering a password.

oc run pgclient \
    --stdin \
    --tty \
    --rm \
    --image docker.io/bitnami/postgresql -- \
    psql --host <postgres-fqdn> --username <postgres-user> --port 5432 --password

Create Role

1. Create the immuta role.

   Copy

   CREATE ROLE immuta with LOGIN ENCRYPTED PASSWORD '<postgres-password>';
   ALTER ROLE immuta SET search_path TO bometadata,public;

2. Grant administrator privileges to the immuta role. Upon successfully completing this installation guide, you can optionally revoke this role grant.

   Copy

   GRANT <admin-role> TO immuta;

Create databases

1. Create databases.

   Copy

   CREATE DATABASE immuta OWNER immuta;
   CREATE DATABASE temporal OWNER immuta;
   CREATE DATABASE temporal_visibility OWNER immuta;

2. Copy

   GRANT ALL ON DATABASE immuta TO immuta;
   GRANT ALL ON DATABASE temporal TO immuta;
   GRANT ALL ON DATABASE temporal_visibility TO immuta;

3. Configure the immuta database.

   Copy

   \c immuta
   CREATE EXTENSION pgcrypto;

4. Configure the temporal database.

   Copy

   \c temporal
   GRANT CREATE ON SCHEMA public TO immuta;

5. Configure the temporal_visibility database.

   Copy

   \c temporal_visibility
   GRANT CREATE ON SCHEMA public TO immuta;
   CREATE EXTENSION btree_gin;

6. Exit the interactive prompt. Type \q, and then press Enter.

Install Immuta

This section demonstrates how to deploy Immuta using the Immuta Enterprise Helm chart once the prerequisite cloud-managed services are configured.

global:
  imageRegistry: ocir.immuta.com
  imagePullSecrets:
    - name: immuta-oci-registry
  postgresql:
    host: <postgres-fqdn>
    port: 5432
    username: immuta
    password: <postgres-password>

audit:
  config:
    elasticsearchEndpoint: http://es-db-elasticsearch.immuta.svc.cluster.local:9200
    elasticsearchUsername: <elasticsearch-username>
    elasticsearchPassword: <elasticsearch-password>
  postgresql:
    database: immuta 

  deployment:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  worker:
    podSecurityContext:  
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL 

discover:
  deployment:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

secure:
  ingress:
    enabled: false

  postgresql:
    database: immuta
    ssl: false

  web:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
  
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

  backgroundWorker:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  
temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls:
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true
    frontend:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    history:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    matching:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    worker:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
  schema:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  proxy:
    deployment:
      podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
      containerSecurityContext:
        enabled: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

global:
  imageRegistry: ocir.immuta.com
  imagePullSecrets:
    - name: immuta-oci-registry
  featureFlags:
    AuditService: false
    detect: false
    auditLegacyViewHide: false
  postgresql:
    host: <postgres-fqdn>
    port: 5432
    username: immuta
    password: <postgres-password>

audit:
  enabled: false

discover:
  deployment:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault

    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

secure:
  ingress:
    enabled: false

  postgresql:
    database: immuta
    ssl: true

  web:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault

    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

  backgroundWorker:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault

    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls:
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true
    frontend:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    history:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    matching:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    worker:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
  schema:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  proxy:
    deployment:
      podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
      containerSecurityContext:
        enabled: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

2. Deploy Immuta.

   Copy

   helm install immuta oci://ocir.immuta.com/stable/immuta-enterprise \
       --values immuta-values.yaml \
       --version 2024.3.9

3. Wait for all pods to become ready.

   Copy

   oc wait --for=condition=Ready pods --all

Validation

1. Determine the name of the Secure service.

   Copy

   oc get service --selector "app.kubernetes.io/component=secure" --output name

2. Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.

   Copy

   oc port-forward <service-name> 8080:http

4. Press Control+C to stop port forwarding.

Next steps

This guide demonstrates how to update credentials referenced in the Immuta Enterprise Helm chart (IEHC).

Kubernetes secrets

Edit secrets

1. Validate that secret immuta-secret exists in the current namespace.

   Copy

   kubectl get secret/immuta-secret

2. Edit secret immuta-secret in place.

   Copy

   kubectl edit secret/immuta-secret

3. Edit secret immuta-legacy-secret in place. Skip this step if the legacy query engine and fingerprint services are disabled (the default).

   Copy

   kubectl edit secret/immuta-legacy-secret

4. Restart pods.

   Copy

   kubectl rollout restart deployment --all --selector "app.kubernetes.io/component=audit,app.kubernetes.io/component=secure"

Legacy query engine

1. Validate that secret immuta-legacy-secret exists in the current namespace.

   Copy

   kubectl get secret/immuta-legacy-secret

2. Get the query engine replica count, this value will be referenced in subsequent step(s).

   Copy

   kubectl get statefulset --all --selector "app.kubernetes.io/component=query-engine" --output template='{{ .status.replicas }}'

3. Scale the replica count down to 1.

   Copy

   kubectl scale statefulset --all --replicas 1 --selector "app.kubernetes.io/component=query-engine"

4. Get the query engine pod name, this value will be referenced in subsequent step(s).

   Copy

   kubectl get pod --selector "app.kubernetes.io/component=query-engine"

5. Copy

   kubectl exec pod/<query-engine-pod-name> -- \
       psql -d immuta -c \
       "ALTER USER postgres WITH ENCRYPTED PASSWORD '<new-patroni-superuser-password>'"

6. Copy

   kubectl exec pod/<query-engine-pod-name> -- \
       psql -d immuta -c \
       "ALTER USER replicator WITH ENCRYPTED PASSWORD '<new-patroni-replication-password>'"

7. Copy

   kubectl exec pod/<query-engine-pod-name> -- \
       psql -d immuta -c \
       "ALTER USER feature_service WITH ENCRYPTED PASSWORD '<new-immuta-feature-password>'"

8. Copy

   kubectl scale statefulset --all --replicas <query-engine-previous-replica-count> --selector "app.kubernetes.io/component=query-engine"

Apply Helm values

1. Update credentials in the immuta-values.yaml file.

2. Copy

   helm upgrade <release-name> oci://ocir.immuta.com/stable/immuta-enterprise --values immuta-values.yaml --version 2024.3.9

Immuta integrates with your data platforms and external catalogs so you can register your data and effectively manage access controls on that data.

This section includes concept, reference, and how-to guides for configuring your data platform integration, registering data sources, and connecting your external catalog so that you can discover, monitor, and protect sensitive data.

This reference guide outlines the features, policies, and audit capabilities supported by each integration.

This section includes how-to and reference guides for Snowflake and how it integrates with Immuta.

This section includes how-to and reference guides for Databricks Unity Catalog and how it integrates with Immuta.

This section includes how-to and reference guides for Databricks Spark and how it integrates with Immuta.

This section includes how-to and reference guides for Starburst (Trino) and how it integrates with Immuta.

This section includes how-to and reference guides for Redshift and how it integrates with Immuta.

This section includes how-to and reference guides for Azure Synapse Analytics and how it integrates with Immuta.

This page includes how-to and reference content for Amazon S3 and how it integrates with Immuta.

This page includes how-to and reference content for Google BigQuery and how it integrates with Immuta.

This section covers the various data catalogs Immuta integrates with.

This getting started guide outlines how to integrate your Snowflake account with Immuta.

How-to guides

• Integration settings:

Reference guides

Frequently asked questions

How can I ensure the fully qualified domain name (FQDN) is resolvable from within the Kubernetes cluster?

1. Create a pod named debug-dns and spawn an interactive shell.

   Copy

   kubectl run debug-dns --stdin --tty --rm --image docker.io/rockylinux/rockylinux:9 -- sh

2. Install package bind-utils.

   Copy

   dnf install bind-utils

3. Perform DNS lookups on a given FQDN.

   Copy

   dig <fqdn>

I'm unsure which Kubernetes namespace or Helm release is associated with my Immuta installation. How can I find this out?

helm list --all-namespaces --output json | jq '.[]|select(.chart | startswith("immuta"))'

I no longer have my immuta-values.yaml Helm values file. How do I recover this file?

helm get values <release-name> > immuta-values.yaml

I don't want to keep passing option --namespace every time I run a Helm command. How do I set a default?

kubectl config set-context --current --namespace=<name>

PostgreSQL

How do I determine if the database is accepting connections?

1. Create a pod named debug-postgres and spawn an interactive shell.

   Copy

   kubectl run debug-postgres --stdin --tty --rm --image docker.io/bitnami/postgresql:latest -- sh

2. Validate that the database is listening.

   Copy

   pg_isready --host <postgres-fqdn> --port 5432

Redis

How can a TCP connection be established without using Redis CLI?

1. Create a pod named debug-redis and spawn an interactive shell.

   Copy

   kubectl run debug-redis --stdin --tty --rm --image docker.io/rockylinux/rockylinux:9 -- sh

2. Send a raw TCP message to the database using Netcat.

   Copy

   nc -zv <redis-fqdn> 6379

How do I establish a TCP connection?

1. Create a pod named debug-redis and spawn an interactive shell.

   Copy

   kubectl run debug-redis --stdin --tty --rm --image docker.io/bitnami/redis:latest -- sh

2. Establish a connection to the database using the Redis client. If a connection can be established with Netcat and the redis-cli command does not return, then Redis could be expecting a TLS connection. Pass option --tls.

   Copy

   redis-cli -h <redis-fqdn> -p 6379

Elasticsearch

How do I query the API using cURL?

1. Create a pod named debug-elasticsearch and spawn an interactive shell.

   Copy

   kubectl run debug-elasticsearch --stdin --tty --rm --image docker.io/rockylinux/rockylinux:9 -- sh

2. Install package curl.

   Copy

   dnf install curl

3. Copy

   curl --fail --request GET "http://<elasticsearch-fqdn>:9200/_cluster/health?pretty"

Helm

When installing the helm chart from ocir.immuta.com, I get error scheme "oci" not supported. What's going on?