You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Korifi levereges RBAC to implement authorization (e. what apps are visible to a certain user). Since Korifi is currently interacting directly with RoleBinding this is currently fix.
If would be great to give the option to install Korifi without the use of RBAC. The authorization would not work out of the box, but has to be provided differently, similar to extenting Korifi via AppWorkload or BuildWorkload.
This has at least 2 aspects:
Instead of creating RoleBinding directly in the api, Korifi could create a CFRole object. Another (optional) controller would then watch those CFRole objects and creates the RoleBinding needed.
For accessing any cf objects (e. apps, processes, ...), this could be done by having a different sets of repositories (e.g. app_repository -> rbac/app_repository and noauth/app_reposiory).
This would improve the extensibility and wouldn't change any of the default behaviour.
Thoughts?
The text was updated successfully, but these errors were encountered:
Description
Korifi levereges RBAC to implement authorization (e. what apps are visible to a certain user). Since Korifi is currently interacting directly with
RoleBinding
this is currently fix.If would be great to give the option to install Korifi without the use of RBAC. The authorization would not work out of the box, but has to be provided differently, similar to extenting Korifi via
AppWorkload
orBuildWorkload
.This has at least 2 aspects:
Instead of creating
RoleBinding
directly in theapi
, Korifi could create aCFRole
object. Another (optional) controller would then watch thoseCFRole
objects and creates theRoleBinding
needed.For accessing any cf objects (e. apps, processes, ...), this could be done by having a different sets of repositories (e.g.
app_repository
->rbac/app_repository
andnoauth/app_reposiory
).This would improve the extensibility and wouldn't change any of the default behaviour.
Thoughts?
The text was updated successfully, but these errors were encountered: