Description
What is the issue?
I was trying to use linkerd viz tap to debug an internal issue, but kept getting tap authorization failed. After looking at the documentation page in the error message (https://linkerd.io/2.16/tasks/securing-linkerd-tap/), it seemed like the problem might be in Linkerd itself as kubectl can-i works
How can it be reproduced?
I believe this might need an EKS cluster configured with EKS Access Entries for authentication :/
Logs, error output, etc
$ kubectl auth can-i watch deployments.v1alpha1.tap.linkerd.io/[xxx] --namespace [xxx] --subresource tap
yes
$ linkerd viz tap deployment/[xxx] --namespace [xxx]
HTTP error, status Code [403] (unexpected API response: {"error":"tap authorization failed (not authorized to access deployments.tap.linkerd.io), visit https://linkerd.io/tap-rbac for more information"})
output of linkerd check -o short
linkerd-identity
----------------
× trust anchors are using supported crypto algorithm
Invalid trustAnchors:
* 498364598153846236906649535816328601770266843336 One Model Linkerd Root CA must use P-256 curve for public key, instead P-384 was used
see https://linkerd.io/2/checks/#l5d-identity-trustAnchors-use-supported-crypto for hints
linkerd-jaeger
--------------
‼ jaeger extension proxies are up-to-date
some proxies are not running the current version:
* collector-9cb9f47cb-2p4dn (edge-24.10.1)
* collector-9cb9f47cb-s8zg2 (edge-24.10.1)
* jaeger-injector-759b7ff6fb-5xcmz (edge-24.10.1)
* jaeger-injector-759b7ff6fb-q46tg (edge-24.10.1)
see https://linkerd.io/2/checks/#l5d-jaeger-proxy-cp-version for hints
‼ jaeger extension proxies and cli versions match
collector-9cb9f47cb-2p4dn running edge-24.10.1 but cli running edge-24.10.2
see https://linkerd.io/2/checks/#l5d-jaeger-proxy-cli-version for hints
linkerd-viz
-----------
‼ viz extension proxies are up-to-date
some proxies are not running the current version:
* alertmanager-alertmanager-0 (edge-24.10.1)
* metrics-api-fd554c577-8htqz (edge-24.10.1)
* metrics-api-fd554c577-ftj2d (edge-24.10.1)
* prometheus-prometheus-0 (edge-24.10.1)
* tap-5579f7499d-2v4dg (edge-24.10.1)
* tap-5579f7499d-5jf5j (edge-24.10.1)
* tap-5579f7499d-bmdfg (edge-24.10.1)
* tap-injector-5bfbc5b658-fqr7c (edge-24.10.1)
* tap-injector-5bfbc5b658-kvz6s (edge-24.10.1)
* tap-injector-5bfbc5b658-mrlmg (edge-24.10.1)
* web-694c5b64d8-hs76l (edge-24.10.1)
* web-694c5b64d8-kkqtp (edge-24.10.1)
see https://linkerd.io/2/checks/#l5d-viz-proxy-cp-version for hints
‼ viz extension proxies and cli versions match
alertmanager-alertmanager-0 running edge-24.10.1 but cli running edge-24.10.2
see https://linkerd.io/2/checks/#l5d-viz-proxy-cli-version for hints
Status check results are ×
Environment
Kubernetes Version: v1.30
Cluster Environment: AWS EKS
Host OS: Amazon Bottlerocket
Linkerd version: Client version: edge-24.10.2 / Server version: edge-24.10.1
Possible solution
I've made a commit which I will push up in a PR shortly, but I suspect the issue may be because the SubjectAccessReview done by the Tap controller doesn't pass in any of the "extra" user attributes
When looking at the audit logs generated by our Kubernetes control plane and comparing the linkerd viz tap vs. kubectl can-i, I can see that kubectl can-i is passing some additional "extra" fields that seem relevant to the EKS Access Entries authentication.
My commit updates ResourceAuthzForUser in linkerd/pkg/k8s/authz.go to take in the list of extra attributes, retrieved via the X-Remote-Extras- HTTP header
Additional context
No response
Would you like to work on fixing this bug?
yes