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

Reply via email to