Lots of issues with Trivy helm chart misconfiguration scanning

[Mo0rBy]

Description

I have found that there are a lot of false positives related to securityContext definitions in vanilla Kubernetes objects as well as custom objects (all Istio objects in my case). Most are just completely incorrect, but the alerts for the deployment manifests are quite interesting.

Vanilla Kubernetes Objects

(In my case, deployments, services and service-accounts)

service.yaml
LOW: service myService in default namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0 > See https://avd.aquasec.com/misconfig/ksv116

A service object cannot have a securityContext definition, so this should not be an alert.

service-account.yaml
LOW: serviceaccount myService in default namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0 > See https://avd.aquasec.com/misconfig/ksv116

A service-account object cannot have a securityContext definition, so this should not be an alert.

deployment.yaml
LOW: deployment myService in default namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0 > See https://avd.aquasec.com/misconfig/ksv116

Within my spec.securityContext definition, I have runAsUser, runAsGroup and fsGroup all defined. In the examples given on "set the security standard for a pod" docs, the supplementalGroups field is not defined. I did some digging and found that this field would probably only be needed in specific use cases (see the kubernetes reference docs). I'm not entirely sure of this is correct and I may be misunderstanding what this field is used for, but if my theory is correct, then this alert should not be present, as I am setting the other fields, which should be enough.

MEDIUM: Container 'myService' of Deployment 'myService' should not set 'securityContext.capabilities.add' > See https://avd.aquasec.com/misconfig/ksv022

This alert is the most interesting and nuanced. Reading the Pod Security Standards, there are 3 categories, Privileged, Baseline and Restricted. In my case, I am following the Restricted standards, but this alert seems to be coming from the Baseline standards. Here are the relevant sections of the Pod Security Standards documentation:

Here are the Baseline standards for securityContext.capabilities:

---

Adding additional capabilities beyond those listed below must be disallowed.

Restricted Fields

• spec.containers[*].securityContext.capabilities.add
• spec.initContainers[*].securityContext.capabilities.add
• spec.ephemeralContainers[*].securityContext.capabilities.add

Allowed Values

• Undefined/nil
• AUDIT_WRITE
• CHOWN
• DAC_OVERRIDE
• FOWNER
• FSETID
• KILL
• MKNOD
• NET_BIND_SERVICE
• SETFCAP
• SETGID
• SETPCAP
• SETUID
• SYS_CHROOT

---

Here are the Restricted standards for securityContext.capabilities:

---

Containers must drop ALL capabilities, and are only permitted to add back the NET_BIND_SERVICE capability. This is Linux only policy in v1.25+ (.spec.os.name != "windows")

Restricted Fields

• spec.containers[*].securityContext.capabilities.drop
• spec.initContainers[*].securityContext.capabilities.drop
• spec.ephemeralContainers[*].securityContext.capabilities.drop

Allowed Values

• Any list of capabilities that includes ALL

Restricted Fields

• spec.containers[*].securityContext.capabilities.add
• spec.initContainers[*].securityContext.capabilities.add
• spec.ephemeralContainers[*].securityContext.capabilities.add

Allowed Values

• Undefined/nil
• NET_BIND_SERVICE

---

Finally, here is my securityContext.capabilities definition in my yaml:

          capabilities:
            drop: ["ALL"]
            add:
              - NET_BIND_SERVICE

This clearly follows the Restricted Pod Security Standards, but the ksv022 alert is coming from the Baseline standards. This is clearly just a difference in the standards that I am following and the standards that are being used to scan the yaml manifest.

Therefore, I would suggest a new feature where you can select which Pod Security Standards to scan against.

Custom objects

(In my case, all the custom objects triggering alerts are Istio objects)

authorization-policy.yaml
LOW: authorizationpolicy myService in default namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0 > See https://avd.aquasec.com/misconfig/ksv116

A authorization-policy object cannot have a securityContext definition, so this should not be an alert.

request-authentication.yaml

LOW: requestauthentication myService in default namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0 > See https://avd.aquasec.com/misconfig/ksv116

A request-authentication object cannot have a securityContext definition, so this should not be an alert.

This sums up all the false positives that I am seeing.

Desired Behavior

The false positive alerts discussed above should not be seen.

Actual Behavior

There are false positives for vanilla Kubernetes objects and custom kubernetes objects for securityContext definitions.

The most interesting that isn't exactly a false positive is ksv022 for the deployment manifest, where the Baseline Pod Security Standard is being used, rather than the Resticted one.

Reproduction Steps

Execute a `trivy config <helm-chart-directory>` on a helm chart with the objects discussed above.

Target

Kubernetes

Scanner

Misconfiguration

Output Format

Table

Mode

Standalone

Debug Output

This is not necessary, debug output shows the exact same false positives.

Operating System

macOS Ventura 13.5.1

Version

Version: 0.44.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-09-11 06:16:57.742189926 +0000 UTC
  NextUpdate: 2023-09-11 12:16:57.742189326 +0000 UTC
  DownloadedAt: 2023-09-11 09:44:46.200029 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-09-11 00:53:00.064262708 +0000 UTC
  NextUpdate: 2023-09-14 00:53:00.064262008 +0000 UTC
  DownloadedAt: 2023-09-11 09:45:53.490486 +0000 UTC
Policy Bundle:
  Digest: sha256:fd5f1ce3d8efb1fe158cb41f9adb9d7c7cc5c4c863b261053c962e6d950350b3
  DownloadedAt: 2023-09-12 12:45:02.274108 +0000 UTC

Checklist

• Run trivy image --reset
• Read the troubleshooting

[Mo0rBy]

I did some digging into how the rules are defined and how to make exceptions to these rules. All the different policies and rules are defined here and I was able to create my own custom rego policy files to ignore these rules for certain Kinds of objects. Here is an example:

[simar7]

cc @chen-keinan

[itaysk]

@chen-keinan can you please take a look?

[zatricky]

In case it's relevant, a small note that the policies moved: https://github.com/aquasecurity/trivy-policies/tree/main/rules/kubernetes/policies

[chen-keinan]

@simar7 subType for this policy look ok , however subtype is not supported for k8s
Please confirm

I have created a PR aquasecurity/defsec#1502 should fix point 1 & 2

still reviewing point 3

[chen-keinan]

@Mo0rBy I have converted this discussion into issue #5679