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

Reply via email to