)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"65e666990f0aeb915fc662c2999190ac50b704bb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ccb5330f_8f556b19","updated":"2024-01-10 15:24:38.000000000","message":"recheck - likely whitespace but need fresh logs","commit_id":"1bc6fab840540b681f016e67249f9821055bca3f"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"90d864ba7c5cc416b71d1749db733cc08a44b7b8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"34522338_30be78d1","updated":"2024-02-07 16:04:44.000000000","message":"I think it is a logical next step to implement \"manager\" for domain scope, so, in general I agree with the direction of the spec.  However, I am very much opposed to adding a new role, when the existing \"manager\" role will solve this use case.\n\nI sort-of assumed that the \"manager\" role would eventually be implemented for a Domain Manager persona, and I think that the fact that it is missing from the SRBAC community goal is just an oversight.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c0136dad437e9322d2cfa70c7be27e3071e9b7c3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ff65747b_57c8d4ca","updated":"2024-02-07 14:25:08.000000000","message":"from first discussions","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"8e88472df8c664a2d78dc5e73ee376eff1172167","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"dcae2953_d9992515","updated":"2024-04-17 12:31:02.000000000","message":"I\u0027m marking all the comments related to the role name as resolved now since we updated the spec to re-use the existing \"manager\" role.","commit_id":"557adfa072d37851fc1801135b7ebbf5ed16c2af"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"2befd8e3a7433d1b8f8911f6c9dea74b27299bde","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"afa810f8_efbb82e2","updated":"2024-04-09 15:31:58.000000000","message":"That makes total sense to me personally. Proposed change looks logical and I don\u0027t see any obvious flaws. The really crucial part of limiting roles that can be assigned is also covered and can be configured (to add some more roles if needed).\n\nSo would be really awesome to have that in keystone.","commit_id":"557adfa072d37851fc1801135b7ebbf5ed16c2af"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"a050f29f559242d52a5b3181df1dd79dbfd7469a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"604058cc_2031528c","updated":"2024-04-17 13:53:15.000000000","message":"Do you have accidentally restored some old state that introduces \"domain-manager\" _role_ (I read it in lots of places across the code)? I thought it was agreed to use \"manager\" role for \"domain-manager\" persona.","commit_id":"cb1d60294ef85e937a06d2ea25ed5458b348338b"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"9a8da3bb6d30190dca4885ee3325e79093ca7f4d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"823b198b_0cf403b1","updated":"2024-04-17 18:46:40.000000000","message":"Agree with the idea. lgtm","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"9f61a3333f18f911f8d7e99e2a5b7c635233cace","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"8c1e7d7e_eb33b985","updated":"2024-04-19 15:41:12.000000000","message":"This is looking much better.  Just a few comments about renaming constants when changing the values.\n\nOther than that we will have to be extra careful to build the `target` dict correctly in all affected APIs.  I have run into issues before because we had inconsisent `target` dicts across different methods in the same API.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"dbbeef88b7810674bc69989c88966567dfc7b7b8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"b1c19e31_83a4de15","updated":"2024-04-17 16:23:17.000000000","message":"looks like what we were discussing.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"12d97204f4a97b1678e7e80f9e9852a4947c424b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"c65ffc88_45378d6a","updated":"2024-04-29 09:17:09.000000000","message":"Thanks for the review comments so far! I adjusted a few things based on the feedback.\n\nSince the default implementation seems to have changed since we initially submitted the spec, I also aligned the code examples with the current implementation.\nFurthermore, I added a new example for addressing multi-resource targets (\"add_user_to_group\") to illustrate necessary additions for proper domain scoping in such cases.","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b88c0ad44a7cd90ae62bc6302c05710ae66fe70f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"d3d3f6af_3ca72d65","updated":"2024-04-29 17:38:00.000000000","message":"lgtm, thanks for adding more details and example.","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"18a86f9670d7344dcffa94bc6fba67be2f077ff8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"2b188496_cd4d5738","updated":"2024-05-28 09:31:50.000000000","message":"I have updated the problem description section based on Sean Mooney\u0027s suggestion (thanks Sean!) and addressed the remaining comments.","commit_id":"8ef34e067bfe14747300702b4bfeca05fcb818fa"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"13832bc48e290c099212b4305377c9b063e079ac","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":12,"id":"76e1cfb8_351f1220","updated":"2024-05-29 17:07:20.000000000","message":"still lgtm","commit_id":"71a91a58eac1389ef3e19637ca7534a3687b4166"}],"specs/keystone/2023.1/domain-manager-role.rst":[{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"90d864ba7c5cc416b71d1749db733cc08a44b7b8","unresolved":true,"context_lines":[{"line_number":17,"context_line":"\u003chttps://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html\u003e`_"},{"line_number":18,"context_line":"introduced the ``manager`` role for projects as a customer-side management role"},{"line_number":19,"context_line":"between ``admin`` and ``member`` but added no such role model for domains."},{"line_number":20,"context_line":"This specification introduces a new ``domain-manager`` role to fill that gap"},{"line_number":21,"context_line":"and enables domain-scoped identity self-service capabilities for customers."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"b624b711_7ff7d579","line":20,"range":{"start_line":20,"start_character":19,"end_line":20,"end_character":54},"updated":"2024-02-07 16:04:44.000000000","message":"A new role is not necessary for this.  We can re-use the existing ``manager`` role, which has the added benefit of already being implemented, and already being part of role implications.\n\nAll we need is to enhance the existing policies to allow/deny tokens that are domain-scoped with the \"manager\" role.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"8e88472df8c664a2d78dc5e73ee376eff1172167","unresolved":false,"context_lines":[{"line_number":17,"context_line":"\u003chttps://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html\u003e`_"},{"line_number":18,"context_line":"introduced the ``manager`` role for projects as a customer-side management role"},{"line_number":19,"context_line":"between ``admin`` and ``member`` but added no such role model for domains."},{"line_number":20,"context_line":"This specification introduces a new ``domain-manager`` role to fill that gap"},{"line_number":21,"context_line":"and enables domain-scoped identity self-service capabilities for customers."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"b57f71bf_c084ea68","line":20,"range":{"start_line":20,"start_character":19,"end_line":20,"end_character":54},"in_reply_to":"b624b711_7ff7d579","updated":"2024-04-17 12:31:02.000000000","message":"Done","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"90d864ba7c5cc416b71d1749db733cc08a44b7b8","unresolved":true,"context_lines":[{"line_number":47,"context_line":"``domain-manager`` and adjust existing policy defaults to incorporate this role"},{"line_number":48,"context_line":"accordingly like described below."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7c5ad8cf_aae6842d","line":52,"range":{"start_line":50,"start_character":0,"end_line":52,"end_character":44},"updated":"2024-02-07 16:04:44.000000000","message":"Can you explain the rationale behind this?  I think that you will still want implied roles for this use case.\n\nThe way I\u0027m understanding this spec is that we want to consider a new persona:  The Domain Manager.  And we can define this new persona as a user that has the \"manager\" role assigned on a domain.  This persona would probably still want to access APIs that require \"member\" roles, such as listing users within a domain, as well as APIs that require \"reader\" role.  This will only be possible only with implied roles.\n\nThat is to say, that a token for the Domain Manager persona would be scoped to a specific domain and include \"manager\", \"member\", and \"reader\" in the roles list so that any policies that require those roles will allow the request.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"8e88472df8c664a2d78dc5e73ee376eff1172167","unresolved":false,"context_lines":[{"line_number":47,"context_line":"``domain-manager`` and adjust existing policy defaults to incorporate this role"},{"line_number":48,"context_line":"accordingly like described below."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9d1f0330_7c3e5cfd","line":52,"range":{"start_line":50,"start_character":0,"end_line":52,"end_character":44},"in_reply_to":"30599f1c_f7e50852","updated":"2024-04-17 12:31:02.000000000","message":"Done","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"b41e9539c64d73cf0bb6337e595c9ff8efa12fe5","unresolved":true,"context_lines":[{"line_number":47,"context_line":"``domain-manager`` and adjust existing policy defaults to incorporate this role"},{"line_number":48,"context_line":"accordingly like described below."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f9a045a_a9043d8f","line":52,"range":{"start_line":50,"start_character":0,"end_line":52,"end_character":44},"in_reply_to":"41e74725_21a4df48","updated":"2024-02-08 17:10:32.000000000","message":"Ugh, mistyped the wrong role name.\n\n\u003e The only additional change we need to fully enable this persona is to modify the relevant API policies to accept tokens that have the ``manager`` role on a domain scope.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"3a61c9493c33b6516b89e7d8ea014a0dd8ad0c70","unresolved":true,"context_lines":[{"line_number":47,"context_line":"``domain-manager`` and adjust existing policy defaults to incorporate this role"},{"line_number":48,"context_line":"accordingly like described below."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"41e74725_21a4df48","line":52,"range":{"start_line":50,"start_character":0,"end_line":52,"end_character":44},"in_reply_to":"55b0f94e_30e8afe0","updated":"2024-02-08 17:06:49.000000000","message":"We are already re-using roles for different scopes.  I think it is important to note that the authorization scope for a user is defined by the role-assignment, not the role itself.\n\nIn other words, when you assign a role you have to define what scope it is being assigned in.  This is how we currently differentiate between personas.\n\nWe can look at both the ``member`` and ``reader`` roles as they are currently used to define the System Member, System Reader, Domain Member, Domain Reader, Project Member and Project Reader personas, all with the same two roles.\n\nFor example, let\u0027s assume a fresh install has a ``member`` role with ID 123456.  To grant permissions for the System Member persona to a user with ID 111111, we need to assign this role on the system scope:\n\n    PUT /v3/system/users/111111/roles/123456\n\nSimilarly, to grant permissions for the Domain Member persona to a user with ID 222222, we need to assign that same role on a specific domain.  For argument\u0027s sake let\u0027s assume we have a domain with ID 456789.  So the role assignment will look like:\n\n    PUT /v3/domains/456789/users/222222/roles/123456\n\nLastly, to grant permissions for the Project Member persona to a user with ID 333333, we need to assign the same role on a specific project.  Assuming we have a project ID of 999999, then the role assignment will look like:\n\n    PUT /v3/projects/999999/users/333333/roles/123456\n\nNote that the same role was used for all three users.  In fact, since the ``manager`` role already exists, we can already assign this role on the scope of a domain to grant someone the Domain Manager persona:\n\n    PUT /v3/domains/$DOMAIN_ID/users/$USER_ID/roles/$MANAGER_ROLE_ID\n    \nThe only additional change we need to fully enable this persona is to modify the relevant API policies to accept tokens that have the ``member`` role on a domain scope.\n\nIt\u0027s important to note that even though the same role was used for all users, user 333333 does not have any permissions on the system and is unable to get valid system-scope tokens.  Likewise, the 222222 user only has permissions on that specific domain, and can\u0027t get valid tokens that are scoped to the system or some arbitrary project scope.\n\nThis is why I am opposed to adding a new role that can only be assigned on a domain scope.  It would further complicate role assignments for something that can already be accomplished with the existing roles using existing patterns.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"ad479b38d4fe53bc8bf5b4f92217e7a2f4702acc","unresolved":true,"context_lines":[{"line_number":47,"context_line":"``domain-manager`` and adjust existing policy defaults to incorporate this role"},{"line_number":48,"context_line":"accordingly like described below."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"55b0f94e_30e8afe0","line":52,"range":{"start_line":50,"start_character":0,"end_line":52,"end_character":44},"in_reply_to":"7c5ad8cf_aae6842d","updated":"2024-02-08 12:17:33.000000000","message":"So aligning the persona would imply that a domain-manger has all the same rights as a project-manager.\n\nIn other words it would be `admin` -\u003e `manager` -\u003e `member` -\u003e `reader`. But it would differ in scopes. But do you plan on using the same role names on different scopes? I thought there would only be one `reader` / `member` who is always project-scoped. And one `admin` that should always be system-scoped and project-scoped.\nNow we would have a role `manager` that for on persona is only project-scoped and for another persona would be domain-scoped and project-scoped? I am concerned, that this might lead to misconfigurations.\n\nWhile domains are handled as just another openstack resource, it will create a whole new layer, which lies between the whole openstack cloud and the project layer. From security perspective I would lean towards an explicit separation between the roles that are allowed to handle resources on these layers.\n\nSo including the domain-manager into the hierarchy would be possible, if there is no need for some role, that only manages projects, groups and users in a domain.\nBut I am concerned about using the same name for different layers.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"d080198b5e5d665bd1a432235ee9343bc655ea9d","unresolved":true,"context_lines":[{"line_number":47,"context_line":"``domain-manager`` and adjust existing policy defaults to incorporate this role"},{"line_number":48,"context_line":"accordingly like described below."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."}],"source_content_type":"text/x-rst","patch_set":2,"id":"30599f1c_f7e50852","line":52,"range":{"start_line":50,"start_character":0,"end_line":52,"end_character":44},"in_reply_to":"7f9a045a_a9043d8f","updated":"2024-04-09 15:36:43.000000000","message":"Well, eventually I read that of `The Domain Manager` \u003d\u003d `manager` assigned to the domain scope.\n\nSo I\u0027d tend to agree that new role should not be required here and we can go forward just with `manager` role assigned to the domain.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"90d864ba7c5cc416b71d1749db733cc08a44b7b8","unresolved":true,"context_lines":[{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"All default policies that concern users, projects, groups and roles in the"},{"line_number":58,"context_line":"Identity API have to be adjusted to incorporate the ``domain-manager`` role"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fae07f89_b5e8c9c6","line":55,"range":{"start_line":53,"start_character":0,"end_line":55,"end_character":73},"updated":"2024-02-07 16:04:44.000000000","message":"Again, having a new role that is exclusive to Keystone sort-of goes against the spirit of the goal of making roles consistent across projects.\n\nAssigning the \"manager\" role and updating the keystone policies does not affect access to APIs in other projects, so I don\u0027t understand why a whole new role would be needed.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"8e88472df8c664a2d78dc5e73ee376eff1172167","unresolved":false,"context_lines":[{"line_number":50,"context_line":"This role should be kept separate to the existing role hierarchy that includes"},{"line_number":51,"context_line":"``admin``, ``member``, and ``reader``. Those role definitions were created to"},{"line_number":52,"context_line":"hierarchical RBAC across all OpenStack APIs."},{"line_number":53,"context_line":"The ``domain-manager`` role however is exclusive to Keystone for managing"},{"line_number":54,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":55,"context_line":"within a domain to enable identity management self-service for end users."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"All default policies that concern users, projects, groups and roles in the"},{"line_number":58,"context_line":"Identity API have to be adjusted to incorporate the ``domain-manager`` role"}],"source_content_type":"text/x-rst","patch_set":2,"id":"463a5f7b_e6b7f383","line":55,"range":{"start_line":53,"start_character":0,"end_line":55,"end_character":73},"in_reply_to":"fae07f89_b5e8c9c6","updated":"2024-04-17 12:31:02.000000000","message":"Done","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"90d864ba7c5cc416b71d1749db733cc08a44b7b8","unresolved":true,"context_lines":[{"line_number":67,"context_line":"   # been replaced by \"role:domain-manager\""},{"line_number":68,"context_line":"   SYSTEM_ADMIN_OR_DOMAIN_ADMIN \u003d ("},{"line_number":69,"context_line":"       \u0027(role:admin and system_scope:all) or \u0027"},{"line_number":70,"context_line":"       \u0027(role:domain-manager and domain_id:%(target.project.domain_id)s)\u0027"},{"line_number":71,"context_line":"   )"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"   # policy defintions using this definition stay the same, for example"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a30967f_a8c4c70b","line":70,"range":{"start_line":70,"start_character":14,"end_line":70,"end_character":28},"updated":"2024-02-07 16:04:44.000000000","message":"This rule would be the same as\n\n    \u0027(role:manager and domain_id:%(target.project.domain_id)s)\u0027\n\nwithout the need of adding the new role.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"8e88472df8c664a2d78dc5e73ee376eff1172167","unresolved":false,"context_lines":[{"line_number":67,"context_line":"   # been replaced by \"role:domain-manager\""},{"line_number":68,"context_line":"   SYSTEM_ADMIN_OR_DOMAIN_ADMIN \u003d ("},{"line_number":69,"context_line":"       \u0027(role:admin and system_scope:all) or \u0027"},{"line_number":70,"context_line":"       \u0027(role:domain-manager and domain_id:%(target.project.domain_id)s)\u0027"},{"line_number":71,"context_line":"   )"},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"   # policy defintions using this definition stay the same, for example"}],"source_content_type":"text/x-rst","patch_set":2,"id":"87d1c479_967a0300","line":70,"range":{"start_line":70,"start_character":14,"end_line":70,"end_character":28},"in_reply_to":"7a30967f_a8c4c70b","updated":"2024-04-17 12:31:02.000000000","message":"Done","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"90d864ba7c5cc416b71d1749db733cc08a44b7b8","unresolved":true,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"   # below \"role:admin\" has been replaced by \"role:domain-manager\""},{"line_number":91,"context_line":"   GRANTS_DOMAIN_ADMIN \u003d ("},{"line_number":92,"context_line":"       \u0027(role:domain-manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"},{"line_number":93,"context_line":"       \u0027 \u0027 + DOMAIN_MATCHES_PROJECT_DOMAIN + \u0027) or \u0027"},{"line_number":94,"context_line":"       \u0027(role:domain-manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"},{"line_number":95,"context_line":"       \u0027 \u0027 + DOMAIN_MATCHES_TARGET_DOMAIN + \u0027) or \u0027"}],"source_content_type":"text/x-rst","patch_set":2,"id":"42c97b71_9736f4c6","line":92,"range":{"start_line":92,"start_character":14,"end_line":92,"end_character":21},"updated":"2024-02-07 16:04:44.000000000","message":"Again, using the existing \"manager\" role here would lead to the same result.  Additionally re-using the \"manager\" role that is already part of implied roles would still allow users with the \"admin\" role to access this API after this change is made.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"8e88472df8c664a2d78dc5e73ee376eff1172167","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":"   # below \"role:admin\" has been replaced by \"role:domain-manager\""},{"line_number":91,"context_line":"   GRANTS_DOMAIN_ADMIN \u003d ("},{"line_number":92,"context_line":"       \u0027(role:domain-manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"},{"line_number":93,"context_line":"       \u0027 \u0027 + DOMAIN_MATCHES_PROJECT_DOMAIN + \u0027) or \u0027"},{"line_number":94,"context_line":"       \u0027(role:domain-manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"},{"line_number":95,"context_line":"       \u0027 \u0027 + DOMAIN_MATCHES_TARGET_DOMAIN + \u0027) or \u0027"}],"source_content_type":"text/x-rst","patch_set":2,"id":"babe3cdd_a18a0271","line":92,"range":{"start_line":92,"start_character":14,"end_line":92,"end_character":21},"in_reply_to":"42c97b71_9736f4c6","updated":"2024-04-17 12:31:02.000000000","message":"Done","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"90d864ba7c5cc416b71d1749db733cc08a44b7b8","unresolved":true,"context_lines":[{"line_number":117,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":118,"context_line":"   policy.RuleDefault("},{"line_number":119,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":120,"context_line":"       check_str\u003d\"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":121,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Finally, all the rules that concern role grants should be adjusted to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"20f41828_5e00664a","line":120,"range":{"start_line":120,"start_character":29,"end_line":120,"end_character":45},"updated":"2024-02-07 16:04:44.000000000","message":"Good point about not allowing a \"manager\" to assign the \"admin\" role.  However, we may want to consider the case where a domain manager may want to assign the \"manager\" role to another user, effectively adding a peer manager on that domain.\n\nWe\u0027ll have to make sure that the implementation of this does populate the target object correctly, since I am unsure that this is already part of it.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":28271,"name":"Josephine Seifert","email":"josephine.seifert@cloudandheat.com","username":"josei"},"change_message_id":"ad479b38d4fe53bc8bf5b4f92217e7a2f4702acc","unresolved":true,"context_lines":[{"line_number":117,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":118,"context_line":"   policy.RuleDefault("},{"line_number":119,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":120,"context_line":"       check_str\u003d\"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":121,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Finally, all the rules that concern role grants should be adjusted to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ee00bcd6_c49d8d7f","line":120,"range":{"start_line":120,"start_character":29,"end_line":120,"end_character":45},"in_reply_to":"20f41828_5e00664a","updated":"2024-02-08 12:17:33.000000000","message":"you are right, we should allow the assigning of project managers here.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"e7b9a83fcb73398c54c325c4feb859e3e829c545","unresolved":false,"context_lines":[{"line_number":117,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":118,"context_line":"   policy.RuleDefault("},{"line_number":119,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":120,"context_line":"       check_str\u003d\"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":121,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Finally, all the rules that concern role grants should be adjusted to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dbd281de_d333b82d","line":120,"range":{"start_line":120,"start_character":29,"end_line":120,"end_character":45},"in_reply_to":"ee00bcd6_c49d8d7f","updated":"2024-04-17 12:47:16.000000000","message":"Adjusted the spec accordingly.","commit_id":"f0940f651cc2ac3bfda3cb5b2b71e7079e77aea0"}],"specs/keystone/2024.1/domain-manager-persona.rst":[{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"9f61a3333f18f911f8d7e99e2a5b7c635233cace","unresolved":true,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"   # for the second part of the folllowing \"or\" conditional \"role:admin\" has"},{"line_number":63,"context_line":"   # been replaced by \"role:manager\""},{"line_number":64,"context_line":"   SYSTEM_ADMIN_OR_DOMAIN_ADMIN \u003d ("},{"line_number":65,"context_line":"       \u0027(role:admin and system_scope:all) or \u0027"},{"line_number":66,"context_line":"       \u0027(role:manager and domain_id:%(target.project.domain_id)s)\u0027"},{"line_number":67,"context_line":"   )"}],"source_content_type":"text/x-rst","patch_set":9,"id":"074053ff_86e22ab9","line":64,"range":{"start_line":64,"start_character":19,"end_line":64,"end_character":31},"updated":"2024-04-19 15:41:12.000000000","message":"We want these constants to represent the actual policy, so I would rename this SYSTEM_ADMIN_OR_DOMAIN_MANAGER","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"c87d53854736e78a2a0ee2826fcf83630ae63157","unresolved":true,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"   # for the second part of the folllowing \"or\" conditional \"role:admin\" has"},{"line_number":63,"context_line":"   # been replaced by \"role:manager\""},{"line_number":64,"context_line":"   SYSTEM_ADMIN_OR_DOMAIN_ADMIN \u003d ("},{"line_number":65,"context_line":"       \u0027(role:admin and system_scope:all) or \u0027"},{"line_number":66,"context_line":"       \u0027(role:manager and domain_id:%(target.project.domain_id)s)\u0027"},{"line_number":67,"context_line":"   )"}],"source_content_type":"text/x-rst","patch_set":9,"id":"21da2f27_5f925565","line":64,"range":{"start_line":64,"start_character":19,"end_line":64,"end_character":31},"in_reply_to":"074053ff_86e22ab9","updated":"2024-04-19 17:17:21.000000000","message":"++","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"12d97204f4a97b1678e7e80f9e9852a4947c424b","unresolved":false,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"   # for the second part of the folllowing \"or\" conditional \"role:admin\" has"},{"line_number":63,"context_line":"   # been replaced by \"role:manager\""},{"line_number":64,"context_line":"   SYSTEM_ADMIN_OR_DOMAIN_ADMIN \u003d ("},{"line_number":65,"context_line":"       \u0027(role:admin and system_scope:all) or \u0027"},{"line_number":66,"context_line":"       \u0027(role:manager and domain_id:%(target.project.domain_id)s)\u0027"},{"line_number":67,"context_line":"   )"}],"source_content_type":"text/x-rst","patch_set":9,"id":"98bbb5e6_8064606f","line":64,"range":{"start_line":64,"start_character":19,"end_line":64,"end_character":31},"in_reply_to":"21da2f27_5f925565","updated":"2024-04-29 09:17:09.000000000","message":"I have changed this and also removed the \"SYSTEM_\" prefix to align it to the current implementation.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"9f61a3333f18f911f8d7e99e2a5b7c635233cace","unresolved":true,"context_lines":[{"line_number":84,"context_line":".. code-block:: python"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"   # below \"role:admin\" has been replaced by \"role:manager\""},{"line_number":87,"context_line":"   GRANTS_DOMAIN_ADMIN \u003d ("},{"line_number":88,"context_line":"       \u0027(role:manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"},{"line_number":89,"context_line":"       \u0027 \u0027 + DOMAIN_MATCHES_PROJECT_DOMAIN + \u0027) or \u0027"},{"line_number":90,"context_line":"       \u0027(role:manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"}],"source_content_type":"text/x-rst","patch_set":9,"id":"043b06ac_8be81977","line":87,"range":{"start_line":87,"start_character":3,"end_line":87,"end_character":22},"updated":"2024-04-19 15:41:12.000000000","message":"Same comment here as above.  I see the benefit of not having to change every policy where this constant is used, however, I think the downside of having a constant whose name does not accurately describe the value is not worth it.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"12d97204f4a97b1678e7e80f9e9852a4947c424b","unresolved":false,"context_lines":[{"line_number":84,"context_line":".. code-block:: python"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"   # below \"role:admin\" has been replaced by \"role:manager\""},{"line_number":87,"context_line":"   GRANTS_DOMAIN_ADMIN \u003d ("},{"line_number":88,"context_line":"       \u0027(role:manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"},{"line_number":89,"context_line":"       \u0027 \u0027 + DOMAIN_MATCHES_PROJECT_DOMAIN + \u0027) or \u0027"},{"line_number":90,"context_line":"       \u0027(role:manager and \u0027 + DOMAIN_MATCHES_USER_DOMAIN + \u0027 and\u0027"}],"source_content_type":"text/x-rst","patch_set":9,"id":"65c69e05_e07cc87d","line":87,"range":{"start_line":87,"start_character":3,"end_line":87,"end_character":22},"in_reply_to":"043b06ac_8be81977","updated":"2024-04-29 09:17:09.000000000","message":"Renamed to \"GRANTS_DOMAIN_MANAGER\" now.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"9f61a3333f18f911f8d7e99e2a5b7c635233cace","unresolved":true,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"e9529a6e_fd00b653","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"updated":"2024-04-19 15:41:12.000000000","message":"alternatively we could just use `not \u0027admin\u0027:$(target.role.name)s` instead of listing all allowed roles.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"12d97204f4a97b1678e7e80f9e9852a4947c424b","unresolved":true,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"ff12c658_762a58c0","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"in_reply_to":"3f1f7855_90d8a387","updated":"2024-04-29 09:17:09.000000000","message":"I strongly agree with Ghanshyam here. From a security perspective we should be explicit here for the default. If operators need additional roles they should be required to deliberately override this default policy in my opinion.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"18a86f9670d7344dcffa94bc6fba67be2f077ff8","unresolved":false,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"c4b5738e_9462b997","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"in_reply_to":"721ce4b7_8a0b7f0c","updated":"2024-05-28 09:31:50.000000000","message":"Acknowledged","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"655cafb0d761f4c500dad171cd7cccbb0224ba93","unresolved":true,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"b1f54838_6869ed0b","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"in_reply_to":"947b88fe_ab2476ff","updated":"2024-05-23 08:44:25.000000000","message":"Correct me if I\u0027m wrong here but in order for custom roles to be effective, they would need to be reflected in the policy settings (e.g. policy.yaml) of the infrastructure, no? And as far as I am aware, there is no API for that as it is part of the cloud infrastructure configuration basically.\n\nSince we intend the domain-manager persona to be given to users outside of the infrastructure (identity management self-service for customers basically), those users would be unable to assign permissions to custom roles as they can\u0027t edit the policy.yaml file of the applicable API services (Nova, Cinder, Keystone etc.).\n\nAs such, I consider the management of roles to be the responsibility of the cloud infrastructure provider who has access to the service configuration.\n\nSo yes, that\u0027s why we are talking about role assignments not role management for the domain-manager persona.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6bccc8f63cd540be1bd906b39f5f7ea5824029bc","unresolved":true,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"721ce4b7_8a0b7f0c","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"in_reply_to":"b1f54838_6869ed0b","updated":"2024-05-23 11:16:20.000000000","message":"ya your correct that what i was realsiing in my second comment.\nto have domain specific roles you woudl need to modify policy.yaml and\nif a operator wants to do that they can also just modify this config option.\n\nso ya management of roles is a cloud infra admin function\ndelegation of roles is a domain managers funciton.\n\ni still think its better to allow delegation fo any role the project manager may have.  the example that comes to mind is at least 3 of our down stream custoemr use custom policy to have a seperate role for live migration.\n\none of them made it so that only sepcial admins could live migrate\nbecause they wanted to restict live migration to the subset of admins that were  on there internal infra team\n\nthe other two customer wanted to give live migration capablity to tenants.\n\nin either case if a cloud infra admin had made this change and granted the live-migration role to a domain manager i think it would be reasonable for that domain manager to be able to delegate that too.\n\ni guess we coudl say in that case the infra admin (who is already wriging custome policy for nova) can just do the same for keyston and update this role.\n\nso while i thnnk the ux might be impovded by not enfocing this in policy but rather doign it in code what is proposed works for the usecase i described so i think it would be reasonabel to move forward with this as is.\n\ni also agree with gmann on not using a negitive regex","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"c87d53854736e78a2a0ee2826fcf83630ae63157","unresolved":true,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"3f1f7855_90d8a387","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"in_reply_to":"e9529a6e_fd00b653","updated":"2024-04-19 17:17:21.000000000","message":"We should avoid using the negative regex in check_str which can allow many other roles also which we do not want. For example, with \u0027not admin\u0027 it will allow role foo to access the API.\n\nMentioning all the allowed roles will restrict the access in correct way.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"10189cb34069ee43262db573fea0b3c8230e5c3a","unresolved":true,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"947b88fe_ab2476ff","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"in_reply_to":"f5adc563_e45ee138","updated":"2024-05-17 14:43:37.000000000","message":"in fact they should be able to asign any role they have or is a custom role defiend for there domain.\n\nadmin is the most problematic that they should not be able to assgine without also having and suing a token with admin.\n\nif we enfoce what roles they can grant in the policy file then \nyou cant have per domain roles.\n\nim not sure if that is something that keystone wants to support becasue realsiticly roles are not domain scoped in other projects so persshape the epxlit filtering as currently speified is the correct approch.\n\n\nis that why the spec specifically calls out \"along with role assignments\"\n\nranther then just roles.\n\ni.e. role creation woudl still require admin?\n\nand domain managers would just be able to assing roles that were precreated by the admin?\n\ngiven how custom  policy work in other projects i guess that makes sense.","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a7faff94b2db788dd3491c393473a21705c32f4a","unresolved":true,"context_lines":[{"line_number":113,"context_line":"   # define a new rule called \"domain_managed_target_role\""},{"line_number":114,"context_line":"   policy.RuleDefault("},{"line_number":115,"context_line":"       name\u003d\u0027domain_managed_target_role\u0027,"},{"line_number":116,"context_line":"       check_str\u003d\"\u0027manager\u0027:%(target.role.name)s or \""},{"line_number":117,"context_line":"                 \"\u0027member\u0027:%(target.role.name)s or \""},{"line_number":118,"context_line":"                 \"\u0027reader\u0027:%(target.role.name)s\"),"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Finally, all the rules that concern role grants should be adjusted to"},{"line_number":121,"context_line":"incorporate this target role restriction. Below is an example for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"f5adc563_e45ee138","line":118,"range":{"start_line":116,"start_character":18,"end_line":118,"end_character":47},"in_reply_to":"ff12c658_762a58c0","updated":"2024-05-17 14:36:10.000000000","message":"i dont think either approch is correct.\n\na domain manager should be able to asign any role they have.\n\nso instead of doing this enforcement via a policy check, i think you should be comparing the role they are trying to assign to the role they have.\n\nusing a nexitive regex or expliclty listing does not allow them to asgin custom roles","commit_id":"48e33cd5b79b89f7a64d21def0c0a436ae3fb992"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a7faff94b2db788dd3491c393473a21705c32f4a","unresolved":true,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"For this purpose a role or persona and corresponding set of permissions are"},{"line_number":40,"context_line":"required which implement this management functionality for customers."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"Proposed Change"},{"line_number":44,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":10,"id":"fcb5a4db_03906dca","line":41,"updated":"2024-05-17 14:36:10.000000000","message":"in the context of a public cloud i can certenly see how this would be desired\n\ni woudl phase the use case like this.\n\n```\nAs the operator of a public cloud, i would like to be able to provision \"virtual private cloud\" VPC on my public cloud instance for reseller customers by allocating the reseller a domain which they can then subdivide on a self-service basis.\n```\n\nin such a vpc mode today the reseller would still ahve to ask the cloud admin to actully set up the relevent projects and users ectra or the public cloud operator would have to grant the reseller admin right.\n\nneither are very practical without a perstient high levle of turst between the reseller and public cloud admin.\n\nrealsitically today you would have to use custom policy and a non standard custom role which is an interop issues between clouds.\n\nthis spec adresses that gap using the standardised manager role.","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"18a86f9670d7344dcffa94bc6fba67be2f077ff8","unresolved":false,"context_lines":[{"line_number":38,"context_line":""},{"line_number":39,"context_line":"For this purpose a role or persona and corresponding set of permissions are"},{"line_number":40,"context_line":"required which implement this management functionality for customers."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"Proposed Change"},{"line_number":44,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":10,"id":"412752b6_13c60aa5","line":41,"in_reply_to":"fcb5a4db_03906dca","updated":"2024-05-28 09:31:50.000000000","message":"Thank you for this example! I think this is a very good example use case description. I have replaced parts of this section by your suggestion.","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a7faff94b2db788dd3491c393473a21705c32f4a","unresolved":true,"context_lines":[{"line_number":46,"context_line":"Adjust existing policy defaults to incorporate the domain-scoped ``manager``"},{"line_number":47,"context_line":"role accordingly like described below."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"The ``domain-manager`` persona should be exclusive to Keystone for managing"},{"line_number":50,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":51,"context_line":"within a domain to enable identity management self-service for end users."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"d60f6bb3_adfe66a9","line":49,"range":{"start_line":49,"start_character":0,"end_line":49,"end_character":62},"updated":"2024-05-17 14:36:10.000000000","message":"this could be problematic.\n\ntoday im not sure if any project other then keystone supprot domain tokens.\n\nbut by stateing this in this spec you are prohiting all other poejct form ever using domian scoped tokens  and the mager role.\n\n\ni.e. nova could never intoduce a concepht where by we coudl mapp hosts to a keystone domaina and then allow domain manager to create  host aggrates and domain specific aviablaity zones.\n\n\nwe dont plan to do that by the way but by defining the domain manager person as exlicvlty for keystone that means that is not a valid thing for any project to design.\n\nwas this your intent?\n\nor did this spec intend to say that the useage of domain-manager person in this spec only desicbes the usage within keystone.\n\n\nif that was the intent then i woudl reword it as\n\n```\nThe ``domain-manager`` persona will be used in Keystone ...\n```","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"18a86f9670d7344dcffa94bc6fba67be2f077ff8","unresolved":false,"context_lines":[{"line_number":46,"context_line":"Adjust existing policy defaults to incorporate the domain-scoped ``manager``"},{"line_number":47,"context_line":"role accordingly like described below."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"The ``domain-manager`` persona should be exclusive to Keystone for managing"},{"line_number":50,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":51,"context_line":"within a domain to enable identity management self-service for end users."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"8204bb70_414aaf00","line":49,"range":{"start_line":49,"start_character":0,"end_line":49,"end_character":62},"in_reply_to":"2a09f67b_79689e7d","updated":"2024-05-28 09:31:50.000000000","message":"Acknowledged","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"655cafb0d761f4c500dad171cd7cccbb0224ba93","unresolved":true,"context_lines":[{"line_number":46,"context_line":"Adjust existing policy defaults to incorporate the domain-scoped ``manager``"},{"line_number":47,"context_line":"role accordingly like described below."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"The ``domain-manager`` persona should be exclusive to Keystone for managing"},{"line_number":50,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":51,"context_line":"within a domain to enable identity management self-service for end users."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"f119e121_14e5d797","line":49,"range":{"start_line":49,"start_character":0,"end_line":49,"end_character":62},"in_reply_to":"d60f6bb3_adfe66a9","updated":"2024-05-23 08:44:25.000000000","message":"Good point. We initially limited the concept to Keystone because we saw the identity management use case for domains here primarily. However, considering the SRBAC rework[^1] as a whole, I agree that it does make sense to broaden the adoption possibilities in a sense that other projects (e.g. Nova) may implement this persona for their uses cases as well.\n\nWe will rephrase this to clarify that this spec will only target to actually *implement* this in Keystone but the persona and \"manager\" role is not meant to be strictly limited to Keystone. It will be entirely up to other projects such as Nova to define and implement domain-level management capabilities using the domain-manager persona for their APIs and resources though. This is out of scope for this spec.\n\n[^1]: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6bccc8f63cd540be1bd906b39f5f7ea5824029bc","unresolved":true,"context_lines":[{"line_number":46,"context_line":"Adjust existing policy defaults to incorporate the domain-scoped ``manager``"},{"line_number":47,"context_line":"role accordingly like described below."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"The ``domain-manager`` persona should be exclusive to Keystone for managing"},{"line_number":50,"context_line":"identity objects such as users, projects and groups along with role assignments"},{"line_number":51,"context_line":"within a domain to enable identity management self-service for end users."},{"line_number":52,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"2a09f67b_79689e7d","line":49,"range":{"start_line":49,"start_character":0,"end_line":49,"end_character":62},"in_reply_to":"f119e121_14e5d797","updated":"2024-05-23 11:16:20.000000000","message":"Acknowledged","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a7faff94b2db788dd3491c393473a21705c32f4a","unresolved":true,"context_lines":[{"line_number":137,"context_line":""},{"line_number":138,"context_line":"However, a domain manager should not be able to assign roles of higher"},{"line_number":139,"context_line":"privileges than themselves, so the set of target roles they are able to"},{"line_number":140,"context_line":"assign/revoke should be restricted using a new rule. Defining this as a rule"},{"line_number":141,"context_line":"offers the advantage that operators or deployers may easily adjust this role"},{"line_number":142,"context_line":"list (which roles are manageable) without the need to rewrite the whole set of"},{"line_number":143,"context_line":"lenghty individual rules for all the API actions:"}],"source_content_type":"text/x-rst","patch_set":10,"id":"c58c8086_215d6653","line":140,"updated":"2024-05-17 14:36:10.000000000","message":"+1\n\na domain manager shoudl only be able to assging roles that they have\n\nif they do not also have the admin role then they should not be able to asgin it.","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"655cafb0d761f4c500dad171cd7cccbb0224ba93","unresolved":false,"context_lines":[{"line_number":137,"context_line":""},{"line_number":138,"context_line":"However, a domain manager should not be able to assign roles of higher"},{"line_number":139,"context_line":"privileges than themselves, so the set of target roles they are able to"},{"line_number":140,"context_line":"assign/revoke should be restricted using a new rule. Defining this as a rule"},{"line_number":141,"context_line":"offers the advantage that operators or deployers may easily adjust this role"},{"line_number":142,"context_line":"list (which roles are manageable) without the need to rewrite the whole set of"},{"line_number":143,"context_line":"lenghty individual rules for all the API actions:"}],"source_content_type":"text/x-rst","patch_set":10,"id":"aa6910cf_00110ad9","line":140,"in_reply_to":"c58c8086_215d6653","updated":"2024-05-23 08:44:25.000000000","message":"Acknowledged","commit_id":"c4cd70f730b60c2bb3fd13ee57484dc189cf0b64"}]}