Project-scoped app creds - Best practice
Hello all, Relatively new to OpenStack. To my understanding, application credentials are bound to users. Is there a way to bind them to Projects (I assume not) or, perhaps, Groups? My naive thought on a possible solution is that if a group has access to a Project, a "generic" user account that everybody has access to could be used for the application credentials. (The use case here is to not bind an app cred to an individual who might leave the organization, thus making the app cred secret lost.) Thanks, Ryan
Hello Ryan, We actually faced a similar situation and we extended Keystone to support the concept of Project bound credentials, which means, credentials that are owned by a project and not by a user. Therefore, the credentials are shared by all users of a project. The spec is the following: https://review.opendev.org/c/openstack/keystone-specs/+/766725 We have it already running in PROD for over 6 months now, and it is also integrated with RadosGW<>Keystone authentication. On Thu, Nov 25, 2021 at 7:53 PM Ryan Bannon <ryan.bannon@gmail.com> wrote:
Hello all,
Relatively new to OpenStack.
To my understanding, application credentials are bound to users. Is there a way to bind them to Projects (I assume not) or, perhaps, Groups? My naive thought on a possible solution is that if a group has access to a Project, a "generic" user account that everybody has access to could be used for the application credentials. (The use case here is to not bind an app cred to an individual who might leave the organization, thus making the app cred secret lost.)
Thanks,
Ryan
-- Rafael Weingärtner
Hi all, Rafael, thanks for the notes! That's a great initiative. Although it looks like it has stalled in the review phase...? (I'm new to interpreting the development workflow for OpenStack.) To all: does anybody else have input on how they solved this issue? Tx, Ryan On Thu, Nov 25, 2021 at 6:21 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Hello Ryan, We actually faced a similar situation and we extended Keystone to support the concept of Project bound credentials, which means, credentials that are owned by a project and not by a user. Therefore, the credentials are shared by all users of a project.
The spec is the following: https://review.opendev.org/c/openstack/keystone-specs/+/766725
We have it already running in PROD for over 6 months now, and it is also integrated with RadosGW<>Keystone authentication.
On Thu, Nov 25, 2021 at 7:53 PM Ryan Bannon <ryan.bannon@gmail.com> wrote:
Hello all,
Relatively new to OpenStack.
To my understanding, application credentials are bound to users. Is there a way to bind them to Projects (I assume not) or, perhaps, Groups? My naive thought on a possible solution is that if a group has access to a Project, a "generic" user account that everybody has access to could be used for the application credentials. (The use case here is to not bind an app cred to an individual who might leave the organization, thus making the app cred secret lost.)
Thanks,
Ryan
-- Rafael Weingärtner
Ryan, That happened with Keystone for some time (I have 3 or more specs that are stuck, even though they were discussed in-depth), the reviews were becoming quite massive (for me, for the specs I proposed) without getting anywhere, and maybe that is a consequence of PTLs/core reviewers being focused on somewhere else, or not having enough time to execute the paperwork of a new feature being proposed, evaluated, and accepted. I know that this is also my fault because I could have volunteered to become core review/PTL to try to add more work on Keystone, but I did not have enough time to dedicate to Keystone. This caused the specs to get stuck (and their patch). That is also why, for this latest spec I created, I did not publish the patch. For the other specs, I proposed the patch, they (the specs) were more or less accepted (we had a consensus), but never got merged, which caused the patches only to get conflicts, and not move forward, which made me a bit disappointed (after having fixed conflicts countless times). One of my new year's resolutions is to dedicate more time to Keystone next year. Or, at least, as much as I dedicate to CloudKitty to see if we can get these moving on.
I think you're being too hard on yourself :) On Fri, Nov 26, 2021 at 12:50 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Ryan, That happened with Keystone for some time (I have 3 or more specs that are stuck, even though they were discussed in-depth), the reviews were becoming quite massive (for me, for the specs I proposed) without getting anywhere, and maybe that is a consequence of PTLs/core reviewers being focused on somewhere else, or not having enough time to execute the paperwork of a new feature being proposed, evaluated, and accepted.
I know that this is also my fault because I could have volunteered to become core review/PTL to try to add more work on Keystone, but I did not have enough time to dedicate to Keystone. This caused the specs to get stuck (and their patch). That is also why, for this latest spec I created, I did not publish the patch. For the other specs, I proposed the patch, they (the specs) were more or less accepted (we had a consensus), but never got merged, which caused the patches only to get conflicts, and not move forward, which made me a bit disappointed (after having fixed conflicts countless times).
One of my new year's resolutions is to dedicate more time to Keystone next year. Or, at least, as much as I dedicate to CloudKitty to see if we can get these moving on.
Haha, thanks! If you want/need I can share the patch to have project bound credentials in Keystone. Just let me know. On Fri, Nov 26, 2021 at 5:21 PM Ryan Bannon <ryan.bannon@gmail.com> wrote:
I think you're being too hard on yourself :)
On Fri, Nov 26, 2021 at 12:50 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Ryan, That happened with Keystone for some time (I have 3 or more specs that are stuck, even though they were discussed in-depth), the reviews were becoming quite massive (for me, for the specs I proposed) without getting anywhere, and maybe that is a consequence of PTLs/core reviewers being focused on somewhere else, or not having enough time to execute the paperwork of a new feature being proposed, evaluated, and accepted.
I know that this is also my fault because I could have volunteered to become core review/PTL to try to add more work on Keystone, but I did not have enough time to dedicate to Keystone. This caused the specs to get stuck (and their patch). That is also why, for this latest spec I created, I did not publish the patch. For the other specs, I proposed the patch, they (the specs) were more or less accepted (we had a consensus), but never got merged, which caused the patches only to get conflicts, and not move forward, which made me a bit disappointed (after having fixed conflicts countless times).
One of my new year's resolutions is to dedicate more time to Keystone next year. Or, at least, as much as I dedicate to CloudKitty to see if we can get these moving on.
-- Rafael Weingärtner
participants (2)
-
Rafael Weingärtner
-
Ryan Bannon