Remote Cluster Configuration for Trivy-Dojo-Report-Operator

[tidusete]

Description

This MR introduces the following changes to the trivy-dojo-report-operator application:

1. Added support for remote cluster configuration using a Kubernetes configuration (kubeconfig) file.
2. Implemented conditional RBAC creation based on the presence of a flag.
3. Updated the login function in the handlers.py file to handle the kubeconfig scenario.

Changes

1. charts/templates/deployment.yaml:

   • Added a new environment variable KUBECONFIG with the value of the path of the mounted kubeconfig file.
   • Added a new volume mount and volume to handle the kubeconfig file, if provided.
   • Added a conditional check for the createRBAC flag to set the service account name.

2. charts/templates/rbac.yaml:

   • Added a conditional check for the createRBAC flag to create the service account, cluster role, and cluster role binding.

3. charts/templates/secret.yaml:

   • Added a new key-value pair to store the remote cluster kubeconfig, if provided.

4. charts/values.yaml:

   • Added a new field remoteClusterKubeconfig to store the base64-encoded remote cluster kubeconfig.
   • Added a new field createRBAC to control the creation of RBAC resources.

5. deploy/trivy-dojo-report-operator.yaml:

   • Added a new volume mount and volume to handle the kubeconfig file, if provided.

6. src/handlers.py:

   • Updated the login_fn function to handle the kubeconfig scenario.

7. src/settings.py:

   • Added a new environment variable KUBECONFIG to store the path to the kubeconfig file.

Rationale

The primary goal of these changes is to provide the flexibility to fetch vulnerabilities from a remote Kubernetes cluster, in addition to the default behavior of fetching them from the same cluster where the operator is running.

If the remoteClusterKubeconfig value is provided, the operator will use the kubeconfig file to authenticate and interact with the remote cluster. In this case, there is no need to create RBAC resources, as the remote cluster's RBAC configuration will be used.

If the remoteClusterKubeconfig value is not provided, the operator will continue to use the default behavior of fetching vulnerabilities from the same cluster where it is running, and the RBAC resources will be created as before.

The changes to the handlers.py file ensure that the login process handles both the kubeconfig scenario and the default scenario, maintaining backward compatibility.

[tidusete]

Can you check it @rndmh3ro and @szEvEz whenever you have time? Thank you so much

[szEvEz]

Hi @tidusete,

thank you for your contribution and your thorough description.
I will try to find some time in the next couple of days to review your request.

As this is a bigger change, also on the general design of this operator, we need to put some more thought into that.

Currently what we were doing, was the following:

• We had one central DefectDojo Instance
• Per environment (cluster), we had one trivy-dojo-report-operator deployed, which was sending this information to the central instance

We need to think about where we wanna head with this solution. In the end, we also could support multiple ways/methods on doing that.

@rndmh3ro maybe you can add your 2 cents here as well (design wise)