[openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
ayoung at redhat.com
Fri Nov 22 01:35:54 UTC 2013
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.
> On 11/21/13, 12:55 AM, "Russell Bryant" <rbryant at redhat.com> wrote:
>> I'd like to check in on the status of this API addition:
>> 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 .
>> This is blocking one of the most important security features for
>> OpenStack, IMO (trusted messaging) . 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
>> - 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?
>>  https://review.openstack.org/#/c/37913/
>> Russell Bryant
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev