open-policy-agent/gatekeeper

Parent issue: #3964 Behavior gaps: #4770, #4771 Dependency cleanup: #4772, #4773, #4774, #4775 Describe the solution you'd like Add a focused, table-driven test suite that verifies Gatekeeper's controller and dependency plan for every independently selectable --operation value. pkg/operations/operations_test.go currently verifies only flag parsing. There is no test that exercises setupControllers or an equivalent wiring plan for isolated operations. As a result, these contradictory paths were not detected: status causes constraint-client initialization but supplies no enforcement point. generate owns CRD/VAP/VAPB behavior but does not start the ConstraintTemplate/Constraint reconcilers. Non-mutation and feature-disabled processes still receive several unused systems and runnables. Suggested scope: Extract the smallest pure/testable operation-to-capability plan needed by setupControllers, or add injectable dependency factories that let tests observe actual construction and registrati

Parent issue: #3964 Related operation cleanup: #4051 Related focused tasks: #4770, #4771, #4772, #4773 Describe the solution you'd like Gatekeeper should initialize the watch manager, cache manager, sync controller, and expectations pruner only for operations that require validation data synchronization. Today setupControllers always creates the cache-manager registrar, sync metrics cache, cache manager, and expectations pruner. controller.AddToManager always registers the cache manager runnable and sync controller. The Config controller also always starts and requires the cache manager. #4423 made this stack tolerate a missing constraint client by installing a no-op CFDataClient. That was necessary for the mutation-webhook startup fix, but it leaves mutation-only and unrelated operation pods carrying validation data-sync infrastructure they do not use. The Config resource has two different responsibilities that need separate dependency decisions: Updating process exclusions used by a

Parent issue: #3964 Describe the solution you'd like Gatekeeper should construct and inject the violation export system only when --enable-violation-export=true. setupControllers currently calls export.NewSystem() for every operation set. The export connection controller already skips registration when export is disabled, and the audit manager only publishes when the flag is enabled, so the default-disabled case carries an unused dependency. This task should remain feature-gated rather than assuming that the export connection controller must share a particular operation pod. Suggested scope: Construct export.System only when violation export is enabled. Register and inject the export dependency only into enabled consumers. Keep the audit publishing and Connection reconciliation paths working when export is enabled. Fail clearly during setup if export is enabled but a required export dependency is absent; do not silently skip requested functionality. Acceptance criteria: With violati

Parent issue: #3964 Related operation cleanup: #4051 Describe the solution you'd like Generator-resource expansion dependencies and controllers should run only in processes that consume expansion behavior. setupControllers currently constructs expansion.System for every operation set. The ExpansionTemplate controller checks only --enable-generator-resource-expansion, which defaults to true, so it can also be registered in status-only, generate-only, and other processes that do not evaluate admission or audit resources. The active expansion consumers are the validating webhook and audit paths. Status aggregation for ExpansionTemplates is a separate concern and should not require the expansion ingestion/evaluation system. Suggested scope: Define an explicit predicate for operations that evaluate expanded resources (webhook and audit). Register the ExpansionTemplate ingestion controller only when expansion is enabled and one of those consumers is assigned. Construct/inject expansion.Syst

Parent issue: #3964 Related operation cleanup: #4051 Describe the solution you'd like Gatekeeper should construct and inject the mutation system only when a mutation operation is assigned. Today setupControllers always calls mutation.NewSystem(...). In addition, pkg/controller/mutators/instances.Adder.Add creates conflict-routing channels and registers the routeConflictEvents runnable before the individual mutator controllers check mutation.Enabled(). A status-only, generate-only, or other non-mutation process therefore receives an unused mutation system and runnable. Use mutation.Enabled() (or an equivalent single source of truth) to align construction and controller registration with these operations: mutation-webhook mutation-controller mutation-status (which documents mutation-controller as implicit) Workload expansion must remain correct. expansion.System already supports a nil mutation system and should apply mutators to generated resources only when a mutation-controller opera