Open Stack

On 11/21/2013 03:08 PM, 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.

I'm ok with it.

I would, however, like to suggest that we work to make the KDS as a 
seperatly runnable service, so that you don't need to run the rest of 
Barbican to get it.   Barbican was originally envisioned as a 
customer/outward facing project, and KDS is internal (primarily), they 
should be runnable at the same time, without getting confused about 
which service they belong in.  Thus, While I would be OK with KDS under 
the Barbican/CloudKeep program, it might not make sense to bundle it 
with the Barbican server.  Using Barbican as a way to bootstrap the 
deployment for the short term is probably OK, though.




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