Expected Behavior
dapr workflow list/dapr workflow history (and other dapr workflow ... -k sub commands) should succeed against a Kubernetes app whose sidecar has dapr.io/api-token-secret set, when DAPR_API_TOKEN is exported with the correct token value.
Actual Behavior
Every dapr workflow ... -k subcommand fails with:
rpc error: code = Unauthenticated desc = Unauthorized
gRPC debug logging (GRPC_GO_LOG_SEVERITY_LEVEL=info GRPC_GO_LOG_VERBOSITY_LEVEL=2) shows the CLI's internal port-forward to the sidecar's gRPC port succeeds and the channel reaches READY, but the RPC itself is rejected, which points to the dapr-api-token metadata simply not being attached to the outgoing call.
Port-forwarding the sidecar's HTTP port directly and calling /v1.0/workflows/dapr/<instanceId> with the same token as an HTTP header returns 200 OK with full workflow status. So the token is valid, but it seems like the CLI's workflow gRPC client just isn't sending it.
Steps to Reproduce the Problem
- Deploy an app to Kubernetes with Dapr sidecar injection and
dapr.io/api-token-secret: <secret-name> set, on Dapr runtime 1.18.3.
- Start at least one workflow instance.
- From a machine with
kubectl access to the cluster and dapr CLI 1.18.2 installed:
export DAPR_API_TOKEN=$(kubectl -n <ns> get secret <api-token-secret> -o jsonpath='{.data.token}' | base64 -d)
dapr workflow list -a <app-id> -n <ns> -k
# → Unauthenticated: Unauthorized
dapr workflow history <instance-id> -a <app-id> -n <ns> -k
# → Unauthenticated: Unauthorized
- Confirm the token is valid by port-forwarding the sidecar's HTTP port (3500) directly to the pod and calling:
curl -H "dapr-api-token: $DAPR_API_TOKEN" http://localhost:3500/v1.0/workflows/dapr/<instance-id>
# → 200 OK with instance status/history
Release Note
RELEASE NOTE: FIX dapr workflow commands in Kubernetes mode (-k) failing with Unauthenticated against sidecars secured with dapr.io/api-token-secret
Expected Behavior
dapr workflow list/dapr workflow history(and otherdapr workflow ... -ksub commands) should succeed against a Kubernetes app whose sidecar hasdapr.io/api-token-secretset, whenDAPR_API_TOKENis exported with the correct token value.Actual Behavior
Every
dapr workflow ... -ksubcommand fails with:rpc error: code = Unauthenticated desc = UnauthorizedgRPC debug logging (
GRPC_GO_LOG_SEVERITY_LEVEL=info GRPC_GO_LOG_VERBOSITY_LEVEL=2) shows the CLI's internal port-forward to the sidecar's gRPC port succeeds and the channel reachesREADY, but the RPC itself is rejected, which points to thedapr-api-tokenmetadata simply not being attached to the outgoing call.Port-forwarding the sidecar's HTTP port directly and calling
/v1.0/workflows/dapr/<instanceId>with the same token as an HTTP header returns200 OKwith full workflow status. So the token is valid, but it seems like the CLI'sworkflowgRPC client just isn't sending it.Steps to Reproduce the Problem
dapr.io/api-token-secret: <secret-name>set, on Dapr runtime1.18.3.kubectlaccess to the cluster anddaprCLI1.18.2installed:Release Note
RELEASE NOTE: FIX dapr workflow commands in Kubernetes mode (-k) failing with Unauthenticated against sidecars secured with dapr.io/api-token-secret