Removing policy from the list of enabled policies might cause panic

[lobkovilya]

Description

Kuma has a list of enabled policies, removing the policy from the list supposed to disable all the API endpoints related to the policy

kuma/deployments/charts/kuma/values.yaml

Lines 957 to 982 in 6a959ad

	plugins:
	resources:
	hostnamegenerators: true
	meshexternalservices: true
	meshidentities: true
	meshmultizoneservices: true
	meshservices: true
	meshtrusts: true
	workloads: true
	policies:
	meshaccesslogs: true
	meshcircuitbreakers: true
	meshfaultinjections: true
	meshhealthchecks: true
	meshhttproutes: true
	meshloadbalancingstrategies: true
	meshmetrics: true
	meshpassthroughs: true
	meshproxypatches: true
	meshratelimits: true
	meshretries: true
	meshtcproutes: true
	meshtimeouts: true
	meshtlses: true
	meshtraces: true
	meshtrafficpermissions: true

However, it might cause panic, because ordered.Policies list contains hardcoded policy types

kuma/pkg/api-server/resource_endpoints.go

Line 1298 in 6a959ad

allPlugins := core_plugins.Plugins().PolicyPlugins(ordered.Policies)

Attempting to call PolicyPlugins with ordered.Policies is going to result in panic

kuma/pkg/core/plugins/registry.go

Line 137 in 6a959ad

panic(fmt.Sprintf("Couldn't find plugin %s", policy))

[lahabana]

@slonka needs to add notes from what was gathered when we looked at it.

[slonka]

Investigation notes

Explored a few approaches to fix this:

Approach 1: Simple continue instead of panic

Replace the panic in PolicyPlugins() (pkg/core/plugins/registry.go:137) with continue to skip unregistered policies. After successful bootstrap, Init() has already panicked for any misconfigured enabled policy, so the only reason a policy isn't registered at runtime is because it was intentionally disabled. One-line fix, but loses the safety net for development bugs.

Approach 2: Track enabled policies in the registry

Snapshot registeredPolicies keys after Init() completes as the "enabled set". In PolicyPlugins(), skip policies not in the enabled set but still panic for policies that ARE enabled yet missing. Preserves the panic as a safety check, but after analysis it's logically equivalent to approach 1 - the scenario it guards against (enabled but not registered) can't happen after successful bootstrap.

Approach 3: Dependency-aware ordering (preferred direction)

Replace the hardcoded ordered.Policies list (pkg/plugins/policies/core/ordered/ordered.go) with a dependency graph. Each policy declares ordering constraints (already documented in comments):

• MeshHTTPRoute, MeshTCPRoute - no dependencies (run first)
• MeshTLS - must run after routes (rebuilds inbound listeners)
• MeshPassthrough - must run after MeshTLS
• MeshAccessLog - must run after MeshPassthrough (reads filter chains it adds)
• MeshHealthCheck - must run after MeshTLS
• MeshCircuitBreaker - must run after MeshHealthCheck (overwrites HealthyPanicThreshold)
• Most others - must run after MeshTLS
• MeshProxyPatch - runs last (patches final state)

Topological sort computes the order. If policy A depends on policy B and B is disabled while A is enabled - panic with a clear error. If a policy is simply disabled and nothing enabled depends on it - skip it. This makes the ordering constraints explicit, self-documenting, and handles disabled policies naturally.

gonum/graph is already used in pkg/plugins/policies/core/rules/rules.go for graph operations, so no new dependencies needed.

Haven't started implementation yet.