kubescape / kubevuln

Kubevuln is an in-cluster component of the Kubescape security platform. It scans container images for vulnerabilities, using Grype as its engine.

Kubevuln

The Kubevuln component is an in-cluster component of the Kubescape security platform. It scans container images for vulnerabilities, using Grype as its engine.

Build Kubevuln

To build kubevuln with its dependencies run: make

Configuration

1. Load config file using the CONFIG environment variable

   export CONFIG=path/to/clusterData.json

   example/clusterData.json

   {
       "gatewayWebsocketURL": "127.0.0.1:8001",
       "gatewayRestURL": "127.0.0.1:8002",
       "kubevulnURL": "127.0.0.1:8080",
       "kubescapeURL": "127.0.0.1:8080",
       "eventReceiverRestURL": "https://report.armo.cloud",
       "eventReceiverWebsocketURL": "wss://report.armo.cloud",
       "rootGatewayURL": "wss://ens.euprod1.cyberarmorsoft.com/v1/waitfornotification",
       "accountID": "*********************",
       "clusterName": "******"
      }

2. Set the PORT environment variable to 8081 export PORT=8080

Environment Variables

Check out scanner/environmentvariables.go

VS code configuration samples

You can use the samples files below to setup your VS code environment for building and debugging purposes.

.vscode/launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Package",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program":  "${workspaceRoot}",
                 "env": {
                     "PORT": "8080",
                     "NAMESPACE": "kubescape",
                     "CONFIG": "${workspaceRoot}/.vscode/clusterData.json",
            },
            "args": [
                "-alsologtostderr", "-v=4", "2>&1"
            ]
        }
    ]
}

We configure the Kubevuln to listen to port 8080, and define the configuration in the clusterData.json file as mentioned above.

Changelog

Kubevuln changes are tracked on the release page

kubevuln's Issues

Security policy (docs)

Generation of VEX documents by the Kubescape relevancy engine

Overview

Kubescape calculates the relevancy of container image vulnerabilities by monitoring using eBPF the application behavior and produces a filtered list of vulnerabilities. Today the results are stored in the same format as the vulnerabilities, however the VEX seems to be a much better choice to store and publish this information. Kubescape needs to publish the filtered list of vulnerabilities in a VEX format.

Solution

In the current state, the Kubevuln is watching the filtered SBOM objects, every time a new object is created or updated a filtered SBOM is created by the node-agent with only those modules that were loaded into the memory.

When a new filtered SBOM is available, the Kubevuln translates the SBOM to vulnerability list using Grype to create a filtered vulnerability list.

In the same step when the filtered vulnerability is created, Kubevuln should generate a VEX object. The object contains statements that all these vulnerabilities are loaded into the memory therefore they're relevant. This object should be stored as an API objects another vulnerability related.

See more at here

cc: @craigbox @puerco

Security insights (docs)

Vulnerability scan fails to verify private registry TLS client certificate

Description

When kubevuln attempts to scan an image stored in our private registry, specifically Harbor, it reports the following error...

{
    "level": "error",
    "ts": "2024-02-05T12:01:16Z",
    "msg": "service error - ScanCVE",
    "error": "error creating SBOM: unable to load image: unable to use OciRegistry source: failed to get image descriptor from registry: Get \"https://harbor.dev.xxxx.xxxx.internal/v2/\": tls: failed to verify certificate: x509: certificate signed by unknown authority",
    "wlid": "wlid://cluster-kube-xxx-xxx-xxx/namespace-xxxx/deployment-xxxx",
    "imageSlug": "harbor.dev.xxxx.xxxx.internal-support-xxxx-latest-88c2a8",
    "imageTag": "harbor.dev.xxxx.xxxx.internal/support/xxxx:latest",
    "imageHash": "harbor.dev.xxxx.xxxx.internal/support/xxxx@sha256:2c197e390019ec47c8ec4aa795430dc3b0055bf7624efca6be826f94e788c2a8"
}

