On Thu, 2022-06-09 at 11:11 +0200, Christian Rohmann wrote: > Hey openstack-discuss, > > I posted to the ML quite a while ago about an issue of resized (Cinder) > volumes not being propagated to the (Nova) instance. > See > http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020476.html. > > The issue there was Cinder being not allowed to send the > "volume-extended" event (or any event for that matter via the Nova API > just using the user token. > For this a configurable additional "privileged user" was added to the > config quite a while back with > https://opendev.org/openstack/cinder/commit/04003d7c513ed4dd5129cbd5ad1af14a5b200677. > > While the functionality then works I suppose there should be canned and > maintained RBAC roles for such kind of inter service to service > communications, e.g. to emit events to others. Otherwise deployments > likely will use admin privileged users ignoring the least privilege > principle and creating an large attack surface. > > And there are quite few of those relations even with the most commonly > used services. > Cinder -> nova, nova-> cincer, nova->ironic, .... nova-> neutron, .... > > Are such canned RBAC rules for "special" inter service users on the > backlog somewhere? Or am I totally misconceiving the issue here? yes its called the service role its been discussed many times over the laste 3-4 virutal ptgs. its part of phase 2 https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-2 """Isolate service-to-service APIs to the service role""" so the target is to start implementing the service role in AA and compelte it in all service by BB https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#aa-release-timeline > > I know there is > https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#isolate-system-specific-api-policies > and also the question for feedback at > https://etherpad.opendev.org/p/rbac-operator-feedback, but that all > seems to focus on the impact of roles used by humans / users and not > about service roles at all. > > > Regards > > Christian > >