Remove wildcard permissions from knative-serving-core ClusterRole

[wiz-abhi]

Fixes #16599

Proposed Changes

• Replace * wildcards in knative-serving-core ClusterRole with explicit resource lists for Knative-owned API groups
• Expand resources for serving.knative.dev, autoscaling.internal.knative.dev, and networking.internal.knative.dev apiGroups to include all CRDs and their /status and /finalizers subresources
• Preserve apiGroups: ["*"] / resources: ["*/scale"] rule to maintain multi-type workload scaling support added in use the /scale subresource to when updating replica count #16540

Release Note

NONE

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: wiz-abhi / name: Wiz Abhi (b320fb2)

[knative-prow]

Welcome @wiz-abhi! It looks like this is your first PR to knative/serving 🎉

[knative-prow]

Hi @wiz-abhi. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: wiz-abhi
Once this PR has been reviewed and has the lgtm label, please assign dprotaso for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[linkvt]

We recently allowed scaling other resources besides deployments that expose the scale API, see #16540

Considering this and that the proposed change above only changes permissions for knative's own CRDs I personally don't see a benefit in this change and don't consider this a security improvement.

Will need to wait for feedback from a maintainer though.

[wiz-abhi]

Thanks for the review — good catch on #16540. You're absolutely right that changing apiGroups: [""] / resources: ["/scale"] to deployments/scale would regress the multi-type workload scaling support added there. I'll revert that part.
For the Knative-owned API groups, my intent was least-privilege hardening (avoiding * to prevent automatic access to future CRDs/subresources in those groups), but I agree the immediate practical security gain may be limited.
I'd like maintainer guidance on policy here:

1. Keep wildcard for Knative API groups (lower maintenance), or
2. Use explicit resource lists for stricter RBAC posture (with ongoing maintenance cost).
   I'm happy to align either way and update/close this PR accordingly.