This section illustrates how to install Immuta on Kubernetes using the Immuta Enterprise Helm chart.

Requirements

This reference guide provides an overview of the Immuta Enterprise Helm chart version requirements and infrastructure recommendations.

Install

The guides in this section illustrate how to install and deploy Immuta in your Kubernetes environment.

Upgrade

The guides in this section illustrate how to upgrade Immuta.

Guides

The guides in this section illustrate how to configure your Immuta Enterprise Helm chart for various scenarios, including optimizing your deployment for production environments.

Disaster recovery

This guide provides links to additional resources for disaster recovery strategies.

Troubleshooting

This page provides troubleshooting guidance and outlines frequently asked questions for the Immuta installation.

Conventions

This page introduces the core concepts and terminology essential for understanding the installation material.

Immuta helps you achieve the following outcomes in your data platform:

• Simplify Operations: Immuta’s dynamic access control and policy management require 93x fewer data policies to manage access control in your data platform according to the GigaOm study. It is simple and scalable, which improves change management and lowers the total cost of ownership of cloud data management.

• Improve data security: Immuta helps prove compliance with rules and regulations, even when securing hundreds of thousands of tables. An Immuta customer, Swedbank, migrated all critical analytics workloads to the cloud in less than 12 months, including over 100 terabytes from more than 2,500 sources.

• Unlock data’s value: Immuta helps organizations get access to more data 100x faster, which translates to improved productivity. An Immuta customer, Thomson Reuters enabled faster access to data, resulting in a 60x increase in data usage and greater productivity.

How does Immuta do it?

Immuta provides three modules to create a full data security platform suite.

Sensitive data discovery and classification: Immuta Discover

Discover sensitive data from millions of fields without manual effort. With over 60 pre-built and domain-specific identifiers, you can tailor data classification to your unique business needs based on your desired confidence level.

Continuous data security monitoring: Immuta Detect

Leverage timely insights into data access and user activity with anomaly indicators for faster analysis and proactive actions.

Data security and access control: Immuta Secure

Immuta’s attribute-based access control (ABAC) delivers scalable data access without role explosion, and dynamic data masking ensures the right users can access the right data.

The guides in this section illustrate how to install and deploy Immuta in your Kubernetes environment.

Prerequisites

Checklist

• RBAC permissions have been granted to create resources in the cluster.

Quickstart

Get started quickly with these essential guides. For a more comprehensive understanding and advanced configurations, explore the full suite of guides.

1. Complete the guide that corresponds with your Kubernetes cluster's distribution.

   • Managed public cloud: This guide includes instructions for

     • Amazon Elastic Kubernetes Service (EKS)

     • Google Kubernetes Engine (GKE)

     • Microsoft Azure Kubernetes Service (AKS)

   • Red Hat OpenShift

   • SUSE Rancher Kubernetes Engine (RKE2)

   • K3s

2. Complete the Ingress configuration guide.

3. Complete the Production best practices guide.

Immuta comprises three core services: Secure, Discover, and Detect. These services rely on PostgreSQL and Elasticsearch to store their states, a caching layer, and Temporal for job execution. The illustration below shows the relationships among these services.

The Immuta Enterprise Helm chart (IEHC) does not include the deployment of PostgreSQL or Elasticsearch, so you must deploy them separately.

Although Immuta recommends using Elasticsearch because it supports several new Immuta features and services, you can deploy Immuta without Elasticsearch. The table below outlines the Immuta features supported with and without Elasticsearch and the dependencies you must deploy and manage yourself.

For more information about legacy features and services no longer enabled in the recommended deployment of Immuta, see the Legacy features and services section.

Version requirements

Kubernetes versions

Metadata database (PostgreSQL)

• PostgreSQL 15.0 or newer

• The pgcrypto, btree_gin extensions must be enabled

Elasticsearch

• Elasticsearch v7 API or newer

• OpenSearch compatible with Elasticsearch v7 API or newer

OpenSearch user

The user provided during the install must have the following permissions:

• cluster:monitor/health

• indices:data/write/bulk*

• indices:data/write/bulk

• indices:data/read/search

• indices:admin/exists

• indices:admin/create

• indices:admin/delete

• indices:admin/settings/update

• indices:admin/get

• indices:data/write/delete/byquery

• indices:data/write/index

• indices:admin/mapping/put

• indices:data/write/bulk

• indices:data/write/bulk*

