Running production-grade stateful workloads (e.g., databases) in Kubernetes is difficult and heavily discouraged due to the following reasons.
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.
Copy the snippet below and replace the placeholder text with the credentials provided to you by your customer success manager:
Create a Kubernetes namespace named immuta for Immuta and its third-party dependencies.
Switch to namespace immuta.
Create a container registry pull secret. Your credentials to authenticate with ocir.immuta.com can be viewed in your user profile at .
Create a Helm values file named es-values.yaml with the following content:
Deploy Elasticsearch.
Create a Helm values file named pg-values.yaml with the following content:
Update all in the pg-values.yaml file.
Deploy PostgreSQL.
This section demonstrates how to deploy Immuta using the Immuta Enterprise Helm chart once the prerequisite local services are configured.
Create a Helm values file named immuta-values.yaml with the following content:
Update all in the immuta-values.yaml file.
Deploy Immuta.
Wait for all pods in the namespace to become ready.
Determine the name of the Secure service.
Listen on local port 8080, forwarding TCP traffic to the Secure service's port named http.
to complete your installation and access your Immuta application.
to secure your Ingress by specifying a Secret that contains a TLS private key and certificate.
.
Wait for all pods in the namespace to become ready.
kubectl wait --for=condition=Ready pods --all
Determine the name of the PostgreSQL database pod. This will be referenced in a subsequent step.
kubectl get pod --selector "app.kubernetes.io/name=postgresql" --output name
Exec into the PostgreSQL database pod using the psql command and immuta user to configure the PostgreSQL user used by Immuta.
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>
kubectl get service --selector "app.kubernetes.io/component=secure" --output name
kubectl port-forward service/<name> 8080:http
Authenticate with OCI registry
Helm chart availability
The deprecated Immuta Helm chart (IHC) is not available from ocir.immuta.com.
Setup
Elasticsearch
PostgreSQL
Install Immuta
Audit records
Preserving legacy audit records
Immuta does not migrate legacy audit records to the universal audit model (UAM), so when you upgrade Immuta those audit records will be lost unless you enable the following setting in your immuta-values.yaml file:
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:
Avoid these special characters in generated passwords