Fixes #23856: Impact of RBAC node filtering on compliance #5268
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://issues.rudder.io/issues/23856
So this PR brings several things:
QueryContext
QueryContext
are provided in APIauthzToken
parameter, and so we are really able to start porting APIs.Where is the compliance computation update to handle node tenants?
Well, there is none, because we did the things correctly: compliance computation takes a list of nodes and everything is node-centric. So we are just passing the correct list based on the user tenant, and most of the changes are just about "correctly weaving from web context to compliance computation the
QueryContext
to be able to have the list of node based on tenants".The main change is in
RuleApplicationStatusService.isApplied
andRuleValService.buildRuleVal
and inComplianceAPIService
(reportingService.findDirectiveNodeStatusReports
) that now uses the restricted list of nodes.Evolving user authz availability in requests
That PR (finally) allows to have the user
node permissions
correctly threaded in all request contexts, be them in UI or in API.It needed mainly two things:
CurrentUser
so that we correctly set its value from spring security result in all context (normal session UI, comet/async case, stateless API requests)authzToken
in API: in place of just getting theactor
, it now holds a fullQueryContext
with alsoNodeSecurityContext
. The actual change is trivial and happens in webapp/sources/rudder/rudder-rest/src/main/scala/com/normation/rudder/rest/ApiAuthorization.scala: we already had the user at end with correct info, so just use them.Most of the remaining changes are boring declaration of
implicit val qc: QueryContext = authzToken.qc
in all API that needs them.Using
MapView
in more placesOur
CoreNodeFactRepository#getAll
was changed to useMapView
in place of a newMap
or something else in a previous commit to avoid a too big refactoring and help with performance.In that PR, we see that is seems to work very well: we have a lot of cases where we were filtering on
nodeInfoService.getAll
result to just map values to know the node'sisPolicyServer
orpolicyMode
.By having the
MapView
, we avoid a lot of intermediary copies (which were not really needed).There was also a lot of places where
MapView
was used so we are just removing more collection creation.This is a rather impacting change, it touches a lot of place, but it is rather trivial : now that Scala clearly differentiate between
Map
andMapView
, the compiler tells us where we need to concretize the view.Switching from NodeInfoService to CoreNodeFact
This is rather easy a normalized. CoreNodeFact is a super-set of NodeInfo, so we don't miss any data.
At several places, I was able to reduce the refactoring need by relaxing the parameter: we were asking for
Map[NodeId, NodeInfo]
but really using onlynodeInfo.isPolicyServer
for example. I think it used to be done like that to avoid more collection duplication/transformation.With the previous change about
MapView
, I was able to passMapView[NodeId, Boolean]
without new collection copy, and without the need to switch fromNodeInfo
toCoreNodeFact
(but yes, I had to switch fromNodeInfo
toBoolean
;) )