Open Stack

Hi,

while we are not using openstack helm I would jump in with our experience.

We are currently creating individual service users for each service (so 1 individual user for each nova-compute on each node) in order to make credential rotation a reasonable thing.
That works flawlessly for us, so I would assume this should also work for openstack helm.

I honestly never understood why the openstack documentation recommends using the individual service users in the individual sections.
Using one user specific to each service is in my opinion a lot more intuitive and brings a bunch of security benefits.

--
Felix Huettner

From: Mohammed Naser <mnaser at vexxhost.com>
Sent: Sunday, February 12, 2023 6:55 PM
To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: [openstack-helm] switching to using service's user for requests

Hi team,

I'm wondering if it makes sense for us to make a change in all of OpenStack Helm's code in order to make it use the service user for all requests.

For example, right now, we are using the placement user in the `[placement]` section in Neutron, or the Neutron user in the `[neutron]` section in Nova.  However, all of these users have the same
exact role and permissions, so I believe it would help a lot in locking down services (let's say placement gets compromised, you can lock it's user only).

I also think it will significantly simplify all of our code for endpoints for the different services, since we'll just be re-using the same credentials.

Let me know what everyone thinks.

Thanks,
Mohammed

--
Mohammed Naser
VEXXHOST, Inc.

Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230213/3fc172dd/attachment.htm>