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

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



----- Original Message -----
> From: "Jay Dobies" <jason dobies redhat com>
> To: pulp-list redhat com
> Sent: Friday, February 24, 2012 3:12:14 PM
> Subject: 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.

Ok, thanks.  For now, user/password authentication works well enough, although we've been testing this for a few weeks, and the repo management itself 
works pretty well.  This is the piece we'll probably be putting into production.  There's some issues with the client utilities (things like connecting to the pulp-server vs cds, consumergroups not being static, etc) that we'll probably use puppet to manage the pulp.repo file ourselves.

But thanks for all the effort put into this project!  Pulp is great.



> 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
> Pulp-list redhat com
> https://www.redhat.com/mailman/listinfo/pulp-list
> 


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