[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Issuing API commands to CDS

On 02/24/2012 08:14 AM, Stephen Benjamin wrote:
Also to make this work I installed qpid-server and qpid-tools on the CDS, and linked them and shared the heartbeat topic:

On Server:
qpid-route link add pulp-server.example.com pulp-cds.example.com --durable
qpid-route dynamic add pulp-server.example.com pulp-cds.example.com heartbeat --durable

qpid-route link add pulp-cds.example.com pulp-server.example.com --durable
qpid-route dynamic add pulp-cds.example.com pulp-server.example.com heartbeat --durable

Should any other topics be shared?  And perhaps there's a better way to setup the qpidd on the CDS?

I've looked into setting federated brokers but not in enough depth to provide much help here. The heartbeat is the only /topic/ but /queues/ will need to be routed as well. I know of a user that maintains a federated broker network. I'll get with them or someone on the QPID team and get back with you.

- Steve

----- Original Message -----
From: "Stephen Benjamin"<stbenjam redhat com>
To: pulp-list redhat com
Sent: Friday, February 24, 2012 2:24:42 PM
Subject: [Pulp-list] Issuing API commands to CDS


I have a situation where the clients can only talk to the CDS in the
datacenter, not the pulp server itself.  It seems like a good idea
that consumers could issue commands to the API instead of the CDS
(like rhnproxy can accept API requests).

Now I have it working to the CDS when you authenticate with with
pulp-consumer (pulp-consumer -u blah -p blah consumer history) since
that bypasses client certificate authentication, but I'd like to be
able to use the certificate.  Of course passing the client
authentication would be difficult or impossible, since it's
effectively a man-in-the-middle attack.

I was thinking that maybe something like this would work:

         API call, auth to cds w/ client cert        forwards api
         call, auth to pulp w/ cds ubercertificate
[consumer] -------------------------------->  [cds]
-------------------------------------------------------->  [pulp]

If this were possible, then I guess a consumer could issue basically
any command to pulp.  This does work for our needs, though.  Would
this be possible today, for the cds to have it's own client
certificate w/ more permissions?

A complete solution would have the cds only let consumers issue
commands for their own hostname I guess.  Here's my
/etc/httpd/conf.d/pulp-api.conf on my CDS, working w/
username/password authentication:

SSLProxyEngine on
ProxyRequests On

<Proxy *>
         Order deny,allow
         Allow from *.example.com

<Location /pulp/api>
         SSLCACertificateFile /etc/pki/pulp/ca.crt
         SSLVerifyClient optional
         SSLVerifyDepth 2
         SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth

         ProxyPass          https://pulp.example.com/pulp/api
         ProxyPassReverse   https://pulp.example.com/pulp/api

- Steve

Stephen Benjamin
Red Hat GmbH

Reg. Adresse: Rudower Chaussee 29, D-12489 Berlin
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Mark Hegarty,Charlie Peters, Michael Cunningham,
Charles Cachera

Pulp-list mailing list
Pulp-list redhat com

Pulp-list mailing list
Pulp-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]