Follow OpenSearch documentation to create the user and add permissions, or see the Setting up OpenSearch permissions knowledge base article.

Cache (Redis/Memcached)

• Redis 7.0 or newer

• Memcached 1.6 or newer

Temporal

• Temporal 1.24.2 or newer

Infrastructure recommendations

Legacy features and services

Some legacy services and features are no longer enabled in the recommended configuration of the IEHC. The table below lists these features and provides links to documentation that outlines how to enable them in Immuta.

This guide demonstrates how to upgrade an existing Immuta deployment installed with the older Immuta Helm chart (IHC) to v2024.2 LTS using the Immuta Enterprise Helm chart (IEHC).

Prerequisites

Create a PostgreSQL database

1. The PostgreSQL instance has been provisioned and is actively running.

2. The PostgreSQL instance's hostname/FQDN is .

3. The PostgreSQL instance is .

For additional information, consult the Deployment requirements.

Validate the Helm release

1. Fetch the metadata for the Helm release associated with Immuta.

2. Review the output from the previous step and verify the following:

   • The Immuta version (appVersion) is

     • The last LTS (2022.5.x) or 2024.1 or newer

     • Less than 2024.2

   • The Immuta Helm chart (version) is greater than or equal to 4.13.5

   • The Immuta Helm chart name (chart) is immuta

3. If any of the criteria is not met, it's first necessary to perform a .

Metadata database

The new IEHC no longer supports deploying a Metadata database (PostgreSQL) inside the Kubernetes cluster. Before transitioning to the new IEHC, it's first necessary to externalize the Metadata database.

Built-in

The following demonstrates how to take a database backup and import the data into each cloud provider's managed PostgreSQL service.

Create backup of old database

1. Get the metadata database pod name.
2. Spawn a shell inside the running metadata database pod.
3. Perform a database backup.
4. Type exit, and then press Enter to exit the shell prompt.

5. Copy file bometadata.dump from the pod to the host's working directory.

Setup new database

1. Create a pod named immuta-setup-db and spawn a shell.
2. Connect to the new PostgreSQL database as a superuser. Depending on the cloud provider, the default superuser name (postgres) might differ.
3. Create immuta, temporal, and temporal_visiblity databases and an immuta role.
4. Type \q, and then press Enter to exit the psql prompt.

5. Authenticate as the immuta user and create the pgcrypto extension.
6. Type \q, and then press Enter to exit the psql prompt.

Restore backup to new database

1. Create a pod named immuta-restore-db and spawn a shell.
2. Copy file bometadata.dump from the host's working directory to pod immuta-restore-db.
3. Spawn a shell inside pod immuta-restore-db.
4. Perform a database restore while authenticated as role immuta. Refer to the value substituted for <postgres-password> when prompted to enter a password.
5. Type exit, and then press Enter to exit the shell prompt.

6. Delete pod immuta-restore-db that was previously created.

External

No additional work is required. The existing database can be reused with the new IEHC.

Helm values

1. Rename the existing immuta-values.yaml Helm values file used by the IHC.

Introduced in 2024.2, the Immuta Enterprise Helm chart (IEHC) is an entirely new Helm chart used to deploy Immuta. Unlike the previous Immuta Helm chart (IHC), the IEHC shares the same version as the Immuta product. Each version of the chart supports a singular version of Immuta. Upgrading the Immuta version now entails upgrading the underlying Helm chart. Failure to do so will lead to an unsupported configuration.

Recommended

• ): Upgrade from v2024.2 LTS to v2024.3 using the Immuta Enterprise Helm chart.

Legacy

• : Upgrade from v2024.2 LTS to v2024.3 using the legacy Immuta Helm chart.

This is a generic guide that demonstrates how to deploy Immuta into RKE2 (i.e., Rancher Government) without dependencies on any particular cloud provider. Advanced Kubernetes expertise is required; therefore, it is not suitable for beginners.

Considerations

For the purposes of this guide, the following state stores are deployed in Kubernetes using third-party Helm charts maintained by :

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

Prerequisite

Checklist

This checklist outlines the necessary prerequisites for successfully deploying Immuta.

Setup

Helm

Authenticate with OCI registry

Kubernetes

Create namespace

1. Create a Kubernetes namespace named immuta.
2. Switch to namespace immuta. All subsequent kubectl commands will default to this namespace.

Create registry secret

Elasticsearch

Install Helm chart

1. Create a Helm values file named es-values.yaml with the following content:

