Adds oci-javascript-mcp-server Kubernetes/Kata Isolation Provider

[dustin-sale]

Description

Extends the existing oci-javascript-mcp-server with a Kubernetes isolation provider while preserving Podman as the default. Provider and profile selection are trusted startup configuration, use exact accepted values, and fail closed without falling back to another runtime or credential source.

The Kubernetes provider includes:

• Explicit local-development, in-cluster, and kata-in-cluster profiles behind a shared isolation-provider interface.
• A fresh, credential-free Kubernetes pod for each JavaScript execution, connected to the trusted host over a bounded framed exec channel while OCI credentials and SDK clients remain on the host.
• Fixed non-root pod security settings, disabled service-account token mounting and service links, bounded memory-backed temporary storage, and reviewed CPU, memory, and ephemeral-storage ranges.
• Startup preflight checks for namespaces, exact RBAC permissions, admission-policy behavior, image digest pinning, and the Kata RuntimeClass and handler where applicable.
• Fail-closed lifecycle handling with absolute deadlines, cancellation, bounded cleanup tails, concurrent channel shutdown and zero-grace pod deletion, and deletion confirmation.
• A cleanup-only reconciler for expired managed pods with separately constrained permissions and per-candidate time bounds.
• Hardened worker-channel validation and budgets for framing, RPC IDs, messages, logs, results, concurrency, egress, and transport backpressure.
• Versioned standard Kubernetes and Kata manifests, container build assets, an OCI session-secret synchronization helper, local dry-run tooling, OpenSpec artifacts, deployment guidance, and security limitations.
• Fake-API, provider, lifecycle, cancellation, reconciliation, hostile-channel, manifest, configuration, and optional real-cluster tests across all three profiles.

The motivation is to support cluster-managed execution and an optional Kata-backed deployment profile without weakening the server's trusted-host boundary or changing existing Podman deployments. The standard Kubernetes profiles provide container isolation only. The Kata profile is intentionally documented as a proof of concept and still requires deployment-specific runtime evidence and a current security review before it can be treated as a VM-grade boundary.

The implementation adds @kubernetes/client-node and its WebSocket type support. Kubernetes deployments require access to a compatible cluster, the documented namespaces and RBAC/admission/network controls, a digest-pinned runner image, and a reviewed Kata RuntimeClass for kata-in-cluster. The credential synchronization helper additionally requires Python 3 and an existing OCI CLI configuration. Podman remains the default and gains no new Kubernetes dependency at runtime. No downstream module changes are required.

Fixes #

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

Run the following from src/oci-javascript-mcp-server:

• npm run check — TypeScript validation passed.
• npm run packcheck — npm package dry-run verification passed.
• npm run check:kubernetes-manifests — all 14 standard and Kata Kubernetes manifest tests passed.
• git diff --check 6633b602248bf44dbaf9aebe2e584c4a53622f1a...HEAD — passed with no whitespace errors.
• npm run ci — 184 tests passed with 95.39% coverage

Additionally, I tested in both local-developement and in-cluster kubernetes isolation provider profile modes.

Test Configuration:

• Firmware version: Not applicable
• Hardware: Apple Silicon (arm64)
• Toolchain: macOS 26.6.2; Node.js 22.14.0; npm 11.18.0; TypeScript 5.9.3
• SDK: oci-sdk 2.132.x; @kubernetes/client-node 2.x; @modelcontextprotocol/sdk 1.29.x

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules