© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
[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
https:/
since my original version the patch was updated to use the admin role when verifying the service token in cinder
https:/
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.