Open Stack

On Tue, 2022-06-28 at 09:48 +0200, Christian Rohmann wrote:
> Hey Sean,
> 
> 
> On 06/05/2021 18:29, Sean Mooney wrote:
> > that woudl make sense give the externa event api is admin only and only inteed to be use by services
> > so the fix would be for cidner to use an admin credtial not the user one to send the event to nova.
> 
> Thanks, yes and that can just be achieved by configuring one which is 
> then used for such calls.
> 
> But instead of a fully privileged "admin" user there rather should exist 
> a proper RBAC role to only allow one service (cinder in this case) to do 
> what it required to function (e.g. send events to Nova) and not just 
> "everything for every other service". This first of all violates the 
> least privilege principle, but in an ecosystem that made up of 
> individual projects of varying security qualities and which are highly 
> distributed it's just a bad idea to give every component and their dog 
> the keys to the kindom.

that is what the service role is inteded to be as i mentioned before.
the admin user was what was agreed to use before.
the service user will not have admin permisisons it will only be used for service to service
comunication for api operations that need higher permision then a normal user but not full adming

the external event api is one such interface that even normal operators are not intented to ever call
its purly a service to service api.

just being facnk we are entirly aware that this violates the principal of least privlaage but you are
missign the context that indivigual servies are not ment to creat arbitary roles.
we are ment to use standard roles and the service role which will be intoduced in phase 2 of the rbac cross
project goal https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-2
is the standard role we agreed to use for that usecase.

in prior iterations of the secure rbac work prior to the reset in direction in yoga we had the concetp
of system scoped tokens being scoped to a specifc system 

so system=all vs system=compute vs system=networking
that was dropped as far as i can tell when we reset the direction

today we can create role and assign them to group or users directly

currently we have no way to model that a user shoudl have this role only on a speciifc service endpoint.
i think to adress your use case we need that abltiy to say the neutron user has the service role on the nova endpoint
but not on any other endpoint.

that will enable your reduction of pivaldages but it not currently planned in our 3 phased adoption fo secure rbac at this time.
> 
> There was a forum on exactly that issue at the Summit and how that is 
> one aspect of the RBAC , see the etherpad: 
> https://etherpad.opendev.org/p/deprivilization-of-service-accounts
yes im aware but jsut to be frack repating this without taking on bored the feedback i had previously given that
1 this si a know gap that we are intentially not adressing in the scope fo the current project goal
2 that the service role is planned to be create to adress marking an endpoint as admin when it does not need to be
is not helpful.

i was not in berlin and dont want to discurage you from expressing your opipion on the list and engagian with the
comunity to improve openstack securtiy.

the way to do that productivly is to get inovled with the secure rbac work and to either work with others to
develop the keystoen feature required to alow ues to assocate role grant to service endpoints or to come up with
another solution that can then be added too the cross project goal.

unless we do a hard pivort away form standardised roles approch and adopt oath/api-key style permissions model used
by github or games like eve onlien for decades where you cate a key tha thas sepcific permision on speicifc api endpoiing tna then use
that api key in to make requests i dotn see another way to adress this cleanly via the api.
https://docs.github.com/en/rest/overview/permissions-required-for-github-apps

to achive something like ^ in an openstack context we would need to develop oslo midelway or similar that coudl read the
policy.yaml file used by each service and expose the roles and access requriement for all api endpoint within the serve at a well know url.
e.g. nova.cloud.com/policy_rules
then keystone would have to aggreate that and allow you to create an applciation credital or similar that was delagated a subset or permissions
on the indivigual serce endpoint. you would then configure the service to use the applciation credideial instead. (note applications credential are
the closest thign we have to an api key or githubs application based permissions model bug they are ment to have roles deleaged to them not per api
end point permssiosn so its not a direct 1:1 mapping)

that would be a very differnt workflow form what we have today.

if you are willing to sign up to do some of the work then im sure you can help drive the direction of this since you seam interested.

in any case without creating per project roles today which is not somethign we wanted to do previosly we need a feature in keystone to do better
then just the service role. but with the service roles no service will need admin if we implemeent thigns correctly.
> 
> 
> Regards
> 
> 
> Christian
> 
>