Switch from starboard operator to Trivy k8s

What does this MR do and why?

Starboard is deprecated and we need to move to trivy k8s. This MR contains the changes to switch from starboard to trivy k8s. Main Issue.

The main changes are:

1. Changed the scanJob.scan function to:
   1. Start a Trivy Pod using the Trivy container image ie aquasec/trivy:0.38.3
   2. Once the Trivy Pod completes the scan and it's Pod status changes to Succeeded. The code will retrieve the scan report from the pod's logs
2. Changed report.go to convert the trivy k8 report to the expected format that internal vulnerability API expects.

Pre-reading

This High-level architecture overview is useful in providing some context on how gitlab-agent works.

Screenshots or screen recordings

Demo of OCS vulnerability scan using Trivy K8s cli

How to set up and validate locally

1. Setup kas in GDK

1. Follow steps 1 to 7 of GitLab Agent Server (KAS) to setup kas in GDK.

2. Setup a k3d cluster

1. Follow steps 1 to 4 of Deploy the GitLab Agent (agentk) with k3d to setup a k3d cluster and loopback alias IP

3. Configure your gdk gitlab project to connect to the agent

1. Follow the steps in Create an agent configuration file.

   • This was the config.yaml that I used.

     config.yaml

     starboard:
         cadence: '30 * * * *'
         vulnerability_report:
             namespaces:
             - default
             - temp-namespace
     
     observability:
         logging:
             level: debug

2. Follow steps 1 to 5 in Register the agent with GitLab to obtain a token for gitlab-agent

4. Grant cluster-admin to the gitlab-agent service account

• Trivy k8s needs cluster-admin role binding to be able to get the workloads in the cluster.
• This is configured in the helm chart commands that the gitlab UI presented in step 3.2. However I could not find instructions to do this for local development.
• To grant cluster-admin role binding I referenced the values from base.yaml and clusterrolebinding.yaml which seems to be used to build the helm chart.
  • Running this will create:
    • A ServiceAccount called gitlab-agent
    • A Namespace called gitlab-agent
    • Grant cluster-admin to the gitlab-agent ServiceAccount

1. Copy the details below into a new file grant-role-binding.yaml and run

       kubectl apply <path_to_grant-role-binding.yaml>

   grant-role-binding.yaml

   apiVersion: v1
   kind: Namespace
   metadata:
     name: gitlab-agent # kpt-set: ${namespace}
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: gitlab-agent # kpt-set: ${serviceaccountname}
     namespace: gitlab-agent # kpt-set: ${namespace}
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: gitlab-agent-cluster-admin
   roleRef:
     name: cluster-admin
     kind: ClusterRole
     apiGroup: rbac.authorization.k8s.io
   subjects:
     - kind: ServiceAccount
       name: gitlab-agent # kpt-set: ${serviceaccountname}
       namespace: gitlab-agent # kpt-set: ${namespace}
   

5. Start agentk locally

1. Create a token.txt file in your gitlab-agent directory using the token obtained from step 3.
   • See Step 1 of Running kas and agentk locally for exact steps
2. To start the agent, you can follow step 5 of Running kas and agentk locally
   • Use POD_NAMESPACE=gitlab-agent instead

6. Start a pod in your cluster and trigger a scan

1. Start ubuntu

   kubectl create deployment ubuntu-deployment --image ubuntu:latest

   • This would create a deployment, replicaset and pod. The pod would fail because there's no long lived processes in ubuntu. However, this does not affect the Trivy scan and I found that this image reports a small amount of vulnerabilities(15) which is useful for testing.
2. In your gdk gitlab project where you created the agent configuration file, change the cron schedule to be 2 minutes from now.
   • This will give the agent time to pick up the new configuration(polled every 20seconds)

7. View vulnerabilities in gitlab dashboard

1. If everything goes as expected, you should see vulnerabilities created in your gdk gitlab project dashboard ie: Infrastructure > Kubernetes clusters > <your_agent> > Security