OpenShift installation

Overview

DALP runs on Red Hat OpenShift Container Platform (OCP) and OKD when the cluster provides the Kubernetes APIs, Route API, storage classes, and security policy required by the charts. The OpenShift path keeps DALP workloads non-root, exposes selected services through Routes, and leaves registry approval, storage selection, secret handling, and disaster recovery evidence with the operator.

The chart renders Kubernetes and OpenShift resources. Your platform team owns the cluster policy. That policy admits images, injects secrets, assigns storage, and exposes hostnames. It also restores state after an incident.

Platform requirements

Security context constraints

DALP images run as non-root and do not require privilege escalation. The charts avoid fixed user IDs so OpenShift can assign a UID from the target project's range.

Required security settings

Review rendered manifests for these settings before production promotion. Each DALP workload must carry all five settings shown below:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
  seccompProfile:
    type: RuntimeDefault

User ID handling

OpenShift assigns arbitrary UIDs from each project's UID range. DALP charts set runAsUser: null to allow OpenShift's admission controller to inject the appropriate UID. Do not specify explicit UIDs in your values overrides. Fixed UIDs conflict with the project range and cause admission failures.

Resource requests and the project LimitRange

Most OpenShift projects apply a LimitRange that sets a minimum CPU and memory request, a minimum limit, and a required CPU limit on every container. OpenShift rejects containers that ask for less than the floor or omit a required limit at admission; the pod never starts.

Several DALP chart defaults sit below a typical floor: certain services request as little as 50m CPU, the database migration Job declares a memory limit without a CPU limit, and the workflow-cleanup CronJob requests 64Mi memory. The values-openshift.yaml override raises the application services and the migration Job to a safe minimum. Check the remaining workloads against your project's LimitRange and raise any that fall short.

Floor values to apply

values-openshift.yaml floors the application services and the migration Job to at least 100m CPU and 128Mi memory. Keep these values in your release. If your project's LimitRange sets a higher minimum, raise them further. The example below shows the safe floor values to apply:

# Application services: floor CPU requests to the project minimum
dapi:
  resources:
    requests:
      cpu: 100m
      memory: 512Mi
    limits:
      cpu: 500m
      memory: 1Gi

didx:
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 512Mi

# Migration Job: a CPU limit is required even though the base chart omits it
dapp:
  migrator:
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 500m
        memory: 512Mi

If your project's memory floor is above 64Mi, also raise the workflow-cleanup CronJob, which the OpenShift override does not floor:

ddwf:
  cleanupResources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 128Mi

Confirm your project's floor before promotion so your overrides clear it:

oc get limitrange -n dalp-production -o yaml

Image security and evidence handoff

DALP runs as containerized workloads on enterprise OpenShift. The images are non-root, the runtime settings are SCC-compatible, and credentials are injected at startup rather than baked in. SettleMint provides the DALP images and Helm values. Your OpenShift team decides which registry, scanner, admission policy, and vault controls approve those images for production.

To redirect the DALP-managed images to a mirrored or air-gapped registry, and to handle the observability stack and other bundled third-party images, see private or air-gapped registry in the prerequisites.

For the audit evidence model behind SBOMs, source review, and deployed image provenance, see Source verification and auditability.

Networking with Routes

OpenShift uses Routes for external access. DALP charts render Route resources only when the cluster exposes the OpenShift Route API and the relevant openShiftRoute.enabled value is true.

Route configuration

Enable only the public surfaces that the OpenShift Router should expose. The Console, Blockscout, and Grafana use separate chart surfaces and separate Route values:

# DALP dApp Route
dapp:
  openShiftRoute:
    enabled: true
    host: dalp.apps.example.com
    tls:
      termination: edge
      insecureEdgeTerminationPolicy: Redirect

# Blockscout UI and API Routes
blockscout:
  blockscout:
    openShiftRoute:
      enabled: true
      host: explorer-api.apps.example.com
      tls:
        termination: edge
        insecureEdgeTerminationPolicy: Redirect
  frontend:
    openShiftRoute:
      enabled: true
      host: explorer.apps.example.com
      tls:
        termination: edge
        insecureEdgeTerminationPolicy: Redirect

# Grafana Route in observability chart values
grafana:
  openShiftRoute:
    enabled: true
    host: grafana.apps.example.com
    tls:
      termination: edge
      insecureEdgeTerminationPolicy: Redirect

The settlemint/dalp application chart consumes the Console and Blockscout Route values. Configure the Grafana Route in the observability chart values when you install observability. If an umbrella chart nests observability under an observability key, put the same Grafana values under that chart key. Leave the Grafana Route disabled when operators should reach Grafana through a private network path or another ingress pattern. See Observability for the monitoring components behind that route.

TLS termination options

Most deployments use edge termination with OpenShift's wildcard certificate or a custom certificate. Use passthrough when the backend must own TLS end-to-end. Use reencrypt when the router must re-encrypt traffic to the pod.

Storage configuration

ODF for production storage

