Activity log for bug #1699060

Date Who What changed Old value New value Message
2017-06-20 08:35:38 Valeriy Ponomaryov bug added bug
2017-06-20 08:35:53 Valeriy Ponomaryov bug task added manila
2017-06-20 08:37:57 Valeriy Ponomaryov description We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner",
2017-06-20 08:38:19 Valeriy Ponomaryov tags policy
2017-06-20 08:38:26 Valeriy Ponomaryov bug task added nova
2017-06-20 08:38:38 Valeriy Ponomaryov bug task added neutron
2017-06-20 08:40:07 Valeriy Ponomaryov bug task added glance
2017-06-20 08:40:21 Valeriy Ponomaryov bug task added murano
2017-06-20 08:40:31 Valeriy Ponomaryov bug task added heat
2017-06-20 08:41:52 Valeriy Ponomaryov description We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules.
2017-06-20 08:43:15 Valeriy Ponomaryov description We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules. We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules.
2017-06-20 11:44:09 Valeriy Ponomaryov bug task added watcher
2017-06-20 11:52:31 Valeriy Ponomaryov bug task added ceilometer
2017-06-20 11:57:49 Valeriy Ponomaryov bug task added aodh
2017-06-20 11:58:37 Valeriy Ponomaryov bug task added panko
2017-06-20 12:42:29 gordon chung bug task deleted aodh
2017-06-20 12:42:37 gordon chung bug task deleted ceilometer
2017-06-20 12:42:52 gordon chung bug task deleted panko
2017-06-20 13:44:46 Valeriy Ponomaryov description We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules. We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules. Related mail-list thread: https://openstack.nimeyo.com/115438/openstack-dev-all-policy-rules-for-apis-based-on-domain_id
2017-06-20 20:11:19 Kirill Zaitsev bug task deleted murano
2017-06-22 09:43:58 Alexey 'Armenelruth' V.A. bug added subscriber Alexey Abashkin
2017-06-23 16:57:50 Sean Dague nova: status New Opinion
2017-06-23 16:57:59 Sean Dague nova: importance Undecided Wishlist
2017-07-05 10:32:22 Rico Lin heat: status New Triaged
2017-07-05 10:32:31 Rico Lin heat: importance Undecided Wishlist
2018-01-18 15:39:21 Ben Swartzlander manila: importance Undecided Wishlist
2018-01-18 15:39:25 Ben Swartzlander manila: status New Opinion
2018-01-18 15:54:33 Sean McGinnis bug task added oslo.policy
2018-01-18 15:54:55 Sean McGinnis bug task deleted cinder
2018-01-30 12:12:48 Akihiro Motoki neutron: status New Opinion
2018-01-30 12:12:56 Akihiro Motoki neutron: importance Undecided Wishlist
2018-02-28 12:27:25 Alexander Chadin watcher: importance Undecided Wishlist
2018-02-28 12:27:29 Alexander Chadin watcher: status New Opinion
2018-05-07 08:08:37 Rico Lin heat: milestone no-priority-tag-bugs
2018-07-30 17:32:15 Ben Nemec oslo.policy: status New Incomplete
2018-07-30 17:32:23 Ben Nemec oslo.policy: importance Undecided Wishlist
2018-10-24 18:59:11 Morgan Fainberg oslo.policy: status Incomplete Invalid