What happened?
When using crossplane render with context handling enabled, the Docker render engine rejects any DOCKER_HOST value that is not unix://.
The relevant check appears to be:
|
func (e *dockerRenderEngine) CheckContextSupport() error { |
if host := os.Getenv("DOCKER_HOST"); host != "" && !strings.HasPrefix(host, "unix://") {
return errors.New("context handling via --context-values/--context-files/--include-context requires a local Docker daemon or Crossplane controller binary")
}This produces a false negative for Docker setups where the local Docker daemon is exposed over TCP.
In my environment, I run WSL on Windows and work inside a dev container. The dev container reaches the WSL Docker daemon via:
DOCKER_HOST=tcp://host.docker.internal:2375
The Docker daemon itself is configured with both Unix socket and TCP listeners:
{
"hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]
}The Docker socket is not mounted into the dev container for security reasons. As I understand it, avoiding a Docker socket mount is a common security measure in dev container and CI environments, where the Docker client may instead talk to a daemon over TCP.
Based on the original commit, this limitation was introduced to ensure the CLI-hosted context function is reachable by the render container. But maybe this can be solved by the new --crossplane-docker-network flag from #65?
3f282d1
Would it make sense to replace the DOCKER_HOST protocol check with a capability check for whether the render container can reach the CLI-hosted context function, or just to support a TCP transport and let the user configure docker-networking with the --crossplane-docker-network flag?
How can we reproduce it?
Run crossplane render with context handling enabled from an environment where Docker is accessed over TCP, for example a dev container that talks to the host Docker daemon:
export DOCKER_HOST=tcp://host.docker.internal:2375
crossplane render <xr.yaml> <composition.yaml> <functions.yaml> --context-values example='{"foo":"bar"}'The command fails during the context support check with:
context handling via --context-values/--context-files/--include-context requires a local Docker daemon or Crossplane controller binary
What environment did it happen in?
- Crossplane CLI version: v2.3.x
- Platform: linux/amd64
- Environment: dev container running in Docker, with Docker daemon running in WSL2 on Windows
- Docker client endpoint:
DOCKER_HOST=tcp://host.docker.internal:2375
- Docker Engine version: 29.5.3
- Kernel:
Linux devbox 6.6.114.1-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Mon Dec 1 20:46:23 UTC 2025 x86_64 GNU/Linux
What happened?
When using
crossplane renderwith context handling enabled, the Docker render engine rejects anyDOCKER_HOSTvalue that is notunix://.The relevant check appears to be:
cli/cmd/crossplane/render/engine_docker.go
Line 70 in b869d00
This produces a false negative for Docker setups where the local Docker daemon is exposed over TCP.
In my environment, I run WSL on Windows and work inside a dev container. The dev container reaches the WSL Docker daemon via:
The Docker daemon itself is configured with both Unix socket and TCP listeners:
{ "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"] }The Docker socket is not mounted into the dev container for security reasons. As I understand it, avoiding a Docker socket mount is a common security measure in dev container and CI environments, where the Docker client may instead talk to a daemon over TCP.
Based on the original commit, this limitation was introduced to ensure the CLI-hosted context function is reachable by the render container. But maybe this can be solved by the new
--crossplane-docker-networkflag from #65?3f282d1
Would it make sense to replace the
DOCKER_HOSTprotocol check with a capability check for whether the render container can reach the CLI-hosted context function, or just to support a TCP transport and let the user configure docker-networking with the --crossplane-docker-network flag?How can we reproduce it?
Run
crossplane renderwith context handling enabled from an environment where Docker is accessed over TCP, for example a dev container that talks to the host Docker daemon:The command fails during the context support check with:
What environment did it happen in?
DOCKER_HOST=tcp://host.docker.internal:2375Linux devbox 6.6.114.1-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Mon Dec 1 20:46:23 UTC 2025 x86_64 GNU/Linux