Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-10-31
16:28:20 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:28:28 bauzas ah yeah
16:28:35 elodilles and that's all :)
16:28:36 bauzas #topic Open discussion
16:28:45 bauzas gmann: wants to talk the topic you had ?
16:29:04 bauzas (gmann) RBAC: service role usage for Nova to talk to other services
16:29:05 gmann oh, which one?
16:29:12 gmann k
16:29:21 bauzas #link https://etherpad.opendev.org/p/nova-caracal-ptg#L871
16:30:08 gmann there are some notes there on the thing I wanted to discuss. we discussed it long back on how to proceed on service role
16:30:59 gmann which was 1. make policy default to service role only 2. accept service token in API 3. use nova generated admin context whereever it is required (for example getting servers in server external event API)
16:32:21 gmann but when I was doing it for swap volume API (which is lot o call from cinder to nova and nova to cinder), it end up that we need to use admin context for almost all the operations in this API. so it looks like we are going to make policy default to service role only and use service token to just check it is called from service not form user
16:32:40 gmann BUT use admin context for all actual operations
16:33:25 gmann this is something we discussed on Monday PTG but left nova specific discussion for later
16:33:47 gmann sean-k-mooney: has idea of passing user as well service token in service-only-APIs whihc is also listed in etherpad
16:34:50 sean-k-mooney right so when swap volume is called by cinder on behalf of user sean
16:34:58 gmann sean-k-mooney: if I understand your idea correct you want to do it same way we do currently right? passing service token as header in user token - https://github.com/openstack/nova/blob/b37d50fecc92c17c3b30e41f6ad8869e1f9bd2ef/nova/service_auth.py#L33
16:35:02 sean-k-mooney we shoudl be recordign that as coming form sean not cinder
16:35:45 sean-k-mooney gmann: yes it would be the presence fo a service token(with service role) in the header and any other token that would make it a service request
16:36:20 bauzas I'm a bit confused here
16:36:29 bauzas probably because I'm not an expert
16:36:33 gmann and that service token can be used to know if request is from service or not. if not then 403.
16:36:34 sean-k-mooney the user token is so we knwo on behlaf of which (user/project) the request was made
16:36:38 dansmith authorized by the service token but limited in scope (and recorded in audit) as the user
16:36:43 bauzas but I thought we were already providing both tokens ?
16:36:49 sean-k-mooney dansmith: exactly
16:37:13 gmann bauzas: we do but we do not check service token is must provided or not
16:37:23 sean-k-mooney bauzas: we are but some of these api are admin only today
16:37:26 bauzas okay, so that's a question server-side ?
16:37:27 gmann dansmith: sean-k-mooney so if no service token presence in those servcei-ony API then 403 right?
16:37:37 sean-k-mooney so the user token in that case is an admin token created form the config for the cinder user
16:37:46 sean-k-mooney gmann: yes
16:37:55 gmann cool.
16:37:58 sean-k-mooney 403 if service token is not passed
16:38:13 sean-k-mooney when callling swap volume or external events api for example
16:38:33 gmann yeah, we do not check that currently so it will achieve the same thing we wanted via policy default
16:38:36 sean-k-mooney for compatiblity we are currently supproting "service or admin" right
16:39:00 gmann it is admin only no service but that is going to be "service or admin"
16:39:01 sean-k-mooney meaning we woudl allow it if the user token was an admin token or if there was an addtional service token
16:39:16 gmann I mean "<whatever default currently admin or member + service role>"
16:40:14 sean-k-mooney so on the devstack side oen thing we shoudl do eventually is have a way to make sure the service_user does nto have admin in its role assignemtns
16:40:43 gmann I am thinking 1. fetch the service token form header 2. use that as target in oslo policy so that if no service role then it fail
16:41:10 sean-k-mooney for the service_only policy rihgt
16:41:15 gmann yes
16:41:21 sean-k-mooney for the service_or_admin we would need to fall back
16:41:26 gmann and policy default will be "admin or service"
16:41:59 sean-k-mooney right so that woudl check the service token if present or user token if not in that case
16:42:09 gmann or we can use "role:service" only in policy default also if we are going to use service token only for policy enforcement
16:42:11 sean-k-mooney is that somethign we can do today?
16:42:49 gmann tricky part is if anyone want to override the policy to non-service role also then it will be little complicated to allow those
16:42:54 dansmith yeah it kinda needs policy to check the service token, but the rest of cinder should use user token for scoping and audit logging
16:43:05 gmann maybe we need to pass both user and service token in oslo.policy
16:43:13 gmann dansmith: yeah
16:43:17 sean-k-mooney gmann: i think ^ is likely needed yes
16:43:29 sean-k-mooney both tokens and likely an extention to policy.json
16:43:37 gmann we need to make sure overriden policy keep working and it is configurable
16:43:37 dansmith gmann: can we have a way to say "apply this rule to service token"? then that can be the default and you could reset it to user if you prefer
16:43:41 sean-k-mooney so that we can express the requireemnt for for roles on each one
16:44:45 sean-k-mooney dansmith: ya i think wee need to be able to say somethign like "service_token_required_role=service or default_token_required_role=admin"
16:44:46 gmann dansmith: need to check if such fallback there in oslo.policy otherwise we can combine the both token in the targets to oslo.policy
16:46:29 gmann if we keep rule as 'role:service' only and passing both token (service and user) as targets to oslo.policy then it will work for our default (service only) as well as for any overridden rule too
16:47:04 sean-k-mooney gmann: that would allow a user that was given the service role to make a request with a single token
16:47:10 sean-k-mooney im not sure we want to allow that
16:47:12 gmann if we will use rule default as 'admin or service' then it will be comlicated to disallow only admin to pass the checks
16:47:40 sean-k-mooney i wanted to disallow the user_token to pass if it had the service role without also having a service token
16:47:47 gmann sean-k-mooney: but admin-or-service also allow such user having service role
16:47:50 sean-k-mooney perhaps that shoudl be allowed but im not convinece it shoudl
16:48:06 sean-k-mooney gmann: it woudl allow it because of the admin role
16:48:11 sean-k-mooney not because of the service role
16:48:13 dansmith well, I was thinking more like "this rule applies to the user token" or "this rule applies to the service token" and default to user, which is current behavior
16:49:04 gmann dansmith: ohk. and change default behavior to check rule for service token right?
16:49:11 dansmith so if you set the swap_volume rule to service token, then it will use the service token to decide if a request can or cannot run that operation instead of the user token (and require it be present of course)
16:49:23 gmann so service token check first if it pass then go for user token check otherwise fail early aonly
16:49:30 dansmith gmann: change default just for swap_volume you mean right?
16:49:52 sean-k-mooney swap_volume and i think external events are the two api this would apply too for now
16:49:59 dansmith and detach
16:50:03 gmann dansmith: I mean first we check service token rule and then user token rule
16:50:18 dansmith gmann: no, not what I was thinking
16:50:26 gmann humm
16:50:33 sean-k-mooney dansmith: well volume detach instnace action will not need this change
16:50:36 dansmith for swap_volume, we only care about the service_token for *authorization* so policy only needs to check that
16:51:03 dansmith cinder still uses the user_token for querying the DB and logging, but the ability to do the operation is authorized by service token
16:51:16 dansmith create_volume would still be authorized by user token only
16:51:23 gmann and default policy will be "role:service" right?
16:51:43 sean-k-mooney "roleLservice token:service"
16:51:54 dansmith sean-k-mooney: well, detach is currently checking the service token explicitly right? so if we extend the syntax to allow saying "this operation is authorized by the service token" we'd want that rule to work the same way Itink
16:52:12 dansmith okay I think we're getting confused here
16:52:17 sean-k-mooney where "role:service" woudl imply "role:service token:user" or current behavior
16:52:19 dansmith perhaps we should take this outside the nova meeting
16:52:27 sean-k-mooney dansmith: detach on the cinder api is
16:52:34 bauzas yeah, I think we need some gmeet
16:52:46 gmann yeah, maybe let's have a call
16:53:09 bauzas I can organize it, but I won't be able to attend it I guess
16:53:14 sean-k-mooney dansmith: ya so i think you and i are on the same page
16:53:46 sean-k-mooney we need a syntax in the role to say this is authorised by the service token
16:53:52 dansmith yeah
16:53:52 gmann let me scheudle one after TC meeting today (which is after 3 hr from now). sean-k-mooney is that late for you?
16:54:03 dansmith gmann: can we make it a different day//
16:54:09 dansmith today is already busy and full of meetings for me
16:54:09 gmann sure

Earlier   Later