Skip to content

Add a user in the docker file

Nick Ilieskou requested to merge add_user_to_dockerfile into main

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:

  1. Make the desired changes in the Dockerfile.

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

  3. Push your commit and wait until the build branch job is complete

  4. If you don't have the gitlab-agent project locally you will need to clone it.

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

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

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

Edited by Nick Ilieskou

Merge request reports