Skip to content

mount trusted CA bundle in runner pods for custom TLS #1247

@ktdreyer

Description

@ktdreyer
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Problem

Runner pods cannot validate TLS certificates from private or corporate CAs. The backend-api Deployment already supports this via a mounted CA bundle, but runner pods do not inherit the same configuration.

Runner pods are created dynamically by the agentic-operator in sessions.go — they are never long-running. Each session spawns a fresh pod, so the fix must go in the pod template construction logic.

Root cause

handleAgenticSessionEvent() in components/operator/internal/handlers/sessions.go builds the runner pod spec but never checks for or mounts a trusted-ca-bundle ConfigMap. On OpenShift clusters with CA injection enabled, this ConfigMap is present in the session namespace and populated automatically. On other clusters, operators may provision it manually.

Fix

Follow the same conditional pattern already used for the ambient-vertex secret:

  1. Check whether a trusted-ca-bundle ConfigMap exists in sessionNamespace.
  2. If present, add a ConfigMap volume and mount it into the ambient-code-runner container at /etc/pki/tls/certs/ca-bundle.crt (UBI9 system CA path).

The mount is conditional — clusters without the ConfigMap are unaffected.

Tests needed

  • Runner pod gets the volume + mount when trusted-ca-bundle ConfigMap exists in the session namespace
  • Runner pod has no extra volume when the ConfigMap is absent
  • Existing behavior (vertex secret, runner token) is not disrupted

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions