)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"42c50ada8f42d248576222d6b3ff597f056528a9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"31f60e22_13f0aef3","updated":"2022-01-29 14:19:38.000000000","message":"-1 until we get some consensus on DB migrations and system vs project scoping.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"de897eba4de369628f54577c573e450065136cab","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"945de2ca_08a202b2","updated":"2022-01-28 16:32:11.000000000","message":"LGTM","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"7b94ec9ad2207bd8623712d2f9a93a6a4ee6e997","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4943fe24_57699aa9","updated":"2022-01-20 18:39:42.000000000","message":"overall lgtm, 1 comment to clarify the scope enforcement for service role.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"ac89fa210308a9705ac6cac69e1f0c61e83d355e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"cd82f1a5_30ab8679","updated":"2022-04-13 09:51:16.000000000","message":"No change since last patch","commit_id":"e0f27814ca6822786d1ed74aa946123cca3eea4d"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f9a74bde5277d0e67b18c70089cef285020d21c7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"1cc590f0_69dab0fa","updated":"2022-10-25 16:03:01.000000000","message":"I agree with this spec except for the issue Ghanshyam identified.  I\u0027d prefer that to be changed as he suggests before this is merged.","commit_id":"8105af43f338274c7e39e45fc60d66195f1bfa87"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"a98f42a3af34a98ccfe0a60837c15bbd3dce9f9a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"a6c39362_e340f870","updated":"2022-10-27 13:51:47.000000000","message":"Revision LGTM.","commit_id":"c522f55050ad88c4e4f7eaa3dff10c1181dc5eb3"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"1e01bc542c45a14b2369b1153c90973c5e9bafdd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"39e85f46_38a3836b","updated":"2022-11-09 14:33:19.000000000","message":"Revision (adding Abhishek as implementor) LGTM!","commit_id":"81d836e7bf9f6a6cd0a5be6cc9a1ca3926331ee3"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d4ea288ebc74a745238f8a08b1933daba5543bab","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"e3bd96e6_d4d3a247","updated":"2022-11-09 16:33:11.000000000","message":"Thanks Abhishek for the help, really appreciate. ","commit_id":"81d836e7bf9f6a6cd0a5be6cc9a1ca3926331ee3"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"0f60be060e9cfb739ac10eca61329869ce980136","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"35daba9b_d72376dd","updated":"2022-11-23 16:52:37.000000000","message":"@Ghanshyam: good catch on PS6!  This version LGTM.","commit_id":"75b4fb25c5b6e2c6ef4b0157c98eeb17c777c054"},{"author":{"_account_id":14250,"name":"Grzegorz Grasza","email":"xek@redhat.com","username":"xek"},"change_message_id":"473e7347cdf3123e0d1af1dbcccd64d3a57f581e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"a2833b8f_a74a0069","updated":"2022-12-02 08:37:41.000000000","message":"LGTM!","commit_id":"75b4fb25c5b6e2c6ef4b0157c98eeb17c777c054"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"b0c427a3e2c78cccf124e904d61a5ee90c1f3012","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"894fab0b_42ef7d63","updated":"2022-11-18 15:59:04.000000000","message":"Looks good to me. Though I believe Lance is not going to be driving this so can be removed from Assignees. (can be a follow-up patch)","commit_id":"75b4fb25c5b6e2c6ef4b0157c98eeb17c777c054"},{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"1a0630e651d18399260f854edc0d019ee241aaf2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"bc582a7f_dd77f35c","updated":"2022-11-30 04:39:46.000000000","message":"This looks good to me.","commit_id":"75b4fb25c5b6e2c6ef4b0157c98eeb17c777c054"}],"specs/keystone/2023.1/default-service-role.rst":[{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"22e1b31712489f3663eb1e42f61ceb3c85464e30","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"   policy.DocumentedRuleDefault("},{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"29f0e314_987d90c2","line":70,"range":{"start_line":70,"start_character":17,"end_line":70,"end_character":45},"updated":"2022-10-21 15:18:00.000000000","message":"we should not allow admin here instead only service role and if anyone want to give user access to such APIs then override the policy file.","commit_id":"8105af43f338274c7e39e45fc60d66195f1bfa87"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"f9a74bde5277d0e67b18c70089cef285020d21c7","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"   policy.DocumentedRuleDefault("},{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"eab68c3b_c71a130b","line":70,"range":{"start_line":70,"start_character":17,"end_line":70,"end_character":45},"in_reply_to":"29f0e314_987d90c2","updated":"2022-10-25 16:03:01.000000000","message":"I agree with Ghanshyam, we need to be careful with the example code because people will tend to copy it.  The API call governed by the policy in this example was specifically designed to be used only by services, so there would be no reason for an admin to make the call.\n\nThere may be cases where it would make sense to have admin-or-service as the default (for example, when only a service can create some entity, but an admin may need to be able to delete it in case the operation was interrupted and the entity is left hanging around), but let\u0027s let the projects figure those out themselves.  I think the example should be service-only to prevent unthinking extension of these service-only API calls.","commit_id":"8105af43f338274c7e39e45fc60d66195f1bfa87"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"483f16cdc52cb2f4470b01d7fb4d09e919d3c54c","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"   policy.DocumentedRuleDefault("},{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fb009295_d79e6973","line":70,"range":{"start_line":70,"start_character":17,"end_line":70,"end_character":45},"in_reply_to":"eab68c3b_c71a130b","updated":"2022-10-25 18:17:24.000000000","message":"done","commit_id":"8105af43f338274c7e39e45fc60d66195f1bfa87"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"f9f1333083010ebb8be00f5364b6ecac16c10f43","unresolved":false,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"   policy.DocumentedRuleDefault("},{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"85ac98c9_324dbdf0","line":70,"range":{"start_line":70,"start_character":17,"end_line":70,"end_character":45},"in_reply_to":"fb009295_d79e6973","updated":"2022-11-14 01:04:46.000000000","message":"Done","commit_id":"8105af43f338274c7e39e45fc60d66195f1bfa87"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"7b24e16a6251af3bdedd56e7dcc08faeb89905ec","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"   policy.DocumentedRuleDefault("},{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"5fe455e2_fdc6c6f7","line":70,"range":{"start_line":70,"start_character":17,"end_line":70,"end_character":46},"updated":"2022-11-14 01:01:31.000000000","message":"seems like this update done in PS5 got reverted in PS6. fixing it","commit_id":"81d836e7bf9f6a6cd0a5be6cc9a1ca3926331ee3"}],"specs/keystone/yoga/default-service-role.rst":[{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"f183ec0a03ae4493a64dfa7b1925b589807c70a9","unresolved":true,"context_lines":[{"line_number":44,"context_line":"Proposed Change"},{"line_number":45,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Expand the ``keystone-manage bootstrap`` utility to create a new role named"},{"line_number":48,"context_line":"``service``. Conflicts should be handled gracefully, especially since some"},{"line_number":49,"context_line":"policies in OpenStack rely on the ``service`` role already and it\u0027s entirely"},{"line_number":50,"context_line":"plausible that operators have created this role already. Existing roles"}],"source_content_type":"text/x-rst","patch_set":1,"id":"650aceab_92fb69a2","line":47,"range":{"start_line":47,"start_character":13,"end_line":47,"end_character":38},"updated":"2022-01-24 09:39:43.000000000","message":"Will there be a DB migration to apply this during upgrades?","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"ded8eafee74cb66c3ed731c1d1e983b9896027cc","unresolved":true,"context_lines":[{"line_number":44,"context_line":"Proposed Change"},{"line_number":45,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Expand the ``keystone-manage bootstrap`` utility to create a new role named"},{"line_number":48,"context_line":"``service``. Conflicts should be handled gracefully, especially since some"},{"line_number":49,"context_line":"policies in OpenStack rely on the ``service`` role already and it\u0027s entirely"},{"line_number":50,"context_line":"plausible that operators have created this role already. Existing roles"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f111212e_2bd438f9","line":47,"range":{"start_line":47,"start_character":13,"end_line":47,"end_character":38},"in_reply_to":"650aceab_92fb69a2","updated":"2022-01-28 16:31:42.000000000","message":"``keystone-manage bootstrap`` is idempotent, so the guidance for an upgrade would be to run the command again.  The ``keystone-manage`` bootstrap will only add a ``service`` role if it does not already exist.  Given that this does not affect the DB schema, I don\u0027t think a DB migration is necessary.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"0c5e7f34866b7ebb8d555b144c3b1e6d7731f276","unresolved":true,"context_lines":[{"line_number":44,"context_line":"Proposed Change"},{"line_number":45,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Expand the ``keystone-manage bootstrap`` utility to create a new role named"},{"line_number":48,"context_line":"``service``. Conflicts should be handled gracefully, especially since some"},{"line_number":49,"context_line":"policies in OpenStack rely on the ``service`` role already and it\u0027s entirely"},{"line_number":50,"context_line":"plausible that operators have created this role already. Existing roles"}],"source_content_type":"text/x-rst","patch_set":1,"id":"18f33020_468cf4e2","line":47,"range":{"start_line":47,"start_character":13,"end_line":47,"end_character":38},"in_reply_to":"b727e822_4fc708bc","updated":"2022-02-22 15:10:52.000000000","message":"Any update on this?","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"53c08ddeb6d740b26e27f95f0288b1db8da53ade","unresolved":true,"context_lines":[{"line_number":44,"context_line":"Proposed Change"},{"line_number":45,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Expand the ``keystone-manage bootstrap`` utility to create a new role named"},{"line_number":48,"context_line":"``service``. Conflicts should be handled gracefully, especially since some"},{"line_number":49,"context_line":"policies in OpenStack rely on the ``service`` role already and it\u0027s entirely"},{"line_number":50,"context_line":"plausible that operators have created this role already. Existing roles"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b727e822_4fc708bc","line":47,"range":{"start_line":47,"start_character":13,"end_line":47,"end_character":38},"in_reply_to":"f111212e_2bd438f9","updated":"2022-01-28 16:56:20.000000000","message":"While that may work, it\u0027s not in the documented keystone upgrade procedure: https://docs.openstack.org/keystone/latest/admin/upgrading.html","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"7b94ec9ad2207bd8623712d2f9a93a6a4ee6e997","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"00f20ff6_65c5f340","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"updated":"2022-01-20 18:39:42.000000000","message":"One thing to mention explicitly, for \u0027service\u0027 token/role-policy, we will still enforce the same scope of APIs. So, for example, in API mentioned in L68, a service role with project scoped will be allowed. And in the case of system-level APIs (not sure if services are accessing the system-level APIs of other services, but in case there is any), a service role with system scope is allowed.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"f183ec0a03ae4493a64dfa7b1925b589807c70a9","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c15ea371_f14fd8f7","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"00f20ff6_65c5f340","updated":"2022-01-24 09:39:43.000000000","message":"There has been some discussion on the ML on this topic.\n\nIn Kolla we are planning to assign the service role to users in the Yoga release, to avoid temporarily giving them system-reader to conform to the new policy defaults (currently they all have admin in the service project). What I\u0027d like to know is, should we assign the service role with project scope or system scope? System makes more sense to me for most of the APIs that services use, however I\u0027d like to go with a common approach.\n\nIt would also be helpful to know whether keystone is on track to meet the yoga timeline outlined in the SRBAC spec (in particular changing the default policies).","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"311d0cc274be4d060206eef0975743cc7bdb5ada","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1038b2d6_a6586f27","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"0564a2f7_a4d4389e","updated":"2022-02-22 14:45:25.000000000","message":"it cannot be system scoped as it is for project level resource. to generate the server external event, you need to know the server-uuid which system user does not have any knowledge of.\n\nThat is why my earlier point was, we will keep scope as per the APIs for user access control and openstack services will access then with special role called \u0027service\u0027 with scope to same as what calling API has.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"91de9d1b37f90f142e09c935571de2bfc445490c","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6e8396be_f723e58a","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"0876532e_e5450e60","updated":"2022-02-21 18:31:05.000000000","message":"I understand that point. And if we can make such API to be used only for OpenStack services then I agree but we cannot do that. These APIs can/are used and seen by users also (admin etc). Even we mention/tell that these are internal APIs and are not meant to be used by other than OpenStack services, there might be someone using them, so for that use case, we need to have proper scope.\n\nI hope we could have a better way to design these internal APIs then your point makes sense. IF we could in some way, I love to make them internal APIs that cannot be used outside of openstack. It helps us in maintenance also.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"0c5e7f34866b7ebb8d555b144c3b1e6d7731f276","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"68728530_8dbf9568","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"1038b2d6_a6586f27","updated":"2022-02-22 15:10:52.000000000","message":"I feel like we are going around in circles here. Yes, it is a project level resource, but in this case the project that owns the resource is not the one that is in scope - it is another \u0027dummy\u0027 project used just to meet this requirement. In any normal API, trying to access the resource of another project would lead to a 403 forbidden error.\n\nAnyway, I\u0027ve made my point a few times over now. I\u0027m not involved in the implementation of this stuff, so perhaps there are things I\u0027m missing.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"efc11a9c989a1ea7d37f5b30d8965e0dc099aff6","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0876532e_e5450e60","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"221cf32d_d75796d1","updated":"2022-02-21 17:01:57.000000000","message":"This sounds like a circular argument to me. If we have to create some dummy project just to use an API, maybe the API should not be project-scoped?","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"41558602a77c71765638c3d9100cb5f046898541","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d3318456_8be4711c","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"31952730_1d4c9964","updated":"2022-02-09 09:15:14.000000000","message":"\u003e this particular policy \u0027os_compute_api:os-server-external-events:create\u0027  will che changed to project scope (project admin), I am in progress of changing those. \n\nWhich project will be in scope for that API? The project of the resource in the event, or the service project?\n\nIs the caller of that API typically a real user or a service user?","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"42c50ada8f42d248576222d6b3ff597f056528a9","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"82e10d0c_82bc5d29","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"5e7c7609_10bc4516","updated":"2022-01-29 14:19:38.000000000","message":"Although these APIs are still in flux, and some (e.g. token validation) allow multiple scopes.\n\nFor any communication that is asynchronous from a user request (e.g. neutron -\u003e nova callbacks), the credentials would need to be generic, and consumed from config. If the credentials were project-scoped, this would not be the project of the associated resource, rather something like the service project. At which point this API looks to me like it should be system-scoped.\n\nIn short, the service project to me mostly seems like an artifact of keystone v2, when everything was project scoped. With v3, surely it is time to free ourselves of this mostly unnecessary project?\n\nThe only case where I can see a use for a service project is where a service creates or owns actual resources that must be associated with a project.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"26b2b50f7dcbf349dcdf705824b7818688f9e6f1","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0564a2f7_a4d4389e","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"6e8396be_f723e58a","updated":"2022-02-22 09:43:47.000000000","message":"Users can still use system-scoped APIs.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d0c5f9e33146aaabe903d0ae74436f696a73bfc3","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"221cf32d_d75796d1","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"75bc0893_221a1fc1","updated":"2022-02-21 16:45:06.000000000","message":"to pass the project scoped policy like external event, user with service role needs to be in some project right? though we do not use that project id for autherization.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"7e195c055677646dd669a62275f4666696c8a44e","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"31952730_1d4c9964","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"772ab162_873d595c","updated":"2022-02-08 20:41:50.000000000","message":"this particular policy \u0027os_compute_api:os-server-external-events:create\u0027  will che changed to project scope (project admin), I am in progress of changing those. \n\nBut yes, even for async call, service role can be scoped to the one used in that particular API policy. Having by default scope is good idea but I will say we can have it as project scoped as that will be most of the service-to-service communication.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d4a6a12a568378e4358832fd7fe53079ef483259","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"be406d4d_28a308c8","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"82e10d0c_82bc5d29","updated":"2022-01-29 20:05:20.000000000","message":"\u003eAlthough these APIs are still in flux, and some (e.g. token validation) allow multiple scopes.\n\nYes, in this case like token validation using any scope is fine as they all are allowed.\n\n\n\u003eFor any communication that is asynchronous from a user request (e.g. neutron -\u003e nova callbacks), \n\nAny example of such callback which is not via APIs? I think every service-to-service communication is via APIs and each API is scoped to either project, system, or domain. That is why I think using the same allowed scopes what APIs allow is right way for \u0027service\u0027 role also.\n\nI do not think should allow \u0027service\u0027 role without scope checks that can open a security issue for users accessing with \u0027service\u0027 role. Even for service-to-ervice communication, scope has to be same/enforced as what APIs is and users does.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"1b19861c2423a1ed0ef035dd863b654a061c9e0d","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5e7c7609_10bc4516","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"a5058bba_7511735c","updated":"2022-01-29 02:36:05.000000000","message":"for scope for service role, yes it will be same as what scope if there for default policy. IMO (as I mentioned in ML[1]), any project will use the service role to communicate to other service with the scope default to that particular API. For example, neutron will call nova\u0027s server external APIs (which is scoped to project) with service role and project scoped token.\n\nI am not sure if any system level APIs are called between services if so then system scope will be used with service role.\n\n[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026789.html","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"cb075e852a183d0425d9834264cd416b6b0b915a","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"772ab162_873d595c","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"be406d4d_28a308c8","updated":"2022-02-08 10:27:38.000000000","message":"\u003e Yes, in this case like token validation using any scope is fine as they all are allowed.\n\nYes, understood. As a deployment tool, Kolla Ansible needs to choose which scope to assign the service role to service users, and I\u0027m trying to work out what is the best choice.\n \n\u003e \n\u003e Any example of such callback which is not via APIs? I think every service-to-service communication is via APIs and each API is scoped to either project, system, or domain. That is why I think using the same allowed scopes what APIs allow is right way for \u0027service\u0027 role also.\n\u003e \n\u003e I do not think should allow \u0027service\u0027 role without scope checks that can open a security issue for users accessing with \u0027service\u0027 role. Even for service-to-ervice communication, scope has to be same/enforced as what APIs is and users does.\n\nI\u0027m not suggesting we remove any scope checks. When I said callback I was referring to API calls, but those which are not generated synchronously with a user request, and so don\u0027t have the user\u0027s context.\n\nAn example is the nova external events API, which neutron calls asynchronously, currently using an \u0027admin\u0027 context.\n\nhttps://docs.openstack.org/api-ref/compute/?expanded\u003drun-events-detail#create-external-events-os-server-external-events\n\nHere\u0027s the policy:\n\nos_compute_api:os-server-external-events:create\nDefault\nrule:system_admin_api\n\nOperations\nPOST /os-server-external-events\n\nScope Types\nsystem\n\nCreate one or more external events\n\nSo it needs a system-scoped admin role, which doesn\u0027t really help us here.\n\nOverall, I\u0027m still inclined towards a setup where service users have a system-scoped service role by default and get project-scoped roles where necessary.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"ded8eafee74cb66c3ed731c1d1e983b9896027cc","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a5058bba_7511735c","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"c15ea371_f14fd8f7","updated":"2022-01-28 16:31:42.000000000","message":"I don\u0027t know whether service to service integration uses mainly project or system scoped APIs.  I think that many will be project-level APIs given that system scope is relatively new.  My suggestion would be to grant the \"service\" role on the \"service\" project as shown below (lines 79-83)","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"40418e7ef9b323236ed57e7ef7592da590945974","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f25e9a83_0fd3432e","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"d3318456_8be4711c","updated":"2022-02-09 09:27:30.000000000","message":"I agree that project scope makes sense in many cases, but for this particular API I\u0027m not so sure.\n\nhttps://opendev.org/openstack/neutron/src/commit/f324ddf769b9d9b68530a191dcf2e419ff2c25d4/neutron/notifiers/nova.py#L88\n\nThe nova client created by neutron for this purpose does not use a user context, it uses auth config in the [nova] section. Currently this is a user with the admin role. The user will not realistically have a role in the project of the resource that it is generating an event about, so I don\u0027t see how a project-scoped API could work.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"a6ad72388f2f2b429bc645ba6527fb04463aa172","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"75bc0893_221a1fc1","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"d8d91eee_c81ad9e2","updated":"2022-02-21 09:42:26.000000000","message":"It sounds like it could work, I just don\u0027t understand why we need a service project.","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b70499f5fba19b57cd950930e7f00eef38022387","unresolved":true,"context_lines":[{"line_number":69,"context_line":"       name\u003d\u0027os_compute_api:os-server-external-events:create\u0027,"},{"line_number":70,"context_line":"       check_str\u003d\u0027role:admin or role:service\u0027,"},{"line_number":71,"context_line":"       scope_types\u003d[\u0027project\u0027]"},{"line_number":72,"context_line":"   )"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Additionally, any deployment tools that create service accounts for OpenStack"},{"line_number":75,"context_line":"services, should start preparing for these policy changes by updating their"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d8d91eee_c81ad9e2","line":72,"range":{"start_line":72,"start_character":3,"end_line":72,"end_character":4},"in_reply_to":"f25e9a83_0fd3432e","updated":"2022-02-20 15:34:41.000000000","message":"In this (server external event APIs) case, as per new guidelines, neutron\u0027s get port is project scoped and from there neutron gets the server-uuid (device-id from port) to send the external event to nova. So we can modify the  \u0027os_compute_api:os-server-external-events:create\u0027 to project scoped.\n\nWith service role, below can be the flow:\n\n-  \u0027os_compute_api:os-server-external-events:create\u0027 scoped to project and default to check_str\u003d\u0027role:admin or role:service\u0027 (as proposed in this spec @L68)\n- neutron is configured in nova section with users belong to service project and role assigned as \u0027service\u0027 (we do not need admin role assignment for service user).\n- neutron call nova API with that project scoped and \u0027service\u0027 role with service project id. neutron does not need to send the project-id of servers it is generating the event for.\n- Nova policy will pass as calling user is \u0027service\u0027 role. Nova will not check any project-id in this call.\n\nDoes it sound good?","commit_id":"219e3d1a15f2114949654de19599f97346e33da0"}]}