# Generic Installation

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](https://bitnami.com/):

* [Elasticsearch](https://artifacthub.io/packages/helm/bitnami/elasticsearch)
* [PostgreSQL](https://artifacthub.io/packages/helm/bitnami/postgresql)

{% hint style="warning" %}
Running production-grade stateful workloads (e.g., databases) in Kubernetes is difficult and heavily discouraged due to the following reasons.
{% endhint %}

* **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

{% hint style="warning" %}
**Helm chart availability**

The deprecated Immuta Helm chart (IHC) is not available from ocir.immuta.com.
{% endhint %}

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

```shell
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.

   ```shell
   kubectl create namespace immuta
   ```
2. Switch to namespace `immuta`.

   ```shell
   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](https://support.immuta.com).

   ```shell
   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:

   ```yaml
   master:
       masterOnly: false
       replicaCount: 1

   data:
       replicaCount: 0

   coordinating:
       replicaCount: 0

   ingest:
       replicaCount: 0
   ```
2. Deploy Elasticsearch.

   ```shell
   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:

   ```yaml
   auth:
       database: immuta
       username: immuta
       password: <postgres-password>
   ```
2. Update all [placeholder values](/2024.2/self-managed-deployment/conventions.md) in the `pg-values.yaml` file.
3. Deploy PostgreSQL.

   ```shell
   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.

   ```shell
   kubectl wait --for=condition=Ready pods --all
   ```
5. Determine the name of the PostgreSQL database pod. This will be referenced in a subsequent step.

   ```shell
   kubectl get pod --selector "app.kubernetes.io/name=postgresql" --output name
   ```
6. Exec into the PostgreSQL database pod using the `psql` command and `immuta` user to configure the PostgreSQL user used by Immuta.

   ```shell
   kubectl exec --stdin --tty pod/<database-pod-name> -- psql -U immuta
   ```
7. Alter the `search_path` for the `immuta` user.

   ```sql
   ALTER ROLE immuta SET search_path TO bometadata,public;
   ```
8. Enable the `pgcrypto` extension.

   ```sql
   CREATE EXTENSION pgcrypto;
   ```
9. Type `\q` then press `Enter` to exit.

## Install Immuta

{% hint style="warning" %}
**Audit records**

**Preserving legacy audit records**

Immuta does not migrate legacy audit records to the [universal audit model (UAM)](/2024.2/detect-your-activity/audit/reference-guides/universal-audit-model-uam.md), so when you upgrade Immuta those audit records will be lost unless you enable the following setting in your immuta-values.yaml file:

```
secure:
  extraEnvVars:
    - name: FeatureFlag_auditLegacyViewHide
      value: "false"
```

**Audit record retention**

Immuta defaults to keeping audit records for 7 days. To change this duration, set the following values in the immuta-values.yaml file. The example below configures audit records to be kept for 90 days:

```yaml
audit:
  deployment:
      extraEnvVars:
        - name: AUDIT_RETENTION_POLICY_IN_DAYS
          value: "90"
```

{% endhint %}

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:

   ```yaml
   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](/2024.2/self-managed-deployment/conventions.md) in the `immuta-values.yaml` file.

{% hint style="warning" %}
**Avoid these special characters in generated passwords**

whitespace, `$`, `&`, `:`, `\`, `/`, `'`
{% endhint %}

3. Deploy Immuta.

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

## Validation

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

   ```shell
   kubectl wait --for=condition=Ready pods --all
   ```
2. Determine the name of the Secure service.

   ```shell
   kubectl get service --selector "app.kubernetes.io/component=secure" --output name
   ```
3. Listen on local port `8080`, forwarding TCP traffic to the Secure service's port named `http`.

   ```shell
   kubectl port-forward service/<name> 8080:http
   ```
4. Navigate to `http://localhost:8080` in a web browser.

## Next steps

* [Configure Ingress](/2024.2/self-managed-deployment/configure/ingress-configuration.md) to complete your installation and access your Immuta application.
* [Configure TLS](/2024.2/self-managed-deployment/configure/tls-configuration.md) 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](/2024.2/self-managed-deployment/configure/immuta-in-production.md).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://documentation.immuta.com/2024.2/self-managed-deployment/install/generic-installation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
