Install Immuta

This section illustrates how to install Immuta using Kubernetes, which allows Immuta to easily scale to meet all your future growth needs.

System Requirements

See the Helm installation prerequisites guide for details about system requirements.

Firewall Rules

Immuta Query Engine Port

The required firewall rules depend on whether you will use the Immuta Query Engine or exclusively use integrations. If you only use integrations, port 5432 is optional.

The following firewall rules are required to be opened to any host or network that need access to the Immuta service. Navigate to the tab of the technology you plan to use:

Integrations

Port	Protocol	Source
443	TCP	Web Service

Immuta Query Engine

Port	Protocol	Source
5432	TCP	PostgreSQL
443	TCP	Web Service

Kubernetes Providers

Immuta has a Helm chart available for installation on Kubernetes:

• Helm Installation on Kubernetes

Specific guides are available for the following Kubernetes cloud providers:

• AWS (including EKS)

• Azure (including AKS)

Supported Software Versions

Immuta supports the Kubernetes distributions outlined below.

Amazon Elastic Kubernetes Service (EKS)

• 1.25

• 1.26

• 1.27

• 1.28

• 1.29

Azure Kubernetes Service (AKS)

• 1.25

• 1.26

• 1.27

• 1.28

• 1.29

Google Kubernetes Engine (GKE)

• 1.24

• 1.25

• 1.26

• 1.27

• 1.28

OpenShift

• 4.12

• 4.13

• 4.14

Rancher Kubernetes Engine (RKE2)

• 1.24

• 1.25

• 1.26

• 1.27

• 1.28

Supported Configurations

Ingress Controller

The Immuta Helm Chart's built-in ingress controller is enabled by default, but will be disabled by default in future versions. If you have production workloads, consider moving away from using the built-in ingress controller.

Kubernetes Distribution	Logging	Ingress	Storage	Backup and Restore	External Metadata Database
AWS EKS	AWS Cloud Watch or third-party logging solution	Built-in ingress controller or third-party ingress controller	AWS EBS (default storage class in EKS)	AWS S3	AWS RDS Postgres (Use the supported version identified in the External Metadata Database Configuration guide.)
Azure EKS	Third-party logging solution	Built-in ingress controller or third-party ingress controller	Azure managed disks (default storage class in AKS)	Azure Blob Storage	Azure Database for PostgreSQL (Use the supported version identified in the External Metadata Database Configuration guide.)
Google GKE	Third-party logging solution	Built-in ingress controller or third-party ingress controller	Google Cloud Persistent Disks (default storage class in GKE)	Google Cloud Storage	Google Cloud SQL for PostgreSQL (Use the supported version identified in the External Metadata Database Configuration guide.)
Red Hat OpenShift	Third-party logging solution	Built-in ingress controller or third-party ingress controller	Cloud disks (AWS EBS, Azure managed disks, or Google Cloud Persistent Disks)	Cloud storage (S3, Azure Blob, Google Cloud Storage) or self-hosted object storage (such as MinIO)	Cloud-managed PostgreSQL, such as AWS RDS Postgres, Azure Database for PostgreSQL, or Google Cloud SQL for PostgreSQL (Use the supported version identified in the External Metadata Database Configuration guide.)
Rancher RKE2	Third-party logging solution	Built-in ingress controller or third-party ingress controller	Cloud Disks (AWS EBS, Azure managed disks, Google Cloud Persistent Disks)	Cloud storage (S3, Azure Blob, Google Cloud Storage) or self-hosted object storage (such as MinIO)	Cloud-managed PostgreSQL, such as AWS RDS Postgres, Azure Database for PostgreSQL, or Google Cloud SQL for PostgreSQL (Use the supported version identified in the External Metadata Database Configuration guide.)

Helm Implementation

Immuta depends on the Helm functionality outlined below.

• templates and functions

• Helm hooks:

  • pre-install

  • pre-upgrade

  • post-upgrade

  • post-delete: This hook is not strictly necessary and is only used to clean up some resources that are not deleted by Helm itself. If the post-delete hook is not supported, some resources may be left on the cluster after running helm delete.

Immuta support ends at our Helm implementation; wrapping Helm in another orchestration tool falls outside the Immuta support window.

Best Practices

Use Kubernetes for Scaling

• Identify a team to set up, configure, and maintain your Kubernetes environment. Immuta will help you with the installation of our platform, but the Kubernetes environment is your company's responsibility. Review Kubernetes best practices here.

• Use persistent volumes.

• Only use the Immuta-provided default Nginx Ingress Controller if you are using the Immuta query engine. Otherwise, opt to use your own ingress controller or no controller at all.

Back Up Your Environment

• Configure backups to run daily.

