As promised during the session, I prepared the heat job with enforce_scope=True set in all services. https://review.opendev.org/c/openstack/heat/+/915398
This test attempt revealed two problems with current keystone policy rules about domain admin https://bugs.launchpad.net/keystone/+bug/2059780 https://bugs.launchpad.net/keystone/+bug/2062045
and proposed the fixes for both https://review.opendev.org/c/openstack/keystone/+/914759 https://review.opendev.org/c/openstack/keystone/+/916130
(These two are proven to fix heat problems in 915398)
I guess I have to do some tricks to make these patches merge-able because of protection job which still depends on "old" scope definitions, it'd be nice if I can hear early feedback before I dig into it further.
Especially I'm unsure if 916130 is the appropriate fix because the change may allow domain scope admin to view all credentials which violates domain scope limitation. If anyone can suggest a better solution (probably update in check_str ?), that is really nice.
On 4/18/24 03:44, Ghanshyam Mann wrote:
Hello Everyone,
I am summarizing the RBAC discussion that happened on Wednesday. Complete notes can be found @ https://etherpad.opendev.org/p/rbac-2024.2-ptg
Goal document: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... Tracking: https://etherpad.opendev.org/p/rbac-goal-tracking
Total Attendees: 10-15
Current progress:
There are a few projects that progress in various phases, one of them is Tacker completed the phase-1. Current progress can be found @ https://etherpad.opendev.org/p/rbac-goal-tracking
Phase-2 (service role):
This has two parts, 1. Change APIs policy default which is meant for service-to-service usage only to allow for service roles. 2. Use service tokens to interact with other services. In 2nd case, we need to use both the user token and as well as service token. Service token will be used for authentication purposes only and user token to do all other operations.
Slaweq updated that Neutron changed the policy but needs to change the token to be used by interaction with other service.
Action item:
- gmann to add the job to make service user token (have service role only) to validate/capture any failure while we
do service token/policy changes.
Enable 'enforce_scope' by default & drop this config option:
We discussed the plan to drop the enforce_scope config option. Scope enforcement needs to be enabled by default and should not be configurable.
I have proposed the plan in the below review, please review and level your feedback.
Before doing that we have one dependency[1] and Takashi needs to test the heat jobs to make sure enabling the enforce_scope by default does not break anything.
AGREE:
- Takashi to add a heat job to find if enforce_scope=True works perfectly and after that only we can enable the flag in oslo policy.
- Based on the above testing results, change the default value to True to be done in oslo policy and release oslo policy so that CI adopts the new default value.
Domain Manager Persona
Details are in the keystone spec[2], there are no objections to this use case. Request to review the spec and provide your feedback.
Global reader
We discussed it at the Vancouver Summit also. There is no objection to adding it but we need spec to be up with details including the new role name. This new global reader can be added like 'admin OR global-reader OR project-reader'
AGREE:
- 'admin OR global-reader OR project-reader' approach sounds good, especially not to split the admin role and avoid breaking existing use cases.
- johnthetubaguy will propose the keystone spec with the details.
- gmann to help in implementation.
I host the RBAC biweekly meeting[3], feel free to add any topic to the meeting etherpad ('Biweekly meeting' section)
[1] https://bugs.launchpad.net/keystone/+bug/2059780 [2] https://review.opendev.org/c/openstack/keystone-specs/+/903172 [3] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup...
-gmann