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 > 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev