Add remote support for SSH and TLS docker contexts

[einyx]

This PR extends the existing remote Docker context support to handle TLS-secured Docker daemons, enabling minikube to work with both SSH and TLS remote Docker contexts.

1. TLS Certificate Management (pkg/drivers/kic/oci/context.go):

   • Loads TLS certificates from Docker's context store
   • Creates temporary directories with proper permissions (0600) for certificate files
   • Manages certificate lifecycle with automatic cleanup on exit

2. Connection Routing (pkg/drivers/kic/kic.go):

   • SSH contexts use localhost (tunneled connection)
   • TLS contexts use the actual remote host address

3. Environment Configuration:

   • Sets DOCKER_TLS_VERIFY=1 and DOCKER_CERT_PATH for TLS contexts
   • Maintains compatibility with existing SSH tunnel behavior

Testing:

• Tested with SSH Docker contexts
• Tested with TLS-secured Docker daemons on remote Linux hosts
• Verified certificate cleanup on minikube exit
• Cross-platform testing: macOS (ARM64) → Linux (x86_64) with TLS

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: medyagh / name: Medya Ghazizadeh (0483850)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: einyx
Once this PR has been reviewed and has the lgtm label, please assign spowelljr for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @einyx!

It looks like this is your first PR to kubernetes/minikube 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/minikube has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @einyx. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[minikube-bot]

Can one of the admins verify this patch?

[medyagh]

@einyx interessting PR ! I am curious do you mind sharing what are your use cases, why did you think about using a remote context ?

[einyx]

Hi @medyagh!

The motivation here is that selfishly I frequently work across multiple machines,
mostly a decent Linux workstation and a more modests Mac Mini and Macbook.

Since my Linux workstation has significantly more resources (CPU, RAM, etc.),
I use it as a remote docker host for resource-intensive builds, distcc and generally for compute.

Use cases this enables:

• Developers on lightweight laptops can provision minikube clusters on more powerful remote machines
• Teams can share development infrastructure while maintaining isolated minikube environments
• I use Terraform to interact with minikube, which this makes even more convenient for extra compute

Attached log from latest minikube run over TLS docker context:
log1.txt

Happy to discuss any concerns or alternative approaches!

[einyx]

@medyagh can I help facilitating this? I know this has been mentioned in a few issues before
#13950 #17868 #13303 #15604

[medyagh]

/ok-to-test

[medyagh]

Hi @medyagh!

The motivation here is that selfishly I frequently work across multiple machines, mostly a decent Linux workstation and a more modests Mac Mini and Macbook.

Since my Linux workstation has significantly more resources (CPU, RAM, etc.), I use it as a remote docker host for resource-intensive builds, distcc and generally for compute.

Use cases this enables:

• Developers on lightweight laptops can provision minikube clusters on more powerful remote machines
• Teams can share development infrastructure while maintaining isolated minikube environments
• I use Terraform to interact with minikube, which this makes even more convenient for extra compute

Attached log from latest minikube run over TLS docker context: log1.txt

Happy to discuss any concerns or alternative approaches!

thank you that makes sense ! I am curious have you tried it on only mac ? does it also work on linux to linux or windows to linux ?

if this opens any "remote listening" on minikube vm ?

[einyx]

/retest

[k8s-ci-robot]

The following users are mentioned in OWNERS file(s) but are untrusted for the following reasons. One way to make the user trusted is to add them as members of the kubernetes org. You can then trigger verification by writing /verify-owners in a comment.

• nirs
  • User is not a member of the org. Satisfy at least one of these conditions to make the user trusted.

[einyx]

Hi @medyagh!
The motivation here is that selfishly I frequently work across multiple machines, mostly a decent Linux workstation and a more modests Mac Mini and Macbook.
Since my Linux workstation has significantly more resources (CPU, RAM, etc.), I use it as a remote docker host for resource-intensive builds, distcc and generally for compute.
Use cases this enables:

• Developers on lightweight laptops can provision minikube clusters on more powerful remote machines
• Teams can share development infrastructure while maintaining isolated minikube environments
• I use Terraform to interact with minikube, which this makes even more convenient for extra compute

Attached log from latest minikube run over TLS docker context: log1.txt
Happy to discuss any concerns or alternative approaches!

thank you that makes sense ! I am curious have you tried it on only mac ? does it also work on linux to linux or windows to linux ?

if this opens any "remote listening" on minikube vm ?

Hi @medyagh!

Currently yes,
When using remote Docker contexts or external Docker hosts, it configures the remote to listen on 0.0.0.0 (as I use multiple interface I found this useful) how would you approach the selection here for the user otherwise?

This is explicitly warned about in the code with a user-visible warning only when a remote context is detected:

"Listening to 0.0.0.0 on {{.host}}. Please be advised"

We could potentially add a detection mechanism for the remote docker daemon or let the user decide with a flag

I personally don't like the SSH implementation for production use, is something I did initially for easy of use and is nice to have, maybe, but I am happy to amend as you see fit, admittedly TLS is much more solid and performant for this so I stopped using the SSH remote context myself after a while.

Can test this on a vm and get back to you soon.

Cheers!