• Test your backups at least once a month.

• Use cloud storage (e.g., S3, ADLS, GCS).

• Create the proper IAM roles and IAM permissions (if using IAM roles). Your backups will fail if this is not configured correctly.

Monitor Your Infrastructure

Implementing infrastructure monitoring for the systems hosting your Immuta application is critical to ensuring its optimal performance, availability, and security. With today's complex IT environments, any disruption or delay in the underlying infrastructure can significantly impact your Immuta operations, affecting data governance processes and business outcomes. Infrastructure monitoring

• allows you to proactively oversee your servers, networks, and other hardware components in real time.

• identifies potential bottlenecks, hardware failures, or performance anomalies before they lead to significant issues or downtime.

• can alert you to unusual activities that might indicate security threats, allowing for swift mitigation.

By monitoring your hosting infrastructure, you ensure that your Immuta application continues to run smoothly, securely, and effectively.

Use any monitoring tool that is already deployed. If you're not using any monitoring tools yet, consider some of the following options:

• CloudTrail (if using AWS EKS or other cloud technologies)

• DataDog (generally platform agnostic)

• Prometheus (free and open-source software)

Use a Log Aggregation Tool

Using a log aggregation tool for your Immuta application is vital to maintaining operational efficiency and security. Modern applications' complex ecosystems generate vast amounts of log data that can be challenging to manage and analyze manually. A log aggregation tool centralizes these logs, making it easier to monitor the application's performance and health in real time. It can help detect anomalies, identify patterns, and troubleshoot issues more efficiently, thereby reducing downtime. Moreover, in the context of security, these tools can help detect suspicious activities or potential breaches by analyzing log data, contributing significantly to your overall data governance and risk mitigation strategy.

The logs in Kubernetes pods get renewed often, preventing Immuta support from viewing log history that is days or weeks old. Because these logs are necessary when investigating the behavior of pods and troubleshooting deployment related issues, enable log aggregation to capture the log history.

Use any logging tool that is already deployed. If you're not using a log aggregation tool yet, consider one of the following options:

• Splunk

• DataDog

• Grafana Loki (free and open-source software)

Once your log aggregation tool is deployed, follow these general best-practice guidelines:

• Pull logs from Immuta on a daily basis. These logs contain all of the information you will need to support auditing and compliance for access, queries, and changes in your environment.

• Store logs for at least 30 days in a log aggregator for monitoring and compliance.

• Discuss with your compliance group or lines of business which fields you want to monitor or report on from the Immuta logs. Immuta captures a wealth of information each time a user logs in, changes a policy, or runs a query, so work with your team to determine which items to capture in a log aggregation tool or store long-term.

Audit Record Storage

To ensure top performance, audit records should not be stored in Immuta longer than the default of 60 days. For long-term audit records, use an external audit storage solution to ensure long-term data retention, data preservation, centralized monitoring, enhanced security, and scalability. Using an external audit storage solution also empowers your organization to meet compliance requirements and derive valuable insights from audit data for informed decision-making and analysis.

By default, most Immuta audit records expire after 60 days, but there are some audit record types that do not expire after 60 days. See the Immuta system audit logs page for details.

Backup Retention Policy

Backup frequency and retention settings directly impact your data protection and disaster recovery capabilities. While a daily backup is the default frequency and provides a standard level of data security, it's essential to evaluate your specific needs and the sensitivity of your data. For organizations dealing with more sensitive or critical information, increasing the backup frequency beyond daily backups can help minimize the risk of data loss and potential downtime. However, balancing the backup frequency with resource use is vital to avoid impacting performance: longer retention periods enable historical data recovery, while shorter periods optimize storage usage. It is crucial to assess regulatory requirements, data validation practices, and your organization's tolerance for data loss to set an effective retention policy.

Configuring backup settings that align with your desired recovery capabilities and data validation frequency ensures a resilient and reliable application deployment. With the flexibility provided by Helm values, you can fine-tune these settings to match your unique business needs and data protection goals effectively:

• Backup frequency: By default, backups are taken once a day at midnight. This can be changed in the backup.schedule parameter in Helm values file using CronJob syntax to specify the frequency of these backups. Daily backups are standard but if there are more sensitive data, you can do more than one backup every day and vice versa.

• Backup file retention: Additionally, the number of backup files retained also matters. By default, 10 backup files are stored at all times in your storage of choice. Every time a new backup is taken, the oldest file is removed from the storage. This can be changed in the backup.maxBackupCount parameter in the Helm values file.

  • For smaller deployments, 10 backup files is acceptable, assuming the backups are taken once a day.

  • For production deployment, work with your Immuta representative to determine the right number of backup files for your environment.