Clusters like Amazon EKS often use a special authentication binary that is declared in the kubeconfig using an exec authentication strategy. This binary is normally not available inside a container. Consequently, a modified kubeconfig is used when telepresence connect --docker executes, appointing a kubeauth binary which instead retrieves the authentication from a port on the Docker host that communicates with another process outside of Docker. This process then executes the original exec command to retrieve the necessary credentials.
This setup was problematic when using WSL, because even though telepresence connect --docker was executed on a Linux host, the Docker host available from host.docker.internal that the kubeauth connected to was the Windows host running Docker Desktop. The fix for this was to use the local IP of the default route instead of host.docker.internal when running under WSL.
Clusters like Amazon EKS often use a special authentication binary that is declared in the kubeconfig using an
execauthentication strategy. This binary is normally not available inside a container. Consequently, a modified kubeconfig is used whentelepresence connect --dockerexecutes, appointing akubeauthbinary which instead retrieves the authentication from a port on the Docker host that communicates with another process outside of Docker. This process then executes the originalexeccommand to retrieve the necessary credentials.This setup was problematic when using WSL, because even though
telepresence connect --dockerwas executed on a Linux host, the Docker host available fromhost.docker.internalthat thekubeauthconnected to was the Windows host running Docker Desktop. The fix for this was to use the local IP of the default route instead ofhost.docker.internalwhen running under WSL.