Open Stack

> it was intended to provide a programitc way for clients to discover
> what option are valid and is use by horizon and heat to generate uis
> and validate input.  https://pasteboard.co/JS99sgU.png

Ah, okay, good to know that Horizon uses this, thanks. That closes the
loop quite a bit, and I assume explains why some people submit updates
to the static definitions now and then.

> this same information used to be used in heat whan you a heat template
> to generate and validat the allowed values for some parmater although
> i dont knwo if that is still used.  heat certely uses info form nova
> to get the list of flavor exctra but i belive it also used this
> informate when generation the ui for templates that defiled new
> flavors.

Okay, it would be good to know if Heat uses this as well.

> looking at the OSSN https://wiki.openstack.org/wiki/OSSN/OSSN-0088 i
> am rather suprised that writing to this api was not admin only.  i had
> alway tought that it was in the past and that readign form it was the
> only thing that was globally accessable as a normal user.

Yeah, the API seems to clearly allow for public and private namespaces
(at least) and loosely ties the structures in the database to a
namespace for ownership. I think that means it was expected to be usable
by regular users and providing some amount of isolation between them. It
does not, however, seem to be very good at keeping private things
private :) A lot of things in glance from the same time period did
admin-only policy enforcement in code instead of policy, which is
probably another indication that it was _expected_ to be usable by
regular users.

> i would suggest that one possible fix would be to alter the policy so
> that writing to this api is admin only. at the ptg we coudl discuss
> shoudl that be extended to user too but i dont personally see a good
> usecase for normally users to be able to create new metadefs.
>
> disableing it would break the current functionaliyt in horizon so i do
> not think that would be a good ensuer experince.

Yeah, if Horizon uses this to make things pick-and-choose'able to the
user, it would be nice to not just fully disable it. Right now, regular
users can create these resources, and may not be aware that the names
they choose are leaked to other users. Further, the creation of those
things are not constrained by any limit, which is also a problem.

If the main usage pattern of this is for admins to define these things
(or just take all the defaults) and users just need to be able to see
the largely-public lists of things they can choose from, then limiting
creation to admins by default instead of fully disabling everything
seems like a good course of action.

I guess the remaining thing I'd like to know is: does anyone want or
expect unprivileged users to be able to create these resources?

Admins should still be aware that the naming is potentially leaky, and
especially if they create these resources for special customers. They
also may want to audit their systems for any resources that users have
created up to this point, which may expose something if they keep read
access enabled for everyone.

It might be good if we can amend the recommendation to explain the
impact of disabling everything on Horizon, along with the recommendation
to restrict creation to admin-only and audit. Not sure what the
procedure is for that.

Thanks Sean!

--Dan