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!

[saarofek-msft]

Hey! Any update on this perhaps?

[benjaminapetersen]

Reference to a similar KMS v2 issue: https://github.com/kubernetes/kubernetes/pull/126930/files

[benjaminapetersen]

@copilot Open a PR to fix this issue.
Use this PR as a reference in order to fix this issue: https://github.com/kubernetes/kubernetes/pull/126930/files

/assign @copilot

[k8s-ci-robot]

@benjaminapetersen: GitHub didn't allow me to assign the following users: copilot.

Note that only kubernetes-sigs members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

@copilot Open a PR to fix this issue.
Use this PR as a reference in order to fix this issue: https://github.com/kubernetes/kubernetes/pull/126930/files

/assign @copilot

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.

[benjaminapetersen]

Sadness. Wanted Copilot to do this for us. 😄

[benjaminapetersen]

Aha, only admin on the repo can assign Copilot.

[enj]

/triage accepted