Platform Services

The platform layer deploys all middleware into the platform namespace. These components provide the data, messaging, identity, and networking foundation that OSDU services depend on.

Platform Services

Components

Each component is independently toggleable via feature flags. All default to enabled except Airflow.

Component	Role
Elasticsearch	Full-text search and indexing for OSDU records
PostgreSQL	Relational storage with per-service databases
Redis	In-memory caching for authorization and session data
RabbitMQ	Async messaging between OSDU services
MinIO	S3-compatible object storage for development
Keycloak	Identity provider with OSDU realm auto-configuration
Airflow	Workflow orchestration for DAG-based tasks (optional)

Foundation-layer components

cert-manager, ECK operator, and CNPG operator are deployed in the foundation layer, not the stack. They are cluster-wide singletons shared across all stacks. See Deployment Model.

Elasticsearch

3-node cluster with combined master/data/ingest roles, managed by the ECK operator. Each node gets dedicated Premium SSD storage with a Retain policy.

A post-deploy bootstrap job configures index templates, ILM policies, and aliases required by OSDU services.

Safeguards compliance

ECK's Helm chart doesn't expose probe configuration. A postrenderer injects the required probes during deployment (see ADR-0004).

PostgreSQL (CloudNativePG)

3-instance HA cluster with synchronous replication: 1 primary (read-write) + 2 sync replicas, spread across availability zones. Each OSDU service gets its own database, matching the ROSA topology (see ADR-0014).

The CNPG operator creates short-lived jobs during bootstrap that cannot have health probes. A policy exemption is applied separately in the access-bootstrap layer (see ADR-0020).

Redis

1 master + 2 replicas providing an in-memory cache layer. Primarily used by the Entitlements service for caching authorization group lookups. Postrender patches add resource limits and health probes for safeguards compliance.

RabbitMQ

3-node cluster using raw Kubernetes manifests instead of a Helm chart (see ADR-0005). Nodes discover each other via DNS peer discovery.

Istio opt-out

RabbitMQ pods opt out of the service mesh because the clustering protocol requires capabilities incompatible with the Istio sidecar. Authentication uses password-based security instead.

Keycloak

Identity provider deployed as raw Kubernetes manifests (see ADR-0016). Backs onto the PostgreSQL cluster for persistence and auto-imports the OSDU realm at startup.

External access is available via Gateway API when a hostname is configured. A readiness gate ensures Keycloak is issuing valid tokens before OSDU services deploy.

Airflow

Workflow orchestration using the KubernetesExecutor, which runs each task as a pod with no persistent workers (see ADR-0012). Control-plane components run on the platform nodepool; task pods run on the default pool and scale to zero.

Note

11 OSDU DAGs are deployed via a Terraform-managed ConfigMap. DAGs requiring the osdu-airflow-lib package or KubernetesPodOperator container images will appear in the Airflow UI but need the custom Airflow image and Airflow Variables configured to execute tasks.

MinIO

S3-compatible object storage running as a single pod for development and testing. Provides the blob storage interface that OSDU services expect.

cert-manager

Automatic TLS certificate management deployed in the foundation layer. Watches for Certificate resources created by the gateway module and provisions Let's Encrypt certificates automatically. Each external endpoint gets its own certificate.

The HTTP-01 challenge solver routes through the Istio ingress gateway, so the gateway must be functional before certificates can be issued.