added missing destination rbac rule for statefulsets

[farhanramzan799]

What is the issue?
When using Linkerd (Edge build 2025.10.*), the linkerd-destination component logs repeated warnings such as:

failed to retrieve resource from direct API call apps/v1, Kind=StatefulSet/: statefulsets.apps "" is forbidden:
User "system:serviceaccount:linkerd:linkerd-destination" cannot get resource "statefulsets" in API group "apps" in the namespace ""

This occurs for multiple workloads using StatefulSets (e.g., Elasticsearch, Redis, RabbitMQ).
The issue seems to stem from missing RBAC permissions for statefulsets in the linkerd-destination ClusterRole.

How can it be reproduced?
Deploy Linkerd Edge build 2025.10.2 (including CRDs and control plane).

Deploy workloads that use StatefulSets (for example, Redis or Elasticsearch).

Observe linkerd-destination logs in the linkerd namespace:
kubectl logs -n linkerd deploy/linkerd-destination

You’ll see permission errors similar to:

failed to retrieve resource from direct API call apps/v1, Kind=StatefulSet/... is forbidden

Logs, error output, etc
level=warning msg="failed to retrieve resource from direct API call apps/v1, Kind=StatefulSet/elastic-system/elasticsearch-es-default: statefulsets.apps "elasticsearch-es-default" is forbidden: User "system:serviceaccount:linkerd:linkerd-destination" cannot get resource "statefulsets" in API group "apps" in the namespace "elastic-system""

Image
output of linkerd check -o short
Image
Environment
Linkerd version: edge-2025.10.2

Possible solution
Add missing RBAC permissions for StatefulSets to the linkerd-destination ClusterRole:

apiGroups: ["apps"]
resources: ["replicasets", "statefulsets"]
verbs: ["list", "get", "watch"]

[sfleen]

Thanks for taking the time to create this PR @farhanramzan79!

Ideally, we'd prefer to not expand our RBAC scope, and the behavior you're seeing where we start trying to read StatefulSets from the k8s API was inadvertently introduced by #14578 in edge-25.10.2 and later rolled back in edge-25.10.3.

I'm planning on reintroducing a PR similar to #14578 that doesn't require additional RBAC rules, so this PR is will unfortunately not be necessary.

I'm going to go ahead and close this, but thank you again for the contribution!