)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":5,"context_line":"CommitDate: 2021-06-16 17:58:58 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Policy layer refactoring"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: I43dd686118374d1320d15fc85bca716cc1010ff0"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"ad90661f_6570e28d","line":8,"updated":"2021-06-17 14:56:01.000000000","message":"Related-Bug: https://bugs.launchpad.net/glance/+bug/1915582","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"6e16969945e61dbc526188351f274a28b3045a67","unresolved":false,"context_lines":[{"line_number":5,"context_line":"CommitDate: 2021-06-16 17:58:58 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Policy layer refactoring"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: I43dd686118374d1320d15fc85bca716cc1010ff0"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"b67b6079_6bee6f05","line":8,"in_reply_to":"67b67ff1_a058af3e","updated":"2021-06-22 05:35:43.000000000","message":"Done","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":true,"context_lines":[{"line_number":5,"context_line":"CommitDate: 2021-06-16 17:58:58 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Policy layer refactoring"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Change-Id: I43dd686118374d1320d15fc85bca716cc1010ff0"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"67b67ff1_a058af3e","line":8,"in_reply_to":"ad90661f_6570e28d","updated":"2021-06-17 15:09:49.000000000","message":"Will do it in next revision!","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"}],"specs/xena/approved/glance/glance-policy-refactoring.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":13,"context_line":"During implementation of V2 Image API in glance an Onion layered architecture"},{"line_number":14,"context_line":"was introduced. The reason behind implementing the layered architecture was to"},{"line_number":15,"context_line":"avoid regression in any layer if either of the layer is modified. Glance has"},{"line_number":16,"context_line":"separate layer for Policy injections which is closed to database rather than"},{"line_number":17,"context_line":"API. This spec will act as a Master specification for policy refactoring and"},{"line_number":18,"context_line":"have several spec-lite\u0027s to explain respective implementation details."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"2f6e5349_4f1cd36a","line":16,"range":{"start_line":16,"start_character":0,"end_line":16,"end_character":8},"updated":"2021-06-17 14:56:01.000000000","message":"\"a separate\"","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":13,"context_line":"During implementation of V2 Image API in glance an Onion layered architecture"},{"line_number":14,"context_line":"was introduced. The reason behind implementing the layered architecture was to"},{"line_number":15,"context_line":"avoid regression in any layer if either of the layer is modified. Glance has"},{"line_number":16,"context_line":"separate layer for Policy injections which is closed to database rather than"},{"line_number":17,"context_line":"API. This spec will act as a Master specification for policy refactoring and"},{"line_number":18,"context_line":"have several spec-lite\u0027s to explain respective implementation details."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"8e21c6da_8c5c5d2a","line":16,"range":{"start_line":16,"start_character":46,"end_line":16,"end_character":52},"updated":"2021-06-17 14:56:01.000000000","message":"\"close\" or \"closer\" ?","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":13,"context_line":"During implementation of V2 Image API in glance an Onion layered architecture"},{"line_number":14,"context_line":"was introduced. The reason behind implementing the layered architecture was to"},{"line_number":15,"context_line":"avoid regression in any layer if either of the layer is modified. Glance has"},{"line_number":16,"context_line":"separate layer for Policy injections which is closed to database rather than"},{"line_number":17,"context_line":"API. This spec will act as a Master specification for policy refactoring and"},{"line_number":18,"context_line":"have several spec-lite\u0027s to explain respective implementation details."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"50f8d16e_7f5e4127","line":16,"range":{"start_line":16,"start_character":0,"end_line":16,"end_character":8},"in_reply_to":"2f6e5349_4f1cd36a","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":true,"context_lines":[{"line_number":13,"context_line":"During implementation of V2 Image API in glance an Onion layered architecture"},{"line_number":14,"context_line":"was introduced. The reason behind implementing the layered architecture was to"},{"line_number":15,"context_line":"avoid regression in any layer if either of the layer is modified. Glance has"},{"line_number":16,"context_line":"separate layer for Policy injections which is closed to database rather than"},{"line_number":17,"context_line":"API. This spec will act as a Master specification for policy refactoring and"},{"line_number":18,"context_line":"have several spec-lite\u0027s to explain respective implementation details."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"a5e87c75_2b84524e","line":16,"range":{"start_line":16,"start_character":46,"end_line":16,"end_character":52},"in_reply_to":"8e21c6da_8c5c5d2a","updated":"2021-06-17 15:09:49.000000000","message":"\"closer\" sounds more appropriate.","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"6e16969945e61dbc526188351f274a28b3045a67","unresolved":false,"context_lines":[{"line_number":13,"context_line":"During implementation of V2 Image API in glance an Onion layered architecture"},{"line_number":14,"context_line":"was introduced. The reason behind implementing the layered architecture was to"},{"line_number":15,"context_line":"avoid regression in any layer if either of the layer is modified. Glance has"},{"line_number":16,"context_line":"separate layer for Policy injections which is closed to database rather than"},{"line_number":17,"context_line":"API. This spec will act as a Master specification for policy refactoring and"},{"line_number":18,"context_line":"have several spec-lite\u0027s to explain respective implementation details."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9b4588c5_4e3eddec","line":16,"range":{"start_line":16,"start_character":46,"end_line":16,"end_character":52},"in_reply_to":"a5e87c75_2b84524e","updated":"2021-06-22 05:35:43.000000000","message":"Done","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":21,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"The current policy enforcement occurs in Policy layer. As such, it is"},{"line_number":24,"context_line":"conceptually tied to the Objects implemented in the Glance architecture. A"},{"line_number":25,"context_line":"problem with this design, which has only revealed itself as the v2 API has"},{"line_number":26,"context_line":"matured, is that operators want to use policies to control who can make API"},{"line_number":27,"context_line":"calls (as they can with most other OpenStack services). In Glance, however,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"eaa1aaa4_8de89863","line":24,"range":{"start_line":24,"start_character":25,"end_line":24,"end_character":32},"updated":"2021-06-17 14:56:01.000000000","message":"s/Objects/objects/","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":21,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"The current policy enforcement occurs in Policy layer. As such, it is"},{"line_number":24,"context_line":"conceptually tied to the Objects implemented in the Glance architecture. A"},{"line_number":25,"context_line":"problem with this design, which has only revealed itself as the v2 API has"},{"line_number":26,"context_line":"matured, is that operators want to use policies to control who can make API"},{"line_number":27,"context_line":"calls (as they can with most other OpenStack services). In Glance, however,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ea81b2ae_e1f8211a","line":24,"range":{"start_line":24,"start_character":25,"end_line":24,"end_character":32},"in_reply_to":"eaa1aaa4_8de89863","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":43,"context_line":""},{"line_number":44,"context_line":"We need a better way of handling policies:"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"1. One of the major proposal is to move the actual policy enforcement up to the"},{"line_number":47,"context_line":"   API layer so that an operator can, for example, easily restrict access to a"},{"line_number":48,"context_line":"   particular call."},{"line_number":49,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3028ffb5_245d84d9","line":46,"range":{"start_line":46,"start_character":20,"end_line":46,"end_character":28},"updated":"2021-06-17 14:56:01.000000000","message":"\"proposals\"","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":43,"context_line":""},{"line_number":44,"context_line":"We need a better way of handling policies:"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"1. One of the major proposal is to move the actual policy enforcement up to the"},{"line_number":47,"context_line":"   API layer so that an operator can, for example, easily restrict access to a"},{"line_number":48,"context_line":"   particular call."},{"line_number":49,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"f07dd44f_8630dae5","line":46,"range":{"start_line":46,"start_character":20,"end_line":46,"end_character":28},"in_reply_to":"3028ffb5_245d84d9","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"1. One of the major proposal is to move the actual policy enforcement up to the"},{"line_number":47,"context_line":"   API layer so that an operator can, for example, easily restrict access to a"},{"line_number":48,"context_line":"   particular call."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"2. Make `get_*` policies to be enforced only while showing particular resource"},{"line_number":51,"context_line":"   rather than enforcing it for each API call. For example `get_image` policy"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2c34e2ec_1b933e49","line":48,"updated":"2021-06-17 14:56:01.000000000","message":"Might be worth noting that this has been a concerted effort in most (if not all) of the other openstack projects, so this puts us more in-line with the current thinking on policy enforcement.","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"1. One of the major proposal is to move the actual policy enforcement up to the"},{"line_number":47,"context_line":"   API layer so that an operator can, for example, easily restrict access to a"},{"line_number":48,"context_line":"   particular call."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"2. Make `get_*` policies to be enforced only while showing particular resource"},{"line_number":51,"context_line":"   rather than enforcing it for each API call. For example `get_image` policy"}],"source_content_type":"text/x-rst","patch_set":1,"id":"459f6bbe_561e0343","line":48,"in_reply_to":"2c34e2ec_1b933e49","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":47,"context_line":"   API layer so that an operator can, for example, easily restrict access to a"},{"line_number":48,"context_line":"   particular call."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"2. Make `get_*` policies to be enforced only while showing particular resource"},{"line_number":51,"context_line":"   rather than enforcing it for each API call. For example `get_image` policy"},{"line_number":52,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":53,"context_line":"   other API calls such as update, delete, upload or download image."}],"source_content_type":"text/x-rst","patch_set":1,"id":"c5cf21ac_de6507e2","line":50,"range":{"start_line":50,"start_character":25,"end_line":50,"end_character":27},"updated":"2021-06-17 14:56:01.000000000","message":"s/to//","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":47,"context_line":"   API layer so that an operator can, for example, easily restrict access to a"},{"line_number":48,"context_line":"   particular call."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"2. Make `get_*` policies to be enforced only while showing particular resource"},{"line_number":51,"context_line":"   rather than enforcing it for each API call. For example `get_image` policy"},{"line_number":52,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":53,"context_line":"   other API calls such as update, delete, upload or download image."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b16df05a_abb592ae","line":50,"range":{"start_line":50,"start_character":25,"end_line":50,"end_character":27},"in_reply_to":"c5cf21ac_de6507e2","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":56,"context_line":"   related policies close to database layer."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"4. Policy enforcement should be backward compatible means it should work with"},{"line_number":59,"context_line":"   old policies as well as new secure RBAC structured policies."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":62,"context_line":"   file from the test repo, instead it should be used our default policies and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"15c12018_aefc8836","line":59,"updated":"2021-06-17 14:56:01.000000000","message":"I\u0027m not sure how possible this is really, although I definitely agree with the goal. We could try to make our new api-based policy enforcement only happen if secure-rbac defaults are enabled, but that\u0027s also likely to be confusing I think.\n\nThe problem is, people might have policies right now that have certain behaviors that won\u0027t work if we start enforcing them strictly. Like the current get-images rule that is missing public -- that works today because we\u0027re not being strict, but after adding the strict-ness, some people with custom rules with definitely have some tweaking to do. Not sure the best way to guard against that, TBH.","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"670218e31b4121e5291efc8dc88c63f452d03f57","unresolved":true,"context_lines":[{"line_number":56,"context_line":"   related policies close to database layer."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"4. Policy enforcement should be backward compatible means it should work with"},{"line_number":59,"context_line":"   old policies as well as new secure RBAC structured policies."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":62,"context_line":"   file from the test repo, instead it should be used our default policies and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bd71773a_b8c6823e","line":59,"in_reply_to":"15c12018_aefc8836","updated":"2021-06-21 14:24:00.000000000","message":"Agree with Dan.  Maybe state this as \"backward compatible to the greatest extent possible\", and maybe add that \"in cases where compatibility is not possible, we will lean to the more secure outcome, which may mean that legacy policy files that allowed some actions may no longer allow those actions\" (though I\u0027m not sure to what extent we can guarantee that, either).","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"6e16969945e61dbc526188351f274a28b3045a67","unresolved":false,"context_lines":[{"line_number":56,"context_line":"   related policies close to database layer."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"4. Policy enforcement should be backward compatible means it should work with"},{"line_number":59,"context_line":"   old policies as well as new secure RBAC structured policies."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":62,"context_line":"   file from the test repo, instead it should be used our default policies and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d92b95dc_7b789fb0","line":59,"in_reply_to":"bd71773a_b8c6823e","updated":"2021-06-22 05:35:43.000000000","message":"Done","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"670218e31b4121e5291efc8dc88c63f452d03f57","unresolved":true,"context_lines":[{"line_number":59,"context_line":"   old policies as well as new secure RBAC structured policies."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":62,"context_line":"   file from the test repo, instead it should be used our default policies and"},{"line_number":63,"context_line":"   needed to overridden as and when required."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"6. In order to test new policy changes with RBAC we need two different CI jobs"},{"line_number":66,"context_line":"   which will run our tests with old policies as well as with the new RBAC flag"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7baf3522_1d6b5ac1","line":63,"range":{"start_line":62,"start_character":36,"end_line":63,"end_character":44},"updated":"2021-06-21 14:24:00.000000000","message":"\"our default policies should be used and overridden as and when required\"","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"6e16969945e61dbc526188351f274a28b3045a67","unresolved":false,"context_lines":[{"line_number":59,"context_line":"   old policies as well as new secure RBAC structured policies."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":62,"context_line":"   file from the test repo, instead it should be used our default policies and"},{"line_number":63,"context_line":"   needed to overridden as and when required."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"6. In order to test new policy changes with RBAC we need two different CI jobs"},{"line_number":66,"context_line":"   which will run our tests with old policies as well as with the new RBAC flag"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0f7ab5db_4d567168","line":63,"range":{"start_line":62,"start_character":36,"end_line":63,"end_character":44},"in_reply_to":"7baf3522_1d6b5ac1","updated":"2021-06-22 05:35:43.000000000","message":"Done","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":82,"context_line":"REST API impact"},{"line_number":83,"context_line":"---------------"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"None"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"Security impact"},{"line_number":88,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f2eab0c6_c61ad8ea","line":85,"updated":"2021-06-17 14:56:01.000000000","message":"I think there\u0027s likely to be some API impact here, but it\u0027s certainly hard to quantify it here. But, I think it\u0027s probably worth saying something about how some operations may succeed or fail given the same set of input policies, just because right now there are conflicts between policy rules that we hope to remove.","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"670218e31b4121e5291efc8dc88c63f452d03f57","unresolved":false,"context_lines":[{"line_number":82,"context_line":"REST API impact"},{"line_number":83,"context_line":"---------------"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"None"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"Security impact"},{"line_number":88,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f9c67cd3_649d0a8a","line":85,"in_reply_to":"abc2124f_54cfbccf","updated":"2021-06-21 14:24:00.000000000","message":"Maybe state this as \u0027No changes to the REST API, but see \"Other Deployer Impact\" section, below.\u0027","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":82,"context_line":"REST API impact"},{"line_number":83,"context_line":"---------------"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"None"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"Security impact"},{"line_number":88,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"abc2124f_54cfbccf","line":85,"in_reply_to":"f2eab0c6_c61ad8ea","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":108,"context_line":"---------------------"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Operators need to understand which policies to govern and how to configure"},{"line_number":111,"context_line":"them properly, specifically related to secure RBAC."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"Developer impact"},{"line_number":114,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9cd47072_62e6285f","line":111,"updated":"2021-06-17 14:56:01.000000000","message":"As above, there\u0027s likely to be some tweaking and testing of any custom policies during upgrade to Xena (or beyond).","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":108,"context_line":"---------------------"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Operators need to understand which policies to govern and how to configure"},{"line_number":111,"context_line":"them properly, specifically related to secure RBAC."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"Developer impact"},{"line_number":114,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a2f9e1b5_8b1a5f31","line":111,"in_reply_to":"9cd47072_62e6285f","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":113,"context_line":"Developer impact"},{"line_number":114,"context_line":"----------------"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Developers will have go be more aware of policies and where policy enforcement"},{"line_number":117,"context_line":"must happen."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"8ee2b374_4293d3f0","line":116,"range":{"start_line":116,"start_character":21,"end_line":116,"end_character":23},"updated":"2021-06-17 14:56:01.000000000","message":"s/go/to/","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":false,"context_lines":[{"line_number":113,"context_line":"Developer impact"},{"line_number":114,"context_line":"----------------"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Developers will have go be more aware of policies and where policy enforcement"},{"line_number":117,"context_line":"must happen."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"4cfcdca9_ca8ad3f5","line":116,"range":{"start_line":116,"start_character":21,"end_line":116,"end_character":23},"in_reply_to":"8ee2b374_4293d3f0","updated":"2021-06-17 15:09:49.000000000","message":"Ack","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"043870c2df6f97663756a905886abe20110e5133","unresolved":true,"context_lines":[{"line_number":124,"context_line":"-----------"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Primary assignee:"},{"line_number":127,"context_line":"  dansmith"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Other contributors:"},{"line_number":130,"context_line":"  abhishek-kekane"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b5250535_60bebafe","line":127,"updated":"2021-06-17 14:56:01.000000000","message":"I\u0027m okay with being the primary on this I guess, but I really really don\u0027t want to have to do all of this work by myself, just FYI.","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"6e16969945e61dbc526188351f274a28b3045a67","unresolved":false,"context_lines":[{"line_number":124,"context_line":"-----------"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Primary assignee:"},{"line_number":127,"context_line":"  dansmith"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Other contributors:"},{"line_number":130,"context_line":"  abhishek-kekane"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f3be244e_6e27e605","line":127,"in_reply_to":"4dedce85_fa28d025","updated":"2021-06-22 05:35:43.000000000","message":"Done","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"dac4b85a0e9cba497889af2f33875f7a4a409f84","unresolved":true,"context_lines":[{"line_number":124,"context_line":"-----------"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"Primary assignee:"},{"line_number":127,"context_line":"  dansmith"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Other contributors:"},{"line_number":130,"context_line":"  abhishek-kekane"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4dedce85_fa28d025","line":127,"in_reply_to":"b5250535_60bebafe","updated":"2021-06-17 15:09:49.000000000","message":"Agree, will add myself as a primary assignee as well.","commit_id":"85f7d6dd249d71f832998f540ff476c854b9fc13"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e8947dfd83bac3e0b3e1a17d87b009711c9b2ffb","unresolved":true,"context_lines":[{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be to the greatest extent possible, means it"},{"line_number":61,"context_line":"   should possibly work with old policies as well as new secure RBAC"},{"line_number":62,"context_line":"   structured policies. In cases where compatibility is not possible, we will"},{"line_number":63,"context_line":"   lean to the more secure outcome, which may mean that legacy policy files"}],"source_content_type":"text/x-rst","patch_set":2,"id":"63ecd4c0_576e0693","line":60,"range":{"start_line":60,"start_character":31,"end_line":60,"end_character":33},"updated":"2021-06-22 13:42:00.000000000","message":"I think maybe you meant \"compatible to the greatest extent possible\" ?","commit_id":"bc4a9774e374e2d3cd1f0d678c0ceb4c70a0880d"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"0238bf68016b7fb264b25f3cf16e688ab45bb8c7","unresolved":false,"context_lines":[{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be to the greatest extent possible, means it"},{"line_number":61,"context_line":"   should possibly work with old policies as well as new secure RBAC"},{"line_number":62,"context_line":"   structured policies. In cases where compatibility is not possible, we will"},{"line_number":63,"context_line":"   lean to the more secure outcome, which may mean that legacy policy files"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d19ef162_a50205ed","line":60,"range":{"start_line":60,"start_character":31,"end_line":60,"end_character":33},"in_reply_to":"63ecd4c0_576e0693","updated":"2021-06-22 16:13:14.000000000","message":"Done","commit_id":"bc4a9774e374e2d3cd1f0d678c0ceb4c70a0880d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e8947dfd83bac3e0b3e1a17d87b009711c9b2ffb","unresolved":true,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Primary assignee:"},{"line_number":134,"context_line":"  dansmith"},{"line_number":135,"context_line":"  abhishek-kekane"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Other contributors:"},{"line_number":138,"context_line":"  pdeore"},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Work Items"},{"line_number":141,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8cf58088_c3bbd1c9","line":138,"range":{"start_line":135,"start_character":1,"end_line":138,"end_character":8},"updated":"2021-06-22 13:42:00.000000000","message":"\\o/","commit_id":"bc4a9774e374e2d3cd1f0d678c0ceb4c70a0880d"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"384d17876e9a493df0bfd48809b787696ebae466","unresolved":true,"context_lines":[{"line_number":32,"context_line":"In addition, while implementing Secure RBAC in glance we also noticed that"},{"line_number":33,"context_line":"certain API calls enforce multiple policies down the layer. For example"},{"line_number":34,"context_line":"in case of `modify_image` policy it enforces `get_image` policy which"},{"line_number":35,"context_line":"enforces `get_image_location` policy. This can be confusing for operators"},{"line_number":36,"context_line":"modifying the policy for `modify_image` and wondering why it hasn\u0027t taken"},{"line_number":37,"context_line":"effect if the `get_image` policy or `get_image_policy` short-circuits the"},{"line_number":38,"context_line":"operation."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":3,"id":"574f9cfb_83717a27","line":38,"range":{"start_line":35,"start_character":38,"end_line":38,"end_character":10},"updated":"2021-06-28 17:50:47.000000000","message":"I\u0027m quite worried that addressing this is going to be even more confusing. As we do not have inheritance baked into these policies this would allow users to blindly change things and not be able to verify that their change actually took effect.\n\nThe example you gave is quite extreme as if the policy prevents \"get_image\" the users would not have any access to images at all. But good example here is for example locations. Lets say user don\u0027t have access to list the locations but they would have cd permissions to them. Meaning one would be able to delete and create locations without actually having access to the resource.\n\nSo that said, I think we still need to enforce that the user can actually access the resource before allowing them to change it.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"003d9a5744dd6e9877e2acf790e413f94cca0db1","unresolved":true,"context_lines":[{"line_number":32,"context_line":"In addition, while implementing Secure RBAC in glance we also noticed that"},{"line_number":33,"context_line":"certain API calls enforce multiple policies down the layer. For example"},{"line_number":34,"context_line":"in case of `modify_image` policy it enforces `get_image` policy which"},{"line_number":35,"context_line":"enforces `get_image_location` policy. This can be confusing for operators"},{"line_number":36,"context_line":"modifying the policy for `modify_image` and wondering why it hasn\u0027t taken"},{"line_number":37,"context_line":"effect if the `get_image` policy or `get_image_policy` short-circuits the"},{"line_number":38,"context_line":"operation."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f904846c_4ac21d60","line":38,"range":{"start_line":35,"start_character":38,"end_line":38,"end_character":10},"in_reply_to":"574f9cfb_83717a27","updated":"2021-06-28 18:17:24.000000000","message":"\u003e I\u0027m quite worried that addressing this is going to be even more confusing. As we do not have inheritance baked into these policies this would allow users to blindly change things and not be able to verify that their change actually took effect.\n\nBut we do have inheritance today, which is the problem. Trying to grant copy-image to a specific \"can-copy-images\" role is not possible. Why? Because the copy-image operation requires modify-image. Aside from the special case we\u0027ve implemented around that, these kinds of things lead to the operator having to basically grant full access to an image to do something to it.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"745760c248d6fc23f63fb5544a2dc1a69759d626","unresolved":true,"context_lines":[{"line_number":32,"context_line":"In addition, while implementing Secure RBAC in glance we also noticed that"},{"line_number":33,"context_line":"certain API calls enforce multiple policies down the layer. For example"},{"line_number":34,"context_line":"in case of `modify_image` policy it enforces `get_image` policy which"},{"line_number":35,"context_line":"enforces `get_image_location` policy. This can be confusing for operators"},{"line_number":36,"context_line":"modifying the policy for `modify_image` and wondering why it hasn\u0027t taken"},{"line_number":37,"context_line":"effect if the `get_image` policy or `get_image_policy` short-circuits the"},{"line_number":38,"context_line":"operation."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":3,"id":"140f4bbc_39ce2186","line":38,"range":{"start_line":35,"start_character":38,"end_line":38,"end_character":10},"in_reply_to":"f904846c_4ac21d60","updated":"2021-07-01 15:44:57.000000000","message":"We do not inherit read access by granting modify access, we have requirement of read access to the resource you are modifying.\n\nI think this is big enough backwards incompatible change that it\u0027s merits should be discussed outside of the refactoring. Also I think it\u0027s big enough breakage that it likely should require API major version change. I know breaking the API is trivial in Nova where you can just declare new microversion and once the old behaviour gets too nasty to maintain you stop supporting it but that is not exactly API stability nor work without microversions.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"384d17876e9a493df0bfd48809b787696ebae466","unresolved":true,"context_lines":[{"line_number":49,"context_line":"   enforcements closer to API layer, so these efforts will also put us more"},{"line_number":50,"context_line":"   in-line with the current thinking of policy enforcement."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"2. Make `get_*` policies be enforced only while showing particular resource"},{"line_number":53,"context_line":"   rather than enforcing it for each API call. For example `get_image` policy"},{"line_number":54,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":55,"context_line":"   other API calls such as update, delete, upload or download image."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."}],"source_content_type":"text/x-rst","patch_set":3,"id":"02e61a8c_c57c0228","line":55,"range":{"start_line":52,"start_character":0,"end_line":55,"end_character":68},"updated":"2021-06-28 17:50:47.000000000","message":"I wholeheartly disagree with this statement. My reasoning above.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"003d9a5744dd6e9877e2acf790e413f94cca0db1","unresolved":true,"context_lines":[{"line_number":49,"context_line":"   enforcements closer to API layer, so these efforts will also put us more"},{"line_number":50,"context_line":"   in-line with the current thinking of policy enforcement."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"2. Make `get_*` policies be enforced only while showing particular resource"},{"line_number":53,"context_line":"   rather than enforcing it for each API call. For example `get_image` policy"},{"line_number":54,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":55,"context_line":"   other API calls such as update, delete, upload or download image."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."}],"source_content_type":"text/x-rst","patch_set":3,"id":"969bf370_6a3e840a","line":55,"range":{"start_line":52,"start_character":0,"end_line":55,"end_character":68},"in_reply_to":"02e61a8c_c57c0228","updated":"2021-06-28 18:17:24.000000000","message":"The easiest counter example that explains why this is necessary is, IMHO, the delete case.\n\nI may want to write some script that deletes snapshots of a nova instance when it\u0027s deleted. That thing reads an audit log that is generated from a consumer of the nova notification queue, or maybe it\u0027s looking at snapshot dependencies in Ceph. Regardless, that script just needs to be able to delete things, but not actually see the image and its associated metadata (which includes usernames and software license keys). I only want to grant it the ability to delete images, but nothing else.\n\nYou could also have a similar sort of thing with update. Say you\u0027ve got an agent that is backing up images to tape very slowly in the background. It\u0027s doing its work at the RBD level of course, but needs to be able to flag an image with a last-backed-up\u003d$date or tape-number\u003d$n after it is done. You don\u0027t need that thing to be able to read the metadata on the image, you just need it to be able to blindly set a key.\n\nSurely there\u0027s a case to be made here for upload-image as well. Imagine a case where I\u0027m creating an image record, putting some software license keys in the metadata and then passing off the ID to some bot that is going to construct the actual image data for people and upload it. I don\u0027t want to have to put that bot in everyone\u0027s project and grant it admin access, I want to define a role for software-uploader-bot, and grant that upload ability across the board, but without any other permissions.\n\nThese are clearly not things everyone will need to be able to do, but if you\u0027re operation on the principle of least privilege, there\u0027s really no reason why we should tell operators that they have to grant those scripts the ability to see everything about the image just to do those things.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"384d17876e9a493df0bfd48809b787696ebae466","unresolved":true,"context_lines":[{"line_number":54,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":55,"context_line":"   other API calls such as update, delete, upload or download image."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"}],"source_content_type":"text/x-rst","patch_set":3,"id":"47c4007f_3127a021","line":58,"range":{"start_line":57,"start_character":0,"end_line":58,"end_character":44},"updated":"2021-06-28 17:50:47.000000000","message":"This is not great for consistency. I think this should be investigated how much extra work it would actually need to be consistent across the policies.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"003d9a5744dd6e9877e2acf790e413f94cca0db1","unresolved":true,"context_lines":[{"line_number":54,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":55,"context_line":"   other API calls such as update, delete, upload or download image."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fe4e7c70_a22c2fcf","line":58,"range":{"start_line":57,"start_character":0,"end_line":58,"end_character":44},"in_reply_to":"47c4007f_3127a021","updated":"2021-06-28 18:17:24.000000000","message":"I actually don\u0027t like the word \"policies\" in here, because IMHO these are business logic decisions. They\u0027re glance behaviors, not really policies. They\u0027re not override-able, based on who you are, they\u0027re fundamental features and thus make sense to be implemented in a fixed way. So, I don\u0027t think it\u0027s a consistency problem.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"63173f1f1caf6f51104ad498740f3bf33817422a","unresolved":true,"context_lines":[{"line_number":54,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":55,"context_line":"   other API calls such as update, delete, upload or download image."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d5246916_05b6ea11","line":58,"range":{"start_line":57,"start_character":0,"end_line":58,"end_character":44},"in_reply_to":"5f4b174a_c0b9e1c1","updated":"2021-07-01 16:27:16.000000000","message":"AFAIK, we can move all policies closer to the API.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6470a268095c1204fd723619a241452a2e383c2d","unresolved":true,"context_lines":[{"line_number":54,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":55,"context_line":"   other API calls such as update, delete, upload or download image."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"}],"source_content_type":"text/x-rst","patch_set":3,"id":"103e04d6_6047db67","line":58,"range":{"start_line":57,"start_character":0,"end_line":58,"end_character":44},"in_reply_to":"d5246916_05b6ea11","updated":"2021-07-01 18:58:05.000000000","message":"Publicize and Add Member are API operations and should be controlled by relevant policy items. What I meant was \"I can see this image because I am a member\" should not be controlled by the policy because it is glance-specific logic. \"I can see images in shared state (because I am  member)\" makes sense as a policy check.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"745760c248d6fc23f63fb5544a2dc1a69759d626","unresolved":true,"context_lines":[{"line_number":54,"context_line":"   should be enforced only for showing particular image to end user and not for"},{"line_number":55,"context_line":"   other API calls such as update, delete, upload or download image."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5f4b174a_c0b9e1c1","line":58,"range":{"start_line":57,"start_character":0,"end_line":58,"end_character":44},"in_reply_to":"fe4e7c70_a22c2fcf","updated":"2021-07-01 15:44:57.000000000","message":"We have policies like publicise image and add member. And I don\u0027t see benefits of enforcing them somewhere else than where all the rest of our policies are enforced. Isn\u0027t the whole point of this work to get the policy enforcement consistently close to the API?","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"384d17876e9a493df0bfd48809b787696ebae466","unresolved":true,"context_lines":[{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"},{"line_number":62,"context_line":"   structured policies. In cases where compatibility is not possible, we will"},{"line_number":63,"context_line":"   lean to the more secure outcome, which may mean that legacy policy files"},{"line_number":64,"context_line":"   that allowed some actions may no longer allow those actions."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":67,"context_line":"   file from the test repo, instead our default policies should be used and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a1ef9fb_80554717","line":64,"range":{"start_line":60,"start_character":0,"end_line":64,"end_character":63},"updated":"2021-06-28 17:50:47.000000000","message":"For not breaking the API as claimed on the REST API Impact section we would need to lean towards the \"old\" behaviour. Or we need to be honest that we\u0027re making breaking changes and then we should honour deprecations, deprecate the old policies and replace them with new ones that behaves differently.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"003d9a5744dd6e9877e2acf790e413f94cca0db1","unresolved":true,"context_lines":[{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"},{"line_number":62,"context_line":"   structured policies. In cases where compatibility is not possible, we will"},{"line_number":63,"context_line":"   lean to the more secure outcome, which may mean that legacy policy files"},{"line_number":64,"context_line":"   that allowed some actions may no longer allow those actions."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":67,"context_line":"   file from the test repo, instead our default policies should be used and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"6ecd990c_dc8406f6","line":64,"range":{"start_line":60,"start_character":0,"end_line":64,"end_character":63},"in_reply_to":"1a1ef9fb_80554717","updated":"2021-06-28 18:17:24.000000000","message":"I think that \"default to the more secure\" is the only reasonable approach here. Every single API call needs to be prepared to hit a 403 at all times. What we\u0027re describing here is that potentially a thing that you used to be able to do is suddenly not allowed, which is a lot better default than the opposite. I don\u0027t even have an example of what might fall into this bucket, but I think having this as the goal of how to handle such a situation is the right one.\n\nAre you saying that if something is too open today (like the metadef CRUD operations were) that we should default to less secure? The metadef prior art suggests that we should take the approach described here, which is opt to fail secure.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"745760c248d6fc23f63fb5544a2dc1a69759d626","unresolved":true,"context_lines":[{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"},{"line_number":62,"context_line":"   structured policies. In cases where compatibility is not possible, we will"},{"line_number":63,"context_line":"   lean to the more secure outcome, which may mean that legacy policy files"},{"line_number":64,"context_line":"   that allowed some actions may no longer allow those actions."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":67,"context_line":"   file from the test repo, instead our default policies should be used and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"970ad1e6_a55f5455","line":64,"range":{"start_line":60,"start_character":0,"end_line":64,"end_character":63},"in_reply_to":"6ecd990c_dc8406f6","updated":"2021-07-01 15:44:57.000000000","message":"I\u0027m saying that if user is currently able to do X after refactoring the user should be still able to do X. We have clear security bug process how to address cases if as part of this work we realize that something did not provide the security intended. Obviously one could always argue that user not being able to do X is likely more secure than the opposite so we should just lock down everything (and yes there is plenty of examples where deployments consider exposing some features being insecure and not allowing them for the users even if that is not widely agreed).\n\nFor this I do expect the user being project member as of RBAC persona, as discussed last cycle we do not have use cases identified for project admin persona and the reader is obviously a new thing that has not existed before. If the scope of said policy does not seem relevan anymore we should deprecate it and propose replacement(s) for it but not redefine it based on opinionated security. Thus lean to the old behaviour and take appropriate process of either security bug or deprecation if we need to change the scope.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"63173f1f1caf6f51104ad498740f3bf33817422a","unresolved":true,"context_lines":[{"line_number":57,"context_line":"3. We can keep resource specific policies such as image members, visibility"},{"line_number":58,"context_line":"   related policies close to database layer."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. Policy enforcement should be compatible to the greatest extent possible,"},{"line_number":61,"context_line":"   means it should possibly work with old policies as well as new secure RBAC"},{"line_number":62,"context_line":"   structured policies. In cases where compatibility is not possible, we will"},{"line_number":63,"context_line":"   lean to the more secure outcome, which may mean that legacy policy files"},{"line_number":64,"context_line":"   that allowed some actions may no longer allow those actions."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"5. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":67,"context_line":"   file from the test repo, instead our default policies should be used and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"490b0b8f_8f920dbe","line":64,"range":{"start_line":60,"start_character":0,"end_line":64,"end_character":63},"in_reply_to":"970ad1e6_a55f5455","updated":"2021-07-01 16:27:16.000000000","message":"Probably I should skip this point from the spec. I have written this considering feature RBAC related changes as well.\n\nAlso just for the information, while adoption project scope we already added deprecation note/message to our existing policy rules. So we are following deprecation policy.\n\nhttps://github.com/openstack/glance/blob/master/glance/policies/image.py#L33","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"384d17876e9a493df0bfd48809b787696ebae466","unresolved":true,"context_lines":[{"line_number":112,"context_line":"Other deployer impact"},{"line_number":113,"context_line":"---------------------"},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Operators need to understand which policies to govern and how to configure"},{"line_number":116,"context_line":"them properly, specifically related to secure RBAC. Also, there\u0027s likely to"},{"line_number":117,"context_line":"be some tweaking and testing of any custom policies during upgrade to Xena"},{"line_number":118,"context_line":"(or beyond)."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Developer impact"},{"line_number":121,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1b5c3ff7_22a8db13","line":118,"range":{"start_line":115,"start_character":0,"end_line":118,"end_character":12},"updated":"2021-06-28 17:50:47.000000000","message":"This is quite harsh take on the fact that we\u0027ve given our deployers the promise until now that we do not break their configs over upgrade (valid up to date config in release N should still work equally on N+1). Are we going to drop this promise in favor to make the work easier for us?","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":9303,"name":"Abhishek Kekane","email":"akekane@redhat.com","username":"abhishekkekane"},"change_message_id":"63173f1f1caf6f51104ad498740f3bf33817422a","unresolved":true,"context_lines":[{"line_number":112,"context_line":"Other deployer impact"},{"line_number":113,"context_line":"---------------------"},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Operators need to understand which policies to govern and how to configure"},{"line_number":116,"context_line":"them properly, specifically related to secure RBAC. Also, there\u0027s likely to"},{"line_number":117,"context_line":"be some tweaking and testing of any custom policies during upgrade to Xena"},{"line_number":118,"context_line":"(or beyond)."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Developer impact"},{"line_number":121,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3e1e5276_819114d6","line":118,"range":{"start_line":115,"start_character":0,"end_line":118,"end_character":12},"in_reply_to":"1383d9af_5e6a37e3","updated":"2021-07-01 16:27:16.000000000","message":"I think the point here is, we have already adopted experimental behavior of RBAC project persona with following proper depreciation rules. Deployer should start understanding those in detail.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"003d9a5744dd6e9877e2acf790e413f94cca0db1","unresolved":true,"context_lines":[{"line_number":112,"context_line":"Other deployer impact"},{"line_number":113,"context_line":"---------------------"},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Operators need to understand which policies to govern and how to configure"},{"line_number":116,"context_line":"them properly, specifically related to secure RBAC. Also, there\u0027s likely to"},{"line_number":117,"context_line":"be some tweaking and testing of any custom policies during upgrade to Xena"},{"line_number":118,"context_line":"(or beyond)."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Developer impact"},{"line_number":121,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"cc36c664_cfc0e58f","line":118,"range":{"start_line":115,"start_character":0,"end_line":118,"end_character":12},"in_reply_to":"1b5c3ff7_22a8db13","updated":"2021-06-28 18:17:24.000000000","message":"Aside from \"do nothing\" what would you suggest here? I\u0027m not really sure what else we can do other than try our best not to break things, flag the potential, and require operators with custom policies to test their stuff.\n\nThis to me is a lot like the rootwrap config. It\u0027s kind of config, but you can\u0027t really change it and expect it to be honored going forward because of how closely tied it is to the internals. The policy file is even worse, since it\u0027s a DSL where you could do a lot of unpredictable things that are fragile from release to release.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"745760c248d6fc23f63fb5544a2dc1a69759d626","unresolved":true,"context_lines":[{"line_number":112,"context_line":"Other deployer impact"},{"line_number":113,"context_line":"---------------------"},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Operators need to understand which policies to govern and how to configure"},{"line_number":116,"context_line":"them properly, specifically related to secure RBAC. Also, there\u0027s likely to"},{"line_number":117,"context_line":"be some tweaking and testing of any custom policies during upgrade to Xena"},{"line_number":118,"context_line":"(or beyond)."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Developer impact"},{"line_number":121,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1383d9af_5e6a37e3","line":118,"range":{"start_line":115,"start_character":0,"end_line":118,"end_character":12},"in_reply_to":"cc36c664_cfc0e58f","updated":"2021-07-01 15:44:57.000000000","message":"I\u0027m suggesting that refactoring the code taking care of our policy enforcement should not change the API behaviour. If we identify defaults we should change, that should be discussed outside of the scope of refactoring and done over appropriate deprecation. Main point is that specially overwritten policies from policy file should behave the same as before the refactoring to not break the deployment over upgrade of the code, like we have promised to our admins for years.","commit_id":"631c9572cbe005ef51a554a721eeb48077371b5b"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"f3b9213dfd3d1425c1a94fa169eb00a36471000c","unresolved":true,"context_lines":[{"line_number":32,"context_line":"In addition, while implementing Secure RBAC in glance we also noticed that"},{"line_number":33,"context_line":"certain API calls enforce multiple policies down the layer. For example"},{"line_number":34,"context_line":"in case of `modify_image` policy it enforces `get_image` policy which"},{"line_number":35,"context_line":"enforces `get_image_location` policy. This can be confusing for operators"},{"line_number":36,"context_line":"modifying the policy for `modify_image` and wondering why it hasn\u0027t taken"},{"line_number":37,"context_line":"effect if the `get_image` policy or `get_image_policy` short-circuits the"},{"line_number":38,"context_line":"operation."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7a266bbd_199e6b71","line":38,"range":{"start_line":35,"start_character":38,"end_line":38,"end_character":10},"updated":"2021-07-05 14:04:19.000000000","message":"My concern with this statement still stands. With point 2. below, this change would be heavily backwards comaptibility breaking change and IMO should not be in the scope of refactoring where the policies are enforced. Being such a fundamental change this probably should require Images API v3.","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"bd877c7f6dd36ce2c5ba7cb75e6fc06f52d57759","unresolved":true,"context_lines":[{"line_number":32,"context_line":"In addition, while implementing Secure RBAC in glance we also noticed that"},{"line_number":33,"context_line":"certain API calls enforce multiple policies down the layer. For example"},{"line_number":34,"context_line":"in case of `modify_image` policy it enforces `get_image` policy which"},{"line_number":35,"context_line":"enforces `get_image_location` policy. This can be confusing for operators"},{"line_number":36,"context_line":"modifying the policy for `modify_image` and wondering why it hasn\u0027t taken"},{"line_number":37,"context_line":"effect if the `get_image` policy or `get_image_policy` short-circuits the"},{"line_number":38,"context_line":"operation."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e71b6c36_0c24f408","line":38,"range":{"start_line":35,"start_character":38,"end_line":38,"end_character":10},"in_reply_to":"4b189927_8a97bcc7","updated":"2021-07-08 17:06:10.000000000","message":"\u003e Good example of what will break if the get_image and modify_image are not enforced together anymore is our image update calls.\n\u003e \n\u003e Client cannot form the json patch at all, and if you hadcraft it either the response will be broken or that specific API will be leaking data as the response for that call is the image metadata in the response body. Including the properties that are read-only in schema or did not get modified in any way.\n\nLeaking what? Whether a key exists or not? TBH, you example here seems to further prove that we do not need to get the key first. If we make a patch call with \"add\" and we get back a conflict, then if we care, we can make the call again with \"change\". Whichever returns 20x tells us what we need to know -- that the key was set (added or updated). In most cases that will be one call instead of two to do a get first, but at worst, it will be the same.\n\nAgree that the clients are currently doing the get first and those would fail if an operator configures the policy to prevent it. However, that *also* means that any operator that configures a write-only permission will immediately know that typical users would be impacted since the clients will do a get first, followed by the update. In summary, the client behaviors already kinda give us the get-then-put behavior, so we don\u0027t need to also enforce/require that in glance, IMHO.","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e2277ff3b8a8d003211a29d5c9f36b854f45c5c8","unresolved":true,"context_lines":[{"line_number":32,"context_line":"In addition, while implementing Secure RBAC in glance we also noticed that"},{"line_number":33,"context_line":"certain API calls enforce multiple policies down the layer. For example"},{"line_number":34,"context_line":"in case of `modify_image` policy it enforces `get_image` policy which"},{"line_number":35,"context_line":"enforces `get_image_location` policy. This can be confusing for operators"},{"line_number":36,"context_line":"modifying the policy for `modify_image` and wondering why it hasn\u0027t taken"},{"line_number":37,"context_line":"effect if the `get_image` policy or `get_image_policy` short-circuits the"},{"line_number":38,"context_line":"operation."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b6b6390c_a8312e34","line":38,"range":{"start_line":35,"start_character":38,"end_line":38,"end_character":10},"in_reply_to":"7a266bbd_199e6b71","updated":"2021-07-06 14:35:48.000000000","message":"I think arguing that making the policy _able_ to be more fine-grained should require a new major API version is extreme hyperbole. The default rules will be exactly what people expect, and remain in-line with history. Meaning by default, nobody will be able to update an image they cannot also show. The only change in behavior would be in a place where the operator had written a policy that granted update ability to someone that didn\u0027t have get permission, and relied on the fact that we check both to ensure that they can\u0027t. I hardly see how that begs an entirely new API major version.\n\nEither way, that situation would be like having 0666 permissions on a file, and making sure people can\u0027t write to it because the directory above is missing the --x bit. Such an arrangement would be extremely irresponsible security policy, especially for a cloud.","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"cef75467604120b9341c6fe2176fd0249a9e505a","unresolved":true,"context_lines":[{"line_number":32,"context_line":"In addition, while implementing Secure RBAC in glance we also noticed that"},{"line_number":33,"context_line":"certain API calls enforce multiple policies down the layer. For example"},{"line_number":34,"context_line":"in case of `modify_image` policy it enforces `get_image` policy which"},{"line_number":35,"context_line":"enforces `get_image_location` policy. This can be confusing for operators"},{"line_number":36,"context_line":"modifying the policy for `modify_image` and wondering why it hasn\u0027t taken"},{"line_number":37,"context_line":"effect if the `get_image` policy or `get_image_policy` short-circuits the"},{"line_number":38,"context_line":"operation."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":4,"id":"4b189927_8a97bcc7","line":38,"range":{"start_line":35,"start_character":38,"end_line":38,"end_character":10},"in_reply_to":"b6b6390c_a8312e34","updated":"2021-07-08 15:41:12.000000000","message":"Good example of what will break if the get_image and modify_image are not enforced together anymore is our image update calls.\n\nClient cannot form the json patch at all, and if you hadcraft it either the response will be broken or that specific API will be leaking data as the response for that call is the image metadata in the response body. Including the properties that are read-only in schema or did not get modified in any way.","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"},{"author":{"_account_id":8122,"name":"Cyril Roelandt","email":"cyril@redhat.com","username":"cyril.roelandt.enovance"},"change_message_id":"f3c40bdd6a41fb8dae1e3276ac213815e20dba13","unresolved":true,"context_lines":[{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. Backward compatibility will be maintained while moving policies closer to"},{"line_number":58,"context_line":"   API layer. (NOTE: RBAC related changes are not considered here.)"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":61,"context_line":"   file from the test repo, instead our default policies should be used and"},{"line_number":62,"context_line":"   overridden as and when required."}],"source_content_type":"text/x-rst","patch_set":4,"id":"ececd1dd_378ee6c8","line":59,"range":{"start_line":59,"start_character":0,"end_line":59,"end_character":0},"updated":"2021-07-05 20:32:51.000000000","message":"I\u0027m sorry I missed the meeting on this topic, but I don\u0027t understand exactly how we can have both 2) and 3).\n\n\nIf the get_* policies are no longer enforced when updating/deleting/uploading/downloading images, doesn\u0027t that somehow change the behaviour of Glance? What exactly do you mean by \"backward compatibility\" then?","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"},{"author":{"_account_id":8122,"name":"Cyril Roelandt","email":"cyril@redhat.com","username":"cyril.roelandt.enovance"},"change_message_id":"2e97f8396d57770d5358195eb39fdd60dfd4fc66","unresolved":true,"context_lines":[{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. Backward compatibility will be maintained while moving policies closer to"},{"line_number":58,"context_line":"   API layer. (NOTE: RBAC related changes are not considered here.)"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":61,"context_line":"   file from the test repo, instead our default policies should be used and"},{"line_number":62,"context_line":"   overridden as and when required."}],"source_content_type":"text/x-rst","patch_set":4,"id":"113e1ee1_df7d6380","line":59,"range":{"start_line":59,"start_character":0,"end_line":59,"end_character":0},"in_reply_to":"67b3e287_fd6be407","updated":"2021-07-07 21:49:46.000000000","message":"OK, thanks for explaining things further.","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e2277ff3b8a8d003211a29d5c9f36b854f45c5c8","unresolved":true,"context_lines":[{"line_number":56,"context_line":""},{"line_number":57,"context_line":"3. Backward compatibility will be maintained while moving policies closer to"},{"line_number":58,"context_line":"   API layer. (NOTE: RBAC related changes are not considered here.)"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"4. At the moment our unit and functional tests are referring to policy.yaml"},{"line_number":61,"context_line":"   file from the test repo, instead our default policies should be used and"},{"line_number":62,"context_line":"   overridden as and when required."}],"source_content_type":"text/x-rst","patch_set":4,"id":"67b3e287_fd6be407","line":59,"range":{"start_line":59,"start_character":0,"end_line":59,"end_character":0},"in_reply_to":"ececd1dd_378ee6c8","updated":"2021-07-06 14:35:48.000000000","message":"The only behavioral change would be if an operator set the policies for get and update to be different from the default and different from each other. The operator can *already* cause \"behavioral change(s)\" in glance, according to that definition, by altering the policy. If we allow them to set custom policies at all, then they can alter those behaviors.\n\nI think what Abhi means by backwards compatibility here is that we won\u0027t remove or change any policy names (which would totally orphan a chunk of an existing policy) and try to keep the same semantics where possible (i.e. not make update_image suddenly also refer to delete operations, etc). That makes sense to me and I think it makes sense for it to be in the spec here like this.\n\nLike anything else, if we make changes to the backend, then custom things operators are doing may require some review and tweaking. We could say \"well, Glance required get_image to do update_image in 2010, so we will forever check get_image *and* update_image when doing an update,\" but that precludes ever being able to allow operators to actually write policies they think they should be able to write, such as the use-cases I gave in earlier discussion on this spec.\n\nRBAC itself is a big change in behavior across the board, in all projects, and yet it\u0027s clearly identified by the larger community of developers and operators and a necessary effort to get ourselves to the point of actually being able to implement a sane security policy. This refactoring is just a step in the way of getting there, and changes like this are going to be required. It\u0027s what release notes, upgrade tool checks, etc are for.","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"},{"author":{"_account_id":5202,"name":"Erno Kuvaja","email":"jokke@usr.fi","username":"jokke"},"change_message_id":"f3b9213dfd3d1425c1a94fa169eb00a36471000c","unresolved":true,"context_lines":[{"line_number":106,"context_line":"Other deployer impact"},{"line_number":107,"context_line":"---------------------"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"Considering experimental support added for project scope realted to Secure"},{"line_number":110,"context_line":"RBAC, operators need to understand which policies to govern and how to"},{"line_number":111,"context_line":"configure them properly. Also, there\u0027s likely to be some tweaking and"},{"line_number":112,"context_line":"testing of any custom policies during upgrade to Xena (or beyond)."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Developer impact"},{"line_number":115,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"42e39328_e7eecaf6","line":112,"range":{"start_line":109,"start_character":0,"end_line":112,"end_character":66},"updated":"2021-07-05 14:04:19.000000000","message":"As noted on L 57 point 3. of proposed change the RBAC changes are not considered within this spec. So I do not understand why they are deployment impact consideration within the scope of this spec?","commit_id":"3c54a84d9ce044a1e159a6abeb59ccf7ce44d67a"}]}