[policy][ptg] RBAC 2024.1 Dalmatian cycle vPTG discussions summary
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.
- https://review.opendev.org/c/openstack/governance/+/915179
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) - https://etherpad.opendev.org/p/rbac-goal-tracking#L169
[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
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
---- On Wed, 17 Apr 2024 19:44:36 -0700 Takashi Kajinami wrote ---
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.
Thanks for testing and reporting bugs. I have commented details in review also.
In 914759, as you are opening the permission for domain admin also, keystone_tempest_plugin test needs to be modified to allow the domain admin user to get the role of the domain[1]. Easy can be to remove all three tests from the DomainAdminTests class and tests definition from its base class SystemAdminTests can be executed as it is for DomainAdminTests class also.
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.
For 916130, I think this was the same case earlier also where the admin in any domain can see the creds of all users[2]. I think it is the same case for project admin also. I mean project admin sees all creds of other domains also? At least seeing the test, it seems yes. In the logs[3] we can see project admin able to get all the creds of all users
I am not 100% sure why domain scope was not added in the new RBAC in first place. We have not solved the domain admin isolation issue yet which requires a global admin in all domains vs an admin within a domain. We have discussed it many times in past but there is no solution for domain admin isolation yet and we are keeping the same behavior in the new RBAC also. IMO, we should add the existing domain admin there and if we fix the domain admin isolation case then we can modify this.
[1] https://github.com/openstack/keystone-tempest-plugin/blob/c0ae2d9930bad1f9e0... [2] https://github.com/openstack/keystone/blob/7a6e1a0bdc79927e5d7fd6ad7e6dda2e0... [3] https://zuul.opendev.org/t/openstack/build/9beac21cbc17449aa272bfcb794a1824/...
-gmann
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
participants (2)
-
Ghanshyam Mann
-
Takashi Kajinami