1. Deploy Elasticsearch.
2. Wait for all Elasticsearch pods to become ready.

PostgreSQL

Install Helm chart

1. Create a Helm values file named pg-values.yaml.

2. Deploy PostgreSQL.
3. Wait for all PostgreSQL pods to become ready.

Configure databases

1. Determine the name of the PostgreSQL database pod. This will be referenced in a subsequent step.
2. Exec into the PostgreSQL database pod using psql.
3. Configure the immuta database.
4. Configure the temporal database.
5. Configure the temporal_visibility database.
6. Exit the interactive prompt. Type \q, 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.

2. Deploy Immuta.
3. Wait for all pods to become ready.

Validation

1. Determine the name of the Secure service.
2. Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.
4. Press Control+C to stop port forwarding.

Next steps

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 for your respective cloud provider.

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 .

PostgreSQL

• You have a PostgreSQL user account with the necessary privileges to create databases, extensions, and roles.

Elasticsearch

Setup

Helm

Authenticate with OCI registry

Kubernetes

Create namespace

1. Create a Kubernetes namespace named immuta.
2. Switch to namespace immuta. All subsequent kubectl commands will default to this namespace.

Create registry secret

PostgreSQL

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.

Create role

1. Create the immuta role.
2. Grant administrator privileges to the immuta role. Upon successfully completing this installation guide, you can optionally revoke this role grant.
3. Grant the immuta role to the current user. Upon successfully completing this installation guide, you can optionally revoke this role grant.

Create databases

1. Create databases.
3. Configure the immuta database.
4. Configure the temporal database.
5. Configure the temporal_visibility database.
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.

2. Deploy Immuta.
3. Wait for all pods to become ready.

Validation

1. Determine the name of the Secure service.
2. Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.
4. Press Control+C to stop port forwarding.

Next steps

This is a generic guide that demonstrates how to deploy Immuta into K3s without dependencies on any particular cloud provider. Advanced Kubernetes expertise is required; therefore, it is not suitable for beginners.

Considerations

For the purposes of this guide, the following state stores are deployed in Kubernetes using third-party Helm charts maintained by :

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

Prerequisites

Checklist

This checklist outlines the necessary prerequisites for successfully deploying Immuta.

Credentials

Setup

Helm

Authenticate with OCI registry

Kubernetes

Create namespace

1. Create a Kubernetes namespace named immuta.
2. Switch to namespace immuta. All subsequent kubectl commands will default to this namespace.

Create registry secret

Elasticsearch

Install Helm chart

1. Create a Helm values file named es-values.yaml with the following content:

1. Deploy Elasticsearch.
2. Wait for all Elasticsearch pods to become ready.

PostgreSQL

Install Helm chart

1. Create a Helm values file named pg-values.yaml.

2. Deploy PostgreSQL.
3. Wait for all PostgreSQL pods to become ready.

Configure databases

1. Determine the name of the PostgreSQL database pod. This will be referenced in a subsequent step.
2. Exec into the PostgreSQL database pod using psql.
3. Configure the immuta database.
4. Configure the temporal database.
5. Configure the temporal_visibility database.
6. Exit the interactive prompt. Type \q, 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.

2. Deploy Immuta.
3. Wait for all pods to become ready.

Validation

1. Determine the name of the Secure service.
2. Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.
4. Press Control+C to stop port forwarding.

Next steps

The following guides offer practical guidance for handling common challenges and configurations.

Ingress configuration

Configure Ingress to complete your installation and access your Immuta application.

TLS configuration

Configure TLS termination for an Ingress resource.

Cosign verification

Verify artifacts hosted on the ocir.immuta.com OCI registry.

Production best practices

Follow these best practices when deploying Immuta in your production environment.

Rotating credentials

Update the credentials referenced in the Immuta Enterprise Helm chart.

External cache configuration

Configure an external key-value cache (such as Redis or Memcached) with the Immuta Enterprise Helm chart.

Enabling legacy query engine and fingerprint

Enable these legacy services for your deployment if they are required for your business use case:

• If you are using any of the data platforms below, you must enable the query engine:

  • Amazon Redshift

  • Azure Synapse Analytics

  • Google BigQuery

  • Any legacy database

• If you are using the legacy sensitive data discovery (SDD) feature, you must enable the query engine and fingerprint services.

Private container registries

Configure pulling images from a private registry.

Air-gapped environments

Tips when installing Immuta without internet access.