Environment

OS: Ubuntu 22.04.3 LTS
Version: kubevuln v0.3.1

Steps To Reproduce

1. Deploy kubescape-operator Helm chart v1.18.1 (kubescape v3.0.3)
2. Scan image from private registry via HTTPS

Expected behavior

Unable to find Helm configuration setting to either add specific TLS Root CA certificate (as a Kubernetes TLS secret), or allow insecure HTTPS connections to Harbor private registry, something similar to --tls.verify=false.

Actual Behavior

Error reported shown above.

Additional context

None

Changelog (docs)

Security Slam 2023 umbrella issue

CLOMonitor report

Summary

Repository: kubevuln
URL: https://github.com/kubescape/kubevuln
Checks sets: CODE
Score: 82

Checks passed per category

Category	Score
Documentation	100%
License	100%
Best Practices	63%
Security	67%
Legal	n/a

Checks

Documentation [100%]

• Changelog (docs)
• Contributing (docs)
• Maintainers (docs)
• Readme (docs)

License [100%]

• Apache-2.0 (docs)
• Approved license (docs)
• License scanning (docs)

Best Practices [63%]

• Artifact Hub badge (docs)
• Contributor License Agreement (docs) EXEMPT
• Developer Certificate of Origin (docs)
• OpenSSF best practices badge (docs)
• OpenSSF Scorecard badge (docs)
• Recent release (docs)

Security [67%]

• Binary artifacts (docs)
• Code review (docs)
• Dangerous workflow (docs)
• Dependencies policy (docs) CHECK FAILED
• Dependency update tool (docs)
• Maintained (docs)
• Software bill of materials (SBOM) (docs)
• Security insights (docs) CHECK FAILED
• Security policy (docs)
• Self-Assessment (docs) CHECK FAILED
• Signed releases (docs)
• Token permissions (docs)

For more information about the checks sets available and how each of the checks work, please see the CLOMonitor's documentation.

Self-Assessment (docs)

Signed releases (docs)

Token permissions (docs)

OpenSSF best practices badge (docs)

Artifact Hub badge (docs)

Dependency update tool (docs)

Maintainers (docs)

Software bill of materials (SBOM) (docs)

OpenSSF Scorecard badge (docs)

Error running kubevuln

Cluster has relevancy beta installed and I assume the scan was either triggered by me restarting a deployment to test to see if anything was generated, or by me hitting "Scan" in the ARMO UI when it seemed like nothing happened.

