The Security serverless roles in Kibana are defined in multiple places using different formats. Causing pain and confusion when they need to be updated.
In Kibana these roles are used for testing only. So every time we update the project-controller definition for production projects (link), there should be a related PR on the Kibana side to make tests executions consistent with what real instances are configured with.
To do that, we are currently defining the roles in multiple places:
So, every time we need to update something in Security roles, we need to find all these definition files and apply the change individually in each of those formats.
Currently, probably caused by this complexity, we don't have the same definition in all those files and the project-controller yml, meaning we are not testing the right role configuration in Kibana. That should also be fixed.
Ideal scenario
Have only one source of truth in Kibana, using the same yaml format. So, we can take the Security roles.yml file from project-controller and paste it to kibana repo directly. And everything works in Kibana reading the role definitions from that one file.
The same approach could be applied to Observability and ES3 roles, if any.
Summary
The Security serverless roles in Kibana are defined in multiple places using different formats. Causing pain and confusion when they need to be updated.
In Kibana these roles are used for testing only. So every time we update the project-controller definition for production projects (link), there should be a related PR on the Kibana side to make tests executions consistent with what real instances are configured with.
To do that, we are currently defining the roles in multiple places:
So, every time we need to update something in Security roles, we need to find all these definition files and apply the change individually in each of those formats.
Currently, probably caused by this complexity, we don't have the same definition in all those files and the project-controller yml, meaning we are not testing the right role configuration in Kibana. That should also be fixed.
Ideal scenario
Have only one source of truth in Kibana, using the same yaml format. So, we can take the Security
roles.yml
file fromproject-controller
and paste it tokibana
repo directly. And everything works in Kibana reading the role definitions from that one file. The same approach could be applied to Observability and ES3 roles, if any.