Open Stack

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.