midPoint on Kubernetes: A Production Deployment Guide

Deploying Evolveum midPoint on Kubernetes brings scalability, reproducibility, and infrastructure-as-code practices to your identity management platform. This guide covers the key considerations for a production-grade midPoint Kubernetes deployment.

Why Kubernetes for midPoint?

Traditional midPoint deployments on bare-metal or VMs work well, but Kubernetes offers distinct advantages for organizations that need:

• Horizontal scaling for large identity populations
• Reproducible environments across dev, staging, and production
• Automated failover and self-healing
• GitOps-driven configuration management
• Consistent deployment across cloud providers (AWS EKS, Azure AKS, GCP GKE)

Architecture Overview

A production midPoint Kubernetes deployment typically consists of:

• midPoint application pods: The core midPoint instances, typically 2-3 replicas for high availability
• PostgreSQL database: midPoint’s repository, deployed as a StatefulSet or using a managed database service (RDS, Cloud SQL)
• Persistent storage: For midPoint home directory, keystores, and configuration files
• Ingress controller: NGINX or Traefik for HTTPS termination and routing
• ConfigMaps and Secrets: For environment-specific configuration without rebuilding images

Helm Charts for midPoint

Helm charts simplify midPoint deployment by packaging all Kubernetes resources into a single, versioned, configurable unit. A well-structured midPoint Helm chart includes:

• Deployment/StatefulSet for midPoint pods
• Service and Ingress definitions
• ConfigMap for midPoint configuration XML
• Secret for database credentials and keystores
• PersistentVolumeClaim for midPoint home
• Health check probes (liveness and readiness)

Values files allow you to customize the deployment per environment without modifying the chart itself.

GitOps Configuration Management

GitOps takes Kubernetes deployment to the next level by treating your entire midPoint configuration as code stored in Git:

• ArgoCD or Flux watches your Git repository for changes
• Any midPoint configuration change (roles, policies, resource definitions) is committed to Git
• The GitOps tool automatically applies changes to the cluster
• Full audit trail of every configuration change with Git history
• Easy rollback by reverting a Git commit

This approach is especially valuable for regulated environments where you need to demonstrate who changed what and when.

Production Hardening Checklist

Before going live, ensure:

• Database backups are automated and tested
• TLS certificates are configured for all endpoints
• Resource limits (CPU, memory) are set on all pods
• Pod disruption budgets prevent all replicas from going down simultaneously
• Monitoring and alerting (Prometheus/Grafana) are configured
• Log aggregation (ELK or Loki) captures midPoint audit logs
• Network policies restrict pod-to-pod communication
• Secrets are managed via external secrets operator or vault

Common Pitfalls

• Shared midPoint home directory: When running multiple replicas, the home directory must be on shared storage (NFS, EFS) or each pod needs its own PVC
• Database connection pooling: Configure connection pool sizes carefully to avoid exhaustion under load
• Startup time: midPoint takes time to initialize. Set generous initialDelaySeconds on liveness probes to prevent restart loops
• Session affinity: If using the midPoint GUI across replicas, configure session affinity on the service or use sticky sessions

Need Help with Your Kubernetes Deployment?

WeKnowIdentity specializes in Kubernetes-native midPoint deployments. We have delivered production environments on EKS, AKS, and bare-metal Kubernetes clusters for enterprise clients. Contact us for architecture guidance.

Related Resources

• Our midPoint consulting services
• Enterprise deployment case studies
• All WeKnowIdentity services