[ops][glance][security] looking for metadefs users
Hello operators and other people interested in metadefs, The Glance team will be giving the metadefs some love in the Xena development cycle in order to address OSSN-0088 [0]. The people who designed and implemented metadefs are long gone, and in determining how to fix OSSN-0088, we would like to understand how people are actually using them in the wild so we don't restrict them so much as to make them useless. We are looking for an operator who uses metadefs to give us a walkthrough on how you are using them at the Xena (virtual) PTG. We are planning to have this session on 23rd April around 1400 UTC. You can find more details about the same in PTG planning etherpad [1]. We are also willing to meet outside the PTG schedule in case the current scheduled time might be blocking the people. I will also reply to this as a reminder mail once our PTG schedule is final. If you do not use the metadef API for some reason related to its inability to solve a problem, lack of flexibility, or other reasons (but wish you could), we would also like to hear about that. We need to know if the feature is worth fixing and maintaining going forward. And when we say "an operator", we don't mean just one ... ideally, we'd like to have a few real-life use cases to consider. If this is affecting you (as an operator) then you can reach us either by mail or #openstack-glance IRC channel or glance weekly meeting [2] which will be held every Thursday around 1400 UTC. [0] https://wiki.openstack.org/wiki/OSSN/OSSN-0088 [1] https://etherpad.opendev.org/p/xena-ptg-glance-planning [2] https://etherpad.opendev.org/p/glance-team-meeting-agenda Thank you and Best Regards, Abhishek Kekane
On Thu, 2021-03-11 at 21:34 +0530, Abhishek Kekane wrote:
Hello operators and other people interested in metadefs,
The Glance team will be giving the metadefs some love in the Xena development cycle in order to address OSSN-0088 [0].
The people who designed and implemented metadefs are long gone, and in determining how to fix OSSN-0088, we would like to understand how people are actually using them in the wild so we don't restrict them so much as to make them useless.
the metadef api was orginally created as a centralised catalog for defineing all teh tuneable that can be defiend via metadata,extra specs or as attibutes on vairous resouces across multipel porjects. https://docs.openstack.org/glance/latest/user/metadefs-concepts.html#backgro... has a table covering most of them 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 the list of available extra specs for the flavor metadta api is generated dirctly form the metadefs api including the desciption we se for "hw:mem_page_size". wehere a validator is specifd such as for hw:cpu_policy a drop down list in the case of enums or other validation can be applied by horizon to the parmaters. https://github.com/openstack/glance/blob/45749c30c1c02375a85eb17be0ccd983c69... "cpu_policy": { "title": "CPU Pinning policy", "description": "Type of CPU pinning policy.", "type": "string", "enum": [ "shared", "dedicated" ] }, 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. while this was never integratein into the unified openstack client to enabel validation of flavors,images ectra that was part of the eventual design goal. at present this is the only openstack api i am currently aware of that allows you to programaticaly diccover this informateion.
We are looking for an operator who uses metadefs to give us a walkthrough on how you are using them at the Xena (virtual) PTG. We are planning to have this session on 23rd April around 1400 UTC. You can find more details about the same in PTG planning etherpad [1]. We are also willing to meet outside the PTG schedule in case the current scheduled time might be blocking the people. I will also reply to this as a reminder mail once our PTG schedule is final.
If you do not use the metadef API for some reason related to its inability to solve a problem, lack of flexibility, or other reasons (but wish you could), we would also like to hear about that. We need to know if the feature is worth fixing and maintaining going forward.
i still think this is a valueable feature that i which was used more often it may seam odd now that galce was choosen as the central registry for storing this information but if this api was removed i think it would be important for all project that have this type of metadta to have an alternitve metond to advertise this info.
And when we say "an operator", we don't mean just one ... ideally, we'd like to have a few real-life use cases to consider.
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. 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.
If this is affecting you (as an operator) then you can reach us either by mail or #openstack-glance IRC channel or glance weekly meeting [2] which will be held every Thursday around 1400 UTC.
[0] https://wiki.openstack.org/wiki/OSSN/OSSN-0088 [1] https://etherpad.opendev.org/p/xena-ptg-glance-planning [2] https://etherpad.opendev.org/p/glance-team-meeting-agenda
Thank you and Best Regards,
Abhishek Kekane
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
On 2021-03-11 09:46:47 -0800 (-0800), Dan Smith wrote: [...]
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.
The recommendation is in a wiki article[1] (in the form of an OSSN document), so can be freely edited. But if someone makes significant updates to the recommendation then we should probably also send an errata announcement to the openstack-announce and openstack-discuss mailing lists detailing what's changed since initial publication. The OSSN process[2] doesn't mandate any particular errata steps, but we can use our own judgement to determine what may be additionally worth announcing/updating for it. [1] https://wiki.openstack.org/wiki/OSSN/OSSN-0088 [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process -- Jeremy Stanley
The recommendation is in a wiki article[1] (in the form of an OSSN document), so can be freely edited. But if someone makes significant updates to the recommendation then we should probably also send an errata announcement to the openstack-announce and openstack-discuss mailing lists detailing what's changed since initial publication. The OSSN process[2] doesn't mandate any particular errata steps, but we can use our own judgement to determine what may be additionally worth announcing/updating for it.
Cool, thanks. I think the recommendation is "review and reconsider the default policy for this feature" and "here is what we think is a good default if you don't otherwise know". Changing our recommended default to be a more generally-applicable doesn't seem to alter the general message to me, so I'd tend think just editing the wiki page is fine. --Dan
On 2021-03-11 10:50:18 -0800 (-0800), Dan Smith wrote: [...]
I think the recommendation is "review and reconsider the default policy for this feature" and "here is what we think is a good default if you don't otherwise know". Changing our recommended default to be a more generally-applicable doesn't seem to alter the general message to me, so I'd tend think just editing the wiki page is fine.
Seems reasonable to me. What do other folks think? -- Jeremy Stanley
Hi, we use metadef to validate our custom metadata in Horizon when users create instances. In our use case, metadef should be written only by admin. +1 to review the default policy. Belmiro CERN On Thu, Mar 11, 2021 at 8:34 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-03-11 10:50:18 -0800 (-0800), Dan Smith wrote: [...]
I think the recommendation is "review and reconsider the default policy for this feature" and "here is what we think is a good default if you don't otherwise know". Changing our recommended default to be a more generally-applicable doesn't seem to alter the general message to me, so I'd tend think just editing the wiki page is fine.
Seems reasonable to me. What do other folks think? -- Jeremy Stanley
---- On Thu, 11 Mar 2021 13:59:02 -0600 Belmiro Moreira <moreira.belmiro.email.lists@gmail.com> wrote ----
Hi,we use metadef to validate our custom metadata in Horizon when users create instances. In our use case, metadef should be written only by admin.+1 to review the default policy.
In a quick search, interop certification guidelines 1] also does not use these API capabilities so changing to admin should be fine from interop and so does from Tempest test modification point of view. [1] https://opendev.org/osf/interop -gmann
BelmiroCERN On Thu, Mar 11, 2021 at 8:34 PM Jeremy Stanley <fungi@yuggoth.org> wrote: On 2021-03-11 10:50:18 -0800 (-0800), Dan Smith wrote: [...]
I think the recommendation is "review and reconsider the default policy for this feature" and "here is what we think is a good default if you don't otherwise know". Changing our recommended default to be a more generally-applicable doesn't seem to alter the general message to me, so I'd tend think just editing the wiki page is fine.
Seems reasonable to me. What do other folks think? -- Jeremy Stanley
On 2021-03-11 14:22:21 -0600 (-0600), Ghanshyam Mann wrote: [...]
In a quick search, interop certification guidelines 1] also does not use these API capabilities so changing to admin should be fine from interop and so does from Tempest test modification point of view. [...]
Yep, if you check out the original bug reports leading up to the OSSN, we did at least confirm these were not part of any trademark program requirement before recommending that access be blocked. That was one of our deciding factors in the disclosure timeline. -- Jeremy Stanley
On Fri, Mar 12, 2021 at 2:27 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-03-11 14:22:21 -0600 (-0600), Ghanshyam Mann wrote: [...]
In a quick search, interop certification guidelines 1] also does not use these API capabilities so changing to admin should be fine from interop and so does from Tempest test modification point of view. [...]
Yep, if you check out the original bug reports leading up to the OSSN, we did at least confirm these were not part of any trademark program requirement before recommending that access be blocked. That was one of our deciding factors in the disclosure timeline. -- Jeremy Stanley
Thanks to Sean and Belmiro for confirming how and where metadefs are used. I think it makes more sense now to keep these metadef create/update/delete APIs admin-only and grant read-only access to normal users. In the advisory we should also specify that there is still a possibility of information leak in this case. Thanks and Regards, Abhishek Kekane
participants (6)
-
Abhishek Kekane
-
Belmiro Moreira
-
Dan Smith
-
Ghanshyam Mann
-
Jeremy Stanley
-
Sean Mooney