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

1. The PostgreSQL instance's hostname/FQDN is resolvable from within the Kubernetes cluster.

2. The PostgreSQL instance is accepting connections.

Elasticsearch

1. The Elasticsearch instance's hostname/FQDN is resolvable from within the Kubernetes cluster.

2. The Elasticsearch instance is accepting connections.

3. The user must have the required permissions.

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 Kubernetes namespace named immuta for Immuta.

   Copy

   kubectl create namespace immuta

2. Switch to namespace immuta.

   Copy

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

3. Create a container registry pull secret. Your credentials to authenticate with ocir.immuta.com can be viewed in your user profile at support.immuta.com.

   Copy

   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

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.

   Copy

   kubectl 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. Create a Helm values file named immuta-values.yaml with the following content:

   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>@<postgres-fqdn>:5432/immuta?schema=audit
       elasticsearchEndpoint: <elasticsearch-endpoint>
       elasticsearchUsername: <elasticsearch-username>
       elasticsearchPassword: <elasticsearch-password>
   
   secure:
     ingress:
       enabled: false
       tls: false
     extraEnvVars:
       - name: FeatureFlag_AuditService
         value: "true"
       - name: FeatureFlag_detect
         value: "true"
       - name: FeatureFlag_auditLegacyViewHide
         value: "true"
   
     postgresql:
       host: <postgres-fqdn>
       port: 5432
       database: immuta
       username: immuta
       password: <postgres-password>
       ssl: true

2. Update all placeholder values in the immuta-values.yaml file.

3. Deploy Immuta.

   Copy

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

Validation

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

   Copy

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

2. Determine the name of the Secure service.

   Copy

   kubectl 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

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

Next steps

The guides in this section illustrate how to install and deploy Immuta in your Kubernetes environment. If your distribution is not listed below (such as K3s or RKE2), follow the generic installation instructions.

• Managed public cloud: This guide includes instructions for

  • Amazon Elastic Kubernetes Service (EKS)

  • Google Kubernetes Engine (GKE)

  • Microsoft Azure Kubernetes Service (AKS)

• Red Hat OpenShift

• Generic installation

• Immuta in an air-gapped environment

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

Getting started

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

The guides in this section illustrate how to install and deploy Immuta in your Kubernetes environment. If your distribution is not listed below (such as K3s or RKE2), follow the generic installation instructions:

• Managed public cloud: This guide includes instructions for

  • Amazon Elastic Kubernetes Service (EKS)

  • Google Kubernetes Engine (GKE)

  • Microsoft Azure Kubernetes Service (AKS)

• Red Hat OpenShift

• Generic installation

Configure

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:

• Upgrading to Immuta v2024.2 LTS: Upgrade from Immuta v2024.1.x or older to Immuta v2024.2 LTS.

• Upgrade Immuta: Upgrade from Immuta v2024.2 LTS or newer.

Disaster recovery

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

Troubleshooting

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

Release notes

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

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.

2. The PostgreSQL instance's hostname/FQDN is resolvable from within the Kubernetes cluster.

3. The PostgreSQL instance is accepting connections.

Redis

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

2. The Redis instance's hostname/FQDN is resolvable from within the Kubernetes cluster.

3. The Redis instance is accepting connections.

Elasticsearch

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

2. The Elasticsearch instance's hostname/FQDN is resolvable from within the Kubernetes cluster.

3. The Elasticsearch instance is accepting connections.

4. The user must have the required permissions.

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. Create a container registry pull secret. Your credentials to authenticate with ocir.immuta.com can be viewed in your user profile at support.immuta.com.

   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. Create a Helm values file named immuta-values.yaml with the content below. Because the Ingress resource will be managed by an OpenShift route you will create when configuring Ingress and not the Immuta Enterprise Helm chart, ingress is set to false below. TLS comes pre-configured with OpenShift, so tls is also set to false.

   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

2. Update all placeholder values in the immuta-values.yaml file.

3. Deploy Immuta.

   Copy

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

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

• Configure Ingress to complete your installation and access your Immuta application.

• Learn more about best practices for Immuta in Production.

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

• Simplify Operations: Immuta’s dynamic access control and policy management require 93x fewer data policies to manage access control in your data platform according to the GigaOm study. It is simple and scalable, which improves change management and lowers the total cost of ownership of cloud data management.

