| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 14:15:03 | admiyo | to Nova. https://adam.younglogic.com/2017/05/fixing-bug-96869/ | |
| 14:15:03 | admiyo | sean-k-mooney, I see that you closed bug 698696 as won;t fix: https://bugs.launchpad.net/keystone/+bug/968696 I think that is a mistake. All role assignments are scoped. I had a proposal a few years back that addresses your concerns. Basically, for "global" actions that nova has scoped to a proejcct (due to history) you confirm that the project on the token is an "administrative" project. It requires minimal changes | |
| 14:19:30 | sean-k-mooney | admiyo: there is no such thing as a project scoped admin | |
| 14:20:05 | sean-k-mooney | admiyo: there is a governance document to descibe how roels shoudl work consitnatnly across all of openstack | |
| 14:20:26 | admiyo | sean-k-mooney, as of when? When Openstack started, that was all there was. It was a bug in the initial design, before Keystone was a project/ | |
| 14:20:30 | sean-k-mooney | the admin role is not scoped to a project based on the desgin agreed in yoga | |
| 14:20:58 | admiyo | And the reason why it has stuck around is that Nova scoped APIs to projects that needed the Aadmin role. It can't be fixed in openstack without being fixed in Nova | |
| 14:21:06 | admiyo | What I wrote up was the "hard" way | |
| 14:21:16 | admiyo | the even harder way was to fix all of the APIs in Nova | |
| 14:21:22 | sean-k-mooney | amorin: have you read https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html | |
| 14:21:34 | sean-k-mooney | amorin: you cant have a proejct scoped admin role in any project | |
| 14:21:37 | sean-k-mooney | its not just nova | |
| 14:21:57 | admiyo | We just killed the Admin role? | |
| 14:22:05 | sean-k-mooney | no | |
| 14:22:53 | sean-k-mooney | the admin role is defiend as a role that allows the bearer to performe admin operations on any service agaisnt any project | |
| 14:23:10 | sean-k-mooney | which is what it has alwasys ment | |
| 14:23:15 | admiyo | "we decided to postpone the scope implementation" | |
| 14:23:23 | admiyo | Heh....scope existed from the get go | |
| 14:23:36 | sean-k-mooney | not in anything other then keystone | |
| 14:23:52 | sean-k-mooney | we not only persponed it we removed it form almost every project that impmented it | |
| 14:24:18 | admiyo | Keystone split off from Nova. It was originally implemented there. The bug is Nova's original sin | |
| 14:24:34 | sean-k-mooney | admiyo: to be clear i was not makeign the deciosn to close it form a nova point of view | |
| 14:24:56 | admiyo | And the problem was that there WERE nova apis that required admin scoped to the project | |
| 14:24:57 | sean-k-mooney | as a comuntiy a collect dission was made not to go in that direction | |
| 14:25:10 | admiyo | so you HAD to split it up somehow. So you can fix it, and maybe it is fixed now | |
| 14:25:53 | sean-k-mooney | admiyo: have you read https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html or partipated in any of the discussion that have been taking place for the last 5 years on this topic | |
| 14:26:18 | admiyo | I got so burnt out by chasing this that I had to step away from Keystone. | |
| 14:26:36 | admiyo | And I have popped in periodically. The bug was still assigned to me for a while. | |
| 14:27:01 | admiyo | And I think it is ok to say that it is fixed if you cannot have a admin scoped project token | |
| 14:27:07 | sean-k-mooney | admiyo: when we explained to operator that they would not be able to do openstack service list --all-tenant with the proposed implemetion they said hell no | |
| 14:27:26 | admiyo | And there was a solution to that | |
| 14:27:45 | admiyo | That was why we had implied roles. | |
| 14:27:55 | sean-k-mooney | we still have implied roels | |
| 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. | |