feat(network): support additional destination CAs by jhjaggars · Pull Request #3292 · NVIDIA/OpenShell

jhjaggars · 2026-09-11T20:25:43Z

Summary

Add a global network-supervisor configuration for additional destination CA certificates so sandbox egress can trust private PKI without replacing default roots or changing gateway control-plane trust.

This series adopts the mechanism merged to main in #3996 (from #3781) and extends it to every first-party compute driver: one operator pre-assembled PEM bundle, the --additional-ca-bundle supervisor flag, and the /etc/openshell/tls/additional/ca-bundle.pem staging path.

Related Issue

Fixes #3295

Changes

Add [openshell.supervisor.network].additional_ca_bundle (single pre-assembled PEM file) with strict, bounded startup validation and fail-closed capability-based driver handling.
Keep effective-config preflight side-effect-free; stage gateway-owned trust material only after the selected driver passes compatibility checks.
Extend the shared network supervisor with additive rustls and child-process trust while preserving user TLS variables in direct mode and keeping proxy CA and gateway mTLS trust separate.
Stage the normalized bundle through read-only Docker/Podman mounts, Kubernetes immutable content-addressed ConfigMaps, and VM overlays, all at the upstream mount path.
Record and validate the expected trust generation at the gateway/driver boundary so mutable or stale runtime material fails closed.
Reconcile stopped sandboxes whose recorded trust generation differs from the restarted gateway snapshot while retaining sandbox identity and supported durable workspace contents.
Restrict Kubernetes ConfigMap RBAC to the operations required for immutable generation creation and validation; do not grant list, watch, patch, update, or delete for this feature.
Enforce one deployable, bounded trust-bundle limit across gateway, Kubernetes, VM, and supervisor consumers.
Reject additional_ca_bundle in operator driver JSON config so the global gateway setting stays the single source; standalone drivers self-source the same bundle from --sandbox-additional-ca-bundle with identical validation.
Add shared cross-driver additional-CA coverage for private/public trust, hostname enforcement, invalid staged material, callback isolation, and removal/restart behavior.
Update gateway reference, architecture, RFC, Helm, compute-driver, and cluster-debugging documentation.

Why lifecycle reconciliation is included

Additional CA sources are startup-only gateway configuration. Updating the source file or Helm source ConfigMap does not hot-reload running supervisors. To roll certificates, an operator updates the source, restarts or redeploys the gateway, and explicitly stop/starts each affected sandbox.

Each runtime records the immutable trust generation it was created with. Without reconciliation, ordinary stop/start cannot reliably move an existing sandbox to the new generation: Docker and Podman retain old container metadata, Kubernetes retains the old content-addressed ConfigMap mount, and VM retains the old writable overlay. Replacing only the staged file would conflict with the recorded digest and correctly fail closed.

The only existing manual alternative is to delete and recreate each affected sandbox, or create a replacement sandbox and move work to it. Sandbox deletion normally removes its driver-owned mutable filesystem storage—Docker/Podman workspace volumes, the Kubernetes sandbox PVC, or the VM writable overlay. Operators would therefore need to back up and restore required /sandbox contents, use external persistent storage, and re-establish any sandbox-specific state. The reconciliation implemented here avoids that migration by rebuilding stale runtime resources during stop/start while preserving the sandbox record and supported durable workspace data.

This lifecycle work can be split into a follow-up only if destructive replacement plus explicit data migration is an acceptable interim certificate-rotation procedure.

Testing

mise run pre-commit passes
Workspace formatting and Clippy with warnings denied pass
Targeted Rust tests pass across core, sandbox, supervisor-network, Docker, Kubernetes, Podman, VM, server, and gateway packages
Helm tests pass: gateway and workspace chart suites including Rust loader validation of the rendered gateway TOML
Unit and process-level tests added/updated
Cross-driver E2E coverage added and feature combinations compile
Rootless Podman manually verified against a private-PKI GitLab endpoint: TLS failed without the additional CA and succeeded with it while default public trust remained enabled
Full mise run test task run as a single validation command
Docker, Kubernetes combined/sidecar, and VM E2E runtime lanes (configured for CI; not run locally)

Checklist

Follows Conventional Commits
Commits are signed off (DCO)
Architecture and user-facing configuration documentation updated

copy-pr-bot · 2026-09-11T20:25:47Z

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

