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.py#910

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/roles/cinder/templates/cinder.conf.j2#110
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