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" <rbry...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
