Support (m)TLS API socket #24583
Comments
meln5674
added
the
kind/feature
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. |
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 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. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Still working on this. |
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-cato bothpodman system serviceandpodman 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
--identityflag, 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'sencoding/pemlibrary by detecting when theTypefield 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.
The text was updated successfully, but these errors were encountered: