Fixes #31878: Turn on Qpid auth and set ACLs to the router certificat… #384
Conversation
ehelms
force-pushed
the
fixes-31878
branch
2 times, most recently
from
a54b52b to
0d8c628
Compare
| acl allow katello_agent@QPID publish exchange name=qmf.default.direct | ||
| acl allow katello_agent@QPID access method name=create | ||
| # allow the actions needed by qpid_router_katello_agent | ||
| acl allow qpid_router_katello_agent@QPID create queue |
There was a problem hiding this comment.
It wasn't possible to use the same certificates with the right CN?
There was a problem hiding this comment.
If we use certificates with a CN of the FQDN for both katello -> qpid and qpid-dispatch -> qpid then we end up having to ensure the ACLs handle both ends of the connection and we potentially elevate qpid-dispatch. Further, when you do debugging you have a hard time deciphering which connection is which.
For example with this update:
connection cproc cpid mech auth connected idle msgIn msgOut
=========================================================================================================================================================
qpid.[::1]:5671-[::1]:35360 - EXTERNAL qpid_router_katello_agent@QPID 6s 4s 0 0
qpid.[::1]:5671-[::1]:35364 - EXTERNAL pipe-katello-server-nightly-centos7.wareagle.example.com@QPID 2s 0s 0 0
qpid.[::1]:5671-[::1]:35366 qpid-stat 26105 ANONYMOUS anonymous@QPID 0s 0s 1 0
There was a problem hiding this comment.
I still think we should use a variable instead of hardcoding qpid_router_katello_agent. Even if we hardcode the value in Puppet code, it is useful to know that it's the common name on the cert. If you use $common_name, I think it's easier to understand.
There was a problem hiding this comment.
Well common_name is how we are using it in this instance. This could just as easily be a username how we previously were defining it. The point is more that if a user with this name connects, it needs to have these restricted ACLs. If we change this to common_name and switch back to username and password we are now having to re-update this code. The only reason we chose to update this from katello_agent to qpid_router_katello_agent was to draw the distinction that we expect the qpid router to connect and not katello-agent directly.
I think we should just leave this as is and do any potential clean up or specification when we tackle having qpid infra off by default because I think that will likely result in moving this qpid setup code closer to the dispatch code.
There was a problem hiding this comment.
ACK'ing based on @jturel's approval and the need to unblock the pipeline
…es CN