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
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
