Skip to content

You are viewing documentation for Immuta version 2022.5.

For the latest version, view our documentation for Immuta SaaS or the latest self-hosted version.

cancel

Helm Installation Prerequisites

Rocky Linux 9

Review the potential impacts of Immuta's Rocky Linux 9 upgrade to your environment before proceeding.

Software Versions

Helm and Immuta's Helm Chart

Immuta uses Helm to manage and orchestrate Kubernetes deployments. Check the Helm Release Notes to ensure you are using the correct Helm Chart with your version of Immuta.

Storage

Database Backups

Database backups for the metadata database and Query Engine may be stored in either cloud-based blob storage or a Persistent Volume in Kubernetes.

Backups may be stored using one of the following cloud-based blob storage services:

  • AWS S3
    • Supports authentication via AWS Access Key ID / Secret Key, IAM Roles via kube2iam or kiam, or IAM Roles in EKS.
  • Azure Blob Storage
    • Supports authentication via Azure Storage Key or Azure SAS Token.
  • Google Cloud Storage
    • Supports authentication via Google Service Account Key

Database Persistence

When database persistence is enabled, Immuta requires access to PersistentVolumes through the use of a persistent volume claim template. These volumes should normally be provided by a block device, such as AWS EBS, Azure Disk, or GCE Persistent Disk.

Additionally, when database persistence is enabled, Immuta requires the ability to run an initContainer as root. When PodSecurityPolicies are in place, service accounts must be granted access to use a PodSecurityPolicy with the ability to RunAsAny user.

Use Persistent Volumes

Backups may be stored in a Kubernetes Persistent Volume. The Persistent Volume must be backed by a storage technology that supports the "ReadWriteMany" access mode.

Best Practice: Persistent Volumes

Your company cluster should be able to provision persistent volumes for the best Immuta use.

RBAC

The Immuta Helm Chart supports RBAC and will try to create all needed RBAC roles by default.

Ingress

Immuta needs Ingress for two services:

  1. Immuta Web Service (HTTP)
  2. Immuta Query Engine (TCP)

The Immuta Helm Chart creates Ingress resources for HTTP services (the Immuta Web Service), but because of limitations with Kubernetes Ingress resources TCP ingress must be configured separately. The configuration for TCP ingress is dependent on the Ingress Controller that you are using in your cluster. Also, the configuration for TCP ingress is optional if you will only integrations, and it can be disabled.

Best Practice: Use Nginx Ingress Controller

Immuta recommends that you use the Nginx Ingress Controller because it supports both HTTP and TCP ingress.

To simplify the configuration for cluster Ingress, the Immuta Helm Chart contains an optional Nginx Ingress component that may be used to configure a Nginx Ingress Controller to be used specifically for Immuta. Contact your Immuta Support Professional for more information.

Worker Node Size

Immuta’s suggested minimum node size has 4 CPUs and 16GB RAM. The default Immuta Helm deployment requires at least 3 nodes.

TLS Certificates

All Immuta services use TLS certificates to enable communication over HTTPS. In order to support many configurations, the Immuta Helm Chart has the ability to configure internal and external communication independently. If TLS is enabled, by default, a certificate authority will be generated then used to sign a certificate for both internal and external communications. See Enabling TLS for instructions to configuring TLS.

Internal HTTPS communication refers to all communication between Immuta services. External HTTPS communication refers to communication between clients and the Immuta Query Engine and Web Service, which is configured using a Kubernetes Ingress resource.