Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completely Whitelabeling Wazuh #178

Closed
AtanasBobev opened this issue May 13, 2024 · 3 comments
Closed

Completely Whitelabeling Wazuh #178

AtanasBobev opened this issue May 13, 2024 · 3 comments

Comments

@AtanasBobev
Copy link

Hey, everyone. I am new to Wazuh so any help would be appreciated.

Is your feature request related to a problem? Please describe.

There is an increasing demand for whitelabling Wazuh. Companies need a security solution, while developers are tasked with making the dashboards look company-like(whitelabeling). When people ask about customizations on forums, they are referred to the opendashboard and wazuh custom branding. Unfortunately, these customizations are not sufficient. Let me provide an example. Here is a sample open dashboard configuration yam I am working on:
image

Now, here is the Wazuh-specific configurations(I am aware they also exist in a yaml file) The Wazuh config options are 1:1 mapped to the UI settings. Here is a sample that is consistent with the data above in terms of text and images:
image

The issue is that the whitelabeling is oddly unfinished. Some part of the UI can be changed, while others can't. This diminishes most if not all benefit of such modifications. Here are a few examples:

  1. Changing the title to say CRYPTANK rather than Wazuh - CRYPTANK
image
  1. Renaming side navigation from Wazuh to CRYPTANK
image
  1. In Management > Rules you can see often the name Wazuh appearing
image
  1. Analogous to Management > Status
image
  1. Management > Logs
image

Describe the solution you'd like

It would be highly beneficial for a complete whitelabeling option. I am not a Wazuh developer, but from a full-stack perspective, it shouldn't be that hard to put strings into translation files for the text and everything else in a .json/yaml file. At the very least it would be make the project more organized. It is good that there are options for whitelabeling but they cannot really be used if the whole process cannot be completed, i.e., this should be a very binary feature, it cannot be done only partly.

Describe alternatives you've considered

I am linking all the resources I consulted before writing here. I admit that there could be some resource that answers my request, but I am yet to find it.

wazuh/wazuh-dashboard-plugins#4392
wazuh/wazuh-dashboard-plugins#4269
wazuh/wazuh#18571
https://opensearch.org/docs/2.1/dashboards/branding/
https://opensearch.org/docs/1.2/dashboards/branding/
https://forum.opensearch.org/t/customizing-the-kibana-login-page/3697

@AlexRuiz7
Copy link
Member

Hello @AtanasBobev

First, I'd like to thank you for getting in touch with us and provide this valuable and constructive feedback. It's always good to see how the users picture the product.

We are aware that the current white-labeling capabilities are limited, and there are a few reasons for that. The UI white-labeling is a recent project which is currently in progress and is being worked on iterations. The 1st picture of the UI you posted here is the result of the first iteration, which is already released and completed. Check wazuh/wazuh-dashboard-plugins#4392 for details. However, the Custom Branding project is not yet complete, and there is a new iteration on the roadmap:

On the other hand, there are some limitations that we have not been able to overcome or that are too expensive in terms of development. The remaining screenshots fall under this category, I fear. Let me explain to you why:

  1. Changing the tab title - If I recall correctly, it was decided to keep Wazuh as a prefix there. So in this case, that's how we wanted it to be.
  2. Side navigation renaming - The plugin's ID in the Manifest (opensearch_dashboards.json) file defines the plugin's name and https://opensearch.org/blog/dashboards-plugins-intro/
    , such as navigation or API endpoints prefix. This value is readonly and can only be set in the manifest file, so changing it during runtime is not possible as far as we know. You can use your own values in there if you want by manually editing the file, but do it at your own risk, as there is no guarantee things will keep working as they should.
  3. These are the names of the files present in the wazuh-manager, and their metadata. These are retrieved using the manager's HTTP API. For that to be customizable, the xml files would need to be changed. That's out of the scope of the Custom Branding project for the UI. This would also cause problems during upgrades, causing duplicated rule files under different names. That change breaks backwards compatibility.
  4. These are the names of the wazuh-daeamons in the manager: the processes names. These can't be custom unless we put a huge amount of effort into it. Again, it would be a huge breaking change.
  5. Same as argument as for the previous points.

Finally, it's about priorities. The next major Wazuh 5.0 is around the corner, and it will greatly change the way Wazuh works, so making these changes now would simply be a waste of time and effort, due to the short life-span they would have.

We do note these feature requests and take them into account.

Regards,
Alex

@AtanasBobev
Copy link
Author

Hey @AlexRuiz7,
Thank you for your detailed answer!

I have a few remaining questions:

  1. How cross-compatible are configuration file changes across project versions? You mentioned that version 5.0 is going to make all whitelabeling efforts obsolete. Does this version change configuration files, or how would future versions not be compatible with previous customizations? If only all/only custom modifications like the ones I am searching for are bound to be erased on each subsequent version, this is good for me to know.
  2. When do you expect roughly to have the Wazuh 5.0 release? I know that these questions cannot have extremely specific answers, but it would give me an idea of what to relay to other members of our team, and what decisions to make.
  3. Does Wazuh dashboard provide an option for custom js/css files? If there is such an option, I can just write UI changes in JS and run them rather than relying on configurations, e.g., the same way theming extensions work.

Warm regards,
Atanas

@AlexRuiz7
Copy link
Member

Hi again @AtanasBobev

  1. Currently, all configuration files are compatible within 4.x versions, as the project follows OpenSearch Dashboards 2.x. Let me however make it clear that 5.0 won't make all white-labeling efforts obsolete, but certainly many many things will change, and we are full-steam towards 5.0. There are many new things coming, and many others will cease to exist, so for us, it was not worth working on making Wazuh customizable to the bone. However, we expect the UI to be based on 2.x version of OpenSearch Dashboards still, as there is no estimate release date for OpenSearch Dashboards 3.0. I would not put much effort on customizing Wazuh, other but the UI.
  2. We expect to have a first Alpha version for the end of the year (Q4 2024). I'd estimate about 2 months of refinement and testing, so maybe it could be released maybe in late Q1 2025 or early Q2 2025, most likely. There will be at least (and hopefully no more) 2 minor 4.x versions before that: 4.8.0 and 4.9.0.
  3. There is no such option as far as I know. Might be worth asking the OpenSearch Dashboards devs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants