)]}'
{"doc/source/reference/policy-enforcement.rst":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9545b3e28b25bd06d1a88c9bc9d748ed54d5e100","unresolved":false,"context_lines":[{"line_number":18,"context_line":"REST API Policy Enforcement"},{"line_number":19,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"The following describes some of the short-comings in how policy is used and"},{"line_number":22,"context_line":"enforced in nova, along with some benefits of fixing those issues. Each issue"},{"line_number":23,"context_line":"has a section dedicated to describing the underlying cause and historical"},{"line_number":24,"context_line":"context in greater detail."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_9f9c8c6a","line":21,"range":{"start_line":21,"start_character":36,"end_line":21,"end_character":49},"updated":"2019-03-18 20:29:31.000000000","message":"shortcomings","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"38764c32fefe948928092ac69a73118d047c58fb","unresolved":false,"context_lines":[{"line_number":18,"context_line":"REST API Policy Enforcement"},{"line_number":19,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"The following describes some of the short-comings in how policy is used and"},{"line_number":22,"context_line":"enforced in nova, along with some benefits of fixing those issues. Each issue"},{"line_number":23,"context_line":"has a section dedicated to describing the underlying cause and historical"},{"line_number":24,"context_line":"context in greater detail."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_baa5d6a0","line":21,"range":{"start_line":21,"start_character":36,"end_line":21,"end_character":49},"in_reply_to":"5fc1f717_9f9c8c6a","updated":"2019-03-18 21:07:57.000000000","message":"Done","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"14d8ee480482d33bfa7be724fda85bde1e38443e","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"The following is a list of issues with the existing policy enforcement system:"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"* Default policies lack exhaustive testing"},{"line_number":32,"context_line":"* Mismatch between authoritative scope and resources"},{"line_number":33,"context_line":"* Policies are inconsistently named"},{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_ca749d00","line":31,"updated":"2019-03-18 14:49:47.000000000","message":"I\u0027m not sure about this one - the defaults are about all that get tested in our functional and integration (tempest) testing. The only things that change policy and run tests against them in a non-unit-test environment is patrole isn\u0027t it?","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"f02216586c7d6d7c8cf942321a5a53562fc99e01","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"The following is a list of issues with the existing policy enforcement system:"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"* Default policies lack exhaustive testing"},{"line_number":32,"context_line":"* Mismatch between authoritative scope and resources"},{"line_number":33,"context_line":"* Policies are inconsistently named"},{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_0d0cf192","line":31,"in_reply_to":"5fc1f717_7ad8ce51","updated":"2019-03-18 23:12:51.000000000","message":"\u003e Also, to the best of my knowledge patrole doesn\u0027t test like this [1].\n\nThat\u0027s true for nova. We do have some unit tests for stuff in the API like this:\n\nhttps://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/test_admin_password.py#L160\n\nBut it\u0027s not comprehensive.","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"71ee3eb284acdb7ddc15f9991dcfc092db89a14b","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"The following is a list of issues with the existing policy enforcement system:"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"* Default policies lack exhaustive testing"},{"line_number":32,"context_line":"* Mismatch between authoritative scope and resources"},{"line_number":33,"context_line":"* Policies are inconsistently named"},{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_7ad8ce51","line":31,"in_reply_to":"5fc1f717_ca749d00","updated":"2019-03-18 21:07:23.000000000","message":"As far as I know, patrole is the only thing testing policy outside of tempest isolation of tempest/api/compute/admin and everything else in tempest/api/compute/.\n\nI should clarify that this doesn\u0027t have to be a full functional test. It\u0027s really just meant to be an API test, like what is described here [0].\n\nAlso, to the best of my knowledge patrole doesn\u0027t test like this [1].\n\n[0] https://docs.openstack.org/keystone/latest/contributor/services.html#ruthless-testing\n[1] https://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/protection/v3/test_users.py","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"14d8ee480482d33bfa7be724fda85bde1e38443e","unresolved":false,"context_lines":[{"line_number":31,"context_line":"* Default policies lack exhaustive testing"},{"line_number":32,"context_line":"* Mismatch between authoritative scope and resources"},{"line_number":33,"context_line":"* Policies are inconsistently named"},{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"},{"line_number":35,"context_line":"* Policy enforcement is spread across multiple levels and components"},{"line_number":36,"context_line":"* Some policies use hard-coded check strings"},{"line_number":37,"context_line":"* Some APIs do not use granular policies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_6d2343a8","line":34,"updated":"2019-03-18 14:49:47.000000000","message":"I\u0027m assuming this is related to the context_is_admin hack in nova?","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"71ee3eb284acdb7ddc15f9991dcfc092db89a14b","unresolved":false,"context_lines":[{"line_number":31,"context_line":"* Default policies lack exhaustive testing"},{"line_number":32,"context_line":"* Mismatch between authoritative scope and resources"},{"line_number":33,"context_line":"* Policies are inconsistently named"},{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"},{"line_number":35,"context_line":"* Policy enforcement is spread across multiple levels and components"},{"line_number":36,"context_line":"* Some policies use hard-coded check strings"},{"line_number":37,"context_line":"* Some APIs do not use granular policies"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_5aa392b2","line":34,"in_reply_to":"5fc1f717_6d2343a8","updated":"2019-03-18 21:07:23.000000000","message":"Well, kind of. Traditionally, keystone only ever provided the `admin` role upon installation, which is why you see is hard-coded and overloaded everywhere.\n\nIn Rocky keystone included two additional roles, `member` and `reader` during bootstrap [0].\n\nThis makes it easier for service developers to write consistent defaults if they can assume those roles are present. It also helps prevent some services from using `observer` and others using `auditor` and others using `reader`.\n\n[0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"14d8ee480482d33bfa7be724fda85bde1e38443e","unresolved":false,"context_lines":[{"line_number":32,"context_line":"* Mismatch between authoritative scope and resources"},{"line_number":33,"context_line":"* Policies are inconsistently named"},{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"},{"line_number":35,"context_line":"* Policy enforcement is spread across multiple levels and components"},{"line_number":36,"context_line":"* Some policies use hard-coded check strings"},{"line_number":37,"context_line":"* Some APIs do not use granular policies"},{"line_number":38,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_8d4f8f69","line":35,"updated":"2019-03-18 14:49:47.000000000","message":"And this is probably the project_only stuff in the DB API.","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"71ee3eb284acdb7ddc15f9991dcfc092db89a14b","unresolved":false,"context_lines":[{"line_number":32,"context_line":"* Mismatch between authoritative scope and resources"},{"line_number":33,"context_line":"* Policies are inconsistently named"},{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"},{"line_number":35,"context_line":"* Policy enforcement is spread across multiple levels and components"},{"line_number":36,"context_line":"* Some policies use hard-coded check strings"},{"line_number":37,"context_line":"* Some APIs do not use granular policies"},{"line_number":38,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_ba971645","line":35,"in_reply_to":"5fc1f717_8d4f8f69","updated":"2019-03-18 21:07:23.000000000","message":"Right - sounds like cinder suffers the same problem.\n\nInstead, it would be nice to encapsulate all this policy stuff in a single layer, that way it\u0027ll be easier to continuously evolve in the future. And it\u0027ll be easier for developers to understand.","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"14d8ee480482d33bfa7be724fda85bde1e38443e","unresolved":false,"context_lines":[{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"},{"line_number":35,"context_line":"* Policy enforcement is spread across multiple levels and components"},{"line_number":36,"context_line":"* Some policies use hard-coded check strings"},{"line_number":37,"context_line":"* Some APIs do not use granular policies"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Addressing the list above helps operators by:"},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_2d3e9bb7","line":37,"range":{"start_line":37,"start_character":32,"end_line":37,"end_character":40},"updated":"2019-03-18 14:49:47.000000000","message":"rules?","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"71ee3eb284acdb7ddc15f9991dcfc092db89a14b","unresolved":false,"context_lines":[{"line_number":34,"context_line":"* Current defaults do not use default roles provided from keystone"},{"line_number":35,"context_line":"* Policy enforcement is spread across multiple levels and components"},{"line_number":36,"context_line":"* Some policies use hard-coded check strings"},{"line_number":37,"context_line":"* Some APIs do not use granular policies"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Addressing the list above helps operators by:"},{"line_number":40,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_7a8f6e29","line":37,"range":{"start_line":37,"start_character":32,"end_line":37,"end_character":40},"in_reply_to":"5fc1f717_2d3e9bb7","updated":"2019-03-18 21:07:23.000000000","message":"Done","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"14d8ee480482d33bfa7be724fda85bde1e38443e","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"1. Providing them with flexible and useful defaults"},{"line_number":42,"context_line":"2. Reducing the likelihood of writing and maintaining custom policies"},{"line_number":43,"context_line":"3. Improving interoperability between deployment"},{"line_number":44,"context_line":"4. Increasing RBAC confidence through first-class testing and verification"},{"line_number":45,"context_line":"5. Reducing complexity by using consistent policy naming conventions"},{"line_number":46,"context_line":"6. Exposing more functionality to end-users, safely, making the entire nova API"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_6da6e311","line":43,"range":{"start_line":43,"start_character":38,"end_line":43,"end_character":48},"updated":"2019-03-18 14:49:47.000000000","message":"deployments","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"71ee3eb284acdb7ddc15f9991dcfc092db89a14b","unresolved":false,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"1. Providing them with flexible and useful defaults"},{"line_number":42,"context_line":"2. Reducing the likelihood of writing and maintaining custom policies"},{"line_number":43,"context_line":"3. Improving interoperability between deployment"},{"line_number":44,"context_line":"4. Increasing RBAC confidence through first-class testing and verification"},{"line_number":45,"context_line":"5. Reducing complexity by using consistent policy naming conventions"},{"line_number":46,"context_line":"6. Exposing more functionality to end-users, safely, making the entire nova API"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_da7f8212","line":43,"range":{"start_line":43,"start_character":38,"end_line":43,"end_character":48},"in_reply_to":"5fc1f717_6da6e311","updated":"2019-03-18 21:07:23.000000000","message":"Done","commit_id":"f9def473547497f493af74e2d3bb05a382475ca7"}]}