Incorrectly implemented service tokens in kolla-ansible
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. Thanks! Franciszek Przewoźny
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
Hey, thanks for the answer. So still there is the third thing - with manual configuration of a cluster that isn't managed by Kolla-ansible - configuration of f.e. Neutron, where its only role is "service", results in unhealthy cluster. There are policies in f.e. Nova that won't allow Neutron required calls, f.e.: Neutron: ERROR neutron.notifiers.nova novaclient.exceptions.Forbidden: Policy doesn't allow os_compute_api:os-server-eternalevents:create to be performed. (HTTP 403) Policy restricting that call is: "os_compute_api:os-server-external-events:create": "rule:context_is_admin" And rule:context_is_admin definition is: "context_is_admin": "role:admin" Assuming it's not some issue on my side, it's currently impossible to get this working without changing policies locally. Franciszek
On 30 Jan 2024, at 16:41, smooney@redhat.com wrote:
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
participants (2)
-
Franciszek Przewoźny
-
smooney@redhat.com