Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
creste opened this issue Jul 28, 2023 · 18 comments · Fixed by aquasecurity/trivy-checks#71
Closed

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

creste opened this issue Jul 28, 2023 · 18 comments · Fixed by aquasecurity/trivy-checks#71
Assignees
Labels
scan/misconfiguration Issues relating to misconfiguration scanning
Milestone

Comments

@creste
Copy link

creste commented Jul 28, 2023

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:

  1. 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"]
  1. 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:

  1. 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
  1. 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
@rvillane
Copy link

rvillane commented Jul 31, 2023

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
Copy link

ksbde commented Aug 1, 2023

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

@chen-keinan
Copy link
Contributor

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

@simar7 simar7 transferred this issue from aquasecurity/defsec Aug 1, 2023
@simar7 simar7 changed the title bug: False positives for ksv116 and ksv104 bug(misconf): False positives for ksv116 and ksv104 Aug 1, 2023
@simar7 simar7 added the scan/misconfiguration Issues relating to misconfiguration scanning label Aug 1, 2023
@stevehipwell
Copy link

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

@Mo0rBy
Copy link

Mo0rBy commented Sep 7, 2023

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

@stevehipwell
Copy link

I'm seeing it on ConfigMap and CustomResourceDefinition objects.

@simar7
Copy link
Member

simar7 commented Sep 7, 2023

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
Copy link

Mo0rBy commented Sep 7, 2023

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
Copy link

codekuu commented Oct 16, 2023

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
Copy link

rvillane commented Jan 2, 2024

@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
Copy link
Member

simar7 commented Jan 2, 2024

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

@chen-keinan do you have any update?

@chen-keinan
Copy link
Contributor

chen-keinan commented Jan 3, 2024

@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
Copy link

Mo0rBy commented Jan 3, 2024

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.

itaysk added a commit to itaysk/trivy-policies that referenced this issue Jan 10, 2024
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.
itaysk added a commit to itaysk/trivy-policies that referenced this issue Jan 10, 2024
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
Copy link
Contributor

itaysk commented Jan 10, 2024

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

@simar7
Copy link
Member

simar7 commented Jan 17, 2024

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

@simar7 simar7 closed this as completed Jan 17, 2024
@itaysk
Copy link
Contributor

itaysk commented Jan 21, 2024

@simar7 what about the second issue (ksv104)?

@simar7
Copy link
Member

simar7 commented Jan 22, 2024

@simar7 what about the second issue (ksv104)?

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

@simar7
Copy link
Member

simar7 commented Feb 7, 2024

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

@simar7 simar7 added this to the v0.50.0 milestone Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scan/misconfiguration Issues relating to misconfiguration scanning
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

10 participants