Support (m)TLS API socket

[meln5674]

Feature request description

Support securely serving the API socket over TCP with TLS and mTLS.

I would like to replace docker with podman in a case where mTLS is required across a network boundary where SSH connections are unacceptable.

While it is possible to proxy the podman socket using e.g. nginx to add TLS on the server side, the remote client has no such capability to consume it. Requiring my end-users to set up a TLS proxy on their local machines is completely out of the question.

Suggest potential solution

Add flags --tls-cert, --tls-key, and --tls-ca to both podman system service and podman system connection add (the latter seems to require changes to https://github.com/containers/common/blob/main/pkg/config/config.go#L690).

Use the Go standard library to both serve and make requests using the provided certificates.

Have you considered any alternatives?

It could be possible to avoid adding new flags (and thus, changing common) by re-using the --identity flag, and requiring the user to provide a single file containing the client certificate chain, client private key, and CA certificate chain, in that order, in a single PEM file. This should be possible using Go's encoding/pem library by detecting when the Type field changes. However, this feel brittle and inelegant, and doesn't provide any way of configuring the server.

Additional context

I am familiar with configuring TLS in Go, and I am happy to implement this change if either design is deemed acceptable.

[Luap99]

I would like to replace docker with podman in a case where mTLS is required across a network boundary where SSH connections are unacceptable.

Can you expand on why ssh is not possible? We prefer using ssh as it doesn't expose the podman socket directly to the network.

I would not object adding TLS support (and adding new flag for that) as long as the code needed for that is simple enough. And if the certificate logic is part of the go standard library then I would assume it is.

But I don't know if there is a history of why we didn't add that so far. I think we always just point users to ssh.

[meln5674]

Can you expand on why ssh is not possible? We prefer using ssh as it doesn't expose the podman socket directly to the network.

We need to have workstations in one network boundary run and build containers in another, and SSH connections are not permitted across this boundary, but HTTPS is. I don't make these rules, I just get to deal with them. We are currently leveraging TLS-protected docker sockets through an mTLS authenticating, re-encrypting proxy as a workaround. We are also looking to, in the future, move this to a setup where SSH is not running at all.

I agree that exposing an unauthenticated socket would be a very poor choice, perhaps it would be worth it to require adding a "yes, I know this is insecure, do as I say" flag/env to allow unauthenticated sockets to run, if that would assuage your concerns.

I would not object adding TLS support (and adding new flag for that) as long as the code needed for that is simple enough.

I worked on a proof of concept yesterday, and I believe I have it working. Currently having issues getting the tests to run, but I will post drafts later today for comment while I sort that out.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[meln5674]

Still working on this.

[skohan]

Hi @meln5674 ,

Have you worked this out yet? We are in similar situation where we need drop in replacement for podman as we are using java-docker-client for communication and don't have time to implement ssh client for now.

[meln5674]

Hi @meln5674 ,

Have you worked this out yet? We are in similar situation where we need drop in replacement for podman as we are using java-docker-client for communication and don't have time to implement ssh client for now.

Still in progress, had to put this on hold for some personal stuff, but should be getting back to it in the next couple of days.

[xinst]

mark on this issue

[froazin]

A decent enough work around for mTLS auth for remote Podman instances is to throw Nginx/Caddy etc on your server to reverse proxy your Podman socket and handle mTLS for you, then stick Stunnel on your client machine to effectively wrap your outbound requests from the Podman CLI to your remote with mTLS :)