| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 14:28:05 | sean-k-mooney | admin impiles member implies reader | |
| 14:28:12 | admiyo | I know. I wrote that implementation and I can see it has been maintained. | |
| 14:28:20 | sean-k-mooney | that does nto solve the problem when a servier is a proejct scoped resoucece | |
| 14:28:39 | admiyo | Yes it does.... | |
| 14:29:29 | sean-k-mooney | well in 5 years noone has been able to expalin how to make it owrk in a way that people can accpet and implemtnet | |
| 14:29:38 | admiyo | You need the appropriate role, but implied roles work down the hierarchy, So if I have the correct role on the parent proejct (or domain) it works for all projects underneath it. | |
| 14:29:58 | sean-k-mooney | sure | |
| 14:30:16 | sean-k-mooney | but we dont supprot domain scoped tokens and you cant have nested projects | |
| 14:30:22 | admiyo | And you could even do it on a domain, but it looks like they have made it work bettern | |
| 14:30:51 | sean-k-mooney | even if we did use the domain scopet token to list all the project you shoudl have acceess too that still means you cant see things across multiple domains | |
| 14:31:14 | admiyo | It used to work. | |
| 14:31:29 | admiyo | I think we called it the default domain.... | |
| 14:31:55 | sean-k-mooney | admiyo: i was just doing clean up of old bugs by the way | |
| 14:32:11 | sean-k-mooney | as far as i can tell what was being asked for in that bug is not compatible with the governance doc | |
| 14:32:33 | sean-k-mooney | admiyo: gmann: has been following srbac more closely then i | |
| 14:32:57 | sean-k-mooney | admiyo: but the only work i am aware of in this are is what descibe in that doc | |
| 14:33:06 | admiyo | It sounds like you have a fix in place. I think that is better to write up there than "won't fix." This was a deal breaker for giving people direct access to the API in a lot of cases, and lead to everyone putting APIs in front of OpenStack. I would love to see it closed properly. | |
| 14:33:10 | opendevreview | Merged openstack/placement master: Switch python version used for periodic jobs https://review.opendev.org/c/openstack/placement/+/932472 | |
| 14:33:46 | sean-k-mooney | admiyo: i really dont get the issue with acess to the apis | |
| 14:33:58 | sean-k-mooney | there are verly few things that actully need admin in nova | |
| 14:34:11 | admiyo | And do those HAVE to be on project tokens? | |
| 14:34:44 | sean-k-mooney | specificly creating flavors, managing compute servcices/host aggreates or things like live migration | |
| 14:34:50 | admiyo | I'll explein the issue after, but I am more interested in the solution, sounds like you have one | |
| 14:35:04 | sean-k-mooney | admiyo: yes if you want to create a service via nova you need to use a project scoped token | |
| 14:35:09 | admiyo | Right, and the resources you list there are not scoped to projects anymore? | |
| 14:35:44 | sean-k-mooney | they were system scoped and now they are project scoped again | |
| 14:36:08 | admiyo | but why are the "admin" then if admin is global role? | |
| 14:36:42 | sean-k-mooney | becuase flavors/hostaggated compute service are not somethign a normal user shoudl be able to modify | |
| 14:36:58 | sean-k-mooney | they are admin because only admins of the openstack cloud should be able to interact with them | |
| 14:37:19 | admiyo | but should a project admin be able to change flavors that are specific to a different project? | |
| 14:37:35 | sean-k-mooney | no | |
| 14:38:05 | sean-k-mooney | you are misussing that term based on the current agreed usage | |
| 14:38:24 | sean-k-mooney | a a use with an admin role is a global admin | |
| 14:38:40 | admiyo | can I have a project specific flavor ? | |
| 14:39:04 | sean-k-mooney | technially yes private flavor are a thing and only admins can create them on behayce fo end users | |
| 14:39:15 | sean-k-mooney | a normal user of a public cloud should not be allowed ot od that with the member role | |
| 14:40:04 | sean-k-mooney | admiyo: a new role that is seperat eform the curent heriacy was proposed if to have project scoped elevated access | |
| 14:40:07 | sean-k-mooney | https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#implement-support-for-project-manager-personas | |
| 14:40:11 | dansmith | flavors are also a lot more involved than they were in 2010 and require knowledge of the backend to some degree to set up in a lot of real-world cases, like knowing what hardware is available and in what configuration | |
| 14:40:14 | sean-k-mooney | its called the project manager role | |
| 14:40:40 | sean-k-mooney | that is part of phase 3 and we are in the midel of pahse 2 right now | |
| 14:41:00 | dansmith | and as sean-k-mooney has been saying, I think this is not nova-specific and also pretty much a sailed ship at this point | |
| 14:41:17 | admiyo | So it looks like you DO have a plan in place to fix the bug. It should not be closed as won't-fix | |
| 14:41:36 | sean-k-mooney | the bug is honestly invlid | |
| 14:42:06 | sean-k-mooney | we have specificly decied to not scope the admin role | |
| 14:42:16 | dansmith | agree | |
| 14:42:17 | admiyo | Well, no. It is not invalid. | |
| 14:42:23 | sean-k-mooney | we are keeping it as a global role and providing a new manager role | |
| 14:42:44 | sean-k-mooney | the manager role can be scoped to project or domains | |
| 14:42:53 | sean-k-mooney | when ever we implemet it | |
| 14:43:06 | admiyo | The admin role has been removed from being a project scoped role, that is fine. But do those APIs still look for the project ID on the token? That was the problem before. If nova has removed that restriction, then you have fixed it. | |
| 14:43:38 | sean-k-mooney | thats a diffent question. | |
| 14:43:39 | admiyo | Becuase other projects beside Nova "reqquired" if for day to day operations. It was a logicial contradiction | |
| 14:44:19 | sean-k-mooney | you realise that cinder or glance until recently reuiqred a proejct in the url | |
| 14:44:26 | sean-k-mooney | not just in the headers | |
| 14:44:27 | admiyo | Oh yes I do | |
| 14:45:15 | admiyo | that actually made certain things easier to do, so I understand why they did it. I am still not certain they were wrong, but having it consistent across all OpenStack was more important | |
| 14:45:19 | sean-k-mooney | to answer your question, weither or not we actuly need a project id depends on a few things, the policy file/default and if we are suign it for auiting | |
| 14:46:30 | ratailor | sean-k-mooney, gibi could you please review this patch https://review.opendev.org/c/openstack/nova/+/928933 and let me know why api-samples tests are failing, I assume something is missing, but not sure what ? I tried my best to find why its failing, but couldn't get any further. | |
| 14:47:05 | sean-k-mooney | if we look at the policy for managing flavor https://github.com/openstack/nova/blob/master/nova/policies/flavor_manage.py#L28 we use the base admin check https://github.com/openstack/nova/blob/master/nova/policies/base.py#L40 which does not check for the project id | |
| 14:47:46 | sean-k-mooney | admiyo: however much of our logging does expect a project id | |
| 14:47:56 | admiyo | policy file overrides are a fix, but not required, so I would say that case if OK. The real issue is the defaults. If the code requires a both a project ID and the Admin role, you have a problem. | |
| 14:48:36 | sean-k-mooney | admiyo: for context we moved them to be system scoped and undit that https://github.com/openstack/nova/commit/066e1e69d1394839a9f0bde4ca8c3a0db2d52396 | |
| 14:48:37 | admiyo | So how do you limit who can get the ADMIN role? | |
| 14:48:52 | sean-k-mooney | you do that via keystone | |
| 14:49:17 | sean-k-mooney | a keyston admin is needed to asing an admin role to a user on a project/domian | |
| 14:49:27 | admiyo | From my perspective, system scoped was a mistake. I understand why they did it (to make things more obvious) but it was fighting all of the services. | |
| 14:49:52 | sean-k-mooney | right which is why we went back to everyting in nova being project scoped again | |
| 14:50:50 | sean-k-mooney | admiyo: if you have a devstack you can proably jsut create a non project scoped token iwth the admin role and call nova to see what the behaivor is | |
| 14:50:59 | admiyo | What I had proposed was that we mark certain projects as ADMIN projects. Thus, if you wanted to be selective about what ADMINs could perform, say, a flavor modification, you put an additional check on those operations. But they still used project scoped tokens | |
| 14:51:33 | sean-k-mooney | admiyo: that not a nova dicussion | |
| 14:51:53 | admiyo | It waws. And it was accepted way-back-why byt the Nova PTL.... | |
| 14:51:59 | sean-k-mooney | if you give someone admin they have admin when you call nova or neutron | |
| 14:52:29 | sean-k-mooney | are you usign the term project to refer to openstack serivce or keystone pojects | |
| 14:52:55 | admiyo | No, I was specifically using it for projects. Because the APIs all required project scoped tokens | |
| 14:53:08 | admiyo | For keystone projects | |
| 14:53:11 | dansmith | admiyo: you seem to be missing a lot of context and community-wide discussion that happened in recent years... | |
| 14:53:23 | admiyo | and, I agreee, the name project was not the right one. | |
| 14:53:27 | dansmith | rehashing it with "it was agreed by the nova PTL in 2012" is not a very compelling argument in 2024 | |
| 14:54:05 | admiyo | it was in 2018, right before the Keystone PTL changed the direction and I rage quit. But the issue still stands that if it is broken in Nova it is broken everywhere | |
| 14:54:18 | admiyo | and the issue was that Admin was required on a project scoped token. | |
| 14:54:40 | admiyo | And elsewhere in openstack, that was required to do things that you would assume an end user could do | |
| 14:54:40 | sean-k-mooney | admiyo: for what its worth there was a discussion abou thaving a maping of roles ot service endpoints | |
| 14:55:23 | sean-k-mooney | admiyo: i.e. give someone admin on the neutron api but not on others. keystone did not want to do that | |
| 14:55:57 | admiyo | to be clear. I was never in support of service scoped tokens. I just stepped away from the discussion after a year of my life went in to gettin a nova acceptable solution....so all I am trying to do now is confirm that you do actually have a solution, and I am...55% convinced of that right now | |
| 14:56:41 | sean-k-mooney | admiyo: do you have an exampel of a call to noava that required admin on a diffent service | |
| 14:57:26 | admiyo | Back in the day it was stuff like add/remove userse from projects and grant role assignments. | |
| 14:57:43 | sean-k-mooney | which are all part of keystone | |
| 14:57:53 | admiyo | so in keystone to assign a user to a project, you HAD to have admin, becuase one of the roles you could grant them was Admin | |
| 14:57:56 | admiyo | and thus..... | |
| 14:58:12 | sean-k-mooney | right so the manager role is proposed to be used to do that | |
| 14:58:20 | sean-k-mooney | a porject manager would be able ot add a user to a project | |
| 14:58:50 | admiyo | TO be honest, I have not tracked what was done in Cinder or Glance ever since then. | |
| 14:58:51 | sean-k-mooney | a domain manager would be able to create proejcts and users in there domain | |
| 14:59:08 | admiyo | I know that kn heat you used to need it to clean up things that were wedged.... | |
| 14:59:45 | sean-k-mooney | again that just soudn like a bug | |
| 15:00:20 | admiyo | What you are saying is that a requirement in Nova dictated how all the other projects had to implement policy. | |
| 15:00:41 | sean-k-mooney | admiyo: no im not | |
| 15:00:51 | admiyo | And you then needed to audit and get agreement from all the other projects on how to fix it. | |
| 15:01:09 | sean-k-mooney | again please read that document | |