jhjaggars · 2026-09-11T20:48:43Z

 [openshell.supervisor.network]
   additional_ca_cert_paths = [
     "/tmp/openshell-e2e-podman.McovxM/additional-ca/ca.crt",
   ]

politerealism

Summary

The design is sound and directly addresses both #3781 (Podman TLS-trust regression) and #3295 (general additional-destination-CA feature): trust material is scoped to the supervisor container only, root-store construction is fixed for both the bundled-ca-roots and native-store variants, validation is fail-closed end-to-end, and the gateway-mTLS trust boundary is provably untouched (new destination_ca_cannot_authenticate_gateway regression test). However, the branch as submitted (eb2db3f65) doesn't compile its own test suite, so CI can't pass yet.

Blocking

cargo test -p openshell-driver-podman -p openshell-driver-docker -p openshell-server (and mise run pre-commit's rust:lint step) fail to compile, all four attributable to this PR's own commits:

crates/openshell-driver-podman/src/container.rs:1833 — new test additional_destination_trust_is_delivered_only_to_supervisor_with_digest is missing the pre-existing required field rootless on IsolationSpecInput.
crates/openshell-driver-podman/src/container.rs:2020 — existing rootful_specs = build_isolation_specs(...) wasn't updated with the new required field network_trust.
crates/openshell-driver-docker/src/tests.rs:135 — sets daemon_version: "28.0.0".to_string(), but DockerDriverRuntimeConfig has no such field.
crates/openshell-server/src/compute/mod.rs:13576 — new test start_sandbox_request_uses_optional_wire_field_six_for_durable_snapshot is missing the pre-existing required field expected_runtime_identity on StartSandboxRequest.

openshell-driver-kubernetes, openshell-driver-vm, and openshell-gateway build and test cleanly in isolation, so this is localized to four struct literals, not systemic.

Non-blocking notes

deploy/helm/openshell/templates/clusterrole.yaml:82-97 / role.yaml:65-70: RBAC grants unscoped get on ConfigMaps (in addition to create), since resourceNames can't restrict dynamically digest-named generations. That lets the gateway service account read any ConfigMap in the bound scope, not just its own CA generations. Reasoning is documented in-line and in the debug-openshell-cluster skill update, but worth a second look given it's a real (if bounded) privilege widening.
crates/openshell-supervisor-network/src/run.rs:212-219: the additional-CA load path fails closed correctly but doesn't emit a ConfigStateChangeBuilder OCSF event the way the adjacent TLS-termination code does at run.rs:401-429. Not required by AGENTS.md's OCSF scope (that's openshell-sandbox-specific), but would be a nice consistency improvement for operator visibility.

Testing

cargo fmt --all -- --check passes. cargo test -p openshell-supervisor-network -p openshell-core -p openshell-supervisor passes (1344/1345, one pre-existing unrelated flake). Docker/Kubernetes/VM e2e lanes haven't been run (not available in my review environment) and remain genuinely unverified — recommend running those before merge, in addition to fixing the compile errors above.

Since v0.1.2 the Podman supervisor runs as its own container, separate from the workload image, so it can no longer inherit a private CA baked into the workload's system trust store. Policy-allowed, inspected HTTPS requests to destinations signed by that CA fail upstream TLS establishment, and the only workaround is rebuilding the supervisor image with the CA baked in. Add a Podman-only additional_ca_bundle setting, independent of the existing proxy_ca_bundle (which requires https_proxy), that bind-mounts an operator PEM into the supervisor container and folds it into the upstream trust store alongside the system CA bundle. Validated on the gateway host at sandbox-create time, matching the existing corporate proxy CA bundle's validation, so a misconfigured path or certificate-free bundle fails closed immediately rather than producing a failed sandbox once the supervisor container starts. Scoped to Podman only, reusing the existing additive-bundle mechanism without new gateway.toml schema, proto fields, or cross-driver plumbing -- a narrower alternative to the in-flight cross-driver implementation in NVIDIA#3292, which remains the intended long-term direction. Fixes NVIDIA#3781. Signed-off-by: politerealism <burdcat17@gmail.com>

github-actions · 2026-10-14T08:34:02Z

This pull request has had no activity for 14 days and is now marked stale.

…ss (NVIDIA#3996) * fix(podman): trust an operator-supplied additional CA for direct egress Since v0.1.2 the Podman supervisor runs as its own container, separate from the workload image, so it can no longer inherit a private CA baked into the workload's system trust store. Policy-allowed, inspected HTTPS requests to destinations signed by that CA fail upstream TLS establishment, and the only workaround is rebuilding the supervisor image with the CA baked in. Add a Podman-only additional_ca_bundle setting, independent of the existing proxy_ca_bundle (which requires https_proxy), that bind-mounts an operator PEM into the supervisor container and folds it into the upstream trust store alongside the system CA bundle. Validated on the gateway host at sandbox-create time, matching the existing corporate proxy CA bundle's validation, so a misconfigured path or certificate-free bundle fails closed immediately rather than producing a failed sandbox once the supervisor container starts. Scoped to Podman only, reusing the existing additive-bundle mechanism without new gateway.toml schema, proto fields, or cross-driver plumbing -- a narrower alternative to the in-flight cross-driver implementation in NVIDIA#3292, which remains the intended long-term direction. Fixes NVIDIA#3781. Signed-off-by: politerealism <burdcat17@gmail.com> * fix(podman): keep additional CA mount on the supervisor build_isolation_specs() keeps only trusted_mount() destinations on the supervisor, and the additional CA path was not in that list. The bind mount stayed on the workload while the supervisor received --additional-ca-bundle for a file it did not have, so startup failed. Add the path to trusted_mount() and cover the final supervisor and workload specs with a test. Correct the docs and a code comment to say the bundle is validated when the driver starts, and add Podman troubleshooting guidance to the debug-openshell-cluster skill. Signed-off-by: politerealism <burdcat17@gmail.com> --------- Signed-off-by: politerealism <burdcat17@gmail.com>

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

Resolve rebase fallout against current upstream main after the series was rebased 214 commits forward: - follow upstream NVIDIA#3110: supervisor→gateway TLS is CA-only, so configure_gateway_tls and its isolation tests drop the client identity - follow upstream tls_secret_names reduction to [String; 1] in the Podman driver while keeping the network trust bundle delivery - port [openshell.supervisor.network] rendering into the openshell.gatewayConfigToml serializer in _toml.tpl - adapt tests to upstream struct/function changes (DriverStartupContext, SandboxRunConfig, IsolationSpecInput, supervisor_pod, VM bootstrap image) - drop conformance-artifact-prefix plumbing removed upstream Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

Unify the additional destination CA series on the mechanism merged to main in NVIDIA#3996: one operator pre-assembled PEM bundle, the --additional-ca-bundle supervisor flag, and the /etc/openshell/tls/additional/ca-bundle.pem staging path. - Replace the gateway-level additional_ca_cert_paths list with a single additional_ca_bundle file validated and staged at gateway startup. - Restore the upstream supervisor argument path and fold-into-roots behavior; drop the --network-additional-ca-bundle and --network-additional-ca-digest contracts. - Keep gateway normalization bounds, content-addressed staging, digest-based driver reconciliation, and stop/start rotation; the freshness check now runs at the gateway/driver boundary instead of the supervisor boundary. - Reject additional_ca_bundle in operator driver JSON config; standalone drivers self-source the bundle from --sandbox-additional-ca-bundle with the same validation. - Extend the Kubernetes ConfigMap name digest segment to keep the full 63-byte budget after the prefix rename. - Box the persisted-sandbox reconciliation futures so callers stay under the clippy::large_futures threshold. Updates Docker, Podman, Kubernetes, and VM delivery, Helm chart and tests, e2e wiring, gateway configuration docs, and the cluster debugging skill to the single mechanism. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

… lockfile The network trust startup tests asserted on raw substrings of gateway diagnostics, but the CLI renderer wraps output at a fixed width with continuation markers and hard-breaks long paths. Compare assertions on whitespace- and continuation-squashed text so they hold regardless of wrap position. Format the e2e workspace (separate cargo workspace, not covered by the root cargo fmt run) and refresh examples/isolation-backend-v8/Cargo.lock for the libc dependency added to the network trust crate. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

The additional CA e2e never ran in CI before the first maintainer test dispatch, and its local container inspection was broken in two ways: it located the supervisor container through e2e network membership (the supervisor is host-networked or runtime-bridged, so the filter matched the CI job container instead), and it required the gateway mTLS CA as a bind mount (Podman delivers it as a container secret when user namespaces remap UIDs). Select the supervisor by managed labels and accept the secret delivery form. The lifecycle leg then exposed a driver bug: stopped-pair trust replacement re-created the per-sandbox TLS CA secret, colliding with the secret still owned by the renamed stopped pair. Mirror the token and resolver secret handling: require and reuse the existing secret during replacement instead of creating it. Validated end-to-end with the Podman additional CA e2e lane. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

…ilures Recovery no longer marks sandboxes Error/InvalidPersistedSandbox when driver_start_request fails during the startup or lifecycle sweeps. Gateway configuration problems (for example a missing launch signer) must not permanently fail unrelated sandbox records; the sweep logs a warning and skips them, matching the behavior before the additional CA work. Sandbox-record failures surface through the normal start path. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

Replace the stopped-pair trust reconciliation with supervisor-only recreation. The destination-trust generation label moves from the workload to the supervisor container, and start_sandbox recreates only the supervisor when its generation is missing or stale. The workload container, its volumes, its secrets, and its workspace data are never replaced: the additional CA bundle is mounted only into the supervisor. Running sandboxes are never gated on trust labels, and recovery without fresh launch credentials keeps the existing supervisor. The intentional -removal fence machinery in the watcher existed only for workload replacement and is removed with it. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

…nges Delete the stopped-workload trust reconciliation path and all of its machinery: the trust-generation label on workload containers, the generation match check in the start fence, the stopped-sandbox replacement, the bounded workspace archive copy with its 512 MiB cap and regular-file-only validation, and the boundary-state rollback helpers. No replacement machinery is needed: the trusted supervisor container is already re-created from the gateway's current configuration on every start via ensure_control_process_for_container, so stop/start picks up the current additional CA bundle while the workload container, its volumes, and its workspace data are never replaced. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

…ifecycle The stop/start lifecycle description already matches the supervisor-only refresh model; remove the two remaining references to restart reconciliation of workload containers. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

Route the gateway TLS isolation test PKI, the destination CA source fixtures, and the gateway startup trust tests through openshell_crypto::pki now that rcgen access is centralized there: generate_keypair/self_signed/signed_by replace the direct rcgen calls and CertifiedKey field access follows the wrapper's shape. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

The first maintainer test dispatch revealed two latent issues in the additional CA e2e that no local run had exercised: the Podman gateway CA secret helper referenced ContainerEngine without the container feature gate, breaking Kubernetes and VM builds of the test, and the Docker branch asserted a client ca.crt bind mount that the Docker driver never creates. Gate the helper like its callers, and assert Docker's actual delivery path instead: the gateway mTLS CA staged as tls/ca.pem inside the read-only supervisor state volume, selected through the OPENSHELL_TLS_CA environment pointer. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

The helm:docs check regenerates the chart README with helm-docs, which orders rows alphabetically; a conflict resolution had placed supervisor.network.additionalCaConfigMapName after the supervisor.podSecurityContext rows. Regenerate with mise run helm:docs. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

Standalone Podman drivers accepting --sandbox-additional-ca-bundle previously kept the operator's source path as the trust artifact path. The immutable-artifact verification performed on every create/start requires exactly mode 0444, which an operator-owned source path cannot guarantee, so a readable-but-writable source failed reconciliation. Read the operator bundle with the same bounded, no-symlink validation, then stage the normalized material into a driver-owned artifact inside a private tempdir held for the driver process lifetime. The artifact is created 0600, synced, and only then restricted to 0444 so no observer ever sees a writable artifact. The operator source and its permissions are never referenced after startup. Addresses GATOR-291f43b2-02. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

…resh Supervisor-only trust reconciliation re-entered create_sandbox_with_existing_token, which re-pulled and re-resolved the workload image tag even though the workload container is retained. If the tag moved to a different image between stop and start, identity resolution and child-environment construction would reflect the new image while the retained workload still runs the original one, leaving mode-0600 bootstrap files the retained user cannot read. During a refresh with a retained workload, inspect the stopped container and pin to the immutable image ID it was created from (Config.Image); never pull or resolve the request tag. The requested reference is still used for child metadata so the retained workload's environment is byte-identical to its original launch. Addresses GATOR-291f43b2-01. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

The additional-CA lane's VM assertions read the destination CA out of the guest overlay and a guest-side supervisor-argv marker — artifacts from the guest-supervisor design that no longer exist now that the VM driver stages the CA host-only and runs the supervisor on the host. Inspect the driver-staged host artifact (digest-compared against the source), assert the guest overlay contains no CA material at the old mount paths, and keep the serial-console no-disclosure check. The workload validation scripts also ran curl, which exists only in the container-engine fixture image; the Kubernetes and VM lanes use the uv-based workload image and died instantly with "canonical main process already finished". Rewrite the main-process, exec, and lifecycle validation scripts in python3 (present in every lane's workload image). The network-policy binary identity is the resolved /proc/<pid>/exe target, so the versioned python3.12 binaries are allowlisted rather than the unversioned symlinks. The hostname mismatch check keeps its semantics: same reachable fixture, mismatched TLS SNI, and the failure must specifically be hostname verification. Addresses GATOR-291f43b2-04. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

…nfigMaps The destination-trust ConfigMap validation compared the whole label map for equality. A mutating admission webhook that attaches an organizational label to the created ConfigMap made the create response fail validation, and the retained ConfigMap then failed every subsequent create/start through the existing-object path, blocking sandbox launches despite the ownership labels, immutable flag, digest, and certificate bytes remaining correct. Validate the gateway-owned label pairs individually and allow unrelated labels; the exact trust-material checks are unchanged. Covered by a regression test with an admission-added label and a missing gateway-owned label. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

The supervisor-only trust refresh renamed the previous supervisor to a random rollback name and then performed the token-secret lookup. A transient lookup failure returned with the supervisor still renamed, where a normal delete could never find it, and the rollback rename and final rollback removal ignored their own failures, leaving orphans with attached control and channel resources. Complete every fallible preparation before the rename. On a failed replacement, restore the canonical name; if the restore itself fails, return an error naming the rollback container so the orphan stays identifiable — a later retry still succeeds because the canonical name is absent and the replacement path recreates a fresh supervisor. Treat not-found during the final rollback removal as success and name the orphan in both the log and the error on other removal failures; a retry observes the fresh canonical supervisor and resumes the normal start path. Covered by failure-injection tests for each transaction boundary: preparation failure before any rename, replacement failure restoring the canonical name, and restore failure naming the orphaned rollback container. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

The gateway-configuration RFC documented an additional_ca_cert_paths list that the strict configuration parser never accepted; document the additional_ca_bundle single-path setting the parser actually enforces. The debug-openshell-cluster skill named the wrong generation annotation (openshell.ai/network-supervisor-trust-generation) and described digest argv and network-init canonicalization checks the implementation does not perform. Correct it to openshell.ai/additional-ca-generation and describe the actual delivery: the supervisor Pod mounts the immutable ConfigMap read-only and receives --additional-ca-bundle for the mount path, with the driver validating the digest annotation and exact bytes per creation. Classify the destination-trust generation hashes as deterministic identity derivation rather than authenticity proofs, following the openshell-crypto exclusions table: trust decisions come from the gateway's normalization, immutable staging, exact-byte validation, and TLS verification. Record the classification in the crypto README and at each hashing site. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

…uth changes Upstream's suspend/resume lifecycle took StartSandboxRequest fields 7 and 8, so the durable-snapshot field moves from 7 to 9; update the wire-format test to assert the field-9 key (0x4a) and initialize the new resume controls. Repair the cli test module after the auth opt-in test merged alongside the environment-guard helpers, and initialize the gateway driver-startup context's network-trust fields in the shared supervision test. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

TaylorMutch · 2026-10-27T16:33:16Z

/ok to test 52e2f28

The durable-snapshot field grows StartSandboxRequest enough that the start-recovery match and the recovery-expiry test exceed the large-futures limit under -D warnings. Box::pin both futures, matching the pattern the recovery path used before the suspend/resume rework. Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

TaylorMutch · 2026-10-27T17:20:08Z

/ok to test 270cd15

TaylorMutch

Reviewed head 270cd1525afc9e7a0b582a33a971394ddd4be500. The Kubernetes admission-label and Podman supervisor-refresh findings from my prior review are addressed, including regression coverage; the documentation and crypto-classification corrections are also present. I compared the rebased series with the previously reviewed content, checked the suspend/resume protobuf-field integration and test repairs, and reviewed the recovery-future boxing fix. No remaining blocking finding from this follow-up review.

Current-head CI is green: Branch Checks, cross-driver E2E, Helm, Trivy, Windows MSVC, DCO, issue acceptance, and the remaining completed workflows all pass. Earlier local validation covered the Kubernetes admission-label regression and four Podman supervisor-refresh tests; those local results were on the previously reviewed equivalent fixes, while the latest head was validated through CI.

jhjaggars mentioned this pull request Sep 11, 2026

feat: trust additional destination CAs for sandbox egress TLS #3295

Closed

jhjaggars force-pushed the feat/network-supervisor-additional-ca branch from a65ec41 to 76279f5 Compare September 14, 2026 19:04

jhjaggars marked this pull request as ready for review September 14, 2026 19:05

jhjaggars requested review from a team, derekwaynecarr, mrunalp and sjenning as code owners September 14, 2026 19:05

jhjaggars force-pushed the feat/network-supervisor-additional-ca branch 10 times, most recently from 46692e8 to eb2db3f Compare September 22, 2026 14:45

politerealism mentioned this pull request Sep 28, 2026

bug: Podman supervisor cannot trust operator-supplied CA for upstream TLS after v0.1.2 architecture change #3781

Closed

4 tasks

politerealism reviewed Sep 28, 2026

View reviewed changes

jhjaggars force-pushed the feat/network-supervisor-additional-ca branch from eb2db3f to 60826fb Compare September 29, 2026 13:21

politerealism mentioned this pull request Sep 30, 2026

fix(podman): trust an operator-supplied additional CA for direct egress #3996

Merged

11 tasks done

github-actions Bot added the state:stale Inactive item at risk of automatic closure. label Oct 14, 2026

jhjaggars force-pushed the feat/network-supervisor-additional-ca branch from 5672597 to 309301d Compare October 15, 2026 20:51

github-actions Bot removed the state:stale Inactive item at risk of automatic closure. label Oct 16, 2026

jhjaggars force-pushed the feat/network-supervisor-additional-ca branch from 309301d to aaf328b Compare October 16, 2026 18:36

jhjaggars added 25 commits October 27, 2026 12:13

feat(network): support additional destination CAs

45695fa

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

fix(network): harden additional CA propagation

e502549

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

fix(network): narrow additional CA review scope

4e6c3ae

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

fix(network): harden additional CA rotation

ab6cb88

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

feat(network): complete additional CA delivery

102c161

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

fix(docker): remove stale runtime fixture field

fbe0a6f

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

chore: refresh testkit lockfile for openshell-core libc dependency

7a8c985

Signed-off-by: Jesse Jaggars <jjaggars@redhat.com>

TaylorMutch approved these changes Oct 27, 2026

View reviewed changes

rhods-devops-app Bot mentioned this pull request Oct 28, 2026

Automated Sync from main to stable red-hat-data-services/openshell#40

Open

Navigation Menu

Repository navigation

feat(network): support additional destination CAs - #3292

feat(network): support additional destination CAs#3292
TaylorMutch merged 26 commits into
NVIDIA:mainfrom
jhjaggars:feat/network-supervisor-additional-ca

jhjaggars commented Sep 11, 2026 •

edited

Loading

Uh oh!

copy-pr-bot Bot commented Sep 11, 2026

Uh oh!

jhjaggars commented Sep 11, 2026

Uh oh!

politerealism left a comment

Uh oh!

github-actions Bot commented Oct 14, 2026

Uh oh!

TaylorMutch commented Oct 27, 2026

Uh oh!

TaylorMutch commented Oct 27, 2026

Uh oh!

TaylorMutch left a comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Conversation

jhjaggars commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Related Issue

Changes

Why lifecycle reconciliation is included

Testing

Checklist

Uh oh!

copy-pr-bot Bot commented Sep 11, 2026

Uh oh!

jhjaggars commented Sep 11, 2026

Uh oh!

politerealism left a comment

Choose a reason for hiding this comment

Summary

Blocking

Non-blocking notes

Testing

Uh oh!

github-actions Bot commented Oct 14, 2026

Uh oh!

TaylorMutch commented Oct 27, 2026

Uh oh!

TaylorMutch commented Oct 27, 2026

Uh oh!

TaylorMutch left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

jhjaggars commented Sep 11, 2026 •

edited

Loading