Conversation
📝 WalkthroughWalkthroughA new helper function conditionally mounts a trusted CA bundle ConfigMap into dynamically-created runner pods. The operator checks the session namespace for Changes
Sequence Diagram(s)sequenceDiagram
participant Operator as Operator (session handler)
participant K8s as Kubernetes API
participant Pod as PodSpec (in-memory)
Operator->>K8s: GET ConfigMap `trusted-ca-bundle` in session namespace
alt ConfigMap Found and has ca-bundle.crt
K8s-->>Operator: ConfigMap with ca-bundle.crt
Operator->>Pod: append ConfigMap Volume `trusted-ca-bundle`
Operator->>Pod: add VolumeMount to container `ambient-code-runner` at /etc/pki/tls/certs/ca-bundle.crt (subPath: ca-bundle.crt, readOnly)
else NotFound
K8s-->>Operator: 404 NotFound
Operator-->>Pod: no changes
else Other error or missing key
K8s-->>Operator: error or missing key
Operator-->>Pod: log warning, no changes
end
Operator->>K8s: create Pod from modified PodSpec
K8s-->>Operator: Pod created / acknowledged
🚥 Pre-merge checks | ✅ 7 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (7 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/operator/internal/handlers/sessions.go`:
- Around line 2172-2200: The code currently only checks that the ConfigMap
exists via k8sClient.CoreV1().ConfigMaps(...).Get and then unconditionally adds
a Volume and a VolumeMount with SubPath "ca-bundle.crt"; you must GET the
ConfigMap object and validate that its Data (or BinaryData) contains the
"ca-bundle.crt" key before appending the pod.Spec.Volumes and before adding the
SubPath mount to pod.Spec.Containers[i].VolumeMounts (match container name
"ambient-code-runner"); if the key is missing, log a warning referencing
types.TrustedCABundleConfigMapName and skip adding the volume/mount to avoid
kubelet SubPath mount failures.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e18eebad-be36-4572-94ec-50e41f26f95b
📒 Files selected for processing (3)
components/operator/internal/handlers/sessions.gocomponents/operator/internal/handlers/sessions_test.gocomponents/operator/internal/types/resources.go
On clusters with private or corporate CAs, runner pods fail TLS validation because they only have the default UBI9 system CA store. The "backend-api" Deployment already supports a trusted CA bundle, but runner pods (created dynamically by the operator) never had matching support. "applyTrustedCABundle" checks for a "trusted-ca-bundle" ConfigMap in the session namespace before each pod is created. On OpenShift, this ConfigMap is auto-populated by CA injection; on other clusters, operators can provision it manually. When present, the ConfigMap is mounted at "/etc/pki/tls/certs/ca-bundle.crt" (the UBI9 system CA path) so all TLS clients in the runner container trust the corporate CA without any application-level changes. Clusters without the ConfigMap are unaffected. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
b5d1c07 to
32550e2
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@components/operator/internal/handlers/sessions.go`:
- Around line 2199-2213: The current patch only mounts the trusted CA bundle
into the ambient-code-runner container; update the code to also mount the same
VolumeMount into init containers and any other containers that need it
(specifically target init container named "init-hydrate" in
pod.Spec.InitContainers and the container named "state-sync" in
pod.Spec.Containers) so they receive the trusted CA before network operations;
reuse the same corev1.VolumeMount (Name "trusted-ca-bundle", MountPath
"/etc/pki/tls/certs/ca-bundle.crt", SubPath "ca-bundle.crt", ReadOnly true) and
log using types.TrustedCABundleConfigMapName, ensuring you iterate
pod.Spec.InitContainers to patch "init-hydrate" and pod.Spec.Containers to patch
both "state-sync" and "ambient-code-runner" (avoid duplicate mounts if already
present).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ea8d4d77-4042-4f4d-89a2-931cf6ff48cd
📒 Files selected for processing (3)
components/operator/internal/handlers/sessions.gocomponents/operator/internal/handlers/sessions_test.gocomponents/operator/internal/types/resources.go
✅ Files skipped from review due to trivial changes (1)
- components/operator/internal/types/resources.go
🚧 Files skipped from review as they are similar to previous changes (1)
- components/operator/internal/handlers/sessions_test.go
| for i := range pod.Spec.Containers { | ||
| if pod.Spec.Containers[i].Name == "ambient-code-runner" { | ||
| pod.Spec.Containers[i].VolumeMounts = append( | ||
| pod.Spec.Containers[i].VolumeMounts, | ||
| corev1.VolumeMount{ | ||
| Name: "trusted-ca-bundle", | ||
| MountPath: "/etc/pki/tls/certs/ca-bundle.crt", | ||
| SubPath: "ca-bundle.crt", | ||
| ReadOnly: true, | ||
| }, | ||
| ) | ||
| log.Printf("Mounted %s ConfigMap to /etc/pki/tls/certs/ca-bundle.crt in runner container", | ||
| types.TrustedCABundleConfigMapName) | ||
| break | ||
| } |
There was a problem hiding this comment.
Mount the bundle into init-hydrate and state-sync too.
This only patches ambient-code-runner. init-hydrate lives in pod.Spec.InitContainers and is configured with repo/S3 inputs (Lines 901-946), and state-sync is configured for S3 (Lines 1230-1248). On private-CA clusters, those containers can still fail TLS before the main runner starts, so private repo hydration/state sync is still broken unless they get the same trust bundle when present.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@components/operator/internal/handlers/sessions.go` around lines 2199 - 2213,
The current patch only mounts the trusted CA bundle into the ambient-code-runner
container; update the code to also mount the same VolumeMount into init
containers and any other containers that need it (specifically target init
container named "init-hydrate" in pod.Spec.InitContainers and the container
named "state-sync" in pod.Spec.Containers) so they receive the trusted CA before
network operations; reuse the same corev1.VolumeMount (Name "trusted-ca-bundle",
MountPath "/etc/pki/tls/certs/ca-bundle.crt", SubPath "ca-bundle.crt", ReadOnly
true) and log using types.TrustedCABundleConfigMapName, ensuring you iterate
pod.Spec.InitContainers to patch "init-hydrate" and pod.Spec.Containers to patch
both "state-sync" and "ambient-code-runner" (avoid duplicate mounts if already
present).
There was a problem hiding this comment.
@coderabbitai how can those require the CA?
There was a problem hiding this comment.
@ktdreyer Good challenge — it depends on the deployment:
init-hydrate's backend API call (BACKEND_API_URL) uses plainhttp://— no TLS at all, so definitely no CA needed there.- S3 (
s3Endpoint) — if it's internal MinIO over HTTP (the typical default here), no CA needed. But if an operator configures an internal HTTPS S3 endpoint backed by a corporate CA,init-hydrateandstate-syncwould fail TLS. - Git clones in
init-hydrate— if repos are hosted on an internal Gitlab/Gitea with a private CA cert, cloning over HTTPS would fail without the bundle.
So the containers can need it, but only when:
- The S3 endpoint is HTTPS + corporate CA, or
- Git repos are on a private-CA HTTPS host
If your target environments use plain-HTTP MinIO and public-CA git hosts, the runner container is the only one making connections (to Anthropic/Claude APIs, etc.) that realistically need the bundle. In that case you can safely ignore my comment. Your call on whether the edge cases (HTTPS S3, private git) are in scope for this PR.
Summary
trusted-ca-bundleConfigMap at/etc/pki/tls/certs/ca-bundle.crt(the UBI9 system CA path), enabling TLS validation against private/corporate CAsFixes #1247
Test plan
TestApplyTrustedCABundle_ConfigMapPresent— volume + mount added when ConfigMap existsTestApplyTrustedCABundle_ConfigMapAbsent— pod unchanged when ConfigMap is missingTestApplyTrustedCABundle_ExistingMountsPreserved— existing mounts not clobberedTestApplyTrustedCABundle_APIError— pod unchanged on transient API errorstrusted-ca-bundleConfigMap in session namespace, start session, verify/etc/pki/tls/certs/ca-bundle.crtin runner pod contains the custom CASummary by CodeRabbit
New Features
Tests