Skip to content

docker: use native gRPC for supported local endpoints - #4069

Draft
crazy-max wants to merge 1 commit into
docker:masterfrom
crazy-max:docker-native-grpc
Draft

docker: use native gRPC for supported local endpoints#4069
crazy-max wants to merge 1 commit into
docker:masterfrom
crazy-max:docker-native-grpc

Conversation

@crazy-max

@crazy-max crazy-max commented Sep 9, 2026

Copy link
Copy Markdown
Member

Automatically use native gRPC for supported Docker daemons over Unix sockets and named pipes, using the daemon support introduced in moby/moby#50744. Retain the legacy /grpc and /session transport for remote endpoints and daemons without native gRPC support, preserving Docker's existing TLS and SSH handling. Concurrent callers share a bounded capability probe, and failed or canceled probes remain retryable. Explicit authentication and authorization failures are returned without falling back.

Comment thread tests/docker.go Outdated
Comment thread driver/docker/driver.go Outdated
Comment on lines +79 to +81
// Native gRPC bypasses the daemon's HTTP authorization middleware.
// Keep it opt-in until Moby enforces authorization on that path.
enabled, _ := strconv.ParseBool(os.Getenv("BUILDX_DOCKER_NATIVE_GRPC"))

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Native gRPC currently bypasses Moby's authorization plugins. httpHandler.ServeHTTP dispatches gRPC requests directly to the gRPC server or extension proxy, bypassing the HTTP API handler where the authorization middleware is registered. Consequently, these requests do not pass through its AuthZRequest check.

This is why native gRPC remains opt-in here. Moby needs to enforce authorization before dispatching native RPCs, covering both local services and the extension proxy while preserving streaming behavior. Keeping Buildx on the legacy transport by default preserves its existing authorization path, but doesn't prevent other clients from accessing the daemon's native gRPC endpoint.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The /grpc endpoint is deprecated; no need to make it opt-in. Buildx isn't responsible for protecting the API because anything already can do.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the opt-in. I kept the DialMeta guard because Desktop uses X-Docker-Desktop-idle: background on the /grpc upgrade to let Resource Saver distinguish background connections from interactive builds (https://github.com/docker/desktop-build/pull/312). That's separate from Moby's authorization middleware. These clients retain the legacy transport until equivalent native gRPC behavior is supported and verified.

@crazy-max crazy-max changed the title docker: opt-in native gRPC support docker: use native gRPC for supported local endpoints Sep 9, 2026
Automatically probe native gRPC support on Unix sockets and named pipes. Share a bounded probe
across concurrent callers and keep failed or canceled probes retryable.

Retain the legacy transport for remote endpoints and daemons without native gRPC support. Return
explicit authentication and authorization failures without falling back.

Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
@crazy-max
crazy-max marked this pull request as ready for review September 9, 2026 14:44
@crazy-max crazy-max modified the milestone: v0.38.0 Sep 9, 2026
@crazy-max
crazy-max marked this pull request as draft September 10, 2026 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants