It seems, that configuration done by kolla-ansible regarding service tokens seems to be not compliant with the documentation. If I'm right, this might mean that OSSA-2023-003 isn't fully fixed there.
2. Service role
From documentation "The default service role is service, but we can use a different name or even have multiple service roles", where in kolla-ansible, Nova service jinja does not have parameter to be set for service_token_roles, and it uses default "service", Cinder on the other hand have HARDCODED "admin" value (https://github.com/openstack/kolla-ansible/blob/stable/2023.2/ansible/roles/cinder/templates/cinder.conf.j2#L119), and that's where I'm a bit lost. I thought that service users "nova" and "cinder" should have only f.e. "service" role in "service" project, not some multiple roles including "admin" one.
3. Policies not prepared for "service" role only
Configuration of other role "service" for services (tested with Neutron and Placement), cannot be done as there are policies restricting some API calls, f.e.:
Neutron:
ERROR neutron.notifiers.nova novaclient.exceptions.Forbidden: Policy doesn't allow os_compute_api:os-server-external-events: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"
Which totally blocks any effort put into getting rid of "admin" service role for other services.
My environment isn't kolla-ansible, but I'm using kolla's jinja templates as a configuration reference sometimes. I'm raising this ticket, as it's a bit suspicious for me that something else is configured in kolla, than is described in manual.
Hi all,
It seems, that configuration done by kolla-ansible regarding service tokens seems to be not compliant with the documentation. If I'm right, this might mean that OSSA-2023-003 isn't fully fixed there.
https:/ /docs.openstack .org/cinder/ 2023.2/ configuration/ block-storage/ service- token.html# configuration
1. Send service token /github. com/openstack/ kolla-ansible/ blob/stable/ 2023.2/ ansible/ roles/cinder/ templates/ cinder. conf.j2, Nova got it defined: https:/ /github. com/openstack/ kolla-ansible/ blob/stable/ 2023.2/ ansible/ roles/nova/ templates/ nova.conf. j2#L211
Section [service_user] is not defined at all for Cinder: https:/
2. Service role token_roles, and it uses default "service", Cinder on the other hand have HARDCODED "admin" value (https:/ /github. com/openstack/ kolla-ansible/ blob/stable/ 2023.2/ ansible/ roles/cinder/ templates/ cinder. conf.j2# L119), and that's where I'm a bit lost. I thought that service users "nova" and "cinder" should have only f.e. "service" role in "service" project, not some multiple roles including "admin" one.
From documentation "The default service role is service, but we can use a different name or even have multiple service roles", where in kolla-ansible, Nova service jinja does not have parameter to be set for service_
3. Policies not prepared for "service" role only
Configuration of other role "service" for services (tested with Neutron and Placement), cannot be done as there are policies restricting some API calls, f.e.:
Neutron: notifiers. nova novaclient. exceptions. Forbidden: Policy doesn't allow os_compute_ api:os- server- external- events: create to be performed. (HTTP 403)
ERROR neutron.
Policy restricting that call is: api:os- server- external- events: create" : "rule:context_ is_admin"
"os_compute_
And rule:context_ is_admin definition is: is_admin" : "role:admin"
"context_
Which totally blocks any effort put into getting rid of "admin" service role for other services.
My environment isn't kolla-ansible, but I'm using kolla's jinja templates as a configuration reference sometimes. I'm raising this ticket, as it's a bit suspicious for me that something else is configured in kolla, than is described in manual.
Best regards,
Franciszek