• Improve data security: Immuta helps prove compliance with rules and regulations, even when securing hundreds of thousands of tables. An Immuta customer, Swedbank, migrated all critical analytics workloads to the cloud in less than 12 months, including over 100 terabytes from more than 2,500 sources.

• Unlock data’s value: Immuta helps organizations get access to more data 100x faster, which translates to improved productivity. An Immuta customer, Thomson Reuters enabled faster access to data, resulting in a 60x increase in data usage and greater productivity.

How does Immuta do it?

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

Sensitive data discovery and classification: Immuta Discover

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.

Continuous data security monitoring: Immuta Detect

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

Data security and access control: Immuta Secure

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

After installing Immuta, begin with Immuta Detect. This section will guide you through Immuta configuration and leverage the capabilities of Immuta Discover to provide insights into where you have gaps in security and a complete understanding of your data ecosystem.

From there, you can move on to Immuta Secure to mitigate (and constantly mitigate) those findings from Immuta Detect. This section includes three separate use cases, which are common across customers and includes recommendations for how to best solve those use cases. Consult the use cases to determine which path is best for you.

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

Install Skopeo

The commands on this page copy the Immuta images from the registry to the local host and export to tarball using skopeo. Install skopeo by following the instructions in the Skopeo GitHub repository.

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

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.12
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.12.tgz -f immuta-values.yaml

The guides below outline how to deploy Immuta without Elasticsearch.

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

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

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

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

Considerations

For the purposes of this guide, the following state stores are deployed in Kubernetes using third-party Helm charts maintained by Bitnami:

• Elasticsearch

• PostgreSQL

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

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

Setup

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

   Copy

   kubectl create namespace immuta

2. Switch to namespace immuta.

   Copy

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

3. Create a container registry pull secret. Your credentials to authenticate with ocir.immuta.com can be viewed in your user profile at support.immuta.com.

   Copy

   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

Elasticsearch

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

   Copy

   master:
       masterOnly: false
       replicaCount: 1
   
   data:
       replicaCount: 0
   
   coordinating:
       replicaCount: 0
   
   ingest:
       replicaCount: 0

2. Deploy Elasticsearch.

   Copy

   helm install es-db oci://registry-1.docker.io/bitnamicharts/elasticsearch \
       --values es-values.yaml

PostgreSQL

1. Create a Helm values file named pg-values.yaml with the following content:

   Copy

   auth:
       database: immuta
       username: immuta
       password: <postgres-password>

2. Update all placeholder values in the pg-values.yaml file.

3. Deploy PostgreSQL.

   Copy

   helm install pg-db oci://registry-1.docker.io/bitnamicharts/postgresql \
       --values pg-values.yaml

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

   Copy

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

5. Determine the name of the PostgreSQL database pod. This will be referenced in a subsequent step.

   Copy

   kubectl get pod --selector "app.kubernetes.io/name=postgresql" --output template='{{ .metadata.name }}'

6. Exec into the PostgreSQL database pod using the psql command and immuta user to configure the PostgreSQL user used by Immuta.

   Copy

   kubectl exec --stdin --tty pod/<database-pod-name> -- psql -U immuta

7. Alter the search_path for the immuta user.

   Copy

   ALTER ROLE immuta SET search_path TO bometadata,public;

8. Enable the pgcrypto extension.

   Copy

   CREATE EXTENSION pgcrypto;

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:

   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:
       # 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
       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>
   
   secure:
     ingress:
       enabled: false
     extraEnvVars:
       - name: FeatureFlag_AuditService
         value: "true"
       - name: FeatureFlag_detect
         value: "true"
       - name: FeatureFlag_auditLegacyViewHide
         value: "true"
   
     postgresql:
       # 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
       host: pg-db-postgresql.immuta.svc.cluster.local
       port: 5432
       database: immuta
       username: immuta
       password: <postgres-password>

2. Update all placeholder values in the immuta-values.yaml file.

3. Deploy Immuta.

   Copy

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

Validation

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

   Copy

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

2. Determine the name of the Secure service.

   Copy

   kubectl 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

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

4. Navigate to http://localhost:8080 in a web browser.

Next steps

• Configure Ingress to complete your installation and access your Immuta application.

• Configure TLS to secure your Ingress by specifying a Secret that contains a TLS private key and certificate.