2023-05-23 21:12:50 {"level":"info","ts":"2023-05-23T20:12:50Z","msg":"starting server"}
2023-05-23 21:12:51 {"level":"info","ts":"2023-05-23T20:12:51Z","msg":"updating grype DB"}
2023-05-23 21:12:57 {"level":"info","ts":"2023-05-23T20:12:57Z","msg":"grype DB updated"}
2023-05-23 21:31:22 {"level":"info","ts":"2023-05-23T20:31:22Z","msg":"scan started","imageID":"docker://sha256:2edf9c994f199aecfea940f65e2582eea072a6c2e2a747db5af3933a77a8ce46","jobID":"7f7cd5fb-2527-46e0-b237-b42cc7fd7430"}
2023-05-23 21:31:22 panic: runtime error: index out of range [3] with length 0 [recovered]
2023-05-23 21:31:22     panic: runtime error: index out of range [3] with length 0 [recovered]
2023-05-23 21:31:22     panic: runtime error: index out of range [3] with length 0
2023-05-23 21:31:22 
2023-05-23 21:31:22 goroutine 1058 [running]:
2023-05-23 21:31:22 go.opentelemetry.io/otel/sdk/trace.(*recordingSpan).End.func1()
2023-05-23 21:31:22     /go/pkg/mod/go.opentelemetry.io/otel/[email protected]/trace/span.go:383 +0x2a
2023-05-23 21:31:22 go.opentelemetry.io/otel/sdk/trace.(*recordingSpan).End(0xc0005ea000, {0x0, 0x0, 0x23100f0bb927f753?})
2023-05-23 21:31:22     /go/pkg/mod/go.opentelemetry.io/otel/[email protected]/trace/span.go:421 +0x942
2023-05-23 21:31:22 panic({0x2424280, 0xc0005e2078})
2023-05-23 21:31:22     /usr/local/go/src/runtime/panic.go:884 +0x212
2023-05-23 21:31:22 go.opentelemetry.io/otel/sdk/trace.(*recordingSpan).End.func1()
2023-05-23 21:31:22     /go/pkg/mod/go.opentelemetry.io/otel/[email protected]/trace/span.go:383 +0x2a
2023-05-23 21:31:22 go.opentelemetry.io/otel/sdk/trace.(*recordingSpan).End(0xc000265980, {0x0, 0x0, 0xc000b2f598?})
2023-05-23 21:31:22     /go/pkg/mod/go.opentelemetry.io/otel/[email protected]/trace/span.go:421 +0x942
2023-05-23 21:31:22 panic({0x2424280, 0xc0005e2078})
2023-05-23 21:31:22     /usr/local/go/src/runtime/panic.go:884 +0x212
2023-05-23 21:31:22 github.com/kubescape/kubevuln/repositories.hashFromImageID({0xc000bf40a0, 0x50})
2023-05-23 21:31:22     /work/repositories/apiserver.go:64 +0xb2
2023-05-23 21:31:22 github.com/kubescape/kubevuln/repositories.(*APIServerStore).GetCVE(0xc000500300, {0x2eba4b0, 0xc000aa82d0}, {0xc000bf40a0, 0x50}, {0x2f766d3, 0x7}, {0x2f7651c, 0x7}, {0xc000f8ea00, ...})
2023-05-23 21:31:22     /work/repositories/apiserver.go:78 +0x245
2023-05-23 21:31:22 github.com/kubescape/kubevuln/core/services.(*ScanService).ScanCVE(0xc0000ca300, {0x2eba4b0, 0xc0002c4a20})
2023-05-23 21:31:22     /work/core/services/scan.go:111 +0x6f8
2023-05-23 21:31:22 github.com/kubescape/kubevuln/controllers.HTTPController.ScanCVE.func1()
2023-05-23 21:31:22     /work/controllers/http.go:106 +0x5e
2023-05-23 21:31:22 github.com/gammazero/workerpool.worker(0x1?, 0x2?, 0x0?)
2023-05-23 21:31:22     /go/pkg/mod/github.com/gammazero/[email protected]/workerpool.go:237 +0x2a
2023-05-23 21:31:22 created by github.com/gammazero/workerpool.(*WorkerPool).dispatch
2023-05-23 21:31:22     /go/pkg/mod/github.com/gammazero/[email protected]/workerpool.go:197 +0x2dd

[question] can't load config file using `CONFIG` env

Description

As mentioned in the README, we can load config file using the CONFIG env.
However, we are unable to load config file path using the CONFIG environment variable.
Kubevuln always defaults to searching the config file in the /etc/config path, even when we define a new path in the CONFIG env.

In order to run kubevuln:

• We either add the config file named clusterData.json in the path /etc/config, the default path where kubevuln searches for it.
• Or, we explicitly define a new path in the code here, where we want Kubevuln to search for the config file named clusterData.json, build kubevuln and then run it

If we follow any of the above 2 steps, then I am able to run it locally

Environment

OS: Ubuntu 20.04.4 LTS

Steps To Reproduce

Method 1:

1. Build kubevuln using make
2. Load config file using the CONFIG environment variable
   export CONFIG=path/to/clusterData.json

Method 2:

1. Build the Docker image from the Dockerfile and run it using:
   docker run <kubevuln-built-image-name> -e CONFIG=path/to/clusterData.json

Additional Context

Is this an expected behavior or am I missing something?

Dependencies policy (docs)

License scanning (docs)