Add a user in the docker file
What are we trying to achieve?
We should run the trivy-k8s-wrapper binary with a new user named gitlab
.
The gitlab
user should not be root but it should be able to write in the /app/
dir because trivy-k8s-wrapper application writes the trivy report in a file named result.json
Why are we doing this?
Trying to resolve https://gitlab.com/gitlab-org/security-products/analyzers/trivy-k8s-wrapper/-/security/vulnerabilities/100247859
What are the relevant issue numbers?
Add a user in the trivy-k8s-wrapper Dockerfile (gitlab-org/gitlab#451012 - closed)
How to test
There are two ways to test this change. The first approach is not a complete test.
Testing locally
After building the image locally we can sh into it in order to check if the right directories have the right permissions. It also makes sense to make sure that you can create and write a file.
For example
docker run --rm -it trivy-k8s-wrapper:exp2 sh
/ $ cd /app/
/app $ ls -l
total 75148
-rwxr-xr-x 1 gitlab gitlab 76946676 Mar 4 09:25 trivyK8Swrapper
/app $ whoami
gitlab
/app $ cat /etc/group | grep gitlab
gitlab:x:1001:gitlab
/app $ echo 'This is a test' > test.txt
/app $ ls -l
total 75152
-rw-r--r-- 1 gitlab gitlab 15 Mar 5 11:26 test.txt
-rwxr-xr-x 1 gitlab gitlab 76946676 Mar 4 09:25 trivyK8Swrapper
Testing against the Gitlab agent
To really test the docker image we need to test against the Gitlab agent.
Follow these steps to test your change:
-
Make the desired changes in the
Dockerfile
. -
Add a number after the image name that will be built by the
build
job. This is required to make sure that you are running the correct docker image and not a cached version. Optionally you can have your test log statement for further proof. -
Push your commit and wait until the
build branch
job is complete -
If you don't have the gitlab-agent project locally you will need to clone it.
-
In order to test you need a test project for which you can connect your K8S cluster. Connecting the K8S cluster to a project can be found in the official documentation.
-
For your test project ensure that you have a valid configuration in the right path. For example
.gitlab/agents/myDevCluster/config.yaml
containing a valid configuration for OCS:container_scanning: cadence: '35 * * * *' vulnerability_report: namespaces: - test resource_requirements: requests: cpu: '200m' memory: 300Mi limits: cpu: '800m' memory: 3000Mi
-
While you are registering your K8S cluster in your test project you will get a token. Store this token in a file somewhere in a secure location. At the same time let the gitlab-agent to get installed on your cluster. This is required since the helm chart installing the gitlab-agent will also install other K8S objects that need to exist in your cluster in order to run the gitlab-agent. After a succesfull installation you can delete the K8S
deployment
of the gitlab-agent on your cluster since we will run it in debug mode. -
Go to the gitlab-agent project on your local filesystem. You can run it in debug mode in VScode studio by using the following configuration:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "agentk",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/cmd/agentk/main.go",
"cwd": "${workspaceFolder}",
"args": ["--kas-address=wss://kas.gitlab.com", "--token-file=/path/to/your/token/file"],
"env": {
"POD_NAMESPACE": "gitlab-agent",
"POD_NAME": "gitlab-agent",
"OCS_SERVICE_ACCOUNT_NAME": "NAME_OF_YOUR_SA",
"OCS_ENABLED": "true",
}
},
]
}
9. Edit the trivy-k8s-wrapper image to be used by the gitlab-agent to your local build.
10. Now in order to trigger OCS you need to change the config.yaml in you test project. You can change the cronjob to run in one minute. Once the OCS scanning pod (trivy-k8s-wrapper) is initiated you can look at the logs of the pod to see what happens.