Install Kubernetes Helm
Rocky Linux 9
Review the potential impacts of Immuta's Rocky Linux 9 upgrade to your environment before proceeding:
ODBC Drivers
Your ODBC drivers should use a driver compatible with Enterprise Linux 9 or Red Hat Enterprise Linux 9.
Container Runtimes
You must run a supported version of Kubernetes.
Use at least Docker v20.10.10 if using Docker as the container runtime.
Use at least containerd 1.4.10 if using containerd as the container runtime.
OpenSSL 3.0
CentOS Stream 9 uses OpenSSL 3.0, which has deprecated support for older insecure hashes and TLS versions, such as TLS 1.0 and TLS 1.1. This shouldn't impact you unless you are using an old, insecure certificate. In that case, the certificate will no longer work. See the OpenSSL migration guide for more information.
FIPS Environments
If you run Immuta 2022.5.x containers in a FIPS-enabled environment, they will now fail. Helm Chart 4.11 contains a feature for you to override the openssl.cnf file, which can be used to allow Immuta to run in your environment, mimicking the CentOS 7 behavior.
Software Versions
Helm 3.2 or greater
Kubernetes: See the Install Immuta page for a list of versions Immuta supports.
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.
Cloud Storage (Recommended)
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, Azure SAS Token, or Azure Managed Identities.
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.
RBAC
The Immuta Helm Chart supports RBAC and will try to create all needed RBAC roles by default.
Ingress
Best Practice: Use Nginx Ingress Controller
Immuta recommends that you use the Nginx Ingress Controller because it supports both HTTP and TCP ingress.
Immuta needs Ingress for two services:
Immuta Web Service (HTTP)
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.
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.
Last updated