Re-enable the authorizer webhook by default.

[renormalize]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

The authorizer webhook was disabled by default due to a potential regression observed around the second alpha release in #223.

However, I have been unable to replicate this issue since, and would like to re-enable it by default. It being enabled by default will also help us in catching any potential bugs before the next release as all new PRs will indirectly check the behavior of the authorizer webhook, along with the E2E tests.

Does this PR introduce a API change?

N/A

Additional documentation e.g., enhancement proposals, usage docs, etc.:

N/A

[Ronkahn21]

LGTM

[unmarshall]

@renormalize you are unable to see the problem because we never print the admission denied error and the response from the webhook is not captured as part of the log.

After i explicitly added a log the error is now visible:

{"level":"info","ts":"2026-01-25T12:05:14.549Z","logger":"authorizer-webhook.authorizer-webhook","msg":"create/update of managed resource denied","user":"system:admin","operation":"UPDATE","resource":{"group":"grove.io","version":"v1alpha1","resource":"podcliquescalinggroups"},"subresource":"","name":"workload2-0-sg-x","namespace":"default","resourceObjectKey":{"name":"workload2-0-sg-x","namespace":"default"}}

There seems to be a system:admin user which is attempting to update PCSG resources. It could be that this user comes from k3d. Need to check further. I also do not know what it is trying to update. Will debug further.

Only for testing, when i added system:admin as one of the allowed service accounts in the Grove operator configuration, then the test succeeded. However this should never be done since system:admin is the user in the kubeconfig that is created/used by k3d. This should be part of the test setup.