Repository navigation
Adds oci-javascript-mcp-server Kubernetes/Kata Isolation Provider - #431
dustin-sale wants to merge 33 commits into
Conversation
…cal development profiles
a5b46e4 to
0fa9f5b
Compare
0fa9f5b to
a652aab
Compare
e576b6d to
2f92241
Compare
2f92241 to
831ae23
Compare
b7aebd3 to
d5f71a4
Compare
Resolve the Kubernetes isolation provider on the shared protobuf gRPC transport with mTLS and pod port-forwarding.
d5f71a4 to
055ac40
Compare
|
Notes from the automated review:
For 2, I'm thinking this is a bit more idiomatic Kube:
If we use Istio or Maistra, then we can mTLS for free. |
…cript-k8s-isolation-provider # Conflicts: # src/oci-javascript-mcp-server/package-lock.json # src/oci-javascript-mcp-server/package.json
|
@gebhardtr I have addressed items 1,2, and 4 from your prior comment.
|
Signed-off-by: Dustin Sale <dustin.sale@oracle.com>
| } | ||
|
|
||
| async preflight(options: { startReconciliation?: boolean } = {}): Promise<void> { | ||
| this.#ready = false; |
There was a problem hiding this comment.
Need checks for namespace, identity, RBAC, admission behavior, RuntimeClass, and node-profile evidence
There was a problem hiding this comment.
You requested that I move the admission probing out of the server in this comment, do I need to add it back?
| if (user.exec != null || user.authProvider != null) { | ||
| throw new ValidationInputError("Kubeconfig exec and auth-provider helpers are unsupported; use token or client-certificate credentials"); | ||
| } | ||
| if (options.impersonate) { |
There was a problem hiding this comment.
This only sets user but groups are checked in https://github.com/oracle/mcp/pull/431/changes#diff-b1ef2b28e669d81493b73032a6be965ef2050f70d50b1d3968e26c0663b2bc26R247 (lines 247-255)
There was a problem hiding this comment.
This relies on Kubernetes’ service-account impersonation behavior: when Impersonate-User names a service account and no Impersonate-Group headers are supplied, the API server derives its normal service-account groups and adds system:authenticated. See the upstream implementation.
The check below verifies the effective identity returned by SelfSubjectReview, including those groups, rather than assuming impersonation succeeded. Missing or unexpected groups fail validation.
I think the current approach is valid, but it deserves an explanatory comment and verification against our target Kubernetes release—the fake-API tests alone don’t establish that behavior.
| () => api.selfCan({ resource, subresource, verb, namespace: options.config.namespace }, signal), | ||
| passed => ({ passed, detail: "Required execution permission must be allowed" }))) return report; | ||
| } | ||
| const policy = runtimePolicyFor(options.config); |
There was a problem hiding this comment.
should we also have an exact Kata profile and a dedicated execution worker pool check here?
and does the policy validation here have to be code that checks individual properties? or do we just hash/version the policy yaml and verify the deployed policy and binding against that version?
Description
Extends the existing
oci-javascript-mcp-serverwith 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:
local-development,in-cluster, andkata-in-clusterprofiles behind a shared isolation-provider interface.RuntimeClassand handler where applicable.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-nodeand 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 KataRuntimeClassforkata-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.Additional unit-test coverage identified and corrected four behavior defects:
fails closed, and the initial readiness GET and watch both respect
cancellation and the absolute execution deadline.
named profiles that inherit a DEFAULT security-token path and profiles that
explicitly override or clear that value.
with regression cases for strings, templates, regular expressions, postfix
division, and JavaScript line terminators.
discover_ociexamples now represent required array fields as arrays,including model arrays, while retaining bounded model expansion.
The suite also verifies concurrent RPC response correlation with reversed
replies and mixed success/failure outcomes, plus background reconciliation's
immediate execution, prevention of overlapping cycles, recovery after failure,
and idempotent stop behavior. These tests use fake APIs and controlled responses.
The RPC protocol and reconciliation shutdown contract are unchanged.
Type of change
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% coverageAdditionally, I tested in both
local-developmentandin-clusterkubernetes isolation provider profile modes.Latest whole-server validation, run from the repository root:
moon run --no-actions oci-javascript-mcp-server:check oci-javascript-mcp-server:test— native setup, protobuf compilation, TypeScript checking, and the c8 test
task passed.
and 95.75% lines. All configured 90% coverage thresholds passed.
corrections and passing afterward. Additional review regressions cover
late readiness events and JavaScript source-preservation edge cases.
git diff --checkpassed.--no-actionsbypassed dependency setup/synchronization after npm dedupestalled; compilation, checking, tests, and coverage enforcement still ran.
These results validate the installed dependency environment. Fake API tests
do not establish real-cluster runtime or admission-policy behavior.
Test Configuration:
arm64)oci-sdk2.132.x;@kubernetes/client-node2.x;@modelcontextprotocol/sdk1.29.xChecklist: