Сделать работу MCP комфортной для агентов за ограниченным RBAC

[karabasBaRaBaS-1276]

What problem does it solve?

Попробовал использовать mcp сервер с AI-агентом (opencode).

Сценарий, который ломается

Типичная сессия агента начинается с «дай обзор текущего состояния». На кластере с урезанным RBAC это выглядит так:

1. get_problems (все неймспейсы) → падение: Cannot read properties of null (reading 'length')
2. list_resources по подам кластер-вайд → сырой 403 от API: cannot list resource "pods" at the cluster scope
3. get_events / get_metrics / список namespaces → те же 403
4. get_permissions → пусто, потому что тот же урезанный пользователь не может читать RBAC-объекты (unreadable: ["ClusterRoles", "RoleBindings", …])
5. Агент сдаётся и спрашивает человека: «а на какие неймспейсы мне можно смотреть?»

Ирония в том, что Sextant уже знает ответ — он лежит в настройках доступа кластера. Агент просто не может его увидеть.

Proposed idea

1. Дать агенту видеть карту собственных прав.
Отдавать настроенный пользователем доступ по кластеру (неймспейсы / kinds / действия / secret-values) через list_clusters или отдельным лёгким tool get_access. Ноль обращений к API-серверу, ноль новых прав — и агент сразу знает, что перебирать, вместо перебора наугад. Одна эта правка превратила бы всю сессию выше в один вызов.

2. Фолбэк на сконфигурированные неймспейсы вместо ошибки.
Инструменты, в описании которых заявлено «все неймспейсы, доступные агенту, если ns не указан», сегодня ловят cluster-scope 403, когда RBAC запрещает кластерный list. Фолбэк на перебор неймспейсов из пункта (1) сделал бы поведение «ns не задан» соответствующим документации даже в запертых кластерах.

3. SelfSubjectRulesReview для get_permissions.
Когда сами RBAC-объекты нечитаемы, агент всё равно может узнать свои эффективные права через authorization.k8s.io SelfSubjectRulesReview — API-сервер считает их сам для вызывающего. С теми же оговорками, что и сейчас (вебхук-авторизаторы не учитываются), но это делает get_permissions полезным именно в урезанных конфигурациях, где он нужнее всего.

4. Плавная деградация для get_problems.
Вместо падения на null — считать проблемы по доступным неймспейсам, а кластерные объекты помечать как «пропущено/неизвестно». get_problems с указанием неймспейса на этой же конфигурации работает нормально, то есть всё уже есть.

5. Компактный вывод для list_resources.
Полные объекты подов — 130–230 КБ на неймспейс: за пределами лимитов MCP-клиента, приходится мириться с обрезкой и обрабатывать JSON локально. Опциональный summary: true (те же колонки, что десктопские таблицы уже считают) или проекция fields сократили бы главный сценарий «получить список и оценить состояние» в 10–50 раз. По умолчанию поведение не меняется — полная обратная совместимость.

Alternatives

No response

Area

Clusters & kubeconfig

[mxp100]

Thank you, this is a very useful report. Each point went into its own issue, and all of them are planned for 0.25.5:

• The get_problems crash: MCP get_problems: crash on read-everywhere rules with Istio served, failed sources silently missing #297. The likely cause is the mesh step, which throws on null when the agent may read every namespace and Istio's kinds are served. The same issue also covers a second defect: a source that failed with 403 was left out of the answer without saying so. Now it will be reported as not checked.
• Seeing its own access map: MCP: let the agent see its own access rules #298. A read-only tool that returns the cluster's agent access rules, plus the known namespaces and the context namespace as hints. It sends no request to the API server and grants nothing new.
• A fallback instead of a cluster-scope 403: MCP: fall back to known namespaces when a cluster-wide list is forbidden #299. When the cluster-wide list is forbidden, the tools will list the known namespaces the agent may read and say which ones were refused.
• SelfSubjectRulesReview for get_permissions: MCP get_permissions: effective permissions from a rules review, behind an opt-in #300. The reviews were deliberately kept away from agents, because they describe the user's own credentials. This will come behind a separate opt-in in the cluster's agent access settings, off by default. The result will be cut to what the agent's own rules allow.
• Compact list_resources: MCP list_resources: optional field projection or summary #301. An optional fields projection, using the path grammar of custom columns, and a summary per common kind. Secret and inline secret paths stay refused, and the default output does not change.

[mxp100]

All five points are now in Sextant 0.25.5. Installed copies update themselves; Homebrew and Scoop already have it.

• get_problems over all namespaces no longer fails when Istio's kinds are served. Lists it could not read are named in failed, so their problems are unknown, not absent (MCP get_problems: crash on read-everywhere rules with Istio served, failed sources silently missing #297).
• get_access returns the agent's rules for a cluster. As hints, it also names the context's namespace and your accessible namespaces, only those the agent may read in (MCP: let the agent see its own access rules #298).
• When the cluster refuses a list over all namespaces, list_resources, get_events, get_metrics and helm_list_releases list those namespaces one by one instead, with refused for the ones the cluster refused too (MCP: fall back to known namespaces when a cluster-wide list is forbidden #299). Sextant must know these namespaces. Add them under the cluster's settings → Connection → Accessible namespaces, or select them in the namespace filter once.
• get_permissions with mine: true returns your SelfSubjectRulesReview, cut to the kinds the agent's rules cover (MCP get_permissions: effective permissions from a rules review, behind an opt-in #300). It works only after you tick Let agents see my effective permissions under the cluster's AI agent access. It is off by default.
• list_resources takes fields (paths such as .status.phase, as in custom columns) or summary: true (MCP list_resources: optional field projection or summary #301).

The details are on the wiki page MCP server. If you try it with opencode on that cluster, I would be glad to hear how the session goes now.