On Tue, 2024-01-30 at 10:09 +0100, Franciszek Przewoźny wrote:
Hi all,
Can someone from kolla-ansible development have a look into that: https://bugs.launchpad.net/kolla-ansible/+bug/2049762 ? As for now, the provided configuration is totally different to what's described in manual. OSSA-2023-003 is not reintocuded by the way kolla configures service tokens for end users but its mitigation is weakend as it may allow admins to detach a volume that is connected to a nova instnace.
so its not generally vernerable but kolla shoudl be adding the service role to the service accoutns and it shoudl not be overrideing the role that cinder is checking to admin. https://review.opendev.org/c/openstack/cinder/+/882836/2/cinder/volume/api.p... i replied on the bug but the service role is intentionaly used in this mitigation because an admin user shoudl not have it. it is used to ensure that admins cant acidentally recreate the cve mechanisume by using there own token to detach the voulmes via the cinder api. there was a todo comment in patchset 4 https://review.opendev.org/c/openstack/kolla-ansible/+/882893/4/ansible/role... questioning if using admin was the correct approch. i had stop working on the patch at that point but i belive it was incorrect and the correct approch was to add the service role to the openstack service accounts to resovle the upgade impact. only an openstack service i.e. nova/neutron should have a user with a service role so that is the part of the mitigation that was weekend by changing the role to admin. as you said in your report the current approch in kolla will prevent removing admin form the service users like nova until this is adressed.
Thanks! Franciszek Przewoźny