1. Confirm Impersonation Headers in Audit Logs Inspect the API server / Rancher audit logs to see if the request is being converted into an impersonated call: Bash kubectl -n cattle-system logs -l app=rancher -c rancher --tail=1000 | grep -i "impersonate" Look for lines where Rancher injects Impersonate-User: u-xxxx or Impersonate-Group: system:authenticated into the watch call for ext.cattle.io/v1/tokens. 2. Compare RBAC Evaluation Time The 60s response could be a combination of impersonation + heavy RBAC evaluation for tokens. When you use a Service Account (often bound to cluster-admin), RBAC evaluation is instantaneous. When you go through Rancher: Rancher evaluates global subject access reviews (SAR) for every single token object in the list/watch stream. Test if granting your Rancher user explicit cluster-admin permissions removes the 60s delay: Temporarily elevate your Rancher user's global role to Administrator. Run the kubectl get --raw ... command through Rancher again. If it now responds immediately: The issue is driven by expensive Subject Access Review (SAR) checks on token watch streams when Rancher evaluates non-admin impersonation contexts. 3. Check for Rancher Auth Proxy Context Timeouts If this is happening even for Admin users through Rancher, it is a known behavior in Rancher's HTTP auth proxy (steve / norman) where impersonated watch requests that don't receive immediate bookmark/delta events hit an internal 60s context deadline in wrap.go or handler.go. To verify this directly in Rancher's logs, trigger the call and watch for context cancellations: Bash kubectl -n cattle-system logs -l app=rancher -c rancher -f | grep -E "wrap.go|Timeout or abort" You will likely see: Plaintext E0401 10:38:45.356217 39 wrap.go:53] "Timeout or abort while handling" method="GET" URI="/apis/ext.cattle.io/v1/tokens?allowWatchBookmarks=true..." This log confirms the proxy layer killed the impersonated watch stream after exactly 60s because no watch bookmark was returned by Steve to reset the proxy's idle timer.