Open Stack

On Thu, Nov 21, 2013 at 2:08 PM, Jarret Raim <jarret.raim at rackspace.com>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.
>

++ I'd like to help make this happen over the next milestone (it's a bit
late to see significant traction here in icehouse-m1). I've *just* started
porting small bits of the proposed implementation over to barbican here:

  https://review.openstack.org/#/c/57787/

I'll do what I can here, but if anyone has the cycles to pick this up and
run with it, please do!


>
>
>
>
> 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?
>

As ayoung mentioned, this was just the result of a couple hallway
meetings-- there weren't any hard conclusions made, but the gist is that
key distribution falls outside of keystone's current scope but deserves
first class development attention. The reference to "stackforge" was
intentionally non-specific on my part, as we had discussed both a
standalone key distribution service or including it with barbican. After
discussing it with the barbican team post-summit, I'm confident that
they're the right team to maintain it and it's the best long term decision.


>  >
> >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
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131121/0ef17240/attachment.html>