[policy] Removing the enforce_scope config option
Hello everyone, As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag. What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered. Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure. 2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3]. How to test your project: I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475) oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479 Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies. - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status... I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope. [1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf... [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9... -gmaan
On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
Hello everyone,
As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag.
What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered.
Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure.
2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3].
How to test your project:
I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475)
oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479
Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status... I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope.
Gentle Reminder about the deadline. I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs. You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing of enforce_scope=false and also remove enforce_scopre=true if set explicitly. - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...) Please use the below topic and hashtag for easy tracking: - topic:"secure-rbac" - hashtag:"remove-enforce-scope-flag" -gmaan
[1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf... [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9...
-gmaan
On Wed, 2026-06-17 at 21:27 -0700, Ghanshyam Maan wrote:
On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
Hello everyone,
As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag.
What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered.
Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure.
2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3].
How to test your project:
I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475)
oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479
Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...
I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope.
Gentle Reminder about the deadline.
I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs.
You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing of enforce_scope=false and also remove enforce_scopre=true if set explicitly.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...)
Please use the below topic and hashtag for easy tracking:
Per my comments on the nova and placement changes, I think we should change the approach slightly. As things stand, the proposal is to remove the option from oslo.policy, so that if the option is set in the config it will now be ignored. That means users will inherit this behavior change as a side- effect of upgrading oslo.policy as opposed to upgrading their service. I think that's backwards. Instead, I think services should be explicitly checking for `enforce_scope = False` and refusing to start if so. The option should stay in oslo.policy for now (it its deprecated form) so that anyone who pulls an updated oslo.policy on e.g. Gazpacho won't suddenly find themselves with a large behaviour change. This will require an additional if-statement in each project (along with the already proposed test and release note changes) but it does ensure it is the *service* that controls scope enforcement rather than it coming in via a library side-effect. Does this make sense? Stephen
- topic:"secure-rbac" - hashtag:"remove-enforce-scope-flag"
-gmaan
[1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf... [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9...
-gmaan
On Wed, Jun 24, 2026 at 3:53 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-17 at 21:27 -0700, Ghanshyam Maan wrote:
On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
Hello everyone,
As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag.
What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered.
Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure.
2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3].
How to test your project:
I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475)
oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479
Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...
I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope.
Gentle Reminder about the deadline.
I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs.
You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing of enforce_scope=false and also remove enforce_scopre=true if set explicitly.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...)
Please use the below topic and hashtag for easy tracking:
Per my comments on the nova and placement changes, I think we should change the approach slightly. As things stand, the proposal is to remove the option from oslo.policy, so that if the option is set in the config it will now be ignored. That means users will inherit this behavior change as a side- effect of upgrading oslo.policy as opposed to upgrading their service. I think that's backwards. Instead, I think services should be explicitly checking for `enforce_scope = False` and refusing to start if so. The option should stay in oslo.policy for now (it its deprecated form) so that anyone who pulls an updated oslo.policy on e.g. Gazpacho won't suddenly find themselves with a large behaviour change. This will require an additional if-statement in each project (along with the already proposed test and release note changes) but it does ensure it is the *service* that controls scope enforcement rather than it coming in via a library side-effect.
Does this make sense?
Honestly, I am not sure what we will gain by keeping the config option but not allowing to change its value. That is more confusing to users/operators that there is a config option to toggle the scope enforcement, but it stops working. Regarding the behaviour change coming from service or oslo.policy, that is more of implementation details. If anyone is upgrading the service to the 2026.2 release, they will need to upgrade the required deps also. That reminds me to update the oslo.policy min version in requirements.txt (I will do that once oslo.policy change is merged and released). Mentioning the same in the release notes can clarify it explicitly that from oslo.policy newer version, the enforce_scope will not work. I think that will be the proper way to handle the upgrade impact. I think that is how we have handled the library maintained/controlled things. For example, support of the policy file as JSON format was deprecated/removed from oslo.policy side and service adopted that behaviour via upgrade of oslo.polcy in their deployment. If anyone is upgrading only oslo.policy in Gazpacho or an older version of OpenStack, then they will be reading the release notes and changes done in the newer version of oslo.policy and know what this upgrade means to the deployed services. That is a valid case for any deps. In summary, I am not sure handling the error at service side or oslo.policy side matters much to upgrade, as release notes should clarify the upgrade impact at both side. But keeping the config option with a hard-coded value seems confusing to me. -gmaan
Stephen
- topic:"secure-rbac" - hashtag:"remove-enforce-scope-flag"
-gmaan
[1]
https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf...
[2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9...
-gmaan
On Wed, 2026-06-24 at 09:44 -0700, Ghanshyam Maan wrote:
On Wed, Jun 24, 2026 at 3:53 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-17 at 21:27 -0700, Ghanshyam Maan wrote:
On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
Hello everyone,
As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag.
What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered.
Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure.
2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3].
How to test your project:
I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475)
oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479
Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...
I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope.
Gentle Reminder about the deadline.
I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs.
You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing of enforce_scope=false and also remove enforce_scopre=true if set explicitly.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...)
Please use the below topic and hashtag for easy tracking:
Per my comments on the nova and placement changes, I think we should change the approach slightly. As things stand, the proposal is to remove the option from oslo.policy, so that if the option is set in the config it will now be ignored. That means users will inherit this behavior change as a side- effect of upgrading oslo.policy as opposed to upgrading their service. I think that's backwards. Instead, I think services should be explicitly checking for `enforce_scope = False` and refusing to start if so. The option should stay in oslo.policy for now (it its deprecated form) so that anyone who pulls an updated oslo.policy on e.g. Gazpacho won't suddenly find themselves with a large behaviour change. This will require an additional if-statement in each project (along with the already proposed test and release note changes) but it does ensure it is the *service* that controls scope enforcement rather than it coming in via a library side-effect.
Does this make sense?
Honestly, I am not sure what we will gain by keeping the config option but not allowing to change its value. That is more confusing to users/operators that there is a config option to toggle the scope enforcement, but it stops working.
This is what we gain: https://review.opendev.org/c/openstack/placement/+/994892 With the plan we've currently proposed, if an operator has set `[oslo_policy] enforce_scope` to `False` on Gazpacho and then upgrade to Hibiscus, the option will now be ignored and things will silently switch over to scope enforcement. That feels like a "Bad Thing (TM)" to do. By comparison, if we keep the option in oslo.policy a while longer and instead check its value in the service then the operator will immediately know that the feature is no longer supported, just as we're seeing in those CI results.
Regarding the behaviour change coming from service or oslo.policy, that is more of implementation details. If anyone is upgrading the service to the 2026.2 release, they will need to upgrade the required deps also. That reminds me to update the oslo.policy min version in requirements.txt (I will do that once oslo.policy change is merged and released). Mentioning the same in the release notes can clarify it explicitly that from oslo.policy newer version, the enforce_scope will not work. I think that will be the proper way to handle the upgrade impact.
I don't know if it's an implementation detail though. Having a behaviour change come in via a dependency is harder to control and understand from an operator perspective. As I noted previously, we would have release note in Nova's Hibiscus release stating that scope enforcement is now required, but it would also be required in Gazpacho if oslo.policy was updated there.
I think that is how we have handled the library maintained/controlled things. For example, support of the policy file as JSON format was deprecated/removed from oslo.policy side and service adopted that behaviour via upgrade of oslo.polcy in their deployment. If anyone is upgrading only oslo.policy in Gazpacho or an older version of OpenStack, then they will be reading the release notes and changes done in the newer version of oslo.policy and know what this upgrade means to the deployed services. That is a valid case for any deps.
That's a good point. With the benefit of hindsight, we should have similarly done that enforcement in the consumer first before removing the option from oslo.policy. It's too late to change that now, but that doesn't mean we should repeat our past mistakes.
In summary, I am not sure handling the error at service side or oslo.policy side matters much to upgrade, as release notes should clarify the upgrade impact at both side. But keeping the config option with a hard-coded value seems confusing to me.
If release notes were enough, we wouldn't need checks for the libvirt and QEMU versions in Nova. IMO runtime checks >>> release notes, and a failed service is a more obvious signal that the operator needs to do something than a release note is. As an operator, I would much rather my service fail to start than have to debug why scopes are being enforced despite my nova.conf file seemingly saying otherwise. Hopefully this all makes sense. Stephen
-gmaan
Stephen
- topic:"secure-rbac" - hashtag:"remove-enforce-scope-flag"
-gmaan
[1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf... [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9...
-gmaan
On Thu, Jun 25, 2026 at 9:02 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-24 at 09:44 -0700, Ghanshyam Maan wrote:
On Wed, Jun 24, 2026 at 3:53 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-17 at 21:27 -0700, Ghanshyam Maan wrote:
On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
Hello everyone,
As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag.
What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered.
Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure.
2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3].
How to test your project:
I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475)
oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479
Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...
I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope.
Gentle Reminder about the deadline.
I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs.
You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing of enforce_scope=false and also remove enforce_scopre=true if set explicitly.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...)
Please use the below topic and hashtag for easy tracking:
Per my comments on the nova and placement changes, I think we should change the approach slightly. As things stand, the proposal is to remove the option from oslo.policy, so that if the option is set in the config it will now be ignored. That means users will inherit this behavior change as a side- effect of upgrading oslo.policy as opposed to upgrading their service. I think that's backwards. Instead, I think services should be explicitly checking for `enforce_scope = False` and refusing to start if so. The option should stay in oslo.policy for now (it its deprecated form) so that anyone who pulls an updated oslo.policy on e.g. Gazpacho won't suddenly find themselves with a large behaviour change. This will require an additional if-statement in each project (along with the already proposed test and release note changes) but it does ensure it is the *service* that controls scope enforcement rather than it coming in via a library side-effect.
Does this make sense?
Honestly, I am not sure what we will gain by keeping the config option but not allowing to change its value. That is more confusing to users/operators that there is a config option to toggle the scope enforcement, but it stops working.
This is what we gain:
https://review.opendev.org/c/openstack/placement/+/994892
With the plan we've currently proposed, if an operator has set `[oslo_policy] enforce_scope` to `False` on Gazpacho and then upgrade to Hibiscus, the option will now be ignored and things will silently switch over to scope enforcement. That feels like a "Bad Thing (TM)" to do. By comparison, if we keep the option in oslo.policy a while longer and instead check its value in the service then the operator will immediately know that the feature is no longer supported, just as we're seeing in those CI results.
Regarding the behaviour change coming from service or oslo.policy, that is more of implementation details. If anyone is upgrading the service to the 2026.2 release, they will need to upgrade the required deps also. That reminds me to update the oslo.policy min version in requirements.txt (I will do that once oslo.policy change is merged and released). Mentioning the same in the release notes can clarify it explicitly that from oslo.policy newer version, the enforce_scope will not work. I think that will be the proper way to handle the upgrade impact.
I don't know if it's an implementation detail though. Having a behaviour change come in via a dependency is harder to control and understand from an operator perspective. As I noted previously, we would have release note in Nova's Hibiscus release stating that scope enforcement is now required, but it would also be required in Gazpacho if oslo.policy was updated there.
I think that is how we have handled the library maintained/controlled things. For example, support of the policy file as JSON format was deprecated/removed from oslo.policy side and service adopted that behaviour via upgrade of oslo.polcy in their deployment. If anyone is upgrading only oslo.policy in Gazpacho or an older version of OpenStack, then they will be reading the release notes and changes done in the newer version of oslo.policy and know what this upgrade means to the deployed services. That is a valid case for any deps.
That's a good point. With the benefit of hindsight, we should have similarly done that enforcement in the consumer first before removing the option from oslo.policy. It's too late to change that now, but that doesn't mean we should repeat our past mistakes.
In summary, I am not sure handling the error at service side or oslo.policy side matters much to upgrade, as release notes should clarify the upgrade impact at both side. But keeping the config option with a hard-coded value seems confusing to me.
If release notes were enough, we wouldn't need checks for the libvirt and QEMU versions in Nova. IMO runtime checks >>> release notes, and a failed service is a more obvious signal that the operator needs to do something than a release note is. As an operator, I would much rather my service fail to start than have to debug why scopes are being enforced despite my nova.conf file seemingly saying otherwise.
Hopefully this all makes sense.
Those are quite different cases, let me add some more details about the enforce_scope role here (which I commented in Gerrit/IRC) for others to have those in a single place and get their feedback. OpenStack services (except ironic, keystone) only support the project-scoped RBAC and system tokens are never intended to work for them as they do not have a project_id, and many operations/resources are associated with the project. Even before we introduced the scope in policy rules, system-scoped token fails somewhere (DB or other layer) where project_id is needed. That failure might have a very confusing error message or code, which might be hard for users to understand. With scope enforcement, it was improved to return 403 at a very early stage. One exception is system_admin, which works as admin in old vs new defaults if scope enforcement is disabled, but admin is admin even if it is an admin in a single project, so I am not considering that a hard use case to consider. enforce_scope=False: ------------------------------ If the user uses system_reader to read the resources/system_admin|member, tries to create the server in Nova, then it will fail somewhere in the DB, or so as there is no project_id associated with that token. error will be 404 or some other error. enforce_scope=True: ----------------------------- In this case, the policy checks itself will throw a 403 error saying you are not using a project-scoped token required by the API access control. So, it does not make user success cases into failure, but the error message/code is improved. That is why failing service for that case is not a valid case. We should not fail service start to serve the things because the error code improvement is disabled. NOTE: Ironic is a valid case because it has system-scoped support. I added it to their meeting agenda explicitly in case they have not read this email. -gmaan
Stephen
-gmaan
Stephen
- topic:"secure-rbac" - hashtag:"remove-enforce-scope-flag"
-gmaan
[1]
https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf...
[2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9...
-gmaan
On 6/25/26 11:06 AM, Ghanshyam Maan wrote:
On Thu, Jun 25, 2026 at 9:02 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-24 at 09:44 -0700, Ghanshyam Maan wrote: > On Wed, Jun 24, 2026 at 3:53 AM Stephen Finucane <stephenfin@redhat.com> wrote: > > On Wed, 2026-06-17 at 21:27 -0700, Ghanshyam Maan wrote: > > > On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote: > > > > Hello everyone, > > > > > > > > As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC > > > > and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal > > > > timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle > > > > to remove this flag. > > > > > > > > What does this mean: > > > > ----------------------------- > > > > Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines > > > > the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project > > > > can catch this exception and raise the modified error message similar to PolicyNotRegistered. > > > > > > > > Action item on projects: > > > > ------------------------------- > > > > 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default > > > > (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change > > > > to remove it and would like to request that the project maintainer look into the changes/failure. > > > > > > > > 2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For > > > > example nova unit tests[3]. > > > > > > > > How to test your project: > > > > > > > > I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in > > > > your project jobs in 'required_project' field and depends-on the oslo.policy change (986475) > > > > > > > > oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 > > > > nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479 > > > > > > > > Tracking and deadline: > > > > ------------------------------ > > > > Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies. > > > > > > > > - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status... > > > > > > > > > > > > > > > > > > > > I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing > > > > enforce_scope. > > > > > > > > > > > > > Gentle Reminder about the deadline. > > > > > > I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the > > > project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs. > > > > > > You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing > > > of enforce_scope=false and also remove enforce_scopre=true if set explicitly. > > > > > > - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...) > > > > > > Please use the below topic and hashtag for easy tracking: > > > > Per my comments on the nova and placement changes, I think we should change the approach slightly. > > As things stand, the proposal is to remove the option from oslo.policy, so that if the option is set > > in the config it will now be ignored. That means users will inherit this behavior change as a side- > > effect of upgrading oslo.policy as opposed to upgrading their service. I think that's backwards. > > Instead, I think services should be explicitly checking for `enforce_scope = False` and refusing to > > start if so. The option should stay in oslo.policy for now (it its deprecated form) so that anyone > > who pulls an updated oslo.policy on e.g. Gazpacho won't suddenly find themselves with a large > > behaviour change. This will require an additional if-statement in each project (along with the > > already proposed test and release note changes) but it does ensure it is the *service* that controls > > scope enforcement rather than it coming in via a library side-effect. > > > > Does this make sense? > > > > > Honestly, I am not sure what we will gain by keeping the config option but not allowing to change its value. > That is more confusing to users/operators that there is a config option to toggle the scope enforcement, but > it stops working.
This is what we gain:
https://review.opendev.org/c/openstack/placement/+/994892
With the plan we've currently proposed, if an operator has set `[oslo_policy] enforce_scope` to `False` on Gazpacho and then upgrade to Hibiscus, the option will now be ignored and things will silently switch over to scope enforcement. That feels like a "Bad Thing (TM)" to do. By comparison, if we keep the option in oslo.policy a while longer and instead check its value in the service then the operator will immediately know that the feature is no longer supported, just as we're seeing in those CI results.
> Regarding the behaviour change coming from service or oslo.policy, that is more of implementation details. If > anyone is upgrading the service to the 2026.2 release, they will need to upgrade the required deps also. That reminds > me to update the oslo.policy min version in requirements.txt (I will do that once oslo.policy change is merged > and released). Mentioning the same in the release notes can clarify it explicitly that from oslo.policy newer version, the > enforce_scope will not work. I think that will be the proper way to handle the upgrade impact.
I don't know if it's an implementation detail though. Having a behaviour change come in via a dependency is harder to control and understand from an operator perspective. As I noted previously, we would have release note in Nova's Hibiscus release stating that scope enforcement is now required, but it would also be required in Gazpacho if oslo.policy was updated there.
> I think that is how we have handled the library maintained/controlled things. For example, support of the policy file as JSON > format was deprecated/removed from oslo.policy side and service adopted that behaviour via upgrade of oslo.polcy in > their deployment. If anyone is upgrading only oslo.policy in Gazpacho or an older version of OpenStack, then they will be > reading the release notes and changes done in the newer version of oslo.policy and know what this upgrade means to > the deployed services. That is a valid case for any deps.
That's a good point. With the benefit of hindsight, we should have similarly done that enforcement in the consumer first before removing the option from oslo.policy. It's too late to change that now, but that doesn't mean we should repeat our past mistakes.
> In summary, I am not sure handling the error at service side or oslo.policy side matters much to upgrade, as release notes > should clarify the upgrade impact at both side. But keeping the config option with a hard-coded value seems confusing to me.
If release notes were enough, we wouldn't need checks for the libvirt and QEMU versions in Nova. IMO runtime checks >>> release notes, and a failed service is a more obvious signal that the operator needs to do something than a release note is. As an operator, I would much rather my service fail to start than have to debug why scopes are being enforced despite my nova.conf file seemingly saying otherwise.
Hopefully this all makes sense.
Those are quite different cases, let me add some more details about the enforce_scope role here (which I commented in Gerrit/IRC) for others to have those in a single place and get their feedback.
OpenStack services (except ironic, keystone) only support the project-scoped RBAC and system tokens are never intended to work for them as they do not have a project_id, and many operations/resources are associated with the project. Even before we introduced the scope in policy rules, system-scoped token fails somewhere (DB or other layer) where project_id is needed. That failure might have a very confusing error message or code, which might be hard for users to understand. With scope enforcement, it was improved to return 403 at a very early stage. One exception is system_admin, which works as admin in old vs new defaults if scope enforcement is disabled, but admin is admin even if it is an admin in a single project, so I am not considering that a hard use case to consider.
enforce_scope=False: ------------------------------ If the user uses system_reader to read the resources/system_admin|member, tries to create the server in Nova, then it will fail somewhere in the DB, or so as there is no project_id associated with that token. error will be 404 or some other error.
enforce_scope=True: ----------------------------- In this case, the policy checks itself will throw a 403 error saying you are not using a project-scoped token required by the API access control.
So, it does not make user success cases into failure, but the error message/code is improved. That is why failing service for that case is not a valid case. We should not fail service start to serve the things because the error code improvement is disabled.
NOTE: Ironic is a valid case because it has system-scoped support. I added it to their meeting agenda explicitly in case they have not read this email.
I've been following along. I like Stephen's approach. When Ironic flipped this default we had a *lot* of confused operators. That being said, I don't see it as a giant deal in either event -- folks got their first warning when Ironic flipped the default. Someone who just flipped it back and completely ignored all migration instructions had to know this day would come :). -JayF
On Thu, Jun 25, 2026 at 11:46 AM Jay Faulkner <jay@gr-oss.io> wrote:
On 6/25/26 11:06 AM, Ghanshyam Maan wrote:
On Thu, Jun 25, 2026 at 9:02 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-24 at 09:44 -0700, Ghanshyam Maan wrote:
On Wed, Jun 24, 2026 at 3:53 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-17 at 21:27 -0700, Ghanshyam Maan wrote:
On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan < gmaan.os14@gmail.com> wrote:
Hello everyone,
As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag.
What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered.
Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure.
2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3].
How to test your project:
I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475)
oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479
Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...
I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope.
Gentle Reminder about the deadline.
I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs.
You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing of enforce_scope=false and also remove enforce_scopre=true if set explicitly.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...)
Please use the below topic and hashtag for easy tracking:
Per my comments on the nova and placement changes, I think we should change the approach slightly. As things stand, the proposal is to remove the option from oslo.policy, so that if the option is set in the config it will now be ignored. That means users will inherit this behavior change as a side- effect of upgrading oslo.policy as opposed to upgrading their service. I think that's backwards. Instead, I think services should be explicitly checking for `enforce_scope = False` and refusing to start if so. The option should stay in oslo.policy for now (it its deprecated form) so that anyone who pulls an updated oslo.policy on e.g. Gazpacho won't suddenly find themselves with a large behaviour change. This will require an additional if-statement in each project (along with the already proposed test and release note changes) but it does ensure it is the *service* that controls scope enforcement rather than it coming in via a library side-effect.
Does this make sense?
Honestly, I am not sure what we will gain by keeping the config option but not allowing to change its value. That is more confusing to users/operators that there is a config option to toggle the scope enforcement, but it stops working.
This is what we gain:
https://review.opendev.org/c/openstack/placement/+/994892
With the plan we've currently proposed, if an operator has set `[oslo_policy] enforce_scope` to `False` on Gazpacho and then upgrade to Hibiscus, the option will now be ignored and things will silently switch over to scope enforcement. That feels like a "Bad Thing (TM)" to do. By comparison, if we keep the option in oslo.policy a while longer and instead check its value in the service then the operator will immediately know that the feature is no longer supported, just as we're seeing in those CI results.
Regarding the behaviour change coming from service or oslo.policy, that is more of implementation details. If anyone is upgrading the service to the 2026.2 release, they will need to upgrade the required deps also. That reminds me to update the oslo.policy min version in requirements.txt (I will do that once oslo.policy change is merged and released). Mentioning the same in the release notes can clarify it explicitly that from oslo.policy newer version, the enforce_scope will not work. I think that will be the proper way to handle the upgrade impact.
I don't know if it's an implementation detail though. Having a behaviour change come in via a dependency is harder to control and understand from an operator perspective. As I noted previously, we would have release note in Nova's Hibiscus release stating that scope enforcement is now required, but it would also be required in Gazpacho if oslo.policy was updated there.
I think that is how we have handled the library maintained/controlled things. For example, support of the policy file as JSON format was deprecated/removed from oslo.policy side and service adopted that behaviour via upgrade of oslo.polcy in their deployment. If anyone is upgrading only oslo.policy in Gazpacho or an older version of OpenStack, then they will be reading the release notes and changes done in the newer version of oslo.policy and know what this upgrade means to the deployed services. That is a valid case for any deps.
That's a good point. With the benefit of hindsight, we should have similarly done that enforcement in the consumer first before removing the option from oslo.policy. It's too late to change that now, but that doesn't mean we should repeat our past mistakes.
In summary, I am not sure handling the error at service side or oslo.policy side matters much to upgrade, as release notes should clarify the upgrade impact at both side. But keeping the config option with a hard-coded value seems confusing to me.
If release notes were enough, we wouldn't need checks for the libvirt and QEMU versions in Nova. IMO runtime checks >>> release notes, and a failed service is a more obvious signal that the operator needs to do something than a release note is. As an operator, I would much rather my service fail to start than have to debug why scopes are being enforced despite my nova.conf file seemingly saying otherwise.
Hopefully this all makes sense.
Those are quite different cases, let me add some more details about the enforce_scope role here (which I commented in Gerrit/IRC) for others to have those in a single place and get their feedback.
OpenStack services (except ironic, keystone) only support the project-scoped RBAC and system tokens are never intended to work for them as they do not have a project_id, and many operations/resources are associated with the project. Even before we introduced the scope in policy rules, system-scoped token fails somewhere (DB or other layer) where project_id is needed. That failure might have a very confusing error message or code, which might be hard for users to understand. With scope enforcement, it was improved to return 403 at a very early stage. One exception is system_admin, which works as admin in old vs new defaults if scope enforcement is disabled, but admin is admin even if it is an admin in a single project, so I am not considering that a hard use case to consider.
enforce_scope=False: ------------------------------ If the user uses system_reader to read the resources/system_admin|member, tries to create the server in Nova, then it will fail somewhere in the DB, or so as there is no project_id associated with that token. error will be 404 or some other error.
enforce_scope=True: ----------------------------- In this case, the policy checks itself will throw a 403 error saying you are not using a project-scoped token required by the API access control.
So, it does not make user success cases into failure, but the error message/code is improved. That is why failing service for that case is not a valid case. We should not fail service start to serve the things because the error code improvement is disabled.
NOTE: Ironic is a valid case because it has system-scoped support. I added it to their meeting agenda explicitly in case they have not read this email.
I've been following along. I like Stephen's approach. When Ironic flipped this default we had a *lot* of confused operators. That being said, I don't see it as a giant deal in either event -- folks got their first warning when Ironic flipped the default. Someone who just flipped it back and completely ignored all migration instructions had to know this day would come :).
Yes, for ironic this can be a valid case. One of the better, long-term solutions for Ironic is to have the config option on the ironic side, with defaults/removal whenever operators are ready. I added the same in the meeting agenda notes. But for any other OpenStack services, it is not justifiable to me not to allow service start because of a config option which improves the error code is disabled. -gmaan
-JayF
On Thu, 2026-06-25 at 11:06 -0700, Ghanshyam Maan wrote:
On Thu, Jun 25, 2026 at 9:02 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-24 at 09:44 -0700, Ghanshyam Maan wrote:
On Wed, Jun 24, 2026 at 3:53 AM Stephen Finucane <stephenfin@redhat.com> wrote:
On Wed, 2026-06-17 at 21:27 -0700, Ghanshyam Maan wrote:
On Wed, Apr 29, 2026 at 1:04 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
Hello everyone,
As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag.
What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered.
Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure.
2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3].
How to test your project:
I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475)
oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479
Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...
I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope.
Gentle Reminder about the deadline.
I started the changes from devstack and some of the devstack plugins, which will take care of integration testing, but the project unit/functional tests need to be fixed/adjusted before the deadline, as it will break the unit/functional testing jobs.
You can see the Nova, placement, and keystone example of fixing unit tests. Basically, you need to remove the testing of enforce_scope=false and also remove enforce_scopre=true if set explicitly.
- https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...)
Please use the below topic and hashtag for easy tracking:
Per my comments on the nova and placement changes, I think we should change the approach slightly. As things stand, the proposal is to remove the option from oslo.policy, so that if the option is set in the config it will now be ignored. That means users will inherit this behavior change as a side- effect of upgrading oslo.policy as opposed to upgrading their service. I think that's backwards. Instead, I think services should be explicitly checking for `enforce_scope = False` and refusing to start if so. The option should stay in oslo.policy for now (it its deprecated form) so that anyone who pulls an updated oslo.policy on e.g. Gazpacho won't suddenly find themselves with a large behaviour change. This will require an additional if-statement in each project (along with the already proposed test and release note changes) but it does ensure it is the *service* that controls scope enforcement rather than it coming in via a library side-effect.
Does this make sense?
Honestly, I am not sure what we will gain by keeping the config option but not allowing to change its value. That is more confusing to users/operators that there is a config option to toggle the scope enforcement, but it stops working.
This is what we gain:
https://review.opendev.org/c/openstack/placement/+/994892
With the plan we've currently proposed, if an operator has set `[oslo_policy] enforce_scope` to `False` on Gazpacho and then upgrade to Hibiscus, the option will now be ignored and things will silently switch over to scope enforcement. That feels like a "Bad Thing (TM)" to do. By comparison, if we keep the option in oslo.policy a while longer and instead check its value in the service then the operator will immediately know that the feature is no longer supported, just as we're seeing in those CI results.
Regarding the behaviour change coming from service or oslo.policy, that is more of implementation details. If anyone is upgrading the service to the 2026.2 release, they will need to upgrade the required deps also. That reminds me to update the oslo.policy min version in requirements.txt (I will do that once oslo.policy change is merged and released). Mentioning the same in the release notes can clarify it explicitly that from oslo.policy newer version, the enforce_scope will not work. I think that will be the proper way to handle the upgrade impact.
I don't know if it's an implementation detail though. Having a behaviour change come in via a dependency is harder to control and understand from an operator perspective. As I noted previously, we would have release note in Nova's Hibiscus release stating that scope enforcement is now required, but it would also be required in Gazpacho if oslo.policy was updated there.
I think that is how we have handled the library maintained/controlled things. For example, support of the policy file as JSON format was deprecated/removed from oslo.policy side and service adopted that behaviour via upgrade of oslo.polcy in their deployment. If anyone is upgrading only oslo.policy in Gazpacho or an older version of OpenStack, then they will be reading the release notes and changes done in the newer version of oslo.policy and know what this upgrade means to the deployed services. That is a valid case for any deps.
That's a good point. With the benefit of hindsight, we should have similarly done that enforcement in the consumer first before removing the option from oslo.policy. It's too late to change that now, but that doesn't mean we should repeat our past mistakes.
In summary, I am not sure handling the error at service side or oslo.policy side matters much to upgrade, as release notes should clarify the upgrade impact at both side. But keeping the config option with a hard-coded value seems confusing to me.
If release notes were enough, we wouldn't need checks for the libvirt and QEMU versions in Nova. IMO runtime checks >>> release notes, and a failed service is a more obvious signal that the operator needs to do something than a release note is. As an operator, I would much rather my service fail to start than have to debug why scopes are being enforced despite my nova.conf file seemingly saying otherwise.
Hopefully this all makes sense.
Those are quite different cases, let me add some more details about the enforce_scope role here (which I commented in Gerrit/IRC) for others to have those in a single place and get their feedback.
OpenStack services (except ironic, keystone) only support the project-scoped RBAC and system tokens are never intended to work for them as they do not have a project_id, and many operations/resources are associated with the project. Even before we introduced the scope in policy rules, system-scoped token fails somewhere (DB or other layer) where project_id is needed. That failure might have a very confusing error message or code, which might be hard for users to understand. With scope enforcement, it was improved to return 403 at a very early stage. One exception is system_admin, which works as admin in old vs new defaults if scope enforcement is disabled, but admin is admin even if it is an admin in a single project, so I am not considering that a hard use case to consider.
enforce_scope=False: ------------------------------ If the user uses system_reader to read the resources/system_admin|member, tries to create the server in Nova, then it will fail somewhere in the DB, or so as there is no project_id associated with that token. error will be 404 or some other error.
enforce_scope=True: ----------------------------- In this case, the policy checks itself will throw a 403 error saying you are not using a project-scoped token required by the API access control.
So, it does not make user success cases into failure, but the error message/code is improved. That is why failing service for that case is not a valid case. We should not fail service start to serve the things because the error code improvement is disabled.
I discussed this with Sean Mooney over the weekend and they made the good point that users won't be able to get into a situation where they use the new version of oslo.policy on an older release since in doing so they will start seeing an exception whenever the service attempts to access the newly deleted option. Given this, combined with the understandable desire to delete this option now rather than wait another year, I drop my objections. I'm happy to follow through with the pattern of splitting the test change patch (where needed) from the dep bump + release note patch in each service that gmaan has now done, and I've already reviewed and helped merge the first of these patches for both Nova and Placement. Cheers, Stephen
NOTE: Ironic is a valid case because it has system-scoped support. I added it to their meeting agenda explicitly in case they have not read this email.
-gmaan
Stephen
-gmaan
Stephen
- topic:"secure-rbac" - hashtag:"remove-enforce-scope-flag"
-gmaan
[1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf... [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9...
-gmaan
So, it does not make user success cases into failure, but the error message/code is improved. That is why failing service for that case is not a valid case. We should not fail service start to serve the things because the error code improvement is disabled.
I discussed this with Sean Mooney over the weekend and they made the good point that users won't be able to get into a situation where they use the new version of oslo.policy on an older release since in doing so they will start seeing an exception whenever the service attempts to access the newly deleted option. Given this, combined with the understandable desire to delete this option now rather than wait another year, I drop my objections. I'm happy to follow through with the pattern of splitting the test change patch (where needed) from the dep bump + release note patch in each service that gmaan has now done, and I've already reviewed and helped merge the first of these patches for both Nova and Placement.
Cool. I have proposed the required changes along with testing one in a few of the projects (need reviews), hope other projects will do the same before the deadline (3rd July). * Nova/Placement: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...) * Cinder: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...) * Glance: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...) * Keystone: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...) * Neutron: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...) -gmaan
Cheers, Stephen
NOTE: Ironic is a valid case because it has system-scoped support. I
added it to their meeting agenda explicitly in case they
have not read this email.
-gmaan
Stephen
-gmaan
Stephen
- topic:"secure-rbac" - hashtag:"remove-enforce-scope-flag"
-gmaan
> > [1]
https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf...
> [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... > [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9... > > -gmaan
On Mon, Jun 29, 2026 at 7:45 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
So, it does not make user success cases into failure, but the error message/code is improved. That is why failing service
for that case is not a valid case. We should not fail service start to serve the things because the error code improvement is disabled.
I discussed this with Sean Mooney over the weekend and they made the good point that users won't be able to get into a situation where they use the new version of oslo.policy on an older release since in doing so they will start seeing an exception whenever the service attempts to access the newly deleted option. Given this, combined with the understandable desire to delete this option now rather than wait another year, I drop my objections. I'm happy to follow through with the pattern of splitting the test change patch (where needed) from the dep bump + release note patch in each service that gmaan has now done, and I've already reviewed and helped merge the first of these patches for both Nova and Placement.
Cool. I have proposed the required changes along with testing one in a few of the projects (need reviews), hope other projects will do the same before the deadline (3rd July).
* Nova/Placement: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Cinder: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Glance: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Keystone: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Neutron: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
-gmaan
One more related update: Devstack is enabling the new defaults for services (which devstack has in-tree settings, not the plugin). If any job is impacted, I would recommend that it's time to fix the issue instead of disabling it on the job side. The same is highly recommended for the other services, which have settings in their own devstack plugin. - https://review.opendev.org/c/openstack/devstack/+/956210 - https://review.opendev.org/c/openstack/devstack/+/994937 -gmaan
Cheers, Stephen
NOTE: Ironic is a valid case because it has system-scoped support. I
added it to their meeting agenda explicitly in case they
have not read this email.
-gmaan
Stephen
-gmaan
Stephen
> > - topic:"secure-rbac" > - hashtag:"remove-enforce-scope-flag" > > -gmaan > > > > > [1]
https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf...
> > [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... > > [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9... > > > > -gmaan
On Thu, Jul 2, 2026 at 10:09 AM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
On Mon, Jun 29, 2026 at 7:45 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
So, it does not make user success cases into failure, but the error message/code is improved. That is why failing service
for that case is not a valid case. We should not fail service start to serve the things because the error code improvement is disabled.
I discussed this with Sean Mooney over the weekend and they made the good point that users won't be able to get into a situation where they use the new version of oslo.policy on an older release since in doing so they will start seeing an exception whenever the service attempts to access the newly deleted option. Given this, combined with the understandable desire to delete this option now rather than wait another year, I drop my objections. I'm happy to follow through with the pattern of splitting the test change patch (where needed) from the dep bump + release note patch in each service that gmaan has now done, and I've already reviewed and helped merge the first of these patches for both Nova and Placement.
Cool. I have proposed the required changes along with testing one in a few of the projects (need reviews), hope other projects will do the same before the deadline (3rd July).
* Nova/Placement: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Cinder: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Glance: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Keystone: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
* Neutron: https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+AND+has...)
oslo.policy change is merged, new version 6.0.0 is released. upper constraints bump will be happening soon, which will break project gate if not fixed yet. - https://review.opendev.org/c/openstack/requirements/+/996511 -gmaan
-gmaan
One more related update: Devstack is enabling the new defaults for services (which devstack has in-tree settings, not the plugin). If any job is impacted, I would recommend that it's time to fix the issue instead of disabling it on the job side. The same is highly recommended for the other services, which have settings in their own devstack plugin.
- https://review.opendev.org/c/openstack/devstack/+/956210 - https://review.opendev.org/c/openstack/devstack/+/994937
-gmaan
Cheers, Stephen
NOTE: Ironic is a valid case because it has system-scoped support. I
added it to their meeting agenda explicitly in case they
have not read this email.
-gmaan
Stephen
-gmaan
> > Stephen > > > > > - topic:"secure-rbac" > > - hashtag:"remove-enforce-scope-flag" > > > > -gmaan > > > > > > > > [1]
https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf...
> > > [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... > > > [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9... > > > > > > -gmaan >
On Wed, Jul 8, 2026 at 11:25 AM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
On Thu, Jul 2, 2026 at 10:09 AM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
On Mon, Jun 29, 2026 at 7:45 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote
oslo.policy change is merged, new version 6.0.0 is released. upper constraints bump will be happening soon, which will break project gate if not fixed yet.
- https://review.opendev.org/c/openstack/requirements/+/996511
Requirement change showed the failing project in cross-project jobs, I have proposed the fixes for the failing project, and it is now green (with depends on the fixes). Please merge those to land the requirement change. NOTE: not all projects are tested in the requirement gate, so there might be more projects failing for the same error. Ironic: https://review.opendev.org/c/openstack/ironic/+/996559 Cinder: https://review.opendev.org/c/openstack/cinder/+/995405 Keystone: https://review.opendev.org/c/openstack/keystone/+/993852 Manila: https://review.opendev.org/c/openstack/manila/+/996539 Magnum: https://review.opendev.org/c/openstack/magnum/+/996540 Octavia: https://review.opendev.org/c/openstack/octavia/+/996546 Heat: https://review.opendev.org/c/openstack/heat/+/996550 -gmaan
-gmaan
-gmaan
One more related update: Devstack is enabling the new defaults for services (which devstack has in-tree settings, not the plugin). If any job is impacted, I would recommend that it's time to fix the issue instead of disabling it on the job side. The same is highly recommended for the other services, which have settings in their own devstack plugin.
- https://review.opendev.org/c/openstack/devstack/+/956210 - https://review.opendev.org/c/openstack/devstack/+/994937
-gmaan
Cheers, Stephen
NOTE: Ironic is a valid case because it has system-scoped support. I
added it to their meeting agenda explicitly in case they
have not read this email.
-gmaan
Stephen
> > -gmaan > > > > > Stephen > > > > > > > > - topic:"secure-rbac" > > > - hashtag:"remove-enforce-scope-flag" > > > > > > -gmaan > > > > > > > > > > > [1]
https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf...
> > > > [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... > > > > [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9... > > > > > > > > -gmaan > >
On Wed, Jul 8, 2026 at 6:58 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
On Wed, Jul 8, 2026 at 11:25 AM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
On Thu, Jul 2, 2026 at 10:09 AM Ghanshyam Maan <gmaan.os14@gmail.com> wrote:
On Mon, Jun 29, 2026 at 7:45 PM Ghanshyam Maan <gmaan.os14@gmail.com> wrote
oslo.policy change is merged, new version 6.0.0 is released. upper constraints bump will be happening soon, which will break project gate if not fixed yet.
- https://review.opendev.org/c/openstack/requirements/+/996511
Requirement change showed the failing project in cross-project jobs, I have proposed the fixes for the failing project, and it is now green (with depends on the fixes). Please merge those to land the requirement change.
Updates Requirements change is merged now, which means Oslo.policy new version 6.0.0 is tested in CI, which will fail the jobs that reference the enforce_scope config option (even doc job if it is referenced in doc). Fixes are known, and can be referenced from the series. Projects can now merge (if the change is up) or propose a change, which can bump the oslo.policy requirement in requirements.txt with the release notes declaring the enforce_scope if gone. Example: - https://review.opendev.org/c/openstack/nova/+/994950 - https://review.opendev.org/c/openstack/neutron/+/995414 https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(status...) -gmaan
-gmaan
-gmaan
-gmaan
One more related update: Devstack is enabling the new defaults for services (which devstack has in-tree settings, not the plugin). If any job is impacted, I would recommend that it's time to fix the issue instead of disabling it on the job side. The same is highly recommended for the other services, which have settings in their own devstack plugin.
- https://review.opendev.org/c/openstack/devstack/+/956210 - https://review.opendev.org/c/openstack/devstack/+/994937
-gmaan
Cheers, Stephen
NOTE: Ironic is a valid case because it has system-scoped support. I
added it to their meeting agenda explicitly in case they
have not read this email.
-gmaan
> > Stephen > > > > > -gmaan > > > > > > > > Stephen > > > > > > > > > > > - topic:"secure-rbac" > > > > - hashtag:"remove-enforce-scope-flag" > > > > > > > > -gmaan > > > > > > > > > > > > > > [1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.enf... > > > > > [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... > > > > > [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a9... > > > > > > > > > > -gmaan > > > >
participants (3)
-
Ghanshyam Maan
-
Jay Faulkner
-
Stephen Finucane