[openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

Jamie Lennox jamielennox at redhat.com
Fri Nov 22 01:51:35 UTC 2013


So i've a feeling that this was proposed and dismissed once before. I
don't remember why.

So my concern with barbican is that i'm under the impression that
barbican was going to be an 'overcloud' service. That's a really bad way
of putting it, but it is service and user facing and discovered via the
service catalog. 

This feature will need to be configured at a lower level (runs in
situations without a token) and so we will need to configure the
services to point to an IP for the KDS service. 

Is this an expected deployment of barbican (i can't see why not)?

Jamie

On Thu, 2013-11-21 at 20:08 +0000, Jarret Raim wrote:
> The Barbican team has been taking a look at the KDS feature and the
> proposed patch and I think this may be better placed in Barbican rather
> than Keystone. The patch, from what I can tell, seems to require that a
> service account create & use a key under its own tenant. In this use case,
> Barbican can handle the entire exchange and Keystone can just provide
> auth/auth for the process. This would allow for some great additional
> features including guaranteed entropy and additional security through the
> use of HSMs, auditing / logging, etc.
> 
> Barbican is pretty far along at this point and it doesn¹t appear to be a
> huge amount of work to move the patch over as it doesn¹t seem to use any
> Keystone internals.
> 
> What would people think about this approach? We¹re happy to help move the
> patch over and I¹m certainly happy to merge it as it feels like a good
> feature for barbican.
> 
> 
> 
> 
> Jarret
> 
> 
> 
> 
> 
> 
> On 11/21/13, 12:55 AM, "Russell Bryant" <rbryant at redhat.com> wrote:
> 
> >Greetings,
> >
> >I'd like to check in on the status of this API addition:
> >
> >    https://review.openstack.org/#/c/40692/
> >
> >The last comment is:
> >
> >   "propose against stackforge as discussed at summit?"
> >
> >I don't see a session about this and from a quick look, don't see notes
> >related to it in other session etherpads.
> >
> >When was this discussed?  Can you summarize it?
> >
> >Last I heard, this was just being deferred to be merged early in
> >Icehouse [1].
> >
> >This is blocking one of the most important security features for
> >OpenStack, IMO (trusted messaging) [2].  We've been talking about it for
> >years.  Someone has finally made some real progress on it and I feel
> >like it has been given little to no attention.
> >
> >I'm not thrilled about the prospect of this going into a new project for
> >multiple reasons.
> >
> > - Given the priority and how long this has been dragging out, having to
> >wait for a new project to make its way into OpenStack is not very
> >appealing.
> >
> > - A new project needs to be able to stand on its own legs.  It needs to
> >have a reasonably sized development team to make it sustainable.  Is
> >this big enough for that?
> >
> >What's the thinking on this?
> >
> >[1]
> >http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html
> >[2] https://review.openstack.org/#/c/37913/
> >
> >-- 
> >Russell Bryant
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






More information about the OpenStack-dev mailing list