Skip to content

You are viewing documentation for Immuta version 2023.1.

For the latest version, view our documentation for Immuta SaaS or the latest self-hosted version.

cancel

Immuta Architecture

Audience: All Immuta Users

Content Summary: This page details the major components, installation, scalability, availability, and security of the Immuta platform.

Immuta Components

Immuta's server-side software comprises the following major components:

  • Fingerprint Service: When enabled, additional statistical queries made during the health check are distilled into summary statistics, called fingerprints. During this process, statistical query results and data samples (which may contain PII) are temporarily held in memory by the Fingerprint Service.

  • Immuta Metadata Database: The database that contains instance metadata that powers the core functionality of Immuta, including policy data and attributes about data sources (tags, audit data, etc.).

  • Immuta Web Service: This component includes the Immuta UI and API and is responsible for all web-based user interaction with Immuta, metadata ingest, and the data fingerprinting process. Notionally a single web service, the fingerprinting functionality runs as a separate service internally and can be independently scaled.

Installation

Immuta's standard installation is a Helm installation to a Kubernetes cluster. This could be a Kubernetes cluster you manage or a hosted solution such as AKS, EKS, or GKE. This is the preferred deployment because of the minimal administration needed to achieve scale and availability.

Scalability

Immuta is designed to be scalable in several dimensions. For the standard Immuta deployment, minimal administrative effort is required to manage scaling beyond the addition of nodes to the Immuta system. Scalability can also be achieved in non-standard deployments, but requires the time of skilled systems administrator resources.

  • The Immuta web service is stateless and horizontally scalable.
  • By keeping a metadata catalog rather than maintaining separate copies of data, Immuta's database is designed to remain small and responsive. By running replicated instances of this internal database, the catalog can scale in support of the web service.

High Availability

Because each component of Immuta is designed to be horizontally scalable, Immuta can be configured for high availability. Upgrades and major configuration changes may require scheduled downtime, but even if Immuta's master internal database fails, recovery happens within seconds. With the addition of an external load balancer, Immuta's standard deployment comes preconfigured with these availability features.

Security

Immuta’s core function of policy enforcement and management is designed to improve your data security. Beyond this primary feature, Immuta protects your data in several other ways.

  • Immuta is designed to leverage your existing identity management system when desired. This design allows Immuta to benefit from the work your security team has already done to validate users, protect credentials, and define roles and attributes.

  • By default, all network communications with Immuta and within Immuta are encrypted via TLS. This practice ensures your data is protected while in transit.

  • Immuta does not make any persistent copies of data.

  • Immuta does not store raw customer data. However, it may temporarily cache samples of their data for SDD and fingerprinting. These samples are stored in the metadata database and cache containers.