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:

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

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

2. Setup a `k3d` cluster

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

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

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

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

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

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

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

Edited Apr 13, 2023 by Shao Ming Tan

Switch from starboard operator to Trivy k8s