[bmscomp]

Follows #427, which limits a chaos step's targetNamespace to the Kafka namespace or the Kates API's own. A review of #427 found three ways around that check on the default litmus-crd provider, all through what Kates hands Litmus. Every Litmus experiment runs as litmus-admin, which the kates-chaos chart lets delete pods, evict and patch nodes in every namespace by default (rbac.nodeChaos.enabled). Reading litmus-go and chaos-runner 3.28 for those turned up a fourth problem: NETWORK_PARTITION never worked on Litmus.

Commits

1. envOverrides may not pick the Litmus namespace or pods (98aabed). chaos-runner sets CHAOS_NAMESPACE and TARGETS first and then lets the ChaosEngine's env overwrite them. litmus-go looks TARGET_PODS up in either namespace. So envOverrides could aim a step at kube-system, past both the namespace check and the broker count.
2. envOverrides may set only TARGET_NODE and NODE_LABEL (3267561). This replaces commit 1's denylist with an allowlist. Litmus's stress, network, DNS and disk-fill helper pods run privileged as root with hostPID. LIB_IMAGE sets their image and CHAOS_SERVICE_ACCOUNT their service account. litmus-go also pastes many env values into bash -c there (CHAOS_TYPE, MATCH_SCHEME, SPOOF_MAP, CPU_LOAD, NETWORK_INTERFACE…), so nearly any override was root on a node. targetTopic reached the same shell as TARGET_HOSTNAMES on a DNS_ERROR. It now has to be a Kafka topic name; a hostname like krafter-kafka-bootstrap.kafka.svc still fits.
3. NETWORK_PARTITION on litmus-crd is a Kates NetworkPolicy (085bf6a). pod-network-partition fails with "provide the appLabel" when TARGETS is empty, and Kates sends no appinfo. It also ignores TARGET_PODS and selects its pods by one label. So split-brain, consumer-isolation and the resilience example never cut anything off. Litmus now hands the type to the kubernetes provider, as it already does POD_DELETE. The kates chart (0.11.5) moves NetworkPolicy create/delete/deletecollection out from behind rbac.directChaos.
4. A fault may carry no cmdProbe, and Litmus gets no probe (a77f339). A fault's cmdProbe became an inline Litmus probe, and Litmus runs those with /bin/sh -c in the experiment pod as litmus-admin. A resilience run's top-level probes, which Kates runs in a broker pod, are unchanged. Nothing shipped puts a probe in a fault.

All refusals go through FaultLimits, which the safety guard, the coordinator and the compound orchestrator apply. Each change has a test that fails on the code before it. The book (07, 02, versions appendix), the disruption guide, the playbook catalog, the overview, the troubleshooting page, the examples README and the chart README match. The two MCP caveats that list what litmus-crd hands the kubernetes provider name NETWORK_PARTITION, and their refs follow LitmusChaosProvider.java.

Upgrade notes

• A plan, schedule or resilience file that sets any envOverrides key other than TARGET_NODE/NODE_LABEL, or a cmdProbe inside a fault, is now refused (422 for a plan, 400 for a resilience run). Cluster settings such as CONTAINER_RUNTIME/SOCKET_PATH go in the kates-chaos chart's experiments.definitions[].env.
• The default kates ClusterRole now lets the API create and delete NetworkPolicies cluster-wide; fix(chaos): a step may target only the Kafka namespace or the Kates API's own #427's namespace check limits where it does.

Testing

• ./mvnw test (KUBECONFIG pointed at a nonexistent file, gRPC codegen skipped): 1,650 tests, 0 failures, 1 skipped
• Spotless check on JDK 25, go vet ./... and go test ./... in cli, including TestMCPCaveat*
• helm lint charts/kates, plus helm template with rbac.directChaos false and true

Not tested on a cluster. The pod-network-partition failure and the helper-pod shell use come from reading the 3.28 sources, not from a reproduction.