Skip to content
OSDU SPI Infrastructure

ADR-0003: Local Helm Chart for SPI Stack Safeguards Compliance

Status: Accepted
Date: 2026-03-20
Deciders: danielscholl

Context and Problem Statement

Section titled “Context and Problem Statement”

AKS Automatic enforces Deployment Safeguards via ValidatingAdmissionPolicies that require all pods to have readiness/liveness probes, resource requests/limits, seccomp profiles, non-root execution, and dropped capabilities. For the SPI stack, the OSDU community Helm charts (from the CIMPL OCI registry) do not expose all these fields, requiring a kustomize postrender pipeline to patch the rendered manifests. This postrender approach is fragile — it breaks when upstream charts change structure and is difficult to debug.

Decision Drivers

Section titled “Decision Drivers”
  • AKS Automatic Deployment Safeguards are non-bypassable and cannot be exempted for user namespaces
  • OSDU community Helm charts lack seccomp profiles, topology spread, and consistent security contexts
  • Kustomize postrender adds complexity and a PowerShell dependency per chart
  • All OSDU services share an identical deployment pattern (Spring Boot on port 8080, actuator probes, configmap envFrom)

Considered Options

Section titled “Considered Options”
  1. Consume OSDU community Helm charts with kustomize postrender patches
  2. Local Helm chart (osdu-spi-service) with compliance baked in
  3. Raw Kubernetes manifests generated by Terraform

Decision Outcome

Section titled “Decision Outcome”

Chosen option: Local Helm chart with compliance baked in, because all OSDU Azure SPI services share the same deployment shape and the safeguards requirements are known at authoring time. A single reusable chart eliminates the postrender pipeline entirely for the SPI stack. The CIMPL stack takes a different approach — see ADR-0006.

Consequences

Section titled “Consequences”
  • Good: Safeguards compliance is guaranteed by the chart template — no runtime patching
  • Good: A single chart serves all 13+ OSDU services via Terraform module parameterization
  • Good: Template changes are immediately testable with helm template
  • Bad: The chart must be maintained separately from upstream OSDU community charts
  • Bad: New safeguards requirements (e.g., future VAP rules) require chart template updates

Key Template Requirements

Section titled “Key Template Requirements”

The osdu-spi-service chart deployment template must include:

  • securityContext.runAsNonRoot: true and seccompProfile.type: RuntimeDefault at pod level
  • securityContext.allowPrivilegeEscalation: false and capabilities.drop: [ALL] per container
  • Resource requests and limits on all containers including init containers
  • Liveness and readiness probes with configurable port and path
  • Topology spread constraints for zone/host distribution