devstack should create admin tenant, users for each service, and associated role for each

Bug #942979 reported by Joseph Heck
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
devstack
Fix Released
Undecided
Joseph Heck

Bug Description

within keystone_data.sh:

* devstack should create a tenant named "service"
 * and keystone users for each service enabled in : ['nova', 'glance', 'horizon', 'quantum', 'swift']
 * the script should also assign the role "admin" for each of those users against the tenant "service"

from associated thread on http://etherpad.openstack.org/keystone-admin-config:

devstack should create tenant named "service", and users named "nova", "glance", "quantum", ... (or just a couple and describe that you could create an arbitrary number of users per service deployments)
(termie) sure, "service" or "admin"
(jesse) I'd like to have a name we recommend to deployers/operators to use - and service seems better?(jay) service is good. admins are people... services are, well, services.
(termie) sure, i can get behind that -thrust-
(jesse) then should we use a role "service" or "admin:service" or ?
(jay) For the service role, I think the role should just be "super" or something like that, meaning no restrictions on use. Different from admin in that I view the term "admin" as a role for users, not services.
(termie) well, right now there is only one admin role, so we are going to use that
(jesse) for today ADMIN, for essex should we have a bug to use a different name (thinking of documentation)
(termie) i feel like it is a relatively "new" feature to provide the granular access to things since to now we've only done admin, we could do it but it will require a lot of testing to get correct since it is adding additional permissions that weren't checked before
(jesse) :( we should NOT change it if it adds anything more than a small risk..(jay) agreed, certainly for Essex.
(termie) once i drop policy.py in this mofo i think we can at least experiment with it and if we feel really good about it we could make teh decision
(jesse) eta for drop of policy - e4? (tonight)
(termie) yes, at that point we can experiment with things, but the initial implementation will be no change to current policy (you are an admin or you are a public user)

Joseph Heck (heckj)
Changed in devstack:
status: New → Confirmed
Jay Pipes (jaypipes)
description: updated
Dean Troyer (dtroyer)
Changed in devstack:
assignee: nobody → Dean Troyer (dtroyer)
Revision history for this message
Dean Troyer (dtroyer) wrote :

Mostly addressed in https://review.openstack.org/4668. Is a horizon user necessary? This is the first I've even thought about it. If so, should there be a service entry in keystone for it also?

Revision history for this message
Joseph Heck (heckj) wrote :

Just spoke with Tres - it only acts as the user that is using it, so he's asserting that it doesn't need it at this time. Horizon doesn't (today) act as an actor external to any user, so I'd say we could skip it.

Joseph Heck (heckj)
Changed in devstack:
status: Confirmed → Fix Committed
Revision history for this message
Joseph Heck (heckj) wrote :

Most is done with https://review.openstack.org/4668, just need a Horizon service account.

Changed in devstack:
status: Fix Committed → In Progress
assignee: Dean Troyer (dtroyer) → Joseph Heck (heckj)
Revision history for this message
Tres Henry (tres) wrote :

Actually I have to change that. According to termie's info on account crud (email, password, etc.) I think Horizon actually does need a service admin account. Which sucks because user's should be able to update their own account info – but that's another conversation.

from IRC:

termie> ohnoimdead: at this point no, a user can't update their own password
termie> all crud is admin api only
termie> ohnoimdead: you, obviously could use horizon's admin user to allow it
termie> ohnoimdead: and assume that you've validated the user's identity locally first

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to devstack (master)

Fix proposed to branch: master
Review: https://review.openstack.org/4752

Revision history for this message
Joseph Heck (heckj) wrote :
Revision history for this message
Joseph Heck (heckj) wrote :

After conversation in IRC with Gabe, Tres, Jesse - leaving no service account for dashboard - it will operate always with permissions the user has.

Changed in devstack:
status: In Progress → Fix Committed
Dean Troyer (dtroyer)
Changed in devstack:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.