Add class to handle creation of certs for advisor service on localhost #474
Conversation
| @@ -0,0 +1,64 @@ | |||
| # Contains certs specific configurations for advisor | |||
| class certs::iop_advisor_engine ( | |||
| Stdlib::Fqdn $hostname = 'localhost', | |||
There was a problem hiding this comment.
I don't like certificates for localhost. I know we have it for candlepin, but is there a way we can avoid this?
There was a problem hiding this comment.
I think it's conceptually the same problem as with candlepin: we run the service on localhost only so it's not reachable via the network (without us having to manage a firewall), but that means that the cert if it should validate be for localhost.
There was a problem hiding this comment.
We can not use SSL? :) What would you propose?
There was a problem hiding this comment.
I guess the only reasonable no-SSL answer are unix sockets, but I am not sure I want to dive into that direction with containers just yet
(plus, that breaks on multi-node deployments, but so does localhost 🤷 )
There was a problem hiding this comment.
I do think plain text http on localhost is fine (probably also for candlepin) if you don't use client certs. You want to be sure for multi-host TLS is supported in the client libs, but that's usually not hard
There was a problem hiding this comment.
We opted for this route for consistency with our Candlepin deployment model. And to give the option to move off localhost if we ever needed to. I am wondering if we should stick with consistency here, and aim for changing how we handle localhost services in our container deployment.
There was a problem hiding this comment.
@ekohl would you be OK with this as-is for now, so we have it at least working, and then re-consider when coming closer to a real release?
|
Ignore AlmaLinux failures, dropping EL8 here -- #475 |
Signed-off-by: Eric D. Helms <ericdhelms@gmail.com>
No description provided.