Allow administrators to set a RuntimeClass for dedicated Kubernetes supervisor Pods #5313

User Story

We use OpenShell for Secure Agent Workspace on OpenShift. We're extending the workspace to Kubernetes and then to Kata Containers through the same Kubernetes driver. We want to keep the agent workload and its dedicated supervisor in separate Pods and let a cluster administrator choose a RuntimeClass for each.

Problem Statement

OpenShell already lets us set the workload Pod's RuntimeClass. The dedicated supervisor Pod has no corresponding driver setting, so we can't place it in its own Kata VM through OpenShell configuration.

Impact / Why This Matters

The supervisor processes agent traffic and opens upstream connections. A separate guest kernel would give the worker node an additional layer of protection if the supervisor were compromised. We also have a future confidential-inference use case: if a supervisor must inspect plaintext requests, we would like to place it in an attested confidential VM. That use case also requires attestation and secure credential delivery. This proposal covers only Pod placement.

Proposed Design

Let a gateway administrator choose the RuntimeClass for dedicated supervisor Pods through Kubernetes driver configuration, including when deploying with Helm. For example, with these illustrative class names:

[openshell.drivers.kubernetes]
default_runtime_class_name = "kata-workload"
supervisor_runtime_class_name = "kata-supervisor" # proposed

The administrator could opt in to one VM per Pod or leave the supervisor on the cluster default. Workload placement would continue to be configured independently. Sandbox creators should have no authority to change supervisor placement.

Acceptance Criteria

• With two distinct classes configured, a newly created sandbox's workload and dedicated supervisor Pods each have the expected spec.runtimeClassName.
• After stop/start, the replacement Pods have the same respective classes.
• With the supervisor setting omitted, its Pod's spec.runtimeClassName stays unset, including when the workload requests Kata.
• A caller changing the workload class cannot change the supervisor class.
• If the configured supervisor class is unavailable, startup reports the failure and never falls back to an ordinary supervisor Pod.

Alternatives Considered

We can start with the supervisor on the cluster default. Inheriting the workload class would prevent independent placement and could give the sandbox creator influence over a trusted component. A cluster admission mutator could add the field, but operators would have to identify driver-owned Pods and maintain that extra policy. Placement belongs to the Kubernetes driver rather than inference middleware or providers.

Agent Investigation

The workload builder resolves the workload class, while the dedicated supervisor Pod builder builds its own Pod spec. The earlier OpenShift two-VM test ran the agent and network proxy in separate Kata VMs. We're proposing independent placement for the dedicated supervisor topology that subsequently merged.

Checklist

• I've reviewed existing issues and the published docs.
• This is a design proposal.