Expose gRPC API over TCP?

[ernoaapa]

I'm planning to create client what connects to containerd over tcp.

Is there any reason why containerd supports only socket file connection?
There might be good reason for this (for instance security) and happy to hear that. I can implement TCP support and provide pull request, but want to first stop by and ask is this something what you don't want to implement for good reason.

[dmcgowan]

The reason is security and configuration. The goal of containerd is to be a simple primitive that is used by other services and container runtimes. Having the containerd API exposed over TCP would be the responsibility of a privileged service which proxied to the containerd socket and had the responsibility for authenticating and securing the TCP connection. We could also envision services which may expose the containerd API over TCP with more limited access to the API than what the containerd socket exposes.

It is best to think of the containerd API as exposed by the daemon as providing full access to the system and kernel. All the services on top of that are responsible for securing access to that API. We don't plan on providing access to the API except by privileged system users.

[alculquicondor]

Does this decision still hold?
You could have an scenario where:

• processes running in the machine and remote clients are trusted
• the extra TCP/socket hop is undesired.

Tthe security decision could be up to the user.

[crosbymichael]

@alculquicondor for the containerd sock it does not make sense to be over tcp. we expect clients using containerd to be root and containerd is designed around a smart client where they need to be on the same machine. The containerd api over tcp is trivial but you will lose the majority of the functionality being on separate machines.

[alculquicondor]

Makes sense. #3162 should be enough for our needs. I missed that PR when I posted.