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:
- Changed the scanJob.scan function to:
-
Start a
Trivy Pod
using the Trivy container image ieaquasec/trivy:0.38.3
- Once the
Trivy Pod
completes the scan and it's Pod status changes toSucceeded
. The code will retrieve the scan report from the pod's logs
-
Start a
- 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
kas
in GDK
1. Setup - Follow steps 1 to 7 of GitLab Agent Server (KAS) to setup kas in GDK.
k3d
cluster
2. Setup a - 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
cluster-admin
to the gitlab-agent
service account
4. Grant - 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
calledgitlab-agent
- A
Namespace
calledgitlab-agent
- Grant
cluster-admin
to thegitlab-agent
ServiceAccount
- A
- Running this will create:
-
Copy the details below into a new file
grant-role-binding.yaml
and runkubectl 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}
agentk
locally
5. Start - 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
- Use
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 by Shao Ming Tan