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:
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
--
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
