Open Stack

On 08/23/2014 02:01 AM, Clint Byrum wrote:
> I don't know how Zaqar does its magic, but I'd love to see simple signed
> URLs rather than users/passwords. This would work for Heat as well. That
> way we only have to pass in a single predictably formatted string.
>
> Excerpts from Zane Bitter's message of 2014-08-22 14:35:38 -0700:
>> Here's an interesting fact about Zaqar (the project formerly known as
>> Marconi) that I hadn't thought about before this week: it's probably the
>> first OpenStack project where a major part of the API primarily faces



Nah, this is the direction we are headed.  Service users (out of LDAP!)  are going to be the norm with a recent feature add to Keytone:


http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/


>> software running in the cloud rather than facing the user.
>>
>> That is to say, nobody is going to be sending themselves messages on
>> their laptop, from their laptop, via a cloud. At least one end of any
>> given queue is likely to be on a VM in the cloud.
>>
>> That makes me wonder: how does Zaqar authenticate users who are sending
>> and receiving messages (as opposed to setting up the queues in the first
>> place)? Presumably using Keystone, in which case it will run into a
>> problem we've been struggling with in Heat since the very early days.
>>
>> Keystone is generally a front end for an identity store with a 1:1
>> correspondence between users and actual natural persons. Only the
>> operator can add or remove accounts. This breaks down as soon as you
>> need to authenticate automated services running in the cloud - in
>> particular, you never ever want to store the credentials belonging to an
>> actual natural person in a server in the cloud.
>>
>> Heat has managed to work around this to some extent (for those running
>> the Keystone v3 API) by creating users in a separate domain and more or
>> less doing our own authorisation for them. However, this requires action
>> on the part of the operator, and isn't an option for the end user. I
>> guess Zaqar could do something similar and pass out sets of credentials
>> good only for reading and writing to queues (respectively), but it seems
>> like it would be better if the user could create the keystone accounts
>> and set their own access control rules on the queues.
>>
>> On AWS the very first thing a user does is create a bunch of IAM
>> accounts so that they virtually never have to use the credentials
>> associated with their natural person ever again. There are both user
>> accounts and service accounts - the latter IIUC have
>> automatically-rotating keys. Is there anything like this planned in
>> Keystone? Zaqar is likely only the first (I guess second, if you count
>> Heat) of many services that will need it.
>>
>> I have this irrational fear that somebody is going to tell me that this
>> issue is the reason for the hierarchical-multitenancy idea - fear
>> because that both sounds like it requires intrusive changes in every
>> OpenStack project and fails to solve the problem. I hope somebody will
>> disabuse me of that notion in 3... 2... 1...



>>
>> cheers,
>> Zane.
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev