Add PR checks for wazuh-kubernetes repository

[teddytpc1]

Description

As part of the DevOps overhaul objective, we need to add PR checks using the Allocator module (if applies). The checks should test the deployments using Minikube and EKS.

Tasks

• Add two workflows for Minikube and EKS. A new AMI with Minikube installed and configured might be needed.
• Test them
• Provide evidence they are working properly

Examples/references

The following workflows use the Allocator, we should replicate its use (if applies):

• https://github.com/wazuh/wazuh-installation-assistant/blob/main/.github/workflows/Test_installation_assistant.yml
• https://github.com/wazuh/wazuh-installation-assistant/blob/main/.github/workflows/Test_installation_assistant_distributed.yml

[vcerenu]

I begin the analysis of the implementation of the tests.
I was reviewing the creation of a new role for the creation of the EKS cluster to carry out the implementation, performing a test with a user with the same permissions that the role will have and performing the deployment of a cluster in the us-east-1 region.
Later I began with the creation of the workflow, which I am in the stage of defining which inputs are necessary for the test.

[vcerenu]

A workflow was created, which contains 2 jobs:

• EKS deployment
• Minikube deployment

These jobs prepare the environment to deploy each of the options.

In the EKS job, eksctl is used to create the cluster in AWS, the iamserviceaccount is created for the addon permissions to create EBSs and the installation of the addon in the cluster. The Wazuh stack is then deployed and at the end the eks cluster is deleted.
In the local deployment job, Minikube is installed on the Github runner and the Wazuh stack is deployed, previously modifying some parameters so that the deployment in Minikube is satisfactory.

It is necessary to review the necessary AWS permissions, since there are errors in the creation of the iamserviceaccount and then set up some tests to verify the correct deployment of the stacks.

[vcerenu]

I have been performing an analysis to obtain the logs of each of the components deployed in each of the stacks, which have different ways of accessing the deployed pods and how to obtain the connection data.

[vcerenu]

I have managed to deploy both environments, both in EKS and locally with Minikube, correctly. Within the execution job in EKS I added all the steps for the creation of the cluster and its subsequent elimination, in order not to leave major expenses in AWS. It is required to continue with the elimination of the volumes associated with the dynamic allocation of PVCs during the deployment of Wazuh.
Some tests were added to verify the correct deployment, in which some errors have been generated that need to be corrected.
Several test workflows have been executed to see how the tests have progressed.

[vcerenu]

I was investigating an error generated when consulting the Wazuh manager API

Run services="`curl -k -s -X GET "https://192.168.49.2:31614/manager/status?pretty=true" -H "Authorization: *** -s -u wazuh-wui:MyS3cr37P450r. *- -k -X GET "https://192.168.49.2:31614/security/user/authenticate?raw=true")" | jq -r .data.affected_items | grep running | wc -l`"
Wazuh indexer nodes:
 % Total % Received % Xferd Average Speed ​​Time Time Time Current
 Dload Upload Total Spent Left Speed

 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (1) Received HTTP/ 0.9 when not allowed
Error: Process completed with exit code 1.

The error was generated by the type of portforward performed in Minikube against the Wazuh manager Load Balancer.
I continue with the investigation regarding this error.

[vcerenu]

Update

It was possible to execute both the deployment test in EKS and the local deployment in the workflow
https://github.com/wazuh/wazuh-kubernetes/actions/runs/11822832575/job/32940753106