ODF is the recommended storage backend for production. It provides Ceph-based distributed storage with RWX support for shared volumes, built-in replication and recovery, and an S3-compatible object store endpoint.

Storage class selection

Set the global storage class to the ODF block storage class:

global:
  storageClass: ocs-storagecluster-ceph-rbd # ODF block storage

To use ODF object storage instead of the RustFS subchart, disable RustFS. Point the object storage configuration at the Ceph object store endpoint:

rustfs:
  enabled: false # Use ODF object storage instead

objectStorage:
  endpoint: s3://rook-ceph-rgw-ocs-storagecluster-cephobjectstore.openshift-storage.svc
  bucket: dalp-assets
  existingSecret: dalp-s3-credentials

Operator integration

OpenShift operators manage supporting infrastructure outside the DALP application chart. The two operators most relevant to a DALP deployment are CloudNativePG and Velero.

CloudNativePG

The CloudNativePG operator works on OpenShift without modification. Install it via OperatorHub or Helm, then configure it to manage the DALP PostgreSQL cluster.

Velero

For backup and disaster recovery, Velero integrates with the cluster through the OADP (OpenShift API for Data Protection) operator available in OperatorHub. OADP provides the Velero CRDs and a supported backup storage location API.

NetworkPolicy considerations

OpenShift Network Policies work identically to Kubernetes, with one addition: the OpenShift Router requires explicit ingress rules to reach pod endpoints. DALP charts detect the Route API and automatically add the required ingress rule:

# Automatically included when route.openshift.io/v1 API is detected
ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress

Installation outline

1. Prepare the project

Create the namespace and verify that the restricted-v2 SCC is available. The DALP workloads require this profile:

# Create project (namespace)
oc new-project dalp-production

# Verify SCC assignment
oc get scc restricted-v2 -o yaml

2. Add the Helm repository

Add the SettleMint Helm repository and refresh the local chart index. If Harbor credentials are required, configure them before running these commands:

helm repo add settlemint https://harbor.settlemint.com/chartrepo/dalp
helm repo update

3. Configure values

Create an OpenShift-specific values file by merging the base values-openshift.yaml with your environment configuration. Replace the example hostnames with your actual cluster domain:

# values-production.yaml
global:
  platform: openshift
  storageClass: ocs-storagecluster-ceph-rbd

# Enable Routes for user-facing services
dapp:
  openShiftRoute:
    enabled: true
    host: dalp.apps.example.com

blockscout:
  blockscout:
    openShiftRoute:
      enabled: true
      host: explorer-api.apps.example.com
  frontend:
    openShiftRoute:
      enabled: true
      host: explorer.apps.example.com

# Disable Traefik (OpenShift Router handles ingress)
traefik:
  enabled: false

4. Install the chart

Install the DALP chart, applying both the OpenShift override file and your environment values. The OpenShift override file sets the platform flag, resource floors, and Route defaults for a restricted SCC environment:

helm install dalp settlemint/dalp \
  -n dalp-production \
  -f values-openshift.yaml \
  -f values-production.yaml

5. Verify the deployment

Confirm all pods are running, Routes exist, and TLS termination is correct. Address any CrashLoopBackOff or Pending pods before handing off to the application configuration stage:

# Check pod status
oc get pods -n dalp-production

# Verify Routes
oc get routes -n dalp-production

# Check Route TLS
oc get route dalp -n dalp-production -o jsonpath='{.spec.tls.termination}'

Troubleshooting

Pod fails with SCC denied

An SCC denial usually means the deployment specifies an explicit UID that conflicts with the project's assigned range. Verify the security context on the offending deployment:

oc get deployment <name> -o yaml | grep -A5 securityContext

Remove any runAsUser with explicit values. Use null or omit the field entirely. OpenShift injects the correct UID at admission when the field is absent.

Pod rejected for resource requests

A minimum/maximum LimitRange rejection means one container requests less CPU or memory than the project floor, or it omits a required CPU limit. Floor that service's resources to your project's minimum as shown in Resource requests and the project LimitRange, then reinstall or upgrade the release.

oc get events -n dalp-production --field-selector reason=FailedCreate
oc get limitrange -n dalp-production -o yaml

Route not accessible

Start by confirming that the Route hostname resolves to the router's IP:

oc get route <name> -o jsonpath='{.spec.host}'
nslookup <hostname>

If the hostname resolves but the connection fails, check the router pod. Confirm it is running in the openshift-ingress namespace:

oc get pods -n openshift-ingress

Storage provisioning fails

A PVC stuck in Pending usually means the storage class is missing or not set as default. Confirm both:

oc get storageclass
oc get pvc -n dalp-production

For ODF environments, also verify that the storage cluster itself is healthy before troubleshooting further:

oc get storagecluster -n openshift-storage

See also

• Prerequisites for infrastructure requirements.
• Installation process for the full deployment sequence.
• High availability for backup, recovery, and RTO/RPO planning.
• Source verification and auditability for evidence packs and image provenance.