[nova] Does anyone remember why server_group_members quota is enforced at the user rather than project level?

Lance Bragstad lbragstad at gmail.com
Thu Mar 14 15:12:57 UTC 2019



On 3/14/19 9:18 AM, Zane Bitter wrote:
> On 13/03/19 5:28 PM, Chris Friesen wrote:
>> On 3/13/2019 8:41 AM, Jay Pipes wrote:
>>
>>> Yep, and IMHO, keypairs is the one and only valid user-specific limit.
>>
>> Even that is a bit sketchy, since instances are owned by projects.
>
> Came here to say this :)
>
> I assume the reason is that it allows a user to upload their public
> key once and use it in every project they are a member of. That's
> nice, but IMHO not worth the pain of having one thing in OpenStack
> that is scoped completely differently to everything else.
>
>> Currently if a user starts up an instance and then leaves without
>> sharing the keypair, other users in the same project would
>> potentially need to rebuild the instance to update the keypair before
>> they can log in to it.
>
> It's an even bigger problem for Heat because we have an
> OS::Nova::Keypair resource but everything breaks if a different user
> updates the stack, because the keypair that Heat created suddenly
> becomes invisible.
>
>> I think an argument could be made that keypairs should be owned by
>> projects, and users should get allocated single-user projects for
>> instances they want to keep private.
>
> Even that is irrelevant as far as keypairs are concerned. Let's not
> kid ourselves that there's any "pair" involved in a keypair. You can
> create one without providing the private key, and if you do have Nova
> generate a private key, it doesn't store it. So a 'keypair' is
> actually just a public key. If a user has an instance they don't want
> other people to log into, they should not share their private key with
> anyone, end of story.

I agree that you shouldn't need another project if password
authentication is disabled on the server and keep private keys private.

I can think of a use case that I find useful and have needed in the past
that would be easier with public keys being project-scoped. As a team of
developers, we had access to a project and we mostly used it for
development instances. Often times we would want to debug things
together on the same server, or peer program (remotely using ssh/mosh +
tmux + $EDITOR). To do this, I'd add all the public keys for my team to
the project, but I was the only one who could view them. If someone else
joined the team, I'd need to get their public key and import it (along
with anyone else on the team). My team members likely had their public
keys associated to the project already for their own development instances.

If things like public keys were project-scoped, I could specify a list
of public keys associated to the project when I create the server. Then,
I only need to manage my public keys but I get access to public keys
associated to the project without having to bloat my own key pair quota.

Sorry for a tangent on public keys when this thread is specific to
server_group_members, but comments about key pairs tripped that use case
for me.

>
> (Obviously if you don't want other users to be able to update/delete
> the server through the Nova API then it should be in a project that no
> other users have permissions for. But this is true independently of
> the scope of keypairs.)
>
> cheers,
> Zane.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190314/5fc1da7b/attachment-0001.sig>


More information about the openstack-discuss mailing list