У mkp нет ни одного безопасного режима, только RBAC. У containers/kubernetes-mcp-server есть
штатный --read-only, --toolsets и denied_resources, официальный гайд по read-only SA и чарт.
Образ quay.io/containers/kubernetes_mcp_server:v0.0.66 с дайджестом (тег проверен в API quay).
RBAC: вместо самодельного списка — встроенная view (secrets в неё не входят) + отдельный
ClusterRole на кластерные объекты и метрики. Аргументы: --port 8080 --read-only --toolsets core.
MCP-сервер k8s из реестра ToolHive: ghcr.io/stackloklabs/mkp/server:0.4.3, transport streamable-http.
Отдельный SA mcp-k8s и ClusterRole mcp-k8s-readonly (только get/list/watch).
Core-группа перечислена поимённо, чтобы не открывать secrets; остальные группы явным списком,
потому что apiGroups: [*] включает и core-группу. Наружу не выводим: без oidcConfigRef прокси
ToolHive неаутентифицирован.
Официальный чарт oci://ghcr.io/dragonflydb/dragonfly-operator/helm/dragonfly-operator v1.6.1.
CRD (dragonflydb.io) ставит сам чарт шаблоном templates/crds.yaml, crds.keep: true.
kube-rbac-proxy отключён (метрики на :8080), ServiceMonitor и дашборд Grafana не включаем
— Prometheus Operator в кластере нет. Образ взят из ghcr и зафиксирован дайджестом.
Dragonfly CR сюда не входит: экземпляр БД создаётся в ns того, кому он нужен.
Одна задача = один MR: правка только комментария, поведение не меняется.
**Что было не так**
Комментарий утверждал, что `dependsOn` работает только внутри своего ns. Это неверно и вводит в заблуждение.
**Как на самом деле**
По CRD-схеме kustomize-controller (`api/v1/dependsOn[].namespace`):
```
namespace:
description: |-
Namespace of the referent, defaults to the namespace of the resource
object that contains the reference.
```
То есть поле опционально и по умолчанию равно namespace **самого объекта Kustomization**, а не namespace, куда тот раскидывает ресурсы. Поэтому «зависимости из другого ns» бывают двух разных видов:
- в `ewatkins/talos-cluster` все app-Kustomization лежат в `flux-system` (`apps/default/netbox/ks.yaml`: `namespace: flux-system`, `targetNamespace: default`), поэтому `dependsOn` на `dragonfly` и `crunchy-postgres-operator-*` пишется без поля `namespace`, хотя рабочие нагрузки уезжают в другие ns;
- в `drag0n141/home-ops` Kustomization лежат в своём target-ns (`apps/ai/toolhive/ks.yaml`: `namespace: &namespace ai`), и там кросс-ns зависимости пишутся явно: `onepassword-connect` с `namespace: external-secrets`, `pocket-id-instance` с `namespace: security`.
**Что у нас**
Наш репозиторий следует второму варианту: `kubernetes/apps/<ns>/kustomization.yaml` задаёт `namespace: <ns>`, то есть app-Kustomization живут в своём ns. Значит зависимости между `ai` и `database` (Dragonfly CR → dragonfly-operator) будут писаться с явным `dependsOn[].namespace`. Комментарий теперь это и описывает.Reviewed-on: #12
Co-authored-by: Hermes Agent <hermes@grachevko.ru>
hermes
