)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"270f31bbc063029a1cc256105bb6e51ea7439d04","unresolved":false,"context_lines":[{"line_number":7,"context_line":"A common policy scenario across all projects"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"All projects should provide a policy file based around a more rich"},{"line_number":10,"context_line":"scenario than simply is a user the global admin or not."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"Change-Id: I6a0957f9c1437627c6310d36d652b2fb3cb63eb9"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"5a5ae5dd_77626faf","line":10,"range":{"start_line":10,"start_character":20,"end_line":10,"end_character":55},"updated":"2016-02-09 15:43:56.000000000","message":"I think this would be clearer if it was:\n\nsimply: \u0027Is a user the global admin or not?\u0027","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"}],"specs/common-default-policy.rst":[{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"99fb5ac14f3be08e511e89b1e58f916ffc7bd6d7","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Maintaining policy is hard for operators. As a side effect of keystone\u0027s V2"},{"line_number":8,"context_line":"roles and devstack\u0027s default roles most services simply assume a member or"},{"line_number":9,"context_line":"admin priviledge seperation for there service. This is really only sufficient"},{"line_number":10,"context_line":"for the most trivial of deployments."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"As a community we need to develop a simple standard usage policy environment"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_b173fae6","line":9,"updated":"2015-11-17 11:01:41.000000000","message":"their","commit_id":"ea74983d2ae6cec10fd81516d07e05ff68726904"},{"author":{"_account_id":11333,"name":"David J Hu","email":"david.hu@hpe.com","username":"dhu"},"change_message_id":"47d94b6c0a4dcde733e49d06c72f04c1c357029b","unresolved":false,"context_lines":[{"line_number":172,"context_line":"- Create additional roles in devstack for testing."},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"- Modify each individual service to provide a policy file that implements the"},{"line_number":175,"context_line":"  above scenario."},{"line_number":176,"context_line":""},{"line_number":177,"context_line":"- Ensure that horizon (as a consumer of policy files) is capable of correctly"},{"line_number":178,"context_line":"  displaying available actions to users based on a more complex policy."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba8a016a_52f8b0e5","line":175,"updated":"2015-11-16 19:57:30.000000000","message":"... and make this policy file the default!","commit_id":"ea74983d2ae6cec10fd81516d07e05ff68726904"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"2ab8a5e81ac5af671faf7e96e48d5ee4373b2ebf","unresolved":false,"context_lines":[{"line_number":10,"context_line":"for the most trivial of deployments."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"As a community we need to develop a simple standard usage policy environment"},{"line_number":13,"context_line":"such that we encorporate some of the common deployment patterns of OpenStack"},{"line_number":14,"context_line":"and reduce the policy burdens on operators."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba8a016a_16c64e49","line":13,"updated":"2015-11-23 22:16:20.000000000","message":"incorporate* ?","commit_id":"14856866fdd5eb36ad8c9210b837f14680118dbb"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"2ab8a5e81ac5af671faf7e96e48d5ee4373b2ebf","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":"As individual services are not aware of all the roles in the deployment there"},{"line_number":51,"context_line":"is no issue with defining roles in policy files that are not available in the"},{"line_number":52,"context_line":"deployment. These just never be present in a token and therefore never match."},{"line_number":53,"context_line":"This means that there is no danger in changing these policy files to use roles"},{"line_number":54,"context_line":"prior to them being available from keystone."},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba8a016a_d61be6c8","line":52,"updated":"2015-11-23 22:16:20.000000000","message":"These roles are never present in a token and therefore never match.* ?","commit_id":"14856866fdd5eb36ad8c9210b837f14680118dbb"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"2ab8a5e81ac5af671faf7e96e48d5ee4373b2ebf","unresolved":false,"context_lines":[{"line_number":94,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"**observer**: The observer role allows a user to discover the resources available"},{"line_number":97,"context_line":"within a project but to have no access to create anything new. This is has been "},{"line_number":98,"context_line":"termed variously the accountant, the auditor, or the observer role."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Related Proposals"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ba8a016a_76eeba8c","line":97,"updated":"2015-11-23 22:16:20.000000000","message":"remove \u0027is\u0027 and whitespace.","commit_id":"14856866fdd5eb36ad8c9210b837f14680118dbb"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"31c2d74ecd9ff4801dc63eaef0fb072783943c09","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Maintaining policy is hard for operators. As a side effect of keystone\u0027s V2"},{"line_number":8,"context_line":"roles and devstack\u0027s default roles most services simply assume a member or"},{"line_number":9,"context_line":"admin priviledge seperation for their service. This is really only sufficient"},{"line_number":10,"context_line":"for the most trivial of deployments."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"As a community we need to develop a simple standard usage policy environment"}],"source_content_type":"text/x-rst","patch_set":3,"id":"da6ed579_9ba272ad","line":9,"updated":"2016-01-13 16:05:57.000000000","message":"privilege separation","commit_id":"7850c7d13afdcf326f9677cc3885a052cd771887"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"31c2d74ecd9ff4801dc63eaef0fb072783943c09","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":"As individual services are not aware of all the roles in the deployment there"},{"line_number":51,"context_line":"is no issue with defining roles in policy files that are not available in the"},{"line_number":52,"context_line":"deployment. These roles are never be present in a token and therefore never"},{"line_number":53,"context_line":"match. This means that there is no danger in changing these policy files to"},{"line_number":54,"context_line":"use roles prior to them being available from keystone."},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da6ed579_bba5f6b5","line":52,"updated":"2016-01-13 16:05:57.000000000","message":"s/be//","commit_id":"7850c7d13afdcf326f9677cc3885a052cd771887"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":2,"context_line":"Common Default Policy"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"https://blueprints.launchpad.net//+spec/common-default-policy"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Maintaining policy is hard for operators. As a side effect of keystone\u0027s V2"},{"line_number":8,"context_line":"roles and devstack\u0027s default roles most services simply assume a member or"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_023ec9d9","line":5,"updated":"2016-01-14 18:59:52.000000000","message":"nit: there\u0027s an extra / in the URI above :)","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"69ff941f35a264a95b0e6d1e8cabe551d4c63c31","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Maintaining policy is hard for operators. As a side effect of keystone\u0027s V2"},{"line_number":8,"context_line":"roles and devstack\u0027s default roles most services simply assume a member or"},{"line_number":9,"context_line":"admin privilege seperation for their service. This is really only sufficient"},{"line_number":10,"context_line":"for the most trivial of deployments."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"As a community we need to develop a simple standard usage policy environment"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_955d3049","line":9,"updated":"2016-01-14 11:13:58.000000000","message":"separation","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":16,"context_line":"Problem description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"For customizability roles in OpenStack are defined at runtime by administrators"},{"line_number":20,"context_line":"and stored in the keystone database. Keystone therefore does not ship with any"},{"line_number":21,"context_line":"roles by default. In contrast policy files are static files that are typically"},{"line_number":22,"context_line":"shipped with the project defining what roles are required to access an"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_f6281735","line":19,"updated":"2016-01-14 18:59:52.000000000","message":"s/customizability roles/customizability, roles/","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"For customizability roles in OpenStack are defined at runtime by administrators"},{"line_number":20,"context_line":"and stored in the keystone database. Keystone therefore does not ship with any"},{"line_number":21,"context_line":"roles by default. In contrast policy files are static files that are typically"},{"line_number":22,"context_line":"shipped with the project defining what roles are required to access an"},{"line_number":23,"context_line":"endpoint."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_f6b6d7f7","line":21,"updated":"2016-01-14 18:59:52.000000000","message":"s/In contrast policy/In contrast, policy/","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Largely as a side effect of Keystone V2 initially having only an admin/member"},{"line_number":31,"context_line":"role distinction and devstack testing a simple deployment scenario by default"},{"line_number":32,"context_line":"most service policy files ship a policy file consisting of only the"},{"line_number":33,"context_line":"admin/non-admin distinction using the admin role (Note that you must have some"},{"line_number":34,"context_line":"role on the project to be authenticated but there is no need to define this"},{"line_number":35,"context_line":"role by name). A result of this is largely the all powerful admin role that"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_569d6364","line":32,"updated":"2016-01-14 18:59:52.000000000","message":"s/most service policy files ship a policy file/most services ship a policy file/","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":38,"context_line":"Having shipped these policy files we then expect deployers to customize them to"},{"line_number":39,"context_line":"suit their needs. However, as these are security critical files that must be"},{"line_number":40,"context_line":"updated and re-merged with every release there is a general reluctance to"},{"line_number":41,"context_line":"modify these files, or at least very little."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"Proposed change"},{"line_number":44,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_b6d05ff7","line":41,"updated":"2016-01-14 18:59:52.000000000","message":"There is the additional problem that the policy files must be kept in sync across thousands of compute nodes... though most config management systems make keeping such files in sync, it\u0027s still an issue with large systems or when you need to revoke a role\u0027s privileges immediately due to a security breach.","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":47,"context_line":"and shipped as the default policy file for services. This scenario will be"},{"line_number":48,"context_line":"backwards compatible with the current admin/member that we currently have."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"As individual services are not aware of all the roles in the deployment there"},{"line_number":51,"context_line":"is no issue with defining roles in policy files that are not available in the"},{"line_number":52,"context_line":"deployment. These roles are never be present in a token and therefore never"},{"line_number":53,"context_line":"match. This means that there is no danger in changing these policy files to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_162dabfd","line":50,"updated":"2016-01-14 18:59:52.000000000","message":"s/roles in the deployment there/roles in the deployment, there/","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"69ff941f35a264a95b0e6d1e8cabe551d4c63c31","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":"As individual services are not aware of all the roles in the deployment there"},{"line_number":51,"context_line":"is no issue with defining roles in policy files that are not available in the"},{"line_number":52,"context_line":"deployment. These roles are never be present in a token and therefore never"},{"line_number":53,"context_line":"match. This means that there is no danger in changing these policy files to"},{"line_number":54,"context_line":"use roles prior to them being available from keystone."},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_3556c42a","line":52,"updated":"2016-01-14 11:13:58.000000000","message":"s/be//","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":62,"context_line":"We do not expect to come up with a scenario that solves problems for everyone."},{"line_number":63,"context_line":"There will always be custom requirements that involve a more complex policy"},{"line_number":64,"context_line":"setup that are not relevant to the general community. The aim here is to create"},{"line_number":65,"context_line":"a scenario that will improve control for the deployers who do not wish to make"},{"line_number":66,"context_line":"their own policy modifications."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The roles"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_d68073c1","line":65,"updated":"2016-01-14 18:59:52.000000000","message":"I would use the term \"schema\" instead of \"scenario\" throughout. RBAC schemas are the more common terminology...","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":68,"context_line":"The roles"},{"line_number":69,"context_line":"---------"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"**admin**: Due to its prevelance today we need to maintain the \u0027admin\u0027 role. A"},{"line_number":72,"context_line":"user with this role is all powerful and is expected to be able to do anything"},{"line_number":73,"context_line":"in OpenStack. Ideally this scope would only extend to the project the user has"},{"line_number":74,"context_line":"the role on (like all roles should), however there are circumstances today"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_b66cdf35","line":71,"updated":"2016-01-14 18:59:52.000000000","message":"s/prevelence today/prevalence, /","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":2218,"name":"Adam Young","email":"adam@younglogic.com","username":"ayoung"},"change_message_id":"4f6df40171ff4a9e2b79fd639afd7b287bd1feae","unresolved":false,"context_lines":[{"line_number":76,"context_line":"capable of doing things in other projects. This role should be strictly"},{"line_number":77,"context_line":"controlled in any deployment."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":80,"context_line":"reasons may cross project boundaries the _project_admin_ role gives users"},{"line_number":81,"context_line":"administrative rights within a project."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a5de9d1_ee8ffe27","line":79,"updated":"2016-01-29 19:41:47.000000000","message":"Let\u0027s drop \u0027admin\u0027 from this.  This is an end user role, and should be labeled to distinguish it.  Suggest Project Manager.","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"016a1ab965fa971904ff9c192bf4d83920b12139","unresolved":false,"context_lines":[{"line_number":76,"context_line":"capable of doing things in other projects. This role should be strictly"},{"line_number":77,"context_line":"controlled in any deployment."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":80,"context_line":"reasons may cross project boundaries the _project_admin_ role gives users"},{"line_number":81,"context_line":"administrative rights within a project."},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3a57f1b5_9a8652b8","line":79,"in_reply_to":"7a5de9d1_ee8ffe27","updated":"2016-02-09 21:57:48.000000000","message":"Lets find something not as overloaded as \"project manager\" if we change this.","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":77,"context_line":"controlled in any deployment."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":80,"context_line":"reasons may cross project boundaries the _project_admin_ role gives users"},{"line_number":81,"context_line":"administrative rights within a project."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"**service**: The service role should only be given to service users, these are"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_1697ebec","line":80,"updated":"2016-01-14 18:59:52.000000000","message":"s/cross boundaries the/cross boundaries, the/","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e89334a1a478de589d8ffa70cded0200b28fa532","unresolved":false,"context_lines":[{"line_number":91,"context_line":"*glance_admin* role. In the same way as _admin_ these are ideally scoped to the"},{"line_number":92,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":93,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":94,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":97,"context_line":"available within a project but to have no access to create anything new. This"}],"source_content_type":"text/x-rst","patch_set":4,"id":"da6ed579_76a50745","line":94,"updated":"2016-01-14 18:59:52.000000000","message":"++","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":2218,"name":"Adam Young","email":"adam@younglogic.com","username":"ayoung"},"change_message_id":"4f6df40171ff4a9e2b79fd639afd7b287bd1feae","unresolved":false,"context_lines":[{"line_number":91,"context_line":"*glance_admin* role. In the same way as _admin_ these are ideally scoped to the"},{"line_number":92,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":93,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":94,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":97,"context_line":"available within a project but to have no access to create anything new. This"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a5de9d1_ae9ca65d","line":94,"in_reply_to":"da6ed579_76a50745","updated":"2016-01-29 19:41:47.000000000","message":"In addition, we should have service level project_{service_type} roles, for people who, inside a project, are allowed to make changes to, say, Neutron networking, as distinguished from people that can only consume those resources.\n\nThis is distinct from, and in addition to, {service_type}_admin","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":2218,"name":"Adam Young","email":"adam@younglogic.com","username":"ayoung"},"change_message_id":"4f6df40171ff4a9e2b79fd639afd7b287bd1feae","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":97,"context_line":"available within a project but to have no access to create anything new. This"},{"line_number":98,"context_line":"has been termed variously the accountant, the auditor, or the observer role."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Related Proposals"},{"line_number":101,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a5de9d1_0e193a22","line":98,"updated":"2016-01-29 19:41:47.000000000","message":"are all observers created equal?  Are there some resources that are visible to all, and some that should only be visible to trusted auditors?","commit_id":"466676406d7c5bd3b18e52129288db3d9734d2f4"},{"author":{"_account_id":17860,"name":"Samuel de Medeiros Queiroz","email":"samueldmq@gmail.com","username":"samueldmq"},"change_message_id":"3581f835bfa793a3a9bada11693ba3c4dc4e00f3","unresolved":false,"context_lines":[{"line_number":2,"context_line":"Common Default Policy"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"https://blueprints.launchpad.net/+spec/common-default-policy"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Maintaining policy is hard for operators. As a side effect of keystone\u0027s V2"},{"line_number":8,"context_line":"roles and devstack\u0027s default roles most services simply assume a member or"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_9f67c124","line":5,"range":{"start_line":5,"start_character":0,"end_line":5,"end_character":60},"updated":"2016-02-09 18:23:27.000000000","message":"404, probably the blueprint hasn\u0027t been created yet?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":2,"context_line":"Common Default Policy"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":""},{"line_number":5,"context_line":"https://blueprints.launchpad.net/+spec/common-default-policy"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Maintaining policy is hard for operators. As a side effect of keystone\u0027s V2"},{"line_number":8,"context_line":"roles and devstack\u0027s default roles most services simply assume a member or"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_61cad151","line":5,"in_reply_to":"5a5ae5dd_9f67c124","updated":"2016-02-09 21:04:01.000000000","message":"Correct.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"For customizeability, roles in OpenStack are defined at runtime by"},{"line_number":20,"context_line":"administrators and stored in the keystone database. Keystone therefore does not"},{"line_number":21,"context_line":"ship with any roles by default. In contrast, policy files are static files that"},{"line_number":22,"context_line":"are typically shipped with the project defining what roles are required to"},{"line_number":23,"context_line":"access an endpoint."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_577893f8","line":21,"range":{"start_line":21,"start_character":45,"end_line":21,"end_character":57},"updated":"2016-02-09 16:09:47.000000000","message":"sample policy files","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"For customizeability, roles in OpenStack are defined at runtime by"},{"line_number":20,"context_line":"administrators and stored in the keystone database. Keystone therefore does not"},{"line_number":21,"context_line":"ship with any roles by default. In contrast, policy files are static files that"},{"line_number":22,"context_line":"are typically shipped with the project defining what roles are required to"},{"line_number":23,"context_line":"access an endpoint."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_41c1d52d","line":21,"in_reply_to":"5a5ae5dd_577893f8","updated":"2016-02-09 21:04:01.000000000","message":"+1","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":22,"context_line":"are typically shipped with the project defining what roles are required to"},{"line_number":23,"context_line":"access an endpoint."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"This mismatch has meant that services using policy files must ship with default"},{"line_number":26,"context_line":"configuration files that may or may not reflect the actual roles that are"},{"line_number":27,"context_line":"present in a deployment."},{"line_number":28,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_f8540322","line":25,"range":{"start_line":25,"start_character":57,"end_line":25,"end_character":61},"updated":"2016-02-17 02:06:12.000000000","message":"they don\u0027t HAVE to... they just do. :) They could have more clearly marked them as samples, and not really had a default policy, for example.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":24,"context_line":""},{"line_number":25,"context_line":"This mismatch has meant that services using policy files must ship with default"},{"line_number":26,"context_line":"configuration files that may or may not reflect the actual roles that are"},{"line_number":27,"context_line":"present in a deployment."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Largely as a side effect of Keystone V2 initially having only an admin/member"},{"line_number":30,"context_line":"role distinction and devstack testing a simple deployment schema by default"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_575f3375","line":27,"updated":"2016-02-09 16:09:47.000000000","message":"can you provide an example?\n\nThis problem will not be solved by the proposed solution.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":24,"context_line":""},{"line_number":25,"context_line":"This mismatch has meant that services using policy files must ship with default"},{"line_number":26,"context_line":"configuration files that may or may not reflect the actual roles that are"},{"line_number":27,"context_line":"present in a deployment."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Largely as a side effect of Keystone V2 initially having only an admin/member"},{"line_number":30,"context_line":"role distinction and devstack testing a simple deployment schema by default"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_81f58d84","line":27,"in_reply_to":"5a5ae5dd_575f3375","updated":"2016-02-09 21:04:01.000000000","message":"Happy to add an example, but for context: we had an operator session at the Tokyo summit where operators described the roles they were having to manually add to their deployments, and there were common themes, most prominently the \"observer\" pattern and service-specific \"admins.\"","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":17860,"name":"Samuel de Medeiros Queiroz","email":"samueldmq@gmail.com","username":"samueldmq"},"change_message_id":"3581f835bfa793a3a9bada11693ba3c4dc4e00f3","unresolved":false,"context_lines":[{"line_number":26,"context_line":"configuration files that may or may not reflect the actual roles that are"},{"line_number":27,"context_line":"present in a deployment."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Largely as a side effect of Keystone V2 initially having only an admin/member"},{"line_number":30,"context_line":"role distinction and devstack testing a simple deployment schema by default"},{"line_number":31,"context_line":"most services ship a policy file consisting of only the admin/non-admin"},{"line_number":32,"context_line":"distinction using the admin role (Note that you must have some role on the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_1f5bd155","line":29,"range":{"start_line":29,"start_character":28,"end_line":29,"end_character":36},"updated":"2016-02-09 18:23:27.000000000","message":"(nit) keystone","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":26,"context_line":"configuration files that may or may not reflect the actual roles that are"},{"line_number":27,"context_line":"present in a deployment."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Largely as a side effect of Keystone V2 initially having only an admin/member"},{"line_number":30,"context_line":"role distinction and devstack testing a simple deployment schema by default"},{"line_number":31,"context_line":"most services ship a policy file consisting of only the admin/non-admin"},{"line_number":32,"context_line":"distinction using the admin role (Note that you must have some role on the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_ec19e47a","line":29,"range":{"start_line":29,"start_character":71,"end_line":29,"end_character":77},"updated":"2016-02-17 02:06:12.000000000","message":"non-admin","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":26,"context_line":"configuration files that may or may not reflect the actual roles that are"},{"line_number":27,"context_line":"present in a deployment."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Largely as a side effect of Keystone V2 initially having only an admin/member"},{"line_number":30,"context_line":"role distinction and devstack testing a simple deployment schema by default"},{"line_number":31,"context_line":"most services ship a policy file consisting of only the admin/non-admin"},{"line_number":32,"context_line":"distinction using the admin role (Note that you must have some role on the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_214939d1","line":29,"in_reply_to":"5a5ae5dd_1f5bd155","updated":"2016-02-09 21:04:01.000000000","message":"+1","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":32,"context_line":"distinction using the admin role (Note that you must have some role on the"},{"line_number":33,"context_line":"project to be authenticated but there is no need to define this role by name)."},{"line_number":34,"context_line":"A result of this is largely the all powerful admin role that must be created in"},{"line_number":35,"context_line":"deployments and overly powerful service users."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Having shipped these policy files we then expect deployers to customize them to"},{"line_number":38,"context_line":"suit their needs. However, as these are security critical files that must be"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_d78803c9","line":35,"range":{"start_line":35,"start_character":16,"end_line":35,"end_character":31},"updated":"2016-02-09 16:09:47.000000000","message":"these must also all-powerful since that\u0027s the only option other than member.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":1916,"name":"Guang Yee","email":"gyee@suse.com","username":"guang-yee"},"change_message_id":"3c7f0c3ca04dd0fc19f8a009c5069aee1cc7debf","unresolved":false,"context_lines":[{"line_number":39,"context_line":"delicately updated and re-merged with every release, there is a general"},{"line_number":40,"context_line":"reluctance to modify these files, or at least very little. Once a revised"},{"line_number":41,"context_line":"policy file is ready for deployment, it can then be a configuration management"},{"line_number":42,"context_line":"challenge to synchronously deploy that policy across thousands of compute"},{"line_number":43,"context_line":"nodes."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_4deaf210","line":43,"range":{"start_line":42,"start_character":53,"end_line":43,"end_character":5},"updated":"2016-02-05 00:48:18.000000000","message":"Wow, really? Thousands? Also, you mean API nodes right? Not sure if compute nodes care about policies.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":39,"context_line":"delicately updated and re-merged with every release, there is a general"},{"line_number":40,"context_line":"reluctance to modify these files, or at least very little. Once a revised"},{"line_number":41,"context_line":"policy file is ready for deployment, it can then be a configuration management"},{"line_number":42,"context_line":"challenge to synchronously deploy that policy across thousands of compute"},{"line_number":43,"context_line":"nodes."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_d75d6349","line":43,"range":{"start_line":42,"start_character":53,"end_line":43,"end_character":5},"in_reply_to":"5a5ae5dd_4deaf210","updated":"2016-02-09 16:09:47.000000000","message":"y, this should be API servers or API nodes or something.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"70c50d91a0c738ff79bbe83615c949972e38794e","unresolved":false,"context_lines":[{"line_number":39,"context_line":"delicately updated and re-merged with every release, there is a general"},{"line_number":40,"context_line":"reluctance to modify these files, or at least very little. Once a revised"},{"line_number":41,"context_line":"policy file is ready for deployment, it can then be a configuration management"},{"line_number":42,"context_line":"challenge to synchronously deploy that policy across thousands of compute"},{"line_number":43,"context_line":"nodes."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba0121b8_6a0e9c35","line":43,"range":{"start_line":42,"start_character":53,"end_line":43,"end_character":5},"in_reply_to":"5a5ae5dd_d75d6349","updated":"2016-03-29 11:57:21.000000000","message":"yeah, you only need the policy.json on the API nodes. The compute api policy stuff actually only runs on the API nodes (well and nova-cells nodes, but lets ignore as the existing nova-cells is on the road to deprecation).","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"70c50d91a0c738ff79bbe83615c949972e38794e","unresolved":false,"context_lines":[{"line_number":41,"context_line":"policy file is ready for deployment, it can then be a configuration management"},{"line_number":42,"context_line":"challenge to synchronously deploy that policy across thousands of compute"},{"line_number":43,"context_line":"nodes."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"ba0121b8_ef7e3ead","line":44,"updated":"2016-03-29 11:57:21.000000000","message":"I have been thinking about how to respond to the ideas here. I am trying to thinking though a different way to express this problem here:\nhttps://review.openstack.org/#/c/298686\n\nI need to loop back and add comments here, and refine the above to try and describe how I am thinking more clearly.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"I would like to define a single, simple, common schema that will be enabled"},{"line_number":49,"context_line":"and shipped as the default policy file for services. This schema will be"},{"line_number":50,"context_line":"backwards compatible with the current admin/member that we currently have."},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_972e0ba4","line":48,"range":{"start_line":48,"start_character":33,"end_line":48,"end_character":39},"updated":"2016-02-09 16:09:47.000000000","message":"\"simple\" is relative.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"8929511c54378635e80e877299468e64eacdd37c","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"I would like to define a single, simple, common schema that will be enabled"},{"line_number":49,"context_line":"and shipped as the default policy file for services. This schema will be"},{"line_number":50,"context_line":"backwards compatible with the current admin/member that we currently have."},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_152b1384","line":48,"in_reply_to":"3a57f1b5_81234d05","updated":"2016-02-09 22:02:16.000000000","message":"it was simpler :p","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"I would like to define a single, simple, common schema that will be enabled"},{"line_number":49,"context_line":"and shipped as the default policy file for services. This schema will be"},{"line_number":50,"context_line":"backwards compatible with the current admin/member that we currently have."},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_81234d05","line":48,"in_reply_to":"5a5ae5dd_972e0ba4","updated":"2016-02-09 21:04:01.000000000","message":"lol +1","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":47,"context_line":""},{"line_number":48,"context_line":"I would like to define a single, simple, common schema that will be enabled"},{"line_number":49,"context_line":"and shipped as the default policy file for services. This schema will be"},{"line_number":50,"context_line":"backwards compatible with the current admin/member that we currently have."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"As individual services are not aware of all the roles in the deployment, there"},{"line_number":53,"context_line":"is no issue with defining roles in policy files that are not available in the"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_6c0dd436","line":50,"range":{"start_line":50,"start_character":44,"end_line":50,"end_character":50},"updated":"2016-02-17 02:06:12.000000000","message":"non-admin","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":50,"context_line":"backwards compatible with the current admin/member that we currently have."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"As individual services are not aware of all the roles in the deployment, there"},{"line_number":53,"context_line":"is no issue with defining roles in policy files that are not available in the"},{"line_number":54,"context_line":"deployment. These roles are never present in a token and therefore never match."},{"line_number":55,"context_line":"This means that there is no danger in changing these policy files to use roles"},{"line_number":56,"context_line":"prior to them being available from keystone."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_b77306b4","line":53,"range":{"start_line":53,"start_character":17,"end_line":53,"end_character":25},"updated":"2016-02-09 16:09:47.000000000","message":"suggest \"using\" or \"referring to\"","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":50,"context_line":"backwards compatible with the current admin/member that we currently have."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"As individual services are not aware of all the roles in the deployment, there"},{"line_number":53,"context_line":"is no issue with defining roles in policy files that are not available in the"},{"line_number":54,"context_line":"deployment. These roles are never present in a token and therefore never match."},{"line_number":55,"context_line":"This means that there is no danger in changing these policy files to use roles"},{"line_number":56,"context_line":"prior to them being available from keystone."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_2177f903","line":53,"in_reply_to":"5a5ae5dd_b77306b4","updated":"2016-02-09 21:04:01.000000000","message":"I consider policy files to be the \"definitions\" of roles, in that policy actually defines what capabilities a role has. Happy to make that more clear, but I don\u0027t think either of the suggestions help convey the intended meaning any further (that they don\u0027t need to be assigned / utilized to users in the deployment).","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":53,"context_line":"is no issue with defining roles in policy files that are not available in the"},{"line_number":54,"context_line":"deployment. These roles are never present in a token and therefore never match."},{"line_number":55,"context_line":"This means that there is no danger in changing these policy files to use roles"},{"line_number":56,"context_line":"prior to them being available from keystone."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"The only chance of collision here is that we create a role with the same name"},{"line_number":59,"context_line":"but different meaning to one that exists in a deployment. For this to happen/be"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_ec8c4481","line":56,"range":{"start_line":56,"start_character":30,"end_line":56,"end_character":43},"updated":"2016-02-17 02:06:12.000000000","message":"\"in a keystone deployment\" might be clearer, to distinguish from keystone the project.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":61,"context_line":"plan a migration to the new role names or continue to ship their custom policy"},{"line_number":62,"context_line":"files."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"We do not expect to come up with a schema that solves problems for everyone."},{"line_number":65,"context_line":"There will always be custom requirements that involve a more complex policy"},{"line_number":66,"context_line":"setup that are not relevant to the general community. The aim here is to create"},{"line_number":67,"context_line":"a schema that will improve control for the deployers who do not wish to make"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_b781c64f","line":64,"range":{"start_line":64,"start_character":35,"end_line":64,"end_character":41},"updated":"2016-02-09 16:09:47.000000000","message":"suggest \"scheme\" rather than schema. (this applies in other places).","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":61,"context_line":"plan a migration to the new role names or continue to ship their custom policy"},{"line_number":62,"context_line":"files."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"We do not expect to come up with a schema that solves problems for everyone."},{"line_number":65,"context_line":"There will always be custom requirements that involve a more complex policy"},{"line_number":66,"context_line":"setup that are not relevant to the general community. The aim here is to create"},{"line_number":67,"context_line":"a schema that will improve control for the deployers who do not wish to make"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_414b15b1","line":64,"in_reply_to":"5a5ae5dd_b781c64f","updated":"2016-02-09 21:04:01.000000000","message":"+1, although I\u0027m not in love with either term.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"803f062444e7218cdc698ef334a2a67baa5f5ce8","unresolved":false,"context_lines":[{"line_number":66,"context_line":"setup that are not relevant to the general community. The aim here is to create"},{"line_number":67,"context_line":"a schema that will improve control for the deployers who do not wish to make"},{"line_number":68,"context_line":"their own policy modifications."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The roles"},{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_77b8d3c8","line":69,"updated":"2016-02-05 08:09:50.000000000","message":"I just want to confirm that this proposal does not mandate any change in where the policy scope (e.g. does the token scope match the project/domain the API is operating on) is checked (I.e. do we do that in the policy file or in code in the service)? That\u0027s a separate discussion (I hope).","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":66,"context_line":"setup that are not relevant to the general community. The aim here is to create"},{"line_number":67,"context_line":"a schema that will improve control for the deployers who do not wish to make"},{"line_number":68,"context_line":"their own policy modifications."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The roles"},{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_c17145e2","line":69,"in_reply_to":"5a5ae5dd_77b8d3c8","updated":"2016-02-09 21:04:01.000000000","message":"Correct - there is no impact on anything beyond the roles immediately available to use in all projects.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"**admin**: Due to its prevalence today, we need to maintain the \u0027admin\u0027 role. A"},{"line_number":74,"context_line":"user with this role is all powerful and is expected to be able to do anything"},{"line_number":75,"context_line":"in OpenStack. Ideally this scope would only extend to the project the user has"},{"line_number":76,"context_line":"the role on (like all roles should), however there are circumstances today"},{"line_number":77,"context_line":"where the admin role implies having admin on the entire deployment and is"},{"line_number":78,"context_line":"capable of doing things in other projects. This role should be strictly"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_eced64f0","line":75,"range":{"start_line":74,"start_character":40,"end_line":75,"end_character":12},"updated":"2016-02-17 02:06:12.000000000","message":"It\u0027s neither totally true nor totally untrue that someone with the admin role is all-powerful today. It\u0027s inconsistent. We created the cloud_admin concept (referred to as admin project below) to begin to address that, though there is still a long way to go to get that implemented across the community. But this seems to be striking off in a totally different direction. If we go this way, let\u0027s be clear that it will not be without a lot of changes across projects. All those inconsistencies have to be addressed one way or another. And it\u0027s both silly and confusing to have an admin role assignment scoped to project/domain if it\u0027s really global, so we would still need to address that.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":1916,"name":"Guang Yee","email":"gyee@suse.com","username":"guang-yee"},"change_message_id":"3c7f0c3ca04dd0fc19f8a009c5069aee1cc7debf","unresolved":false,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_0db15ae1","line":83,"range":{"start_line":83,"start_character":0,"end_line":83,"end_character":38},"updated":"2016-02-05 00:48:18.000000000","message":"Can you quantify \"administrative rights within a project\"? We don\u0027t have project admin versus global admin distinction today.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10420,"name":"Adrian Turjak","email":"devs+openstack@uncaught-exceptions.com","username":"adriant"},"change_message_id":"f70437a377b8941250fb4267f8a0f6430812f0a1","unresolved":false,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_43f3bb9e","line":83,"in_reply_to":"3a57f1b5_e130010a","updated":"2016-02-15 22:45:05.000000000","message":"Another option is to call it \"project_owner\" so it does not contain the word admin at all, but conveys enough of the intended meaning.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_e130010a","line":83,"in_reply_to":"5a5ae5dd_0db15ae1","updated":"2016-02-09 21:04:01.000000000","message":"This is intended to apply within a tenancy, and is not truly admin. I\u0027m not particularly a fan of the naming, but I left this from the previous revision.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":13781,"name":"Pieter","email":"pkruithofjr@gmail.com","username":"pkruithofjr"},"change_message_id":"60031c1c15733d290778c58fe04dd94e27d0b47d","unresolved":false,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bae84128_fb2f41f4","line":83,"in_reply_to":"dae33548_43f3bb9e","updated":"2016-02-19 14:25:59.000000000","message":"Agree.  Project Admin is confusing to End Users.  My impression is that a Project Owner has certain rights within a project such as adding users with the intent of reducing some of the overhead for admins.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"f366b70a04ab4e53d3e15b3b0f370a93b94217a9","unresolved":false,"context_lines":[{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_30bc8105","line":84,"updated":"2016-01-30 18:53:55.000000000","message":"So keystone for sure needs a domain_admin concept (which will soon just mean project_admin on a project with is_domain\u003dTrue). Is it the proposal that we do or do not have such a role?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"e5700e822054b6669010c9ae6d99add5285f0c83","unresolved":false,"context_lines":[{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_732e408d","line":84,"in_reply_to":"7a5de9d1_30bc8105","updated":"2016-02-02 00:31:48.000000000","message":"The goal of this cross-project spec is to define the minimum convention of roles that should appear in every service\u0027s policy.json -- not to exclude any service-specific roles, nor to preclude a deployer from adding their own custom roles.\n\ndomain_admin is an interesting one though that might be worth adding to this spec though, if it has applications in more services than just keystone.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_e4732fb3","line":84,"in_reply_to":"7a5de9d1_7199231f","updated":"2016-02-09 21:04:01.000000000","message":"I agree with both of your lines of thinking :)","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"c25ef5b1e17957fb9c816f23f6e2ec3131322b97","unresolved":false,"context_lines":[{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_f66f7ec1","line":84,"in_reply_to":"7a5de9d1_732e408d","updated":"2016-02-02 02:46:49.000000000","message":"given the way we are moving with keystone domains and that it will take a while for this spec to be approved and implemented do we want a domain_admin role to be something that becomes normal? (thinking as dolph says that we\u0027re talking cross-project here not excluding what we would do in a service)","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3d5db0c3b7c40f147dbdd1f569611b8c2705f701","unresolved":false,"context_lines":[{"line_number":81,"context_line":"**project_admin**: To distinguish from the _admin_ role that for historical"},{"line_number":82,"context_line":"reasons may cross project boundaries, the _project_admin_ role gives users"},{"line_number":83,"context_line":"administrative rights within a project."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_7199231f","line":84,"in_reply_to":"7a5de9d1_f66f7ec1","updated":"2016-02-03 10:21:12.000000000","message":"If the move is directly towards hierarchical projects (ie a domain being a special kind of project which contains other projects) then perhaps domain_admin as a role is overkill. That said it does relate to a specific entity and can be useful in that context.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"**{service_type}_admin**: A role that gives administrative access to one"},{"line_number":90,"context_line":"service.  The service type here is the identifying service type that is"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_f7f09ecb","line":87,"updated":"2016-02-09 16:09:47.000000000","message":"Is this role also used by cross-project API requests, for example, neutron notifying nova that the network is ready? If so, add that to the description.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**service**: The service role should only be given to service users, these are"},{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"**{service_type}_admin**: A role that gives administrative access to one"},{"line_number":90,"context_line":"service.  The service type here is the identifying service type that is"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_bb555051","line":87,"in_reply_to":"5a5ae5dd_f7f09ecb","updated":"2016-02-17 02:06:12.000000000","message":"I don\u0027t think it should have to be. The same user may be used for both, but it could and probably should have multiple roles to delineate the different things it needs to be able to do. May still be worth spelling that out, since folks are used to these just being \"admin\" and not having to worry about it.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"316da6897f41cfc505a75d92c59fd46c6d41dffc","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"**{service_type}_admin**: A role that gives administrative access to one"},{"line_number":90,"context_line":"service.  The service type here is the identifying service type that is"},{"line_number":91,"context_line":"available from the service catalog. For example there would be a"},{"line_number":92,"context_line":"*_compute_admin_* and an *_image_admin_* role and not a *nova_admin* or"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_c6737714","line":89,"range":{"start_line":89,"start_character":0,"end_line":89,"end_character":24},"updated":"2016-02-09 15:10:50.000000000","message":"Can we just combine this with the servide role above?  Do we really need this next tier?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"41040d7e1d21da922b1e027913f13e0497e1c5cf","unresolved":false,"context_lines":[{"line_number":86,"context_line":"the users that are in auth_token middleware and are able to validate other"},{"line_number":87,"context_line":"user\u0027s tokens."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"**{service_type}_admin**: A role that gives administrative access to one"},{"line_number":90,"context_line":"service.  The service type here is the identifying service type that is"},{"line_number":91,"context_line":"available from the service catalog. For example there would be a"},{"line_number":92,"context_line":"*_compute_admin_* and an *_image_admin_* role and not a *nova_admin* or"}],"source_content_type":"text/x-rst","patch_set":5,"id":"3a57f1b5_64ddff6f","line":89,"in_reply_to":"5a5ae5dd_c6737714","updated":"2016-02-09 21:04:01.000000000","message":"I think this might be intended to be backwards from how you\u0027re thinking of it; a \"nova_admin\" role isn\u0027t a role that the nova service user has, it\u0027s a role that users (or service users) have to perform operations on nova. Or am I misunderstanding your question?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":90,"context_line":"service.  The service type here is the identifying service type that is"},{"line_number":91,"context_line":"available from the service catalog. For example there would be a"},{"line_number":92,"context_line":"*_compute_admin_* and an *_image_admin_* role and not a *nova_admin* or"},{"line_number":93,"context_line":"*glance_admin* role. In the same way as _admin_ these are ideally scoped to the"},{"line_number":94,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":95,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":96,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_3b194089","line":94,"range":{"start_line":93,"start_character":58,"end_line":94,"end_character":7},"updated":"2016-02-17 02:06:12.000000000","message":"Either you\u0027re scoped or you\u0027re not. If you\u0027re scoped, you should not be able to do things outside that scope. That\u0027s what scoping means. That admins can do certain things outside their scope today is a problem we need to go fix, not expand.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6486,"name":"Brant Knudson","email":"blk@acm.org","username":"blk-u"},"change_message_id":"3197807a263b30d887c4151bf15a79da8d474eef","unresolved":false,"context_lines":[{"line_number":95,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":96,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"**{service_type}_{api_resource]_manager**: A role that gives administrative"},{"line_number":99,"context_line":"access to a subset of a service\u0027s API dealing with a specific type of resource."},{"line_number":100,"context_line":"For example, an *identity_catalog_manager* is capable of fully managing"},{"line_number":101,"context_line":"(creating, fetching, listing, updating, and deleting) keystone\u0027s service"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_b7030676","line":98,"range":{"start_line":98,"start_character":32,"end_line":98,"end_character":39},"updated":"2016-02-09 16:09:47.000000000","message":"If \"manager\" is just a synonym for \"admin\", the same word should be used rather than different ones.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"316da6897f41cfc505a75d92c59fd46c6d41dffc","unresolved":false,"context_lines":[{"line_number":95,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":96,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"**{service_type}_{api_resource]_manager**: A role that gives administrative"},{"line_number":99,"context_line":"access to a subset of a service\u0027s API dealing with a specific type of resource."},{"line_number":100,"context_line":"For example, an *identity_catalog_manager* is capable of fully managing"},{"line_number":101,"context_line":"(creating, fetching, listing, updating, and deleting) keystone\u0027s service"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_c64a97ac","line":98,"range":{"start_line":98,"start_character":0,"end_line":98,"end_character":41},"updated":"2016-02-09 15:10:50.000000000","message":"Same as above","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"316da6897f41cfc505a75d92c59fd46c6d41dffc","unresolved":false,"context_lines":[{"line_number":104,"context_line":"give you similar management capabilities over just the endpoint management API"},{"line_number":105,"context_line":"(excluding regions and services)."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"**{service_type}_{api_capability}**: This is an ultra-fine grained role"},{"line_number":108,"context_line":"allowing access to exactly one API capability. For example, a user provisioning"},{"line_number":109,"context_line":"tool might be granted authorization create new users (*identity_create_user*)"},{"line_number":110,"context_line":"and to fetch individual users (*identity_get_user*), but not to list all users"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_266ccb07","line":107,"range":{"start_line":107,"start_character":0,"end_line":107,"end_character":35},"updated":"2016-02-09 15:10:50.000000000","message":"And same here.. do we need this fine-grained layering?  IMHO this just adds complexity and potential confusion and is prone to errors.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"b2b00217322254c29b43c91d11764b7971a1fff6","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"**{service_type}_{api_capability}**: This is an ultra-fine grained role"},{"line_number":108,"context_line":"allowing access to exactly one API capability. For example, a user provisioning"},{"line_number":109,"context_line":"tool might be granted authorization create new users (*identity_create_user*)"},{"line_number":110,"context_line":"and to fetch individual users (*identity_get_user*), but not to list all users"},{"line_number":111,"context_line":"in the system (*identity_list_users*) or to delete any users"},{"line_number":112,"context_line":"(*identity_delete_user*). Note that this means there will be thousands of"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_61cf0db4","line":109,"updated":"2016-02-09 15:11:55.000000000","message":"\"to create\"","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"c25ef5b1e17957fb9c816f23f6e2ec3131322b97","unresolved":false,"context_lines":[{"line_number":112,"context_line":"(*identity_delete_user*). Note that this means there will be thousands of"},{"line_number":113,"context_line":"granular role definitions in policy files across OpenStack, but, like all other"},{"line_number":114,"context_line":"role definitions proposed as part of this schema, they neither need to exist in"},{"line_number":115,"context_line":"keystone nor be assigned to users."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":118,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_73008002","line":115,"range":{"start_line":115,"start_character":13,"end_line":115,"end_character":15},"updated":"2016-02-02 02:46:49.000000000","message":"I\u0027m not sure about the addition of these 2 fine grained roles. What i\u0027m looking to define here is a basic set of roles that aren\u0027t required but are somewhat expected to be created by the likes of devstack or ansible/puppet/other install mechanism such that the services can supply better defaults.\n\nHaving said that if the role does not exist in keystone then it will never match in the policy file so having policy files that include something like this should not be a cost.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"b2b00217322254c29b43c91d11764b7971a1fff6","unresolved":false,"context_lines":[{"line_number":112,"context_line":"(*identity_delete_user*). Note that this means there will be thousands of"},{"line_number":113,"context_line":"granular role definitions in policy files across OpenStack, but, like all other"},{"line_number":114,"context_line":"role definitions proposed as part of this schema, they neither need to exist in"},{"line_number":115,"context_line":"keystone nor be assigned to users."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":118,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_81d48947","line":115,"updated":"2016-02-09 15:11:55.000000000","message":"If we expect policy files to be inspectable it would nice if they were not full of maybes, maybe?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":112,"context_line":"(*identity_delete_user*). Note that this means there will be thousands of"},{"line_number":113,"context_line":"granular role definitions in policy files across OpenStack, but, like all other"},{"line_number":114,"context_line":"role definitions proposed as part of this schema, they neither need to exist in"},{"line_number":115,"context_line":"keystone nor be assigned to users."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":118,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_d668eb89","line":115,"in_reply_to":"5a5ae5dd_81d48947","updated":"2016-02-17 02:06:12.000000000","message":"I think we have to have this if the goal is that folks can use policy files without extensive editing. There are a lot of cases like the example where someone needs to be able to get something but not to delete it.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":2243,"name":"John Griffith","email":"john.griffith8@gmail.com","username":"john-griffith"},"change_message_id":"316da6897f41cfc505a75d92c59fd46c6d41dffc","unresolved":false,"context_lines":[{"line_number":119,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":120,"context_line":"accountant, the auditor, or the observer role."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"**project_observer**: The project_observer role allows a user to discover the"},{"line_number":123,"context_line":"resources available within a *specific* tenancy across OpenStack but have no"},{"line_number":124,"context_line":"access to create, modify, or delete resources."},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_a62e7ba3","line":122,"range":{"start_line":122,"start_character":0,"end_line":122,"end_character":20},"updated":"2016-02-09 15:10:50.000000000","message":"Same as above on the service tiers... If we want an \"observer\" then that\u0027s fine... but do we really need two more layers underneath it?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":119,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":120,"context_line":"accountant, the auditor, or the observer role."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"**project_observer**: The project_observer role allows a user to discover the"},{"line_number":123,"context_line":"resources available within a *specific* tenancy across OpenStack but have no"},{"line_number":124,"context_line":"access to create, modify, or delete resources."},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_51ba256f","line":122,"range":{"start_line":122,"start_character":0,"end_line":122,"end_character":20},"in_reply_to":"5a5ae5dd_a62e7ba3","updated":"2016-02-17 02:06:12.000000000","message":"I agree... observer is observer, admin is admin. Scope (project or global) is something different. Let\u0027s add the concept of a global type to role assignments and you don\u0027t need to mix scope information into role names. We already have the concept of scope where it should be, in role assignments (where you choose project or domain today). Just add global as a possibility there. You could probably even have db migrations transform any existing admin role assignments to global to preserve backward compatibility on upgrades as we shift to truly enforcing scope properly.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"c25ef5b1e17957fb9c816f23f6e2ec3131322b97","unresolved":false,"context_lines":[{"line_number":121,"context_line":""},{"line_number":122,"context_line":"**project_observer**: The project_observer role allows a user to discover the"},{"line_number":123,"context_line":"resources available within a *specific* tenancy across OpenStack but have no"},{"line_number":124,"context_line":"access to create, modify, or delete resources."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_d61e025e","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":6},"updated":"2016-02-02 02:46:49.000000000","message":"what do you anticipate needing to be observed outside of a project? something like listing hypervisors? \n\nmaybe we should call this admin_observer rather than extend the project_ prefix - i only did this because we already have the admin role that is overused.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"a197822096b16c4e2f1f8bd4a985f5e7615988b8","unresolved":false,"context_lines":[{"line_number":121,"context_line":""},{"line_number":122,"context_line":"**project_observer**: The project_observer role allows a user to discover the"},{"line_number":123,"context_line":"resources available within a *specific* tenancy across OpenStack but have no"},{"line_number":124,"context_line":"access to create, modify, or delete resources."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_0d4bd988","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":6},"in_reply_to":"7a5de9d1_31716be1","updated":"2016-02-04 00:49:28.000000000","message":"+1 - i like that. It\u0027d be good to just deprecate the \u0027admin\u0027 role in favour of an explicit project_admin or global_admin. \n\nglobal_admin would be very similar to keystone\u0027s current cloud_admin, but that concept is not exposed in other services.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3d5db0c3b7c40f147dbdd1f569611b8c2705f701","unresolved":false,"context_lines":[{"line_number":121,"context_line":""},{"line_number":122,"context_line":"**project_observer**: The project_observer role allows a user to discover the"},{"line_number":123,"context_line":"resources available within a *specific* tenancy across OpenStack but have no"},{"line_number":124,"context_line":"access to create, modify, or delete resources."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_31716be1","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":6},"in_reply_to":"7a5de9d1_70fe0407","updated":"2016-02-03 10:21:12.000000000","message":"++ loving Doug\u0027s suggestion here. Deprecating \u0027admin\u0027 and replacing it with \u0027global_admin\u0027 might also bring about a forced change which would be good.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"26597cf1126571570ca393000c739db3674fdea3","unresolved":false,"context_lines":[{"line_number":121,"context_line":""},{"line_number":122,"context_line":"**project_observer**: The project_observer role allows a user to discover the"},{"line_number":123,"context_line":"resources available within a *specific* tenancy across OpenStack but have no"},{"line_number":124,"context_line":"access to create, modify, or delete resources."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_70fe0407","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":6},"in_reply_to":"7a5de9d1_d61e025e","updated":"2016-02-02 18:25:18.000000000","message":"I like having standardized prefixes to describe the expected scope. In fact, I\u0027d like to have a \"global\" prefix (global_admin, global_observer, etc.) for that case. The global_admin and admin roles could be synonyms.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":136,"name":"Tim Bell","email":"tim.bell@cern.ch","username":"tim-bell"},"change_message_id":"d83dfbf1b64edaf828eee935e8fd2b66481fa5a2","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"},{"line_number":128,"context_line":"to create, modify, or delete resources."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Related Proposals"},{"line_number":131,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_f04ee96d","line":128,"updated":"2016-01-30 18:36:44.000000000","message":"We currently have\n\n- operator - console/reboot for procedures following alarms\n- accounting - r/o access to quota and ceilometer to produce reports on usage to stakeholders","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"517ff5945f0e2a2de1c09aa41abb866271cc368e","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"},{"line_number":128,"context_line":"to create, modify, or delete resources."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Related Proposals"},{"line_number":131,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_472197fa","line":128,"in_reply_to":"5a5ae5dd_4d07911c","updated":"2016-02-04 11:34:54.000000000","message":"I think that\u0027s a good start. It\u0027d be helpful to have a description of how one would do this in the documentation (or at the very least in a blog post) somewhere. If there is such a thing, I\u0027ve not seen it.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"a197822096b16c4e2f1f8bd4a985f5e7615988b8","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"},{"line_number":128,"context_line":"to create, modify, or delete resources."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Related Proposals"},{"line_number":131,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_4d07911c","line":128,"in_reply_to":"5a5ae5dd_ed02276f","updated":"2016-02-04 00:49:28.000000000","message":"There is a proposal linked below for implied roles expected to land in mitaka - essentially a role can be composed of other roles. If we provide the low level _observer roles in policy files can we leave it up to the deployer to create an operator role that covers their individual cases?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"3d5db0c3b7c40f147dbdd1f569611b8c2705f701","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"},{"line_number":128,"context_line":"to create, modify, or delete resources."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Related Proposals"},{"line_number":131,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_ed02276f","line":128,"in_reply_to":"7a5de9d1_93b2dc4a","updated":"2016-02-03 10:21:12.000000000","message":"Actually the \u0027operator\u0027 role with that functionality is a relatively common requirement. Effectively the need is to be able to see things (like the observer), but also do limited (no delete, no add, no change, etc) functions - only very simple functions like access the console, reboot the server, etc.\n\nConsider a case where an entry-level admin is given access to the console and to reboot servers for standby support purposes in the middle of the night. This person doesn\u0027t need to change anything within the Cloud - only on the server. It\u0027s akin to IPMI/ILO/DRAC access to a hardware system for emergency needs.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"e5700e822054b6669010c9ae6d99add5285f0c83","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":127,"context_line":"available within a specific service, regardless of tenancy, but have no access"},{"line_number":128,"context_line":"to create, modify, or delete resources."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Related Proposals"},{"line_number":131,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_93b2dc4a","line":128,"in_reply_to":"7a5de9d1_f04ee96d","updated":"2016-02-02 00:31:48.000000000","message":"\"operator\" sounds like a specialized role that wouldn\u0027t be covered under these conventions, unless it happened to fit the {service_type}_{api_resource}_manager convention. Either way, to be clear, this spec would not preclude you from defining custom, specialized roles in policy! (see henrynash\u0027s domain_admin comment above)\n\nIs \"accounting\" equivalent to one of the above conventions? (observer, project_observer, {service_type}_observer), then?","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":159,"context_line":"small number) of projects that are deemed the *admin project*. This project is"},{"line_number":160,"context_line":"the only project that is capable of being granted the *admin* role and"},{"line_number":161,"context_line":"adminstrators must therefore authenticate to this project before performing any"},{"line_number":162,"context_line":"operations that cross project boundaries. This would typically relate to the"},{"line_number":163,"context_line":"*{service_type}_admin* roles such that you would have to be authenticated"},{"line_number":164,"context_line":"against the admin project to do cross project operations."},{"line_number":165,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_f147f8b9","line":162,"range":{"start_line":162,"start_character":42,"end_line":162,"end_character":69},"updated":"2016-02-17 02:06:12.000000000","message":"can you clarify how you envision that? I\u0027m familiar with the admin project being added, but I\u0027m not following how that is supposed to relate to this (seems to me that it would be an either/or thing, not complementary).","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":1916,"name":"Guang Yee","email":"gyee@suse.com","username":"guang-yee"},"change_message_id":"3c7f0c3ca04dd0fc19f8a009c5069aee1cc7debf","unresolved":false,"context_lines":[{"line_number":165,"context_line":""},{"line_number":166,"context_line":"These specifications make it easier to customize roles for deployers however"},{"line_number":167,"context_line":"they do not directly address the problem of administrators not being willing to"},{"line_number":168,"context_line":"modify policy."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":".. _Implied roles: https://review.openstack.org/#/c/125704/"},{"line_number":171,"context_line":".. _Dynamic policy: https://review.openstack.org/#/c/133814/"}],"source_content_type":"text/x-rst","patch_set":5,"id":"5a5ae5dd_2d48d686","line":168,"updated":"2016-02-05 00:48:18.000000000","message":"In theory, if we just have {service_type}_{api_capability}, like one per API, we can build everything else with implied roles. Drawback is that token data, along with the X-Roles header, may experience explosion after we expended all the implied roles.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":165,"context_line":""},{"line_number":166,"context_line":"These specifications make it easier to customize roles for deployers however"},{"line_number":167,"context_line":"they do not directly address the problem of administrators not being willing to"},{"line_number":168,"context_line":"modify policy."},{"line_number":169,"context_line":""},{"line_number":170,"context_line":".. _Implied roles: https://review.openstack.org/#/c/125704/"},{"line_number":171,"context_line":".. _Dynamic policy: https://review.openstack.org/#/c/133814/"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_5186a4db","line":168,"in_reply_to":"5a5ae5dd_2d48d686","updated":"2016-02-17 02:06:12.000000000","message":"the token and header explosion should be a key concern here... Definitely need to address those in this document.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"dcec9b014f341ba013e88a6b0f87f55149b616f2","unresolved":false,"context_lines":[{"line_number":188,"context_line":"----------"},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"The intention will be that the new schema is backwards compatible with the"},{"line_number":191,"context_line":"policy files that we are currently shipping with services. The admin/member"},{"line_number":192,"context_line":"distinction that is currently in use will still be available there will just be"},{"line_number":193,"context_line":"additional roles suggested in policies."},{"line_number":194,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"dae33548_3162003f","line":191,"range":{"start_line":191,"start_character":69,"end_line":191,"end_character":75},"updated":"2016-02-17 02:06:12.000000000","message":"non-admin","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"26597cf1126571570ca393000c739db3674fdea3","unresolved":false,"context_lines":[{"line_number":200,"context_line":"- Create a wiki/other document for describing the schema and roles available"},{"line_number":201,"context_line":"  in the default policy. We never want the default policy to include all"},{"line_number":202,"context_line":"  possible use cases but we want to be able to control and review additions to"},{"line_number":203,"context_line":"  the default policy in future."},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"- Create additional roles in devstack for testing."},{"line_number":206,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7a5de9d1_307bac7d","line":203,"updated":"2016-02-02 18:25:18.000000000","message":"This seems like the sort of thing we ought to be able to extract directly from the source policy file. I can help with sphinx integration to add this to project documentation automatically, like we\u0027ve started doing with configuration options.","commit_id":"ac064f9b1bf0c4921629ef85bb46faa5bb46b6f4"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"9f9930e81c1ac87592700cd38c4bcea7fb3df8ab","unresolved":false,"context_lines":[{"line_number":72,"context_line":"The roles"},{"line_number":73,"context_line":"---------"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"``global_admin`` (synonymous with today\u0027s ``admin`` role): Due to its"},{"line_number":76,"context_line":"prevalence today, we need to maintain the ``admin`` role. However, in order to"},{"line_number":77,"context_line":"provide additional explicitness going forward about the true nature of the"},{"line_number":78,"context_line":"``admin`` role, it will become synonymous with ``global_admin``. A user with"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba0121b8_1f9e6407","line":75,"updated":"2016-04-01 22:24:29.000000000","message":"There was some consensus in the previous patchset to introduce a \"global_admin\"; here\u0027s an example of the impact of this change with backwards compatibility:\n\n   https://review.openstack.org/#/c/300683/","commit_id":"daad6a2bc70dd8059664fed29fb619c3d081d344"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":31,"context_line":"schema by default most services ship a policy file consisting of only the"},{"line_number":32,"context_line":"admin/non-admin distinction using the admin role (Note that you must have some"},{"line_number":33,"context_line":"role on the project to be authenticated but there is no need to define this"},{"line_number":34,"context_line":"role by name).  A result of this is largely the all powerful admin role that"},{"line_number":35,"context_line":"must be created in deployments and overly powerful service users."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Having shipped these policy files we then expect deployers to customize them to"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_0bc52c8d","line":34,"range":{"start_line":34,"start_character":36,"end_line":34,"end_character":43},"updated":"2016-04-25 05:19:23.000000000","message":"largely?","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"2a0dff887661209205634600a0d49d61e7e221a9","unresolved":false,"context_lines":[{"line_number":31,"context_line":"schema by default most services ship a policy file consisting of only the"},{"line_number":32,"context_line":"admin/non-admin distinction using the admin role (Note that you must have some"},{"line_number":33,"context_line":"role on the project to be authenticated but there is no need to define this"},{"line_number":34,"context_line":"role by name).  A result of this is largely the all powerful admin role that"},{"line_number":35,"context_line":"must be created in deployments and overly powerful service users."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Having shipped these policy files we then expect deployers to customize them to"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_c93a0acd","line":34,"range":{"start_line":34,"start_character":36,"end_line":34,"end_character":43},"in_reply_to":"1a122d0e_0bc52c8d","updated":"2016-04-25 18:28:15.000000000","message":"Done","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"**admin**: Due to its prevalence today, we need to maintain the \u0027admin\u0027 role. A"},{"line_number":74,"context_line":"user with this role is all powerful and is expected to be able to do anything"},{"line_number":75,"context_line":"in OpenStack. Ideally this scope would only extend to the project the user has"},{"line_number":76,"context_line":"the role on (like all roles should), however there are circumstances today"},{"line_number":77,"context_line":"where the admin role implies having admin on the entire deployment and is"},{"line_number":78,"context_line":"capable of doing things in other projects. This role should be strictly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_6ba4a0b8","line":75,"range":{"start_line":75,"start_character":14,"end_line":75,"end_character":21},"updated":"2016-04-25 05:19:23.000000000","message":"That\u0027s putting it mildly... That the admin role extends beyond the project to which it is granted is a huge problem that urgently needs a solution.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"2a0dff887661209205634600a0d49d61e7e221a9","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"**admin**: Due to its prevalence today, we need to maintain the \u0027admin\u0027 role. A"},{"line_number":74,"context_line":"user with this role is all powerful and is expected to be able to do anything"},{"line_number":75,"context_line":"in OpenStack. Ideally this scope would only extend to the project the user has"},{"line_number":76,"context_line":"the role on (like all roles should), however there are circumstances today"},{"line_number":77,"context_line":"where the admin role implies having admin on the entire deployment and is"},{"line_number":78,"context_line":"capable of doing things in other projects. This role should be strictly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_89a5b205","line":75,"range":{"start_line":75,"start_character":14,"end_line":75,"end_character":21},"in_reply_to":"1a122d0e_6ba4a0b8","updated":"2016-04-25 18:28:15.000000000","message":"So the reason i ditched the global_ specific roles is we merged the admin-project spec in keystone [1]. This is deemed to fix bug #968696 on exactly this. \n\nGiven this is now in keystone/openstack - do you think we need to distinguish between admin and global roles here. My feeling (and i tried to express) is that we can now say that admin scoped roles will be indicated by the presence of is_admin_project in tokens and so we don\u0027t need thes roles.\n\n[1] https://github.com/openstack/keystone-specs/blob/master/specs/keystone/mitaka/is_admin_project.rst","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":87,"context_line":"available from the service catalog. For example there would be a"},{"line_number":88,"context_line":"*_compute_admin_* and an *_image_admin_* role and not a *nova_admin* or"},{"line_number":89,"context_line":"*glance_admin* role. In the same way as _admin_ these are ideally scoped to the"},{"line_number":90,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":91,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_ebf3909d","line":91,"range":{"start_line":90,"start_character":21,"end_line":91,"end_character":22},"updated":"2016-04-25 05:19:23.000000000","message":"Unless this depends on adding the concept of global role assignments (which can currently only be project or domain scoped), it will extend the colossal problem we have today that the admin role can do things across projects even when it is scoped to a project. We must not do that. One role (admin) that can do things beyond its scope is already one too many.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"2a0dff887661209205634600a0d49d61e7e221a9","unresolved":false,"context_lines":[{"line_number":87,"context_line":"available from the service catalog. For example there would be a"},{"line_number":88,"context_line":"*_compute_admin_* and an *_image_admin_* role and not a *nova_admin* or"},{"line_number":89,"context_line":"*glance_admin* role. In the same way as _admin_ these are ideally scoped to the"},{"line_number":90,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":91,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_69a816dc","line":91,"range":{"start_line":90,"start_character":21,"end_line":91,"end_character":22},"in_reply_to":"1a122d0e_ebf3909d","updated":"2016-04-25 18:28:15.000000000","message":"see above on is_admin_project.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":2218,"name":"Adam Young","email":"adam@younglogic.com","username":"ayoung"},"change_message_id":"4360aa350bde3dbe439429c0d31438e8bcd28145","unresolved":false,"context_lines":[{"line_number":90,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":91,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9a061dce_e9513710","line":93,"updated":"2016-04-04 12:56:06.000000000","message":"Add Member in here.  Member is the expected role for customers, and implies \"writable\" access on non-sensitive resources.  For Nova, Member is the ability to launch and destroy VMs.  For Cinder, Member is the ability to create volumes.\n\nWe can allow {service_type}_member roles as implied roles of member, but they should not be the norm.  The only case I know of where they are needed is Neutron, where some deployers want to be able to turn off \"create/delete networks, subnets, and interfaces\" from end users, but still allow \"attach and detach.\"","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"2a0dff887661209205634600a0d49d61e7e221a9","unresolved":false,"context_lines":[{"line_number":90,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":91,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_09ba4223","line":93,"in_reply_to":"1a122d0e_cb5a1483","updated":"2016-04-25 18:28:15.000000000","message":"That\u0027s a really good point on is:observer - i will need to think about that. Are you at summit we can discuss?","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":90,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":91,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_cb5a1483","line":93,"in_reply_to":"9a061dce_6ebfc9fb","updated":"2016-04-25 05:19:23.000000000","message":"That falls apart when we add the observer role, unless we are going to specifically add \"and not role:observer\" to things that an observer shouldn\u0027t be able to do. And that would put the burden on the policy creator to remember to add that everywhere it\u0027s appropriate. It would be much safer to have to opt-in allowing someone to do something than to have to opt-out.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"895fe2ccfd7274c7a503a305feb7376b5c336db8","unresolved":false,"context_lines":[{"line_number":90,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":91,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9a061dce_6ebfc9fb","line":93,"in_reply_to":"9a061dce_e9513710","updated":"2016-04-05 01:54:18.000000000","message":"I don\u0027t want to deal with a required role hierarchy in this spec. So long as the roles are specified how they are constructed is not really relevant here. \n\nI hvae this as a note a few paragraphs down. Why do we need an explicit member role (and why is it capitalized) defined here? It\u0027d be nice if these were all the same across deployments but i don\u0027t think i ever want to explicity test for Member in policy, just that it\u0027s got _a_ role in a project.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":90,"context_line":"project however they convey the ability to do operations that are across"},{"line_number":91,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_8b12dcb2","line":93,"in_reply_to":"9a061dce_e9513710","updated":"2016-04-25 05:19:23.000000000","message":"it\u0027s not that simple. In order to launch a VM, you have to be able to create a volume, a network port, etc. Until/unless we fix that (by having the nova-to-other-service call use a trust?), your \"compute_member\" would have to also be a \"storage_member\", etc.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":97,"context_line":"accountant, the auditor, or the observer role."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_0b27ec12","line":95,"range":{"start_line":95,"start_character":10,"end_line":95,"end_character":49},"updated":"2016-04-25 05:19:23.000000000","message":"again, we\u0027re exacerbating the problem we have today of a role being granted with project scope and yet being allowed to do things beyond that project. If we want a global role, then we need to create the concept of global role assignments to go along with the existing concepts of project and domain-scoped assignments. Then this is not the nature of the role, but depends on the scope. You could just as easily make a case for a project-scoped observer, or a domain-scoped observer, as for a global observer. Allow them all by 1) creating an observer role and 2) creating the global role assignment concept.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"2a0dff887661209205634600a0d49d61e7e221a9","unresolved":false,"context_lines":[{"line_number":92,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":97,"context_line":"accountant, the auditor, or the observer role."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_29ec5e28","line":95,"range":{"start_line":95,"start_character":10,"end_line":95,"end_character":49},"in_reply_to":"1a122d0e_0b27ec12","updated":"2016-04-25 18:28:15.000000000","message":"i think this is all covered by is_admin_project. There are some migration issues in adopting this but I think it solves the problem.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":97,"context_line":"accountant, the auditor, or the observer role."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":100,"context_line":"available within a specific service, regardless of tenancy, but have no access"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_4b21e4fa","line":97,"range":{"start_line":97,"start_character":0,"end_line":97,"end_character":45},"updated":"2016-04-25 05:19:23.000000000","message":"There are a large number of OpenStack deployments with customized policy files calling this the \"viewer\" role.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"2a0dff887661209205634600a0d49d61e7e221a9","unresolved":false,"context_lines":[{"line_number":94,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":95,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":96,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":97,"context_line":"accountant, the auditor, or the observer role."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":100,"context_line":"available within a specific service, regardless of tenancy, but have no access"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_6944961a","line":97,"range":{"start_line":97,"start_character":0,"end_line":97,"end_character":45},"in_reply_to":"1a122d0e_4b21e4fa","updated":"2016-04-25 18:28:15.000000000","message":"I take it here you want me to add viewer as an alternative? not that you want me to rename observer-\u003eviewer?","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"0fab9c07a4110ae35ec0308749cb36645821077f","unresolved":false,"context_lines":[{"line_number":133,"context_line":"enforce that operations that are not project specific should be performed only"},{"line_number":134,"context_line":"with the is_admin_project flag."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"This behaviour of cross project operations based on the presence of the flag"},{"line_number":137,"context_line":"will also be applied to the roles specified here such that"},{"line_number":138,"context_line":"*{service_type}_admin* etc should be granted within the admin project to"},{"line_number":139,"context_line":"perform cross project admin operations."}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_6bf1406a","line":136,"range":{"start_line":136,"start_character":43,"end_line":136,"end_character":76},"updated":"2016-04-25 05:19:23.000000000","message":"only keystone cares about that flag today, and I\u0027ve seen nothing to give me hope of other services taking it up. If we\u0027re aiming for that here, there needs to be much more emphasis on this.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":7191,"name":"Jamie Lennox","email":"jamielennox@gmail.com","username":"jamielennox"},"change_message_id":"2a0dff887661209205634600a0d49d61e7e221a9","unresolved":false,"context_lines":[{"line_number":133,"context_line":"enforce that operations that are not project specific should be performed only"},{"line_number":134,"context_line":"with the is_admin_project flag."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"This behaviour of cross project operations based on the presence of the flag"},{"line_number":137,"context_line":"will also be applied to the roles specified here such that"},{"line_number":138,"context_line":"*{service_type}_admin* etc should be granted within the admin project to"},{"line_number":139,"context_line":"perform cross project admin operations."}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a122d0e_a96d0e9b","line":136,"range":{"start_line":136,"start_character":43,"end_line":136,"end_character":76},"in_reply_to":"1a122d0e_6bf1406a","updated":"2016-04-25 18:28:15.000000000","message":"Well it only got released in Mitaka so most projects will lag a little here. I am expecting that the cleanup of policy involved in implementing this spec will coincide with the proliferation of is_admin_project.\n\nI just don\u0027t want to hit every project multiple times. If we can get this approved we can try and improve everyone\u0027s policy at once.\n\nI also expect some things to be discussed around policy at the summit so i\u0027m wanting to know the outcome of those talks as well.","commit_id":"32ea552b17f603ce638d2d935f4405d56a8dbd7d"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"3a05ed6392de5780aa0ff0e5618d26289e6b2188","unresolved":false,"context_lines":[{"line_number":34,"context_line":"admin/non-admin distinction using the admin role (Note that you must have some"},{"line_number":35,"context_line":"role on the project to be authenticated but there is no need to define this"},{"line_number":36,"context_line":"role by name).  A result of this is the all powerful admin role that must be"},{"line_number":37,"context_line":"created in deployments and overly powerful service users."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Having shipped these policy files we then expect deployers to customize them to"},{"line_number":40,"context_line":"suit their needs. However, as these are security critical files that must be"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7ffa3b31_bf9b73c7","line":37,"updated":"2017-04-17 22:12:41.000000000","message":"It\u0027s actually even worse than this - we can\u0027t create application accounts with locked down privileges, because there is probably some service somewhere that allows full access to it for any account with any role in the project.\n\nEnd users can *maybe* do it, if their deployment is appropriately customised, but their application certainly won\u0027t be portable to other clouds. But we can\u0027t build support for that into OpenStack application deployment tools like Heat because we have to assume the default policy. And we certainly can\u0027t do it for application-layer things that are part of OpenStack itself (think: Trove, Sahara).\n\nThis proposed TC resolution discusses the problem:\n\nhttps://review.openstack.org/#/c/447031/5/resolutions/20170317-cloud-applications-mission.rst","commit_id":"dc6090b1454a48f8447384e0a03c37a280c2a050"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"e024be34ee0af6e596415221687bb16c06f1577e","unresolved":false,"context_lines":[{"line_number":93,"context_line":"projects when required. Eg. The *identity_admin* role should be able to create"},{"line_number":94,"context_line":"new domains, something for which there is not an obvious project to scope to."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"**observer**: The observer role allows a user to discover the resources"},{"line_number":97,"context_line":"available across OpenStack, regardless of tenancy, but have no access to"},{"line_number":98,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":99,"context_line":"accountant, the auditor, viewer, or the observer role."}],"source_content_type":"text/x-rst","patch_set":8,"id":"1a122d0e_54e313a4","line":96,"updated":"2016-04-26 20:30:46.000000000","message":"Do we want different types of observer (admin observer, member observer, etc...)?\n\nDo we break this up between \"system-level observer\" and \"end user level observer\"?","commit_id":"dc6090b1454a48f8447384e0a03c37a280c2a050"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"e024be34ee0af6e596415221687bb16c06f1577e","unresolved":false,"context_lines":[{"line_number":98,"context_line":"create, modify, or delete resources. This has been termed variously the"},{"line_number":99,"context_line":"accountant, the auditor, viewer, or the observer role."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"**{service_type}_observer**: A role allows a user to discover the resources"},{"line_number":102,"context_line":"available within a specific service, regardless of tenancy, but have no access"},{"line_number":103,"context_line":"to create, modify, or delete resources."},{"line_number":104,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"1a122d0e_d4b3a398","line":101,"updated":"2016-04-26 20:30:46.000000000","message":"On behalf of ayoung: can we have a {service_type}_member?","commit_id":"dc6090b1454a48f8447384e0a03c37a280c2a050"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"3a05ed6392de5780aa0ff0e5618d26289e6b2188","unresolved":false,"context_lines":[{"line_number":106,"context_line":"OpenStack as a user is part of a project if they have a role on that project."},{"line_number":107,"context_line":"The name of this role is not important here because we don\u0027t test for it"},{"line_number":108,"context_line":"specifically for project membership, for most operations we just want to know a"},{"line_number":109,"context_line":"user has any role in a project."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Related Features"},{"line_number":112,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7ffa3b31_ff021bb4","line":109,"updated":"2017-04-17 22:12:41.000000000","message":"So, I think this is the wrong approach and ayoung is correct to ask for a {service_type}_member role as well.\n\nIt\u0027s wrong because you\u0027re essentially blacklisting the *_observer roles from writing stuff, while all other roles get full write access (except to admin-only stuff). A true RBAC system needs to *whitelist* access to stuff by role. There\u0027s still no way to create locked down application accounts if we don\u0027t do it that way.\n\nJohn\u0027s proposed Nova spec does it right IMO: https://review.openstack.org/#/c/427872/19 - I\u0027d like to see this spec generalise something similar to that across all of OpenStack.","commit_id":"dc6090b1454a48f8447384e0a03c37a280c2a050"},{"author":{"_account_id":17860,"name":"Samuel de Medeiros Queiroz","email":"samueldmq@gmail.com","username":"samueldmq"},"change_message_id":"837032ed554a3926b90a991a65863141336d71d7","unresolved":false,"context_lines":[{"line_number":135,"context_line":"enforce that operations that are not project specific should be performed only"},{"line_number":136,"context_line":"with the is_admin_project flag."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"This behaviour of cross project operations based on the presence of the flag"},{"line_number":139,"context_line":"will also be applied to the roles specified here such that"},{"line_number":140,"context_line":"*{service_type}_admin* etc should be granted within the admin project to"},{"line_number":141,"context_line":"perform cross project admin operations."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":".. _Implied roles: https://review.openstack.org/#/c/125704/"},{"line_number":144,"context_line":".. _Admin Project: https://review.openstack.org/#/c/242232/"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9a89bdaa_821a3c6d","line":141,"range":{"start_line":138,"start_character":0,"end_line":141,"end_character":39},"updated":"2016-09-02 19:37:37.000000000","message":"So perhaps we want another admin and observer roles that respect project isolation?","commit_id":"dc6090b1454a48f8447384e0a03c37a280c2a050"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"3a05ed6392de5780aa0ff0e5618d26289e6b2188","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"   * - Release Name"},{"line_number":231,"context_line":"     - Description"},{"line_number":232,"context_line":"   * - Mitaka"},{"line_number":233,"context_line":"     - Introduced"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7ffa3b31_7fddeb40","line":232,"updated":"2017-04-17 22:12:41.000000000","message":":(","commit_id":"dc6090b1454a48f8447384e0a03c37a280c2a050"}]}