feat(studio-cp,oab-mcp): K8sFleetBinding.expected_principal + k8s_fleet_config_write (studio#104) - #107
Open
brettchien wants to merge 1 commit into
Conversation
…et_config_write (studio#104) Third sub-item of #104, stacked on #106. - K8sFleetBinding gets expected_principal: Option<String>, deliberately named to match FleetBinding's AWS-side field — the verify machinery already exists symmetrically (observe_k8s_identity's SelfSubjectReview- derived principal + k8s_principal_kind, same shape as observe_identity/ identity_matches for AWS), this just wires the config schema to it. Typically a system:serviceaccount:<ns>:<name> string, or a plain username; unset = no identity check for that fleet. - k8s_fleet_config_write: new MCP tool mirroring fleet_config_write's AWS-side write path (validate text parses, write bytes verbatim so comments/layout survive, return the parsed fleets + raw text). save_k8s_bindings_text (studio-cp/lib.rs) already existed and needed zero changes — it's a generic toml::from_str + verbatim write, so it picked up the new field automatically once added to the schema structs. Unlike AWS bindings, k8s bindings aren't cached anywhere in OabMcp yet (nothing dispatches provisioning to K8sDriver yet either — separate item), so this is a plain validate-then-write, no in-memory state to invalidate. Ref: studio#104.
This was referenced Aug 27, 2026
Open
brettchien
added a commit
that referenced
this pull request
Aug 27, 2026
…104) t_provision now branches on a new provider arg (default "aws", unchanged behavior): "k8s" calls provision_from_library_k8s (#114) with context/ expected_principal taken as direct args, not resolved via a fleet name — the console's identity form already collects context/namespace/service- account directly (#108/#109), and for a brand-new fleet there's no existing K8sFleetBinding to look up anyway. Fleet-scoped k8s lookup (for redeploying into an already-known k8s fleet) is left as explicit future work, not needed for this dispatch to exist. Also updates deploy_provision's tool description, which was stale after #113 (redeploy no longer requires an existing manifest) and needed the new provider/context/expected_principal params documented. NOTE — branch lineage: this stack (#112→#113→#114→this) was cut from `main` before #104's original stack (#105-110) merged, not from #110 — so K8sFleetBinding.expected_principal (originally #107) is re-added here too. Identical field in both places; trivial merge conflict to resolve whenever both land, flagging explicitly rather than silently duplicating without a note. With this, deploy_provision fully supports k8s end-to-end (provisioning side) — the remaining piece for full onboarding is unblocking console's k8s "Next" button (#108/#109's placeholder), a separate follow-up. Ref: studio#104.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Third sub-item of #104, stacked on #106 (please merge #105 → #106 → this in order).
K8sFleetBinding.expected_principal: Option<String>— deliberately named to matchFleetBinding's AWS-side field. The verify machinery already exists symmetrically:observe_k8s_identity'sSelfSubjectReview-derived principal +k8s_principal_kindclassification is the same shape asobserve_identity/identity_matchesfor AWS — this just wires the config schema field, no new verify logic needed. Typicallysystem:serviceaccount:<ns>:<name>for a service account, or a plain username; unset = no identity check for that fleet (same "unset = don't check" contract AWS has).k8s_fleet_config_write— new MCP tool mirroringfleet_config_write's AWS-side write path: validatetextparses before writing, store bytes verbatim (comments/layout preserved), return the parsed fleets + raw text.save_k8s_bindings_text(already existed,studio-cp/lib.rs:924) needed zero changes — it's a generictoml::from_str+ verbatim write, so it picked up the newexpected_principalfield automatically once added to the schema structs (K8sFleetBinding,K8sFleetBody, theFrom<K8sFleetsDoc>conversion).Unlike AWS bindings, k8s bindings aren't cached anywhere in
OabMcpyet — nothing here dispatches provisioning toK8sDriveryet either (that's the separatedeploy_provisionprovider-param item, still open in #104). So this write tool is a plain validate-then-write with no in-memory state to invalidate, unliket_fleet_writewhich also drops a memoized-config cache.Testing
Added a TOML round-trip test (
k8s_fleet_expected_principal_parses_and_defaults_to_none) and updated the two existingK8sFleetBindingstruct-literal tests for the new field.Same local-build caveat as #105/#106:
cargo check -p studio-cp -p oab-mcpOOM-kills onaws-sdk-ec2on this machine (6th identical failure today, same pre-existing environment constraint) — hand-verifiedK8sFleetBindings/default_k8s_bindings_path/save_k8s_bindings_textsignatures directly against source in this repo before writing this. CI is the real gate.Scope note
deploy_provision's provider param (dispatch toK8sDriver) and console-side wiring are still open in #104 — this PR is backend-schema-and-write-path only.Ref #104. Stacks on #106 (which stacks on #105) — merge in order.