[Pulp-list] Issuing API commands to CDS

[Stephen Benjamin]

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

On CDS:
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?



- Steve



----- Original Message -----
> From: "Stephen Benjamin" <stbenjam at redhat.com>
> To: pulp-list at redhat.com
> Sent: Friday, February 24, 2012 2:24:42 PM
> Subject: [Pulp-list] Issuing API commands to CDS
> 
> Hi,
> 
> 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
> </Proxy>
> 
> <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
> </Location>
> 
> 
> 
> - Steve
> 
> 
> 
> --
> Stephen Benjamin
> Red Hat GmbH
> http://europe.redhat.com/
> Mobile:+49(0)173-728-5703
> 
> 
> 
> ______________________________________________________
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list
>