Posted	Nick	Remark
#openstack-nova - 2024-10-16
21:39:28	sean-k-mooney[m]	yep
21:39:38	admiyo	but you automatically have access to that if you have the role assignment on the domain-as-aproject
21:39:43	admiyo	and yes, domains were a mistake
21:40:10	admiyo	OK, let me look at the keystone role assignemnt api. that is the real question
21:40:10	sean-k-mooney[m]	well domains are kind for for the VPC/reseller usecse
21:40:23	sean-k-mooney[m]	but that is not very common
21:40:51	admiyo	NO, domains should have just been nested proejcts (tennants) on the proejct side, and IdPs on the user side
21:41:08	admiyo	domains as groupings of projects was a mistake
21:41:22	sean-k-mooney[m]	probably
21:41:40	admiyo	but they predated Federated Identity. But IdP is the logical grouping for users, not domains
21:41:41	sean-k-mooney[m]	im not really aware of domains being used by any of our custoemrs
21:41:55	sean-k-mooney[m]	it would be a good question for the openstack user survay
21:41:56	admiyo	this is all 20.20 hindsight
21:42:42	admiyo	Although I do remember rendering insufficient resistenace to domains, thinking they should be projects. And I do rmeember being to person reminding people they were projects, not tennants. So I am very much to blame
21:44:12	sean-k-mooney[m]	there is one feature that i have always wanted in keystone since your here. i wish there was a way to get a token form an sshkey like i want to just use the openstack client but assocating a public key with my user and using my private key to sign in
21:44:48	sean-k-mooney[m]	the other feature is more a nova one but people have asked use to provide a token to vms liek k8s does
21:45:34	sean-k-mooney[m]	i.e have a way via the metadata api to provide a project scoped token or proably applciation credital to the vm
21:45:57	admiyo	And I think I just spotted how things are broken. I am working backwards here. But there is no specific check in the keystone role assignment API that does anything like say "you can only assign a role that you yourself have" which was one of the reasons for implied roles. And to do a role assignment for a project I need the role":
21:46:00	admiyo	"identity:create_grant": "(rule:admin_required) or ((role:admin and domain_id:%(target.user.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:admin and domain_id:%(target.user.domain_id)s and domain_id:%(target.domain.id)s) or (role:admin and domain_id:%(target.group.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:admin and domain_id:%(target.group.domain_id)s and domain_id:%(target.domain.id)
21:46:00	admiyo	s)) and (domain_id:%(target.role.domain_id)s or None:%(target.role.domain_id)s)"
21:46:05	sean-k-mooney[m]	usually people ask for that in JWT format
21:46:05	admiyo	Ugh...really.
21:46:27	admiyo	OK, I think I see what they are doing there.
21:46:43	admiyo	And I think it is broken by that first or
21:46:58	sean-k-mooney[m]	there is some form of delegation check for applciation credentials
21:47:15	admiyo	yeah, but it is skipped
21:47:49	sean-k-mooney[m]	it might be enforced outside the policy layer
21:47:53	admiyo	(rule:admin_required) means that anyone with an admin role can execute that policy
21:47:59	admiyo	none of the others will be checked
21:48:06	sean-k-mooney[m]	right
21:48:11	admiyo	#"admin_required": "role:admin or is_admin:1
21:48:22	sean-k-mooney[m]	but thats in line with how admin works in all other proejcts
21:48:37	sean-k-mooney[m]	* all other openstack services
21:49:00	sean-k-mooney[m]	admiyo: i will note that keystones docs still document what you want
21:49:11	sean-k-mooney[m]	but i dont think that has been true for a very very long time
21:49:32	sean-k-mooney[m]	admiyo: https://docs.openstack.org/keystone/latest/admin/service-api-protection.html#admin
21:49:37	admiyo	I just generated the policy file from the code
21:50:10	sean-k-mooney[m]	that is not consistent with the standard definition of admin
21:50:22	sean-k-mooney[m]	per the SRBAC comunity goal
21:50:56	sean-k-mooney[m]	the keystone doc imples it is scoped but that has never been the case as far as i was aware
21:51:13	sean-k-mooney[m]	so i think it documented the intent you had in 2015
21:51:23	admiyo	We are going to have to break the operators one way or another to fix this
21:51:26	sean-k-mooney[m]	but not what was implemnted
21:51:34	admiyo	EIther in their keystone workflows or in their Nova
21:52:04	sean-k-mooney[m]	perhaps but i dont think any deployemnt cna be using the workflow you are descibing
21:52:06	admiyo	I think it might be less painful to do it in Keystone, and it will at a minimum make those policy rules simpler
21:53:23	admiyo	OK let me talk it through with the Keystone folks. I think I can see a way forward. Bascially, if the policy enforcement for Keystone uses a role other than admin for performing the operation when you want it limited to a project, everything else will be ok
21:53:24	sean-k-mooney[m]	ya so it looks like the keytone doc was never updated after yoga
21:54:24	sean-k-mooney[m]	admiyo: jsut remember the defintion of the personas and role means were effectivly moved out of keystone with the goverance resolution
21:56:01	admiyo	Yeah, but they are effectively implemented there, which means if Keystone is wrong, everyone suffers
21:56:13	admiyo	and I think that is what I am seeing. At least according to the policy generate
21:56:17	admiyo	d on my system
21:57:35	admiyo	ADMIN_OR_DOMAIN_ADMIN = (
21:57:35	admiyo	'(' + base.RULE_ADMIN_REQUIRED + ') or '
21:57:35	admiyo	'(' + GRANTS_DOMAIN_ADMIN + ') and '
21:57:36	admiyo	'(' + DOMAIN_MATCHES_ROLE + ')'
21:57:36	admiyo	)
21:57:51	admiyo	yeah it is right there in the code. OK.
22:00:14	sean-k-mooney[m]	admiyo: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#legacy-admin-continues-to-work-as-it-is is why i marked the bug as wont fix by the way
22:01:19	sean-k-mooney[m]	we collectivly commited to not change admin going forward and instead add manager for more scoped privaldged access
22:01:47	sean-k-mooney[m]	which is pahse 3 which is where we are now
22:02:19	sean-k-mooney[m]	phase 2 and 3 are basiclaly happening in parallel
22:03:18	sean-k-mooney[m]	we already use the servie role in some cases but have not removed admin so they were admin_required and not they are admin_or_serivce for upgrade reasons
22:04:38	admiyo	sean-k-mooney[m], ok, so the only point you and I now disagree on is the status of the bug. You should make it "in progress" and not "wish list" because you have made changes to fix it. And if you do that, and fix it, I will grant a copy of the t shirt I had made up to both you and to whomever did the lionshare of the work for fixing it.
22:06:40	sean-k-mooney[m]	so the reason i set it as wont fix is we wont ever limit the scope of admin to a project or domain
22:07:00	sean-k-mooney[m]	so we wont fix the bug in the way it was stated in the deciption
22:07:37	sean-k-mooney[m]	we are fixing it by intoducing a new role for “scoped” admin
22:10:25	admiyo	OK. No T-shirt for you. But I can see your argument.
22:11:03	JayF	admiyo: you'd be surprised at the number of people who read the title/first lines of an issue, see "fix released" and assumed they got exactly what they wanted rather than whatever compromise item got fixed instead :)
22:11:17	admiyo	I suspect, however, that things are broken in other services. Admin needs to go away everywhere, and have special enforcement in Keystone
22:11:56	JayF	admiyo: are you an ironic user? Would be interested to see what you think about how we took on rbac
22:12:02	admiyo	JayF, I think you misspelled Jaded
22:12:17	admiyo	JayF, I have been an Ironic user in the past. I will take a look
22:12:42	JayF	I don't think we'd likely change anything, but I'm curious how it comes across to someone who has old openstack experience back when Ironic was an admin-only api
22:12:45	admiyo	But the short of it is that Ironic is almost all admin functions as defined by Nova. Which may or may not be how you view the world
22:12:51	JayF	not anymore :)
22:13:00	admiyo	Yeah, I am a big Bifrost fan
22:13:17	JayF	You can 100% use a project manager as your nova service user today, as long as the nodes being managed are node.owner=that_project
22:13:18	admiyo	https://adam.younglogic.com/2022/05/keystone-ldap-with-bifrost/
22:13:55	sean-k-mooney[m]	well not exactly its perfectly reasonable for ironic to be accessed with member or reader if a node has been assigned to a user/project
22:13:55	JayF	admiyo: authenticating ironic, which has a component called ipa, using freeipa, is just devious :D
22:14:10	admiyo	We had the name first
22:14:14	admiyo	and I worked on both
22:14:14	JayF	sean-k-mooney[m]: yeah, I think he's commenting on the old ironic world before we had a concept of non-admin
22:14:18	JayF	admiyo: beer had the name first
22:14:37	JayF	admiyo: Did I know you as another nickname? Or is my old man brain just being forgetful
22:14:42	admiyo	https://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
22:14:46	admiyo	ayoung
22:14:52	JayF	aha
22:15:41	sean-k-mooney[m]	admiyo: for what its worth you have also been able to use ironci via nova with just member for a decade or more
22:16:31	JayF	sean-k-mooney[m]: not a project-scoped member, but yes :)
22:16:58	admiyo	sean-k-mooney[m], the problem was (and I suspect still is) that other projects are using admin the same way that keystone was.
22:17:10	sean-k-mooney[m]	the real delta now is ironic nativly supprot assinging host to project/user adn partitioning the privlsaged info(ipmi creds) form the ablity to do things like power on/off a system
22:17:16	JayF	sean-k-mooney[m]: I <3 that our model allows a central ironic to have multiple novas talking to it that all are just isolated by rbac project. How many people use this arch? Hell if I know. But it's a green flag that it's possible :D
22:17:21	admiyo	i.e. you as the local admin, not a global one
22:17:39	admiyo	JayF, that was something I dreamt of in the past
22:17:41	JayF	sean-k-mooney[m]: yeah, that's default in devstack now too, it's really really nice to see all the redacted stuff :D
22:17:46	admiyo	very cool. and how it should be
22:18:14	JayF	admiyo: we basically support now, at provision time, we will assign the project that owns the instance on the node to "node.lessee", allowing that project minimal access (mainly reader) to that node
22:18:51	admiyo	"dear google, I want the actual git repo, not github, for openstack. Please at least return that in the second or third search result."

Earlier   Later