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

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

This sort of functionality is definitely on our radar, we just haven't gotten time to do it yet. It's a use case we want to hit for exactly the reasons you describe: security and routing issues.

You're also dead on about the man-in-the-middle attack. I'm impressed, most people don't see that. I think when we get to it we'll design something that allows for it. We'll need to still track which consumer a request is coming from for various reasons, but that can be solved by having the CDS extract the consumer identity and including it across its own secure pipe to the server.

Unfortunately, I can't really say when we'll be getting to this. It's not as soon as 2-3 months but it's also probably within the year, but don't quote me on that.

On 02/24/2012 08:24 AM, Stephen Benjamin wrote:

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

Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org

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