Immuta comprises three core services (Secure, Discover, and Detect) that rely on PostgreSQL and Elasticsearch to store their states. The illustration below shows the relationships among these services.

The Immuta Enterprise Helm chart (IEHC) (represented by the yellow box above) does not deploy PostgreSQL or Elasticsearch, so you must deploy and manage 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.

For guidance on how to configure the IEHC to deploy Immuta with or without Elasticsearch, see one of the guides below:

Version requirements

Kubernetes versions

• Kubernetes 1.29 to 1.32

Metadata database (PostgreSQL)

• PostgreSQL 15.0 or newer

• The pgcrypto extension 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

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.

Next step

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

The following cloud-managed services must be provisioned before proceeding:

Validation

PostgreSQL

Elasticsearch

Authenticate with OCI registry

Copy the snippet below and replace the placeholder text with the credentials provided to you by your customer success manager:

Setup

1. Create a Kubernetes namespace named immuta for Immuta.
2. Switch to namespace immuta.

PostgreSQL

1. Connect to the database as superuser (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.
2. Create an immuta role and database.
3. Revoke privileges from CURRENT_USER as they're no longer required.
4. Enable the pgcrypto extension.
5. Type \q, and then press Enter to exit.

Install Immuta

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

1. Create a Helm values file named immuta-values.yaml with the following content:
3. Deploy Immuta.

Validation

1. Wait for all pods in the namespace to become ready.
2. Determine the name of the Secure service.
3. Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.

Next steps

Prerequisites and requirements

• Use a supported version of Kubernetes.

• Use Helm 3.2.0 or newer (When using a Helm version older than 3.8.0, enable OCI experimental mode by exporting environment variable HELM_EXPERIMENTAL_OCI=1.)

Pull the Helm chart

ocir.immuta.com

Copy the snippet below and replace the placeholder text with the credentials provided to you by your Immuta support professional:

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

Install Immuta

• • Amazon Elastic Kubernetes Service (EKS)

  • Google Kubernetes Engine (GKE)

  • Microsoft Azure Kubernetes Service (AKS)

Configure Ingress

Additional recommendations

This page provides one possible way to download and package Immuta artifacts for consumption on a separate network with no Internet access.

Install Skopeo

Authenticate Skopeo to the Immuta registry

Copy the snippet below and replace the placeholder text with the credentials provided by your Immuta representative:

skopeo login https://ocir.immuta.com -u <username> -p <password>

Copy images from the Immuta registry

export IMMUTA_VERSION=2024.2.16
export IMMUTA_IMAGES="audit-service audit-export-cronjob cache classify-service immuta-service"
export IMMUTA_LEGACY_IMAGES="immuta-db immuta-fingerprint"
for image in ${IMMUTA_IMAGES} ${IMMUTA_LEGACY_IMAGES}; do
  skopeo copy docker://ocir.immuta.com/stable/${image}:${IMMUTA_VERSION} docker-archive://${PWD}/${image}-${IMMUTA_VERSION}.tar;
done

Pull the Immuta Enterprise Helm chart (IEHC)

1. Copy the snippet below and replace the placeholder text with the credentials provided by your Immuta representative:

   Copy

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

2. Download the IEHC for the current Immuta release:

   Copy

   helm pull oci://ocir.immuta.com/stable/immuta-enterprise --version 2024.2.16

Push images to the private registry

After transferring the Immuta container images and IEHC to your air-gapped network, load them into the container registry there after authenticating.

export PRIVATE_REGISTRY=your.private-registry.com
export IMMUTA_VERSION=2024.2.16
export IMMUTA_IMAGES="audit-service audit-export-cronjob cache classify-service immuta-service"
export IMMUTA_LEGACY_IMAGES="immuta-db immuta-fingerprint"
for image in ${IMMUTA_IMAGES} ${IMMUTA_LEGACY_IMAGES}; do
  skopeo copy docker-archive://${PWD}/${image}-${IMMUTA_VERSION}.tar docker://${PRIVATE_REGISTRY}/immuta/${image}:${IMMUTA_VERSION};
done

Install from IEHC tarball

Override the image registry in the Helm chart values overrides:

---
global:
  imageRegistry: your.private-registry.com
  imageRepositoryMap:
    immuta/immuta-service: immuta/immuta-service
    immuta/immuta-db: immuta/immuta-db
    immuta/immuta-fingerprint: immuta/immuta-fingerprint
    immuta/audit-service: immuta/audit-service
    immuta/audit-export-cronjob: immuta/audit-export-cronjob
    immuta/classify-service: immuta/classify-service
    immuta/cache: immuta/cache

The IEHC can be referenced via filename if there is no Helm chart repository on the destination network:

helm upgrade --install immuta ./immuta-enterprise-2024.2.16.tgz -f immuta-values.yaml

• • Amazon Elastic Kubernetes Service (EKS)

  • Google Kubernetes Engine (GKE)

  • Microsoft Azure Kubernetes Service (AKS)

This section illustrates how to install Immuta on Kubernetes using the Immuta Enterprise Helm chart.

This how-to guide includes instructions and links for installing Immuta in any Kubernetes environment.

Requirements

This reference guide provides an overview of the Immuta Enterprise Helm chart version requirements and infrastructure recommendations.

Install

• • Amazon Elastic Kubernetes Service (EKS)

  • Google Kubernetes Engine (GKE)

  • Microsoft Azure Kubernetes Service (AKS)

The guides in this section illustrate how to configure your Immuta Enterprise Helm chart for various scenarios, including optimizing your deployment for production environments.

Upgrade

The guides in this section illustrate how to upgrade the Immuta Enterprise Helm chart:

This guide provides links to additional resources for disaster recovery strategies.

This page provides troubleshooting guidance and outlines frequently asked questions for the Immuta installation.

This guide outlines the updates and bug fixes to the Immuta Enterprise Helm chart.

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

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

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

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

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

The Immuta web service listens on the following ports:

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

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       ingressClassName: nginx
       annotations:
         nginx.ingress.kubernetes.io/force-ssl-redirect: 'true'
         nginx.ingress.kubernetes.io/proxy-body-size: '64m'

2. Copy

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

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

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       annotations:
         # Determines which type of load balancer is provisioned
         #   gce-internal
         #   gce
         kubernetes.io/ingress.class: gce
         # Listen on both 80 and 443
         kubernetes.io/ingress.allow-http: 'true'
         # Redirect traffic from 80 to 443
         cloud.google.com/frontend-config: immuta

2. Create a file named frontendconfig.yaml with the following content.

   Copy

   apiVersion: networking.gke.io/v1beta1
   kind: FrontendConfig
   metadata:
     name: immuta
   spec:
     redirectToHttps:
       enabled: true
       responseCodeName: RESPONSE_CODE

3. Apply the FrontendConfig CRD.

   Copy

   kubectl apply -f frontendconfig.yaml

4. Copy

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

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

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       ingressClassName: alb
       annotations:
         # Determines which type of load balancer is provisioned
         #   internal
         #   internet-facing
         alb.ingress.kubernetes.io/scheme: internet-facing
         alb.ingress.kubernetes.io/target-type: ip
         # Listen on both 80 and 443
         alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
         # Redirect traffic from 80 to 443
         alb.ingress.kubernetes.io/ssl-redirect: '443'

2. Copy

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

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

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       ingressClassName: webapprouting.kubernetes.azure.com
       # https://azure.github.io/application-gateway-kubernetes-ingress/annotations/
       annotations:
         appgw.ingress.kubernetes.io/ssl-redirect: 'true'

2. Copy

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

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

   Copy

   secure:
     ingress:
       hostname: <immuta-fqdn>
       ingressClassName: traefik
       annotations:
         # Listen on ports 80 and 443
         traefik.ingress.kubernetes.io/router.entrypoints: web,websecure
         # Redirect HTTP to HTTPS
         # When referencing middleware you must prefix the name with its namespace
         # <namespace>-<middleware-name>@kubernetescrd
         traefik.ingress.kubernetes.io/router.middlewares: immuta-https-redirectscheme@kubernetescrd

2. Create a file named middleware.yaml with the following content.

   Copy

   apiVersion: traefik.containo.us/v1alpha1
   kind: Middleware
   metadata:
     name: https-redirectscheme
   spec:
     redirectScheme:
       scheme: https
       permanent: true

3. Apply the Middleware CRD.

   Copy

   kubectl apply -f middleware.yaml

4. Copy

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

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.

   Copy

   secure:
     ingress:
       enabled: false

2. Get the service name for Secure.

   Copy

   oc get service --selector "app.kubernetes.io/component=secure" --output template='{{ .metadata.name }}'

3. Copy

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     name: immuta
   spec:
     host: <immuta-fqdn>
     to:
       kind: Service
       name: immuta-secure
     port:
       targetPort: http
     tls:
       termination: edge
       insecureEdgeTerminationPolicy: Redirect

4. Apply the Route CRD.

   Copy

   oc apply -f route.yaml

5. Copy

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

Verify

1. Create a file named immuta-cosign.pub with the following content:
2. Verify artifact signature.

Frequently asked question

How can I list all container images referenced in the IEHC?

List all container images by rendering the chart templates locally.

This is an OpenShift-specific guide on how to deploy Immuta with the following managed services:

• Cloud-managed PostgreSQL

• Cloud-managed Redis

• Cloud-managed Elasticsearch

Prerequisites

Review the following criteria before proceeding with deploying Immuta.

PostgreSQL

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

Redis

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

Elasticsearch

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

Authenticate with OCI registry

Copy the snippet below and replace the placeholder text with the credentials provided to you by your customer success manager:

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

Setup

1. Create a new OpenShift project named immuta for 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

5. Copy

   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

Cloud-managed PostgreSQL

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

   Copy

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

2. Create an immuta role and database.

   Copy

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

3. Revoke privileges from CURRENT_USER as they're no longer required.

   Copy

   REVOKE immuta FROM CURRENT_USER;

4. Enable the pgcrypto extension.

   Copy

   \c immuta
   CREATE EXTENSION pgcrypto;

5. Type \q, and then press Enter to exit.

Install Immuta

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

1. Copy

   global:
     imageRegistry: ocir.immuta.com
     imagePullSecrets:
       - name: immuta-oci-registry
     imageRepositoryMap:
       immuta/immuta-service: stable/immuta-service
       immuta/immuta-db: stable/immuta-db
       immuta/immuta-fingerprint: stable/immuta-fingerprint
       immuta/audit-service: stable/audit-service
       immuta/audit-export-cronjob: stable/audit-export-cronjob
       immuta/classify-service: stable/classify-service
       immuta/cache: stable/cache
   
   audit:
     config:
       databaseConnectionString: postgres://immuta:<postgres-password>@pg-db-postgresql.immuta.svc.cluster.local:5432/immuta?schema=audit
       elasticsearchEndpoint: http://es-db-elasticsearch.immuta.svc.cluster.local:9200
       elasticsearchUsername: <elasticsearch-username>
       elasticsearchPassword: <elasticsearch-password>
   
     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
   
   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:
     extraEnvVars:
       - name: FeatureFlag_AuditService
         value: "true"
       - name: FeatureFlag_detect
         value: "true"
       - name: FeatureFlag_auditLegacyViewHide
         value: "true"
   
     ingress:
       enabled: false
       tls: false
   
     postgresql:
       host: <postgres-fqdn>
       port: 5432
       database: immuta
       username: immuta
       password: <postgres-password>
       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

3. Deploy Immuta.

   Copy

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

Validation

1. Wait for all pods in the namespace to become ready.

   Copy

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

2. Determine the name of the Secure service.

   Copy

   oc get service --selector "app.kubernetes.io/component=secure" --output template='{{ .metadata.name }}'

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

   Copy

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

Next steps

Introduced in 2024.2, the Immuta Enterprise Helm chart (IEHC) is an entirely new Helm chart used to deploy Immuta. This section guides you through configuring the IEHC to finish and prepare your installation for a production environment.

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

Configure TLS termination for an Ingress resource.

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

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

Update the credentials referenced in 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.

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

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.

Kubernetes secrets

Create secret

1. Create a file named secret-data.env with the following content.
2. Create secret named immuta-secret from file secret-data.env.
3. Delete file secret-data.env, as it's no longer needed.

Edit Helm values

1. Edit immuta-values.yaml to include the following Helm values.
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

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.

How to get started

Immuta Enterprise Helm chart

2024.2.0

Added

• Initial release of the chart.

2024.2.1

Changed

• Updated to 2024.2.1

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.

This section provides upgrade guides for two scenarios:

The guides below outline how to deploy Immuta without Elasticsearch.

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

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

Edit Helm values

Redis

Memcached

Apply Helm values

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.
2. Edit secret immuta-secret in place.
3. Edit secret immuta-legacy-secret in place. Skip this step if the legacy query engine and fingerprint services are disabled (the default).
4. Restart pods.

Legacy query engine

1. Validate that secret immuta-legacy-secret exists in the current namespace.
2. Get the query engine replica count, this value will be referenced in subsequent step(s).
3. Scale the replica count down to 1.
4. Get the query engine pod name, this value will be referenced in subsequent step(s).

Apply Helm values

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

This is a generic guide that demonstrates how to deploy Immuta into any Kubernetes cluster without dependencies on any particular cloud provider.

Considerations

• Operational overhead: Managing PostgreSQL and Elasticsearch on Kubernetes requires expertise in deploying, maintaining, and scaling these databases and search engines effectively. This involves tasks like setting up monitoring, configuring backups, managing updates, and ensuring high availability. Cloud-managed services abstract much of this operational burden away, allowing teams to focus on application development rather than infrastructure management.

• Resource allocation and scaling: Kubernetes requires careful resource allocation and scaling decisions to ensure that PostgreSQL and Elasticsearch have sufficient CPU, memory, and storage. Properly sizing these resources can be challenging and may require continuous adjustments as workload patterns change. Managed services typically handle this scaling transparently and can automatically adjust based on demand.

• Data integrity and high availability: PostgreSQL and Elasticsearch deployments need robust strategies for data integrity and high availability. Kubernetes can facilitate high availability through pod replicas and distributed deployments, but ensuring data consistency and durability across database instances and search indexes requires careful consideration and often additional tooling.

• Performance: Kubernetes networking and storage configurations can introduce performance overhead compared to native cloud services. For latency-sensitive applications or high-throughput workloads, these factors become critical in maintaining optimal performance.

• Observability: Troubleshooting issues in a Kubernetes environment, especially related to database and search engine performance, can be complex. Managed services typically come with built-in monitoring, logging, and alerting capabilities tailored to the specific service, making it easier to identify and resolve issues.

• Security and compliance: Kubernetes environments require careful attention to security best practices, including network policies, access controls, and encryption. Managed services often come pre-configured with security features and compliance certifications, reducing the burden on teams to implement and maintain these measures.

Authenticate with OCI registry

Copy the snippet below and replace the placeholder text with the credentials provided to you by your customer success manager:

Setup

1. Create a Kubernetes namespace named immuta for Immuta and its third-party dependencies.
2. Switch to namespace immuta.

Elasticsearch

1. Create a Helm values file named es-values.yaml with the following content:
2. Deploy Elasticsearch.

PostgreSQL

1. Create a Helm values file named pg-values.yaml with the following content:
3. Deploy PostgreSQL.
4. Wait for all pods in the namespace to become ready.
5. Determine the name of the PostgreSQL database pod. This will be referenced in a subsequent step.
6. Exec into the PostgreSQL database pod using the psql command and immuta user to configure the PostgreSQL user used by Immuta.
7. Alter the search_path for the immuta user.
8. Enable the pgcrypto extension.
9. Type \q then press Enter to exit.

Install Immuta

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

1. Create a Helm values file named immuta-values.yaml with the following content:
3. Deploy Immuta.

Validation

1. Wait for all pods in the namespace to become ready.
2. Determine the name of the Secure service.
3. Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.
4. Navigate to http://localhost:8080 in a web browser.

Next steps

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.

Create Kubernetes secret

1. Create a file named secret-data.env with the following content.
2. Create secret named immuta-legacy-secret from file secret-data.env
3. Delete file secret-data.env, as it's no longer needed.

Edit Helm values

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

Apply Helm values

This guide demonstrates how to upgrade Immuta. The Immuta Enterprise Helm chart (IEHC) shares the same version with the Immuta product, so upgrading the Immuta version entails upgrading the IEHC. Failure to upgrade the underlying Helm chart will lead to an unsupported configuration.

Immuta Enterprise Helm chart

Upgrade Immuta.

All application state is stored in the PostgreSQL metadata database; therefore, recovering from a disaster event only entails restoring the aforementioned PostgreSQL database. Consult each cloud provider's point-in-time recovery (PITR) documentation for guidance:

This guide demonstrates how to upgrade an existing Immuta deployment installed with the Immuta Helm chart (IHC) to the latest LTS release using the newer 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.
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.
2. Spawn a shell inside the running metadata database pod.
3. Perform a database backup.
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.

Setup new database

1. Create a pod named immuta-setup-db and spawn a shell.
2. Connect to the new PostgreSQL database as a superuser. Depending on the cloud provider, the default superuser name (postgres) might differ.
3. Create an immuta role and database.
4. Type \q, and then press Enter to exit the psql prompt.

5. Authenticate as the immuta user and create the pgcrypto extension.
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.
2. Copy file bometadata.dump from the host's working directory to pod immuta-restore-db.
3. Spawn a shell inside pod immuta-restore-db.
4. Perform a database restore while authenticated as role immuta. Refer to the value substituted for <postgres-password> when prompted to enter a password.
5. Type exit, and then press Enter to exit the shell prompt.

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

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.
2. Legacy audit records: If you want to be able to view audit records from before the 2024.2 upgrade, set FeatureFlag_auditLegacyViewHide to false in your Helm values file.

3. • • Amazon Elastic Kubernetes Service (EKS)

     • Google Kubernetes Engine (GKE)

     • Microsoft Azure Kubernetes Service (AKS)

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.
2. Install package bind-utils.
3. Perform DNS lookups on a given FQDN.

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

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

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

PostgreSQL

How do I determine if the database is accepting connections?

1. Create a pod named debug-postgres and spawn an interactive shell.
2. Validate that the database is listening.

Redis

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

1. Create a pod named debug-redis and spawn an interactive shell.
2. Send a raw TCP message to the database using Netcat.

How do I establish a TCP connection?

1. Create a pod named debug-redis and spawn an interactive shell.
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.

Elasticsearch

How do I query the API using cURL?

1. Create a pod named debug-elasticsearch and spawn an interactive shell.
2. Install package curl.