• Learn more about best practices for Immuta in Production.

This guide demonstrates how to verify signed artifacts (i.e., container images, Helm charts) hosted on ocir.immuta.com using Cosign from Sigstore.

Verify

1. Create a file named immuta-cosign.pub with the following content:

   Copy

   -----BEGIN PUBLIC KEY-----
   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEIGUDdu5dgqxQTlbNt0bCIl+zCN65
   JC/PmmaC08Eb/UbpkSDmcn/t9Jh+w6Chwkkcp1olcOS1BqCaWrbtViu6Xg==
   -----END PUBLIC KEY-----

2. Verify artifact signature.

   Copy

   cosign verify \
       --key ./immuta-cosign.pub \
       ocir.immuta.com/stable/<artifact-name>:2024.2.12

Frequently asked question

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

List all container images by rendering the chart templates locally.

helm template <release-name> oci://ocir.immuta.com/stable/immuta-enterprise \
    --values immuta-values.yaml \
    --version 2024.2.12 \
| yq '..|.image? | select(.)' | sort -u

The instructions and how-to guides on this page illustrate how to install Immuta in your Kubernetes environment. If you are upgrading Immuta, navigate to the Upgrade section instead.

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

• Deploy the services listed on the Deployment requirements guide. See the recommendations table for guidance for specific cloud providers.

• Grant RBAC permissions to create Kubernetes resources in the cluster.

Pull the Helm chart

Consult the upgrade overview if unsure which Helm chart to use.

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

(Deprecated) archives.immuta.com

1. Obtain the Kubernetes Helm Installation Credentials to authenticate with Immuta's Helm registry from your Immuta support professional

2. Copy the snippet below and replace the placeholder text with the credentials you obtained in the previous step to add the Helm repository:

   Copy

   echo <token> | helm repo add --username <username> --password-stdin immuta https://archives.immuta.com/charts

3. (Optional) Fetch the latest chart information from the repository:

   Copy

   helm repo update immuta

4. List all available versions of the chart.

   • Immuta Enterprise Helm chart (IEHC):

     Copy

     helm search repo --regexp 'immuta/immuta-enterprise\v' --versions

   • Immuta Helm chart (IHC):

     Copy

     helm search repo --regexp 'immuta/immuta\v' --versions

Install Immuta

Immuta can be installed on any Kubernetes cluster. Select a guide below that corresponds to your Kubernetes distribution to install Immuta. If your distribution is not listed below (such as K3s or RKE2), follow the generic installation instructions:

• Managed public cloud: This guide includes instructions for

  • Amazon Elastic Kubernetes Service (EKS)

  • Google Kubernetes Engine (GKE)

  • Microsoft Azure Kubernetes Service (AKS)

• Red Hat OpenShift

• Generic installation

Configure Ingress

To complete your installation and access the Immuta application, configure Ingress.

Additional recommendations

The configure section includes guidance for various scenarios you may encounter during and post-deployment. Below are several guides from that section that most customers follow to complete their deployment of Immuta, but none of these is a requirement for the Immuta installation to work.

• TLS configuration: Secure your Ingress by specifying a Secret that contains a TLS private key and certificate.

• Immuta in production: Follow these best practices for configuring your deployment for a production environment.

• External cache configuration: The Immuta Enterprise Helm chart manages its own Memcached deployment inside the cluster. However, you can opt to externalize the key-value cache post-installation.

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

Prerequisite

The Immuta in production guide must be completed before proceeding.

Redis

1. Edit secret immuta-secret that was created in the Immuta in production guide.

   Copy

   kubectl edit secret/immuta-secret

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

Edit Helm values

Edit the immuta-values.yaml file to include the relevant Helm values listed below. Update all placeholder values with your own 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

Perform a Helm upgrade to apply the changes made to immuta-values.yaml.

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

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. Update the placeholder value with a query engine superuser password.

   Copy

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

6. Update the placeholder value with a query engine replication password.

   Copy

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

7. Update the placeholder value with a query engine feature password.

   Copy

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

8. Scale the replica count back up to the previous value by updating the placeholder value.

   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. Perform a Helm upgrade to apply the changes made to immuta-values.yaml. Update the placeholder value with your own release name.

   Copy

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

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

Assign memory resource limits to pods.

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