HTTP/2 over UDS: Secrets-Store CSI driver sends “:authority” as the socket path instead of “localhost”

[saarofek-msft]

What steps did you take and what happened:

1. Implemented a custom Secrets-Store CSI provider in ASP.NET Core (.NET 8, gRPC) and exposed it via a Unix-domain socket (e.g. /var/run/credprovider/credprovider.sock).
2. Deployed the provider sidecar next to kubernetes-sigs/secrets-store-csi-driver (driver image v1.5.0) in a Kubernetes cluster (v1.30).
3. Printed the gRPC and http/2.0 traffic from the ASP.NET Core prgoram and saw that the driver sends
   :authority: /var/run/credprovider/credprovider.sock
   (the socket path, not a host).
4. ASP.NET Core rejects the request with “Request malformed: invalid host/authority header value” and resets the stream.

What did you expect to happen:
The driver should by default set
:authority: localhost
(or leave allow some flag to override this behavior) when talking over a UDS, matching common practice for HTTP/2+gRPC on Unix sockets.

Anything else you would like to add:

• Spec references

  • RFC 9113 § 8.3.1 – :authority must be the authority portion of the target URI (host[:port]), never a path.
  • RFC 3986 § 3.2 – authority = [ userinfo "@" ] host [ ":" port ]; again, it is never a path that begins with “/”.

• UDS conventions

  • Many HTTP/2 implementations (nghttpx, Node.js) and the gRPC docs default the :authority header to localhost when using UDS.
  • ASP.NET Core enforces strict host/authority validation and this behavior is not configurable (see Consider allowing a user to disable Host header validation dotnet/aspnetcore#18522).

• Impact

  • Any non-Go provider implemented with a stack that follows the spec (e.g., ASP.NET Core, Java Netty, etc.) cannot interoperate without an additional proxy layer rewriting the header.

Which provider are you using:
Custom .NET 8 gRPC provider (not one of the existing Go providers).

Environment:

• Secrets Store CSI Driver version: v1.5.0
• Kubernetes version:

$ kubectl version
Client Version: v1.32.0
Kustomize Version: v5.5.0
Server Version: v1.31.8-gke.1045000

Thanks a lot in advance!

[k8s-ci-robot]

This issue is currently awaiting triage.

If secrets-store-csi-driver contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.