Proposal: Implement Docker and Kubectl remote connectors in addition to SSH

[xeoneox]

I'm finding myself less in need of ssh connections nowadays and more in need of a Docker or Kubectl pod connection. Ansible has this capability, at least with Docker. I envision instead of just --local, a --docker, or --kube switch. The kube one would need more info on pod + container to connect with (my use case is kata containers). It'd be great to have something simpler than Ansible for this job. Kubectl has most of the necessities and a plugin system to extend it.

[xeoneox]

How about an aws_ssm and buildah connector as well.

[xeoneox]

I think SSM is a reasonable place to start. If this looks good, I'll work on integrated Teleport, or docker/podman later.

[umputun]

re: the SSM bit - which mode are you thinking? AWS uses one name for two different things:

• Session Manager tunnels SSH through AWS. The existing *ssh.Client path in pkg/executor/connector.go plugs in mostly unchanged, just a different transport.
• RunCommand API is request/response. No streaming, no SFTP, no agent forwarding. That's a separate execution model and would need its own executor.Interface impl plus a different file-transfer story (aws s3 cp or similar).

the boundary that currently locks everything to SSH is runner.Connector in pkg/runner/runner.go:50-52. It returns *executor.Remote (concrete, holds *ssh.Client) rather than executor.Interface. For Session Manager that's fine, for RunCommand it's not, and for docker/kubectl/buildah it definitely isn't, those need their own executor.Interface impl.

before you start: which SSM mode, and is refactoring Connector.Connect to return executor.Interface part of the plan or out of scope?

[xeoneox]

The Session Manager. Yes, I plan on having a new connector to the executor interface.