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.

This PR also fixes E2E tests and introduces a new dynamic client which creates a bearer token via TokenRequest API using the service account with which Grove operator is started. The authorizer webhook allows calls to change managed resources when it comes from grove service account.

Previous to this PR, user system:admin was making calls to scale-out/in PCLQ/PCSG and with authorizer webhook enabled this will be disallowed as system:admin is not an exempted account. Also we would not like to change the values.yaml to include test users that k3d brings in.

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.

[gflarity]

Thanks for the PR!

A few small things in my comments. I'd like to see the Clientset and hardcoded (valid for 1 hour) fixed if you don't disagree. The printDiff is just a nit. I won't request changes so this doesn't get blocked on me. Ping me for a fast approval after, I'll also chat with @sanjaychatterjee and ask him to approve it I'm not immediately available.