[rbac][nova][cinder] Canned roles for service users / inter-service communication (e.g. event submission)
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..... 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/04003d7c513ed4dd5129cbd5ad1af14a.... 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? I know there is https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... 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
On 09/06/2022 11:11, Christian Rohmann wrote:
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?
I know there is https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... 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.
I just noticed that Christian Berendt does a forum talk on "Deprivilization of the internal service accounts" TODAY at 2:40pm - 3:10pm at A05 on apparently that exact question :-) Regards Christian
On 09/06/2022 12:39, Christian Rohmann wrote:
I just noticed that Christian Berendt does a forum talk on "Deprivilization of the internal service accounts" TODAY at 2:40pm - 3:10pm at A05 on apparently that exact question :-)
The notes on the discussion can be found here: https://etherpad.opendev.org/p/deprivilization-of-service-accounts Regards Christian
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.....
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/04003d7c513ed4dd5129cbd5ad1af14a....
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-rba... """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-rba...
I know there is https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rba... 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
participants (2)
-
Christian Rohmann
-
Sean Mooney