# Managed Public Cloud

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 managed services must be provisioned and running before proceeding. For further assistance consult the [recommendations table](/latest/configuration/self-managed-deployment/deployment-requirements.md#infrastructure-recommendations) for your respective cloud provider.

{% hint style="warning" %}
**Feature availability**

If deployed without ElasticSearch/OpenSearch, several core services and features will be unavailable. See the [deployment requirements](/latest/configuration/self-managed-deployment/deployment-requirements.md) for details.
{% endhint %}

{% tabs %}
{% tab title="Amazon Web Services (AWS)" %}

* [Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/rds/)
* (Optional) [Amazon OpenSearch](https://docs.aws.amazon.com/opensearch-service/)
  {% endtab %}

{% tab title="Microsoft Azure" %}

* [Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/)
* (Optional) [Elastic Cloud on Azure](https://www.elastic.co/partners/microsoft-azure)
  {% endtab %}

{% tab title="Google Cloud Platform (GCP)" %}

* [Google Cloud SQL for PostgreSQL](https://cloud.google.com/sql/docs/postgres)
* (Optional) [Elastic Cloud on Google Cloud](https://www.elastic.co/partners/google-cloud)
  {% endtab %}
  {% endtabs %}

### Checklist

This checklist outlines the necessary prerequisites for successfully deploying Immuta.

#### Credentials

* [ ] You have the credentials needed to access the ocir.immuta.com OCI registry. These can be viewed in your user profile at [support.immuta.com](https://support.immuta.com).

#### PostgreSQL

* [ ] The PostgreSQL instance's hostname/FQDN is [resolvable from within the Kubernetes cluster](/latest/configuration/self-managed-deployment/troubleshooting.md#common).
* [ ] The PostgreSQL instance is [accepting connections](/latest/configuration/self-managed-deployment/troubleshooting.md#postgresql).
* [ ] You have a PostgreSQL user account with the necessary privileges to create databases, extensions, and roles.
* [ ] The Helm chart only supports username/password authentication for PostgreSQL. At this time, other authentication mechanisms are not supported.

#### Elasticsearch

* [ ] The Elasticsearch instance's hostname/FQDN is [resolvable from within the Kubernetes cluster](/latest/configuration/self-managed-deployment/troubleshooting.md#common).
* [ ] The Elasticsearch instance is [accepting connections](/latest/configuration/self-managed-deployment/troubleshooting.md#elasticsearch).
* [ ] The user must have the [required permissions](/latest/configuration/self-managed-deployment/deployment-requirements.md#opensearch-user).
* [ ] The Helm chart supports the following authentication methods for Elasticsearch. At this time, other authentication mechanisms are not supported:
  * [ ] [Username and password](/latest/configuration/self-managed-deployment/configure/opensearch-authentication/setting-up-opensearch-user-permissions-for-username-and-password-authentication.md)
  * [ ] [AWS assumed role for OpenSearch](/latest/configuration/self-managed-deployment/configure/opensearch-authentication/setting-up-opensearch-user-permissions-for-an-aws-role.md)

## Setup

### Helm

#### Authenticate with OCI registry

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

### Kubernetes

{% hint style="info" %}
Creating a dedicated namespace ensures a logically isolated environment for your Immuta deployment, preventing resource conflicts with other applications.
{% endhint %}

#### Create namespace

1. Create a Kubernetes namespace named `immuta`.

   ```bash
   kubectl create namespace immuta
   ```
2. Switch to namespace `immuta`. All subsequent `kubectl` commands will default to this namespace.

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

#### Create registry secret

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

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

{% hint style="info" %}
**Connecting a client**

There are numerous ways to connect to a PostgreSQL database. This step demonstrates how to connect with psql by creating an ephemeral Kubernetes pod.
{% endhint %}

#### Connect to the database

Connect to the database as an admin (e.g., `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.

```sh
kubectl run pgclient \
    --stdin \
    --tty \
    --rm \
    --image docker.io/bitnami/postgresql -- \
    psql --host <postgres-fqdn> --username <postgres-admin> --dbname postgres --port 5432 --password
```

#### Create role

{% hint style="info" %}
Temporal's upgrade mechanism utilizes SQL command `CREATE EXTENSION` when managing database schema changes. However, in cloud-managed PostgreSQL offerings, this command is typically restricted to roles with elevated privileges to protect the database and maintain the stability of the cloud environment.

To ensure Temporal can successfully manage its schema, an administrator role must be granted temporarily. The role name varies depending on the cloud-managed service:

* Amazon RDS: `rds_superuser`
* Azure Database: `azure_pg_admin`
* Google Cloud SQL: `cloudsqlsuperuser`
  {% endhint %}

1. Create the `immuta` role.

   ```sql
   CREATE ROLE immuta with LOGIN ENCRYPTED PASSWORD '<postgres-password>';
   ALTER ROLE immuta SET search_path TO bometadata,public;
   ```
2. Grant administrator privileges to the `immuta` role. Upon successfully completing this installation guide, you can optionally revoke this role grant.

   ```plsql
   GRANT <admin-role> TO immuta;
   ```
3. Grant the `immuta` role to the current user. Upon successfully completing this installation guide, you can optionally revoke this role grant.

   ```plsql
   GRANT immuta TO CURRENT_USER;
   ```

#### Create databases

1. Create databases.

   ```plsql
   CREATE DATABASE immuta OWNER immuta;
   CREATE DATABASE temporal OWNER immuta;
   CREATE DATABASE temporal_visibility OWNER immuta;
   ```
2. Grant role `immuta` additional privileges. Refer to the [PostgreSQL documentation](https://www.postgresql.org/docs/current/static/ddl-priv.html) for further details on database roles and privileges.

   ```plsql
   GRANT ALL ON DATABASE immuta TO immuta;
   GRANT ALL ON DATABASE temporal TO immuta;
   GRANT ALL ON DATABASE temporal_visibility TO immuta;
   ```
3. Configure the `immuta` database.

   ```plsql
   \c immuta
   CREATE EXTENSION pgcrypto;
   ```
4. Configure the `temporal` database.

   ```plsql
   \c temporal
   GRANT CREATE ON SCHEMA public TO immuta;
   ```
5. Configure the `temporal_visibility` database.

   <pre class="language-plsql"><code class="lang-plsql">\c temporal_visibility
   <strong>GRANT CREATE ON SCHEMA public TO immuta;
   </strong>CREATE EXTENSION btree_gin;
   </code></pre>
6. Exit the interactive prompt. Type `\q`, and then press `Enter`.

## Install Immuta

This section demonstrates how to deploy Immuta using the Immuta Enterprise Helm chart once the prerequisite cloud-managed services are configured.

{% hint style="warning" %}
**Feature availability**

If deployed without Elasticsearch/OpenSearch, several core services and features will be unavailable. See the [deployment requirements](/latest/configuration/self-managed-deployment/deployment-requirements.md) for details.
{% endhint %}

{% tabs %}
{% tab title="Default" %}

<pre class="language-yaml" data-title="immuta-values.yaml" data-line-numbers><code class="lang-yaml">global:
  imageRegistry: ocir.immuta.com
  imagePullSecrets:
    - name: immuta-oci-registry
  postgresql:
    host: &#x3C;postgres-fqdn>
    port: 5432
    username: immuta
    password: &#x3C;postgres-password>

audit:
  config:
    elasticsearchEndpoint: &#x3C;elasticsearch-endpoint>
    searchAuthenticationType: &#x3C;<a data-footnote-ref href="#user-content-fn-1">'UsernamePassword'</a> or '<a data-footnote-ref href="#user-content-fn-2">AWS</a>'>
  # If you use OpenSearch and authenticate with username and password, uncomment the lines below by deleting the hash symbols
    #elasticsearchUsername: &#x3C;elasticsearch-username>
    #elasticsearchPassword: &#x3C;elasticsearch-password>
  # If you use OpenSearch and authenticate with AWS role, uncomment the lines below by deleting the hash symbols. When using AWS role authentication, elasticsearchUsername (above) must be set to ''.
    #searchAwsRegion: '&#x3C;deployment-OS-region>'
  # If Immuta is deployed in an AWS account that is different than OpenSearch, then you must configure a trust relationship between the Immuta role and an OpenSearch role 
    #searchAwsRoleArn: '&#x3C;assumed-role-arn>'
  postgresql:
    database: immuta
  #init:
     #extraEnvVars:
        # <a data-footnote-ref href="#user-content-fn-3">Audit retention</a> defaults to 7 days. To change the retention period, uncomment the lines below by deleting the hash symbols and update the value
        #- name: AUDIT_RETENTION_POLICY_IN_DAYS
          #value: 90

secure:
  ingress:
    enabled: false
  postgresql:
    database: immuta
    ssl: true

temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls: 
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true
</code></pre>

{% endtab %}

{% tab title="Without Elasticsearch" %}
{% code title="immuta-values.yaml" lineNumbers="true" %}

```yaml
global:
  imageRegistry: ocir.immuta.com
  imagePullSecrets:
    - name: immuta-oci-registry
  postgresql:
    host: <postgres-fqdn>
    port: 5432
    username: immuta
    password: <postgres-password>

audit:
  enabled: false

secure:
  ingress:
    enabled: false
  postgresql:
    database: immuta
    ssl: true
  extraEnvVars:
    - name: FeatureFlag_AuditService
      value: false
    
temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls: 
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true
```

{% endcode %}
{% endtab %}
{% endtabs %}

1. Create a file named `immuta-values.yaml` with the above content, making sure to update all [placeholder values](/latest/configuration/self-managed-deployment/conventions.md).

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

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

2. Deploy Immuta.

   ```bash
   helm install immuta oci://ocir.immuta.com/stable/immuta-enterprise \
       --values immuta-values.yaml \
       --version 2026.1.4
   ```
3. Wait for all pods to become ready.

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

## Validation

{% hint style="info" %}
This section helps you validate your Immuta installation by temporarily accessing the application locally. However, this access is limited to your own computer. To enable access for other devices, you must proceed with configuring Ingress outlined in the [Next steps](#next-steps) section.
{% endhint %}

1. Determine the name of the Secure service.

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

   ```bash
   kubectl port-forward <service-name> 8080:http
   ```
3. In a web browser, navigate to [localhost:8080](http://localhost:8080), to ensure the Immuta application loads.
4. Press `Control+C` to stop port forwarding.

## Next steps

{% tabs %}
{% tab title="Amazon Web Services (AWS)" %}

* [Configure Ingress for EKS](/latest/configuration/self-managed-deployment/configure/ingress-configuration.md#aws-load-balancer-controller) (required).
* [Configure TLS certificates for EKS](/latest/configuration/self-managed-deployment/configure/tls-configuration.md#aws-load-balancer-controller).
* [Learn about best practices for running Immuta in production](/latest/configuration/self-managed-deployment/configure/immuta-in-production.md).
  {% endtab %}

{% tab title="Microsoft Azure" %}

* [Configure Ingress for AKS](/latest/configuration/self-managed-deployment/configure/ingress-configuration.md#aks-application-gateway-ingress-controller) (required).
* [Configure TLS certificates for AKS](/latest/configuration/self-managed-deployment/configure/tls-configuration.md#aks-application-gateway-ingress-controller).
* [Learn about best practices for running Immuta in production](/latest/configuration/self-managed-deployment/configure/immuta-in-production.md).
  {% endtab %}

{% tab title="Google Cloud Platform (GCP)" %}

* [Configure Ingress for GKE](/latest/configuration/self-managed-deployment/configure/ingress-configuration.md#gke-ingress-controller) (required).
* [Configure TLS certificates for GKE](/latest/configuration/self-managed-deployment/configure/tls-configuration.md#gke-ingress-controller).
* [Learn about best practices for running Immuta in production](/latest/configuration/self-managed-deployment/configure/immuta-in-production.md).
  {% endtab %}
  {% endtabs %}

[^1]: If using `UsernamePassword`, you must include the `elasticsearchUsername` and `elasticsearchPassword` values.

[^2]: If using `AWS` role authentication, `elasticsearchUsername` must be set to `''` and you must include the `searchAwsRegion` value.

[^3]: For more details about Immuta's audit retention, see the [Audit best practices page](/latest/configuration/self-managed-deployment/configure/audit-best-practices.md#retention-period).


---

# 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/latest/configuration/self-managed-deployment/install/managed-public-cloud.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.