search

telekom-mms / trivy-dojo-report-operator

This Kubernetes operator listens for vulnerability reports generated by the Trivy Operator and forwards them to Defect Dojo for further analysis and tracking.
GNU General Public License v3.0
13 stars 15 forks source link

Remote Cluster Configuration for Trivy-Dojo-Report-Operator #84

Open tidusete opened 2 weeks ago

tidusete commented 2 weeks ago

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 commented 6 days ago

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

szEvEz commented 2 days ago

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 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)