| I have provisioned a 3.11 cluster in RHPDS and playaround the EFK feature, and here are my findings: 1. In 3.11, the EFK stack is available by default. Fluentd will collect the outputs to stdout of all the pods and forward them to elasticsearch.
2. The EFK stack is secured by the oauth proxy and it does support multi-tenancy as well, but it only supports 2 types of users: admin user or app users. Admin users can see all the indies of all the namespaces, and the app users can see the indies of the namespaces that they have access to.
3. I logged in as a normal developer user1, and provisioned sync service and generated some audit logs. I can only see the kibana index for my own namespace. I created some queries, visualisations and dashboards, and saved them. I then logged in as a different developer user who also has access to the same namespace. This time I can still see the same index, but there are no saved queries, visualisations and dashboards.
4. From what I have gathered, it looks like the EFK stack did use the SearchGuard [1] plugin to implement the multi-tenant feature. However, it looks like they are only using the default configuration: each user has 2 default tenants: global or private. The global tenant allows to share save dashboards across all the users, while private tenant allows each user to have their own dashboards. The global tenant is not a good fit for our purpose: not all the users will need to access the sync service dashboards.
5. It is possible to add dashboards to a user programatically. However, this can only be done after the user login to the Kibana UI at least once. Because the Kibana UI is protected by the openshift oauth proxy, upon the first time login, the user will be asked to give permission to allow Kibana to access their user info on OpenShift. I am not sure if there is a way to perform the login programatically. But even if it's possible, I don't think we should do it. We also need to know the user's username to perform the operation of adding dashboards or queries to the user's kibana. From all this information, I don't think APB is a good fit to us. The reasons are: 1. There is nothing needs to be provisioned by us, really. The EFK stack will be available by default in 3.11, and if it's not available, we should not try to provision it as it is quite complicated to do. We also thought about creating a managed service broker for the EFK service, which doesn't really do anything, but just create a route in the project so that users will be able to see the kibana URL. But after chatting with Craig Brookes, he thinks this doesn't add too much value, it is more of a hack rather than a solution. Plus we are going to show the URL in the sync UI (we should be able to get the url of the logging service somehow by looking at how the `View Archive` button is generated).
2. There is also no binging required. All the logs to stdout are automatically forwarded to EFK. So if we want to automate the setup of the default dashboards, we should look at creating an operator for that. However, given that users will have to login to the Kibana at least once, it's is reasonable if we provide the template json files through the sync UI, and give user instructions on how to import them to Kibana. I think this should be our first step, and could be enough to meet the requirements for tech preview. If we have more time, and if there are some better ways to automate this, we can look at implement the operator to automate the process. This should be the next step. [1] https://docs.search-guard.com/v5/kibana-multi-tenancy |
