2 Commits

Include renames

Author	SHA1	Message	Date
Michael Suchacz	7ca7c30f40	feat: add group and user ACLs to MCP server configs (#27944) ... Adds group and user ACLs to org-scoped MCP server configs so organizations can restrict specific MCP servers to subsets of members, mirroring the template ACL pattern. ## Summary - Migration adds `group_acl`/`user_acl` JSONB columns (nested `{"<id>": {"permissions": [...]}}` shape) and seeds every existing config with its organization's Everyone group read entry (the Everyone group ID equals the org ID), so member access is unchanged by default. Creation seeds the same entry. - The blanket org-member read grant from the base PR is replaced by ACL evaluation: Rego requires org membership for every ACL grant, and `GetAuthorizedMCPServerConfigs` compiles ACL-aware SQL filters. - New `ActionShare` (org admins) gates `GET|PATCH /api/experimental/organizations/{organization}/mcp-servers/{mcpserverconfig}/acl` (nested under the organization like the rest of the config surface). PATCH validates principals against the config's organization, merges sparse updates under a row lock, stamps `updated_by`/`updated_at`, and is audited as a Write with `Old` captured before authorization. A config deleted concurrently between the middleware fetch and the locked re-fetch is concealed as 404, matching the update and delete handlers. ACL columns are tracked in the audit table. - ACL management is available in all editions (no enterprise entitlement), documented in the MCP servers page. Revoking an ACL does not retro-strip already-selected configs from existing chats; new selection is blocked at chat create. - Force On respects the ACL: the forced set is loaded as the chat owner, so a `force_on` server whose ACL denies the owner never attaches at create, send, or generation time. - No rolling-upgrade machinery: upgrades run in scheduled maintenance downtime, so the migration only backfills existing rows; the API sets the Everyone read grant explicitly on every insert. Stacked on #27943. Part of the MCP org-separation stack. Closes https://linear.app/codercom/issue/CODAGT-712 UAT: verified on a dogfood instance with two members and a custom group: Everyone-seed default visibility, group grant with Everyone removal (non-member loses list/fetch/selection), foreign-principal rejection, non-admin share denial (audited 403 / concealed 404), user_acl restore, and audited ACL diffs. > Mux (AI agent) authored this PR on Mike's behalf. <!-- mux-attribution: model=claude-fable-5 thinking=high -->	2026-08-19 19:25:18 +00:00
Michael SuchaczandMathias Fredriksson	443e3b9b80	feat!: org-scope MCP server configs with RBAC (#27942) ... Moves `mcp_server_configs` from deployment scope to organization scope so each organization fully controls the MCP servers its members can use with Coder Agents. ## Summary - Migration: adds `organization_id` (NOT NULL, FK) and keeps existing rows as the default organization's originals with credentials intact. Other organizations start with no MCP servers and configure their own; nothing is copied across organizations. Chats outside the default organization keep any now-cross-organization `mcp_server_ids` entries; the runtime already ignores IDs that do not resolve in the chat's organization, so no data rewrite is needed. Slug uniqueness becomes `(organization_id, slug)`. - RBAC: new org-scoped `ResourceMCPServerConfig` with regosql converter and `GetAuthorizedMCPServerConfigs`; org admins get in-org CRUD, org members get read (replaced by ACL evaluation in the follow-up ACL PR in this stack). - API: all config routes nest under the organization, matching templates: `POST|GET /api/experimental/organizations/{organization}/mcp-servers` and `GET|PATCH|DELETE .../mcp-servers/{mcpserverconfig}` (plus `oauth2/connect`), resolved by a read-only param middleware that conceals read-denied and cross-organization access as 404. Two routes stay on the frozen `/api/experimental/mcp/servers/{mcpServer}` block: the OAuth2 callback (the redirect URI baked into existing AS-side client registrations) and `oauth2/disconnect`, which must remain reachable by users removed from the organization so they can still revoke their token grant. - Chat runtime: selection validation and generation resolve configs strictly by IDs, enabled state, and the chat's organization in SQL; requested duplicates are normalized; invalid or cross-org IDs are rejected with the precise ID list. IDs already persisted on a chat are exempt from message-time rejection so disabling a selected server never blocks sends; generation skips servers that are no longer usable. - Frontend: API layer and admin settings pages target the new endpoints. The admin page manages the default organization's servers; the org picker is tracked separately (CODAGT-714). - Security hardening from review: OAuth user grants are additionally bound to `oauth2_revocation_url` (changing it invalidates grants, and a racing OAuth callback gets 409 instead of recreating a grant). Stack-wide SSRF protection for MCP config-directed traffic was split into its own PR at the top of this stack (#28242) to keep this diff reviewable; this PR keeps main's existing discovery IP-range guard. OAuth2 auto-discovery now completes before the config row is inserted: a failed discovery persists nothing, and there is no provisional row that concurrent updates could race against. Two follow-up PRs in this stack were split out to keep this diff reviewable: #28064 completes the swagger annotations for the moved routes (main already ships these experimental MCP handlers unannotated), and #28065 carries hardening fixes and regression pins on top of the cutover. - Force On enforcement (landed on main mid-review) is org-scoped: the forced set is read per chat organization (`GetForcedMCPServerConfigsByOrganization`), so another organization's `force_on` server never attaches to a chat. ## Breaking changes (experimental API) The MCP server config endpoints move from the deployment-scoped `/api/experimental/mcp/servers` block to organization-nested paths: `POST|GET /api/experimental/organizations/{organization}/mcp-servers` and `GET|PATCH|DELETE /api/experimental/organizations/{organization}/mcp-servers/{mcpserverconfig}` (plus `oauth2/connect`). The old paths are removed, so API consumers must supply an organization. Two routes intentionally stay on the frozen `/api/experimental/mcp/servers/{mcpServer}` block: the OAuth2 callback (its redirect URI is baked into existing AS-side client registrations) and `oauth2/disconnect` (must remain reachable by users removed from the organization). These endpoints are under `/api/experimental`, so no deprecation window is provided. ## Rolling upgrades During a rolling deploy, an old replica creating an MCP config can fail the new `NOT NULL organization_id` constraint until it is upgraded (reads are unaffected: old binaries' generated queries select their own column lists). This matches the repo's existing precedent for additive NOT NULL migrations (000562) and affects only the admin config-create path in the upgrade window. Upgrades are expected to run in scheduled maintenance downtime with the database locked during migration, so the migration ships no rolling-upgrade compatibility machinery. The down migration deletes organization-created configs (their chat references are cleaned by the 000510 delete trigger) and restores deployment-wide slug uniqueness. Part of the MCP org-separation stack (CODAGT-711 -> CODAGT-717 audit -> CODAGT-712 ACLs -> CODAGT-806 token RBAC). Closes https://linear.app/codercom/issue/CODAGT-711 UAT: validated end to end on a two-org dogfood deployment, including a real pre-migration to post-migration upgrade, cross-org isolation (404s), same-slug-two-orgs, chat selection gating, and a live MCP tool call through the org-scoped generation path. The migration was later revised to keep existing rows in the default organization only (no per-organization copies); that revision is covered by the migration test suite. > Mux (AI agent) authored this PR on Mike's behalf. <!-- mux-attribution: model=claude-fable-5 thinking=high --> --------- Co-authored-by: Mathias Fredriksson <mafredri@gmail.com>	2026-08-19 18:04:13 +00:00