Replace Tenant Level Admin with Domain in Keystone
Many of the V2.0 accept any user that has the admin role on any tenant as an overall admin. This is surprising to many people, but also a possible security hole.
We are going to migrate all users with the role 'admin' on a tenant to an admin on the default domain, and remove the check in keystone. The assert_admin calls in keystone will be replaced with policy checks instead.+
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Dolph Mathews
Whiteboard
[edit: Jesse Pretorius 18 Mar 2013]
The way I see this there should be at least three layers of roles:
1) A super-admin role which has access across all domains. This would typically be a support admin who needs to assist tenants with support queries. This role also creates tenants, etc.
2) A tenant-admin role which is allowed to do all things that tenant members can do, which also has the ability to create tenant users and do other tenant-specific support tasks.
3) A tenant-member role which is allowed to do all the typical items like creating instances, uploading (tenant-specific) images, etc.
There could easily be more roles - for example an observer (read-only) at each layer.
[Lin Hua Cheng: Apr 17 2013]
For role #2 and #3, should it be domain-admin that should be able to create projects and users for the domain?
Why do we need tenant-member role? Can't this be achieve by assigning a user to a 'user' role on project scope?
The data migration described above is completely arbitrary and dangerous.
