Service tokens seems to be incorrectly implemented in kolla-ansible
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Security Advisory |
New
|
Undecided
|
Unassigned | ||
OpenStack Security Notes |
New
|
Undecided
|
Unassigned | ||
kolla-ansible |
Fix Released
|
Undecided
|
Unassigned | ||
Antelope |
Fix Released
|
Undecided
|
Unassigned | ||
Bobcat |
Fix Released
|
Undecided
|
Unassigned | ||
Caracal |
Fix Released
|
Undecided
|
Unassigned | ||
Yoga |
Fix Committed
|
Undecided
|
Unassigned | ||
Zed |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
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.
1. Send service token
Section [service_user] is not defined at all for Cinder: https:/
2. Service role
From documentation "A service role is nothing more than a Keystone role that allows a deployment to identify a service without the need to make them admins", and later: "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:
ERROR neutron.
Policy restricting that call is:
"os_compute_
And rule:context_
"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
tags: | added: cinder nova |
description: | updated |
information type: | Private Security → Public Security |
[service_user] for services that work like not is used for making request to other services
in the context of the cve cinder does not actually need that section.
note ironic does not use a [service_user] section it uses the details form the relevant service section i.e. cinder instead and assumes that it has the admin and service roles.
so cinder does not need the [service_user] section for the cve mitigation in its config.
it may use it for the other uses of service_user which is to test that when calling other services with a user token that may expire it was valid when cinder received it and should be honoured as if it was still valid by the receiving service.
you are correct that policies in services are not prepared for service role only in general which is why we recommend using both the service and admin role for the user configured in [service_user] in the interm period.
the i have not looked at the details of all of kolla config but i proposed the original patch for the service_user support for nova in kolla /github. com/openstack/ kolla-ansible/ commit/ ddadaa282e72cc4 37470859766ac96 3ac757a26a
https:/
since my original version the patch was updated to use the admin role when verifying the service token in cinder
https:/ /github. com/openstack/ kolla-ansible/ commit/ ddadaa282e72cc4 37470859766ac96 3ac757a26a# diff-61b022281f 112ed49c0169e67 dd999658a41397d f88acb4c224904d 1c11b03cdR110
that is not correct and that could have security implications.
the service role is intentionally referenced in the upstream docs regarding this because its a role a normal admin.human should not have.
it was intentionally used so that admin could not delete cinder volume atachemetn with there normal admin accounts.
by enforceing the token has the admin role instead that protection has been removed but the cve is not reintudced for end users as normal users are still blocked.
kolla should be adding the service role to the service accounts (nova neutron ectra) and they should not be setting service_token_roles = admin in the cinder config.