Open Stack

On 11/21/13, 7:51 PM, "Jamie Lennox" <jamielennox at redhat.com> wrote:


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

Why would there be a need for token less authentication? My understanding
of the feature is that each service account would have a KDS key
associated with it. This means that each account would need to
authenticate to Keystone before talking to Barbican. Are there service
accounts that don’t have a keystone account?

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

We certainly could enable this if needed. We already create separate uwsgi
processes for the main and admin apis. We could create another one for the
KDS. I’d rather not do that unless we have to though.


Jarret



>
>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.ht
>>>ml
>> >[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
>
>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev