bug(misconf): False positives for ksv116 and ksv104 #4922

creste · 2023-07-28T22:03:32Z

Describe the bug
Trivy started reporting many false positives 3 hours ago after aquasecurity/defsec#1386 was merged into main.

To Reproduce ksv116
Steps to reproduce the behavior:

Create clusterrole.yaml file with these contents:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: test
rules:
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
    verbs: ["get", "list", "watch"]

Scan the cluster role with trivy:

trivy fs --exit-code 1 --debug --scanners config clusterrole.yaml

Expected behavior
Trivy doesn't report any failures.

Output of your tfsec command with --debug flag
Trivy reports the cluster role is missing a securityContext, which doesn't make sense because cluster roles can't have a securityContext:

2023-07-28T17:50:02.796-0400	DEBUG	Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-07-28T17:50:02.801-0400	DEBUG	cache dir:  /home/user/.cache/trivy
2023-07-28T17:50:02.801-0400	INFO	Misconfiguration scanning is enabled
2023-07-28T17:50:02.801-0400	DEBUG	Policies successfully loaded from disk
2023-07-28T17:50:02.831-0400	DEBUG	Walk the file tree rooted at 'clusterrole.yaml' in parallel
2023-07-28T17:50:02.831-0400	DEBUG	Scanning Kubernetes files for misconfigurations...
2023-07-28T17:50:04.065-0400	DEBUG	Scanning Helm files for misconfigurations...
2023-07-28T17:50:04.098-0400	DEBUG	OS is not detected.
2023-07-28T17:50:04.098-0400	INFO	Detected config files: 1
2023-07-28T17:50:04.098-0400	DEBUG	Scanned config file: clusterrole.yaml

clusterrole.yaml (kubernetes)

Tests: 146 (SUCCESSES: 145, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: clusterrole test in default namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

To Reproduce ksv104
Steps to reproduce the behavior:

Create pod.yaml file with these contents:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mydeployment
  namespace: mynamespace
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      serviceAccountName: myserviceaccount
      automountServiceAccountToken: true
      containers:
        - name: container
          image: myregistry/mycontainer:myversion
          resources:
            limits:
              cpu: "1"
              memory: "1Gi"
            requests:
              cpu: "1"
              memory: "1Gi"
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 10001
            runAsGroup: 10001
      securityContext:
        seccompProfile:
          type: RuntimeDefault

Scan the pod with trivy:

trivy fs --exit-code 1 --debug --scanners config pod.yaml

Expected behavior
Trivy doesn't report any failures.

Output of your tfsec command with --debug flag
Trivy reports the pod cannot set a seccomp profile to Unconfined but the pod already sets a seccomp profile to RuntimeDefault:

trivy fs --exit-code 1 --debug --scanners config pod.yaml 
2023-07-28T17:59:47.883-0400	DEBUG	Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-07-28T17:59:47.888-0400	DEBUG	cache dir:  /home/user/.cache/trivy
2023-07-28T17:59:47.888-0400	INFO	Misconfiguration scanning is enabled
2023-07-28T17:59:47.889-0400	DEBUG	Policies successfully loaded from disk
2023-07-28T17:59:47.923-0400	DEBUG	Walk the file tree rooted at 'pod.yaml' in parallel
2023-07-28T17:59:47.923-0400	DEBUG	Scanning Helm files for misconfigurations...
2023-07-28T17:59:47.924-0400	DEBUG	Scanning Kubernetes files for misconfigurations...
2023-07-28T17:59:49.424-0400	DEBUG	OS is not detected.
2023-07-28T17:59:49.424-0400	INFO	Detected config files: 1
2023-07-28T17:59:49.424-0400	DEBUG	Scanned config file: pod.yaml

pod.yaml (kubernetes)

Tests: 146 (SUCCESSES: 144, FAILURES: 2, EXCEPTIONS: 0)
Failures: 2 (UNKNOWN: 0, LOW: 1, MEDIUM: 1, HIGH: 0, CRITICAL: 0)

MEDIUM: container container of deployment mydeployment in mynamespace namespace should specify a seccomp profile
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Seccomp profile must not be explicitly set to 'Unconfined'.

See https://avd.aquasec.com/misconfig/ksv104
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────


LOW: deployment mydeployment in mynamespace namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

System Info

trivy version:

 trivy --version
Version: 0.43.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-07-07 12:09:44.26531882 +0000 UTC
  NextUpdate: 2023-07-07 18:09:44.26531842 +0000 UTC
  DownloadedAt: 2023-07-07 14:18:17.949251153 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-05-22 01:03:23.3204665 +0000 UTC
  NextUpdate: 2023-05-25 01:03:23.3204662 +0000 UTC
  DownloadedAt: 2023-05-22 13:52:33.823587465 +0000 UTC
Policy Bundle:
  Digest: sha256:acf1cb62a4ade75773ec3d265cc4d90160d285bbacaa7b6947a34830c1e45c5c
  DownloadedAt: 2023-07-28 21:33:27.321098109 +0000 UTC

OS:

uname -a
Linux user-Precision-5570 5.19.0-46-generic aquasecurity/defsec#47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

The text was updated successfully, but these errors were encountered:

rvillane · 2023-07-31T15:04:04Z

I get a similar problem due to rule ksv116, but is my case, it complains about K8s objects running as root, but these k8s objects do not have a securityContext

trivy command executed:

trivy config --severity LOW,MEDIUM,HIGH,CRITICAL --exit-code 1 yaml-k8s-files

Examples:

microservice-helm-chart/templates/configmap.yaml (kubernetes)
==================================================================
Tests: 145 (SUCCESSES: 144, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (LOW: 1, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: configmap admin-service-pls-config in pls-adminservice namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
────────────────────────────────────────
 microservice-helm-chart/templates/configmap.yaml:1
────────────────────────────────────────
   1 [ ---
────────────────────────────────────────



microservice-helm-chart/templates/hpa.yaml (kubernetes)
============================================================
Tests: 145 (SUCCESSES: 144, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (LOW: 1, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: horizontalpodautoscaler admin-service-pls in pls-adminservice namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
────────────────────────────────────────
 microservice-helm-chart/templates/hpa.yaml:1
────────────────────────────────────────
   1 [ ---
────────────────────────────────────────



microservice-helm-chart/templates/istio-authorization-policy.yaml (kubernetes)
===================================================================================
Tests: 150 (SUCCESSES: 144, FAILURES: 6, EXCEPTIONS: 0)
Failures: 6 (LOW: 6, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: authorizationpolicy admin-service-pls-force-valid-jwt-token in pls-adminservice namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
────────────────────────────────────────
 microservice-helm-chart/templates/istio-authorization-policy.yaml:1
────────────────────────────────────────
   1 [ ---
────────────────────────────────────────



microservice-helm-chart/templates/istio-certificate.yaml (kubernetes)
==========================================================================
Tests: 146 (SUCCESSES: 144, FAILURES: 2, EXCEPTIONS: 0)
Failures: 2 (LOW: 2, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: certificate admin-service-pls-tls in istio-system namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
────────────────────────────────────────
 microservice-helm-chart/templates/istio-certificate.yaml:1
────────────────────────────────────────
   1 [ ---
────────────────────────────────────────



microservice-helm-chart/templates/istio-gateway.yaml (kubernetes)
======================================================================
Tests: 146 (SUCCESSES: 144, FAILURES: 2, EXCEPTIONS: 0)
Failures: 2 (LOW: 2, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: gateway admin-service-pls-gw in pls-adminservice namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
────────────────────────────────────────
 microservice-helm-chart/templates/istio-gateway.yaml:1
────────────────────────────────────────
   1 [ ---
────────────────────────────────────────



microservice-helm-chart/templates/istio-request-authentication.yaml (kubernetes)
=====================================================================================
Tests: 146 (SUCCESSES: 144, FAILURES: 2, EXCEPTIONS: 0)
Failures: 2 (LOW: 2, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: requestauthentication admin-service-pls-jwt-authentication-rule in pls-adminservice namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
────────────────────────────────────────
 microservice-helm-chart/templates/istio-request-authentication.yaml:1
────────────────────────────────────────
   1 [ ---
────────────────────────────────────────


microservice-helm-chart/templates/istio-virtual-service.yaml (kubernetes)
==============================================================================
Tests: 146 (SUCCESSES: 144, FAILURES: 2, EXCEPTIONS: 0)
Failures: 2 (LOW: 2, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: virtualservice admin-service-pls-vs in pls-adminservice namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0
════════════════════════════════════════
According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.

See https://avd.aquasec.com/misconfig/ksv116
────────────────────────────────────────
 microservice-helm-chart/templates/istio-virtual-service.yaml:1
────────────────────────────────────────
   1 [ ---
────────────────────────────────────────

Another minor detail, the link recommended for additional details -> https://avd.aquasec.com/misconfig/ksv116 is broken, I get HTTP 404 back.

ksbde · 2023-08-01T14:47:08Z

I have also the same issue. Can anyone from the contributors look into that issue deeper? @simar7

chen-keinan · 2023-08-01T18:48:52Z

@creste @ksbde thanks , I'll take a look

stevehipwell · 2023-09-07T09:40:25Z

Is there any progress on this and in the meantime is there a way to disable Kubernetes scanning (when running trivy config ./)?

Mo0rBy · 2023-09-07T14:14:10Z

This also pops up on service and service-account objects, when they also cannot have a securityContext section defined.

stevehipwell · 2023-09-07T14:33:47Z

I'm seeing it on ConfigMap and CustomResourceDefinition objects.

simar7 · 2023-09-07T15:08:51Z

Is there any progress on this and in the meantime is there a way to disable Kubernetes scanning (when running trivy config ./)?

We have #4901 but it is currently not being worked on.

Mo0rBy · 2023-09-07T15:16:46Z

I've just noticed that if you set a securityContext within the template.spec rather than the template.spec.container, Trivy just doesn't see this and will alert to various securityContext settings not being set for each container, when they are in fact globally set across the pod, so all containers have those settings.

codekuu · 2023-10-16T08:04:09Z

Bumping this since we have the same problem. Has anyone managed to solve this without ignore?

trivy 0.46.0 - latest db (2023-10-26)
trivy fs --scanners=config,secret,license .

"AVDID": "AVD-KSV-0116",
"Title": "Runs with a root primary or supplementary GID",
 "Description": "According to pod security standard 'Non-root groups', containers should be forbidden from running with a root primary or supplementary GID.",
"Message": "deployment nebula-api in nebula namespace should set spec.securityContext.runAsGroup, spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup to integer greater than 0",

deployment:

spec:
  securityContext:
    runAsUser: 31337
    runAsGroup: 31337
    fsGroup: 31337
etc...
    spec:
      containers:
        - name: XXXXXXXXXXXXXXX
          etc...
          securityContext:
            runAsUser: 31337
            runAsGroup: 31337
            fsGroup: 31337
            allowPrivilegeEscalation: false
            runAsNonRoot: true
            readOnlyRootFilesystem: true
            seccompProfile:
              type: RuntimeDefault
            capabilities:
              drop: ["ALL"]
etc...

tried using different uids between spec.securityContext and containers[].securityContext

rvillane · 2024-01-02T17:28:52Z

@simar7 @chen-keinan any recommendations here? the only workaround to at least continue using trivy to scan k8s YAML files is to avoid priority LOW findings, which correspond to the priority assigned to ksv116 and ksv104 tickets.

Any details about a potential fix is highly appreciated, thanks

simar7 · 2024-01-02T21:55:42Z

@creste @ksbde thanks , I'll take a look

@chen-keinan do you have any update?

chen-keinan · 2024-01-03T07:02:05Z

@creste @ksbde thanks , I'll take a look

@chen-keinan do you have any update?

@simar7 nope, I think it will be the best for @mjshastha to have a look as it come from his PR.

@mjshastha could you please have a look on this issue?

Mo0rBy · 2024-01-03T08:17:25Z

I just want to add that issue #5679 may be a duplicate of this. It originates from a discussion I created where I was seeing similar false positives on Helm chart misconfig scanning.

reported in aquasecurity/trivy#4922 since the failRootGroupId rule is given a default value, it doesn't fail the deny rule and results in a false detection. added an explicit check for the failRootGropuId truthiness to resolve.

reported in aquasecurity/trivy#4922 since the failRootGroupId rule is given a default value, it doesn't fail the deny rule and results in a false detection. added an explicit check for the failRootGropuId truthiness to resolve. also fixed the sad path test

itaysk · 2024-01-10T16:17:18Z

created a fix for the first issue (ksv116) here aquasecurity/trivy-checks#53

simar7 · 2024-01-17T02:18:22Z

Fixed via aquasecurity/trivy-checks#53 and will be in next release.

itaysk · 2024-01-21T12:09:50Z

@simar7 what about the second issue (ksv104)?

simar7 · 2024-01-22T23:31:19Z

@simar7 what about the second issue (ksv104)?

Sorry didn't realize we hadn't fixed that one yet in your PR. Reopening.

simar7 · 2024-02-07T22:49:27Z

This should be fixed in the next release with aquasecurity/trivy-checks#71

simar7 assigned chen-keinan Aug 1, 2023

simar7 transferred this issue from aquasecurity/defsec Aug 1, 2023

simar7 changed the title ~~bug: False positives for ksv116 and ksv104~~ bug(misconf): False positives for ksv116 and ksv104 Aug 1, 2023

simar7 added the scan/misconfiguration Issues relating to misconfiguration scanning label Aug 1, 2023

stevehipwell mentioned this issue Sep 7, 2023

feat(misconf): Add support for wildcard ignores #5120

Closed

itaysk mentioned this issue Jan 10, 2024

fix: fail for irrelevant resources aquasecurity/trivy-checks#53

Merged

simar7 closed this as completed Jan 17, 2024

simar7 reopened this Jan 22, 2024

simar7 assigned nikpivkin Feb 2, 2024

nikpivkin mentioned this issue Feb 6, 2024

fix(checks): check the Seccomp of the controllers aquasecurity/trivy-checks#71

Merged

simar7 closed this as completed in aquasecurity/trivy-checks#71 Feb 7, 2024

simar7 added this to the v0.50.0 milestone Feb 7, 2024

simar7 added this to Trivy Roadmap Feb 7, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bug(misconf): False positives for ksv116 and ksv104 #4922

bug(misconf): False positives for ksv116 and ksv104 #4922

creste commented Jul 28, 2023

rvillane commented Jul 31, 2023 •

edited

Loading

ksbde commented Aug 1, 2023

chen-keinan commented Aug 1, 2023

stevehipwell commented Sep 7, 2023

Mo0rBy commented Sep 7, 2023

stevehipwell commented Sep 7, 2023

simar7 commented Sep 7, 2023

Mo0rBy commented Sep 7, 2023

codekuu commented Oct 16, 2023 •

edited

Loading

rvillane commented Jan 2, 2024

simar7 commented Jan 2, 2024

chen-keinan commented Jan 3, 2024 •

edited

Loading

Mo0rBy commented Jan 3, 2024

itaysk commented Jan 10, 2024

simar7 commented Jan 17, 2024

itaysk commented Jan 21, 2024

simar7 commented Jan 22, 2024

simar7 commented Feb 7, 2024

bug(misconf): False positives for ksv116 and ksv104 #4922

bug(misconf): False positives for ksv116 and ksv104 #4922

Comments

creste commented Jul 28, 2023

rvillane commented Jul 31, 2023 • edited Loading

ksbde commented Aug 1, 2023

chen-keinan commented Aug 1, 2023

stevehipwell commented Sep 7, 2023

Mo0rBy commented Sep 7, 2023

stevehipwell commented Sep 7, 2023

simar7 commented Sep 7, 2023

Mo0rBy commented Sep 7, 2023

codekuu commented Oct 16, 2023 • edited Loading

rvillane commented Jan 2, 2024

simar7 commented Jan 2, 2024

chen-keinan commented Jan 3, 2024 • edited Loading

Mo0rBy commented Jan 3, 2024

itaysk commented Jan 10, 2024

simar7 commented Jan 17, 2024

itaysk commented Jan 21, 2024

simar7 commented Jan 22, 2024

simar7 commented Feb 7, 2024

rvillane commented Jul 31, 2023 •

edited

Loading

codekuu commented Oct 16, 2023 •

edited

Loading

chen-keinan commented Jan 3, 2024 •

edited

Loading