This is a guide on how to deploy Immuta on OpenShift.

Prerequisites

The following managed services must be provisioned and running before proceeding. For further assistance consult the recommendations table for your respective cloud provider.

• PostgreSQL

• (Optional) Elasticsearch/OpenSearch

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.

PostgreSQL

• The PostgreSQL instance's hostname/FQDN is resolvable from within the Kubernetes cluster.

• The PostgreSQL instance is accepting connections.

• You have a PostgreSQL user account with the necessary privileges to create databases, extensions, and roles.

Elasticsearch

• The Elasticsearch instance's hostname/FQDN is resolvable from within the Kubernetes cluster.

• The Elasticsearch instance is accepting connections.

• The user must have the required permissions.

Setup

Helm

Authenticate with OCI registry

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

Kubernetes

Create project

1. Create an OpenShift project named immuta.

   Copy

   oc new-project immuta

2. Get the UID range allocated to the project. Each running container's UID must fall within this range. This value will be referenced later on.

   Copy

   oc get project immuta --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'

3. Get the GID range allocated to the project. Each running container's GID must fall within this range. This value will be referenced later on.

   Copy

   oc get project immuta --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'

4. Switch to project immuta.

   Copy

   oc project 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.

oc 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

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.

oc run pgclient \
    --stdin \
    --tty \
    --rm \
    --image docker.io/bitnami/postgresql -- \
    psql --host <postgres-fqdn> --username <postgres-user> --port 5432 --password

Create Role

1. Create the immuta role.

   Copy

   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.

   Copy

   GRANT <admin-role> TO immuta;

Create databases

1. Create databases.

   Copy

   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 for further details on database roles and privileges.

   Copy

   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.

   Copy

   \c immuta
   CREATE EXTENSION pgcrypto;

4. Configure the temporal database.

   Copy

   \c temporal
   GRANT CREATE ON SCHEMA public TO immuta;

5. Configure the temporal_visibility database.

   Copy

   \c temporal_visibility
   GRANT CREATE ON SCHEMA public TO immuta;
   CREATE EXTENSION btree_gin;

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.

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

audit:
  config:
    elasticsearchEndpoint: http://es-db-elasticsearch.immuta.svc.cluster.local:9200
    elasticsearchUsername: <elasticsearch-username>
    elasticsearchPassword: <elasticsearch-password>
  postgresql:
    database: immuta 

  deployment:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  worker:
    podSecurityContext:  
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL 

discover:
  deployment:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

secure:
  ingress:
    enabled: false

  postgresql:
    database: immuta
    ssl: false

  web:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
  
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

  backgroundWorker:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault
      
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  
temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls:
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true
    frontend:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    history:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    matching:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    worker:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
  schema:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  proxy:
    deployment:
      podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
      containerSecurityContext:
        enabled: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

global:
  imageRegistry: ocir.immuta.com
  imagePullSecrets:
    - name: immuta-oci-registry
  featureFlags:
    AuditService: false
    detect: false
    auditLegacyViewHide: false
  postgresql:
    host: <postgres-fqdn>
    port: 5432
    username: immuta
    password: <postgres-password>

audit:
  enabled: false

discover:
  deployment:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault

    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

secure:
  ingress:
    enabled: false

  postgresql:
    database: immuta
    ssl: true

  web:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault

    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

  backgroundWorker:
    podSecurityContext:
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
      runAsUser: <user-id>
      # A number that is within the project range:
      #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
      runAsGroup: <group-id>
      seccompProfile:
        type: RuntimeDefault

    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

temporal:
  enabled: true
  schema:
    createDatabase:
      enabled: false
  server:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    config:
      persistence:
        default:
          sql:
            database: temporal
            tls:
              enabled: true
        visibility:
          sql:
            database: temporal_visibility
            tls:
              enabled: true
    frontend:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    history:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    matching:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    worker:
      containerSecurityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
  schema:
    podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
    containerSecurityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
  proxy:
    deployment:
      podSecurityContext:
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.uid-range"}}{{"\n"}}'
        runAsUser: <user-id>
        # A number that is within the project range:
        #   oc get project <project-name> --output template='{{index .metadata.annotations "openshift.io/sa.scc.supplemental-groups"}}{{"\n"}}'
        runAsGroup: <group-id>
        seccompProfile:
          type: RuntimeDefault
      containerSecurityContext:
        enabled: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL