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

Trivy operator exception unexpected result: empty message instead of removing the check #1742

Closed
thommeo opened this issue Jan 4, 2024 · 3 comments · Fixed by #1845
Closed
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. target/kubernetes Issues relating to kubernetes cluster scanning

Comments

@thommeo
Copy link

thommeo commented Jan 4, 2024

What steps did you take and what happened:

Adding exception as OPA policy results in empty messages in reports instead of removing the checks.

Related to aquasecurity/trivy#5679

I have a lot of false positives from KVS116 that requires adding spec.securityContext to ConfigMaps, NetworkPolicies and other resources which security context is not applicable to.

In an attempt to eliminate those false positives, I tried to add exception for this rule in the. Helm chart. Here is the values.yaml:

  trivyOperator:
    policiesConfig: |
      policy.ksv116_exclude_resources.kinds: "*"
      policy.ksv116_exclude_resources.rego: |
        # ref: https://github.com/aquasecurity/trivy-policies/blob/main/checks/kubernetes/general/runs_with_a_root_primary_or_supplementary_GID.rego
        package builtin.kubernetes.KSV116

        # Exclude resource kinds from KSV116
        exception[rules] {
          resource_kinds := {
            "NetworkPolicy",
            "ConfigMap",
            "Service",
            "ReplicaSet",
          }
          resource_kinds[input.kind]
          rules := [""]
        }

It works fine locally. Tested as described here - works as expected. Using the above Rego file removes the false positives.

When running with trivy operator in live Kubernetes cluster, it re-creates the policies with the only difference - it clears the message from the report.

Before

apiVersion: aquasecurity.github.io/v1alpha1
kind: ConfigAuditReport
metadata:
  annotations:
    trivy-operator.aquasecurity.github.io/report-ttl: 24h0m0s
  creationTimestamp: "2024-01-04T15:25:46Z"
  generation: 1
  labels:
    plugin-config-hash: 58fd957545
    resource-spec-hash: 9b5cdd74f
    trivy-operator.resource.kind: NetworkPolicy
    trivy-operator.resource.name: allow-any
    trivy-operator.resource.namespace: <...>
  name: networkpolicy-<...>
  namespace: <...>
  ownerReferences:
  - apiVersion: networking.k8s.io/v1
    blockOwnerDeletion: false
    controller: true
    kind: NetworkPolicy
    name: allow-any
    uid: de6f00ab-a5cf-4b3e-83ce-c09cc82b18dc
  resourceVersion: "11500641"
  uid: 3c43d1e9-fe2c-4b4b-994e-b444a4c7f7a0
report:
  checks:
  - category: Kubernetes Security Check
    checkID: KSV116
    description: According to pod security standard 'Non-root groups', containers
      should be forbidden from running with a root primary or supplementary GID.
    messages:
    - networkpolicy allow-any in <...> namespace should set spec.securityContext.runAsGroup,
      spec.securityContext.supplementalGroups[*] and spec.securityContext.fsGroup
      to integer greater than 0
    severity: LOW
    success: false
    title: Runs with a root primary or supplementary GID
  scanner:
    name: Trivy
    vendor: Aqua Security
    version: 0.18.0
  summary:
    criticalCount: 0
    highCount: 0
    lowCount: 1
    mediumCount: 0

After

apiVersion: aquasecurity.github.io/v1alpha1
kind: ConfigAuditReport
metadata:
  annotations:
    trivy-operator.aquasecurity.github.io/report-ttl: 24h0m0s
  creationTimestamp: "2024-01-04T15:34:48Z"
  generation: 1
  labels:
    plugin-config-hash: 565d547fbc
    resource-spec-hash: 56766fc755
    trivy-operator.resource.kind: NetworkPolicy
    trivy-operator.resource.name: allow-any
    trivy-operator.resource.namespace: <...>
  name: allow-any
  namespace: <...>
  ownerReferences:
  - apiVersion: networking.k8s.io/v1
    blockOwnerDeletion: false
    controller: true
    kind: NetworkPolicy
    name: <...>
    uid: 6ab4da63-543c-4616-90a3-5a04a7f60d23
  resourceVersion: "11505030"
  uid: a4bbcbde-2627-428e-80f4-2e64ce331432
report:
  checks:
  - category: Kubernetes Security Check # <<<<<<<<<<<<<<<<<<<<<<<< Expected: not to have this check at all
    checkID: KSV116
    description: According to pod security standard 'Non-root groups', containers
      should be forbidden from running with a root primary or supplementary GID.
    messages:
    - "" # <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Message is empty
    severity: LOW
    success: false
    title: Runs with a root primary or supplementary GID
  scanner:
    name: Trivy
    vendor: Aqua Security
    version: 0.18.0
  summary:
    criticalCount: 0
    highCount: 0
    lowCount: 1
    mediumCount: 0
  updateTimestamp: "2024-01-04T15:34:48Z"

What did you expect to happen:

The check should be missing in reports and metrics.

Environment:

  • Trivy-Operator version "Version":"0.18.0", "Commit":"c73d65dca31483e6c7b8edcd5e386b3f4bf6d0f2"
  • Kubernetes version (use kubectl version): v1.27.6
  • Helm chart version 0.20.0
  • OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): macos 14.2.1
@thommeo thommeo added the kind/bug Categorizes issue or PR as related to a bug. label Jan 4, 2024
@chen-keinan
Copy link
Collaborator

@thommeo thank you for the input , I do not think exception is supported in operator however I assume to could be fairly small change to support it

@chen-keinan chen-keinan added kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. target/kubernetes Issues relating to kubernetes cluster scanning and removed kind/bug Categorizes issue or PR as related to a bug. labels Jan 8, 2024
@thommeo
Copy link
Author

thommeo commented Jan 14, 2024

@chen-keinan Thannk you for your reply. The reason for this is actually the fact that the defsec rule us not configured correctly to only apply to relevand kinds (i.e. Pods). It raises false positives on the all other resources e.g. NetworkPolicy etc.

Is there any other way to deal with the situation? Some other way to override it on operator?

@chen-keinan
Copy link
Collaborator

@chen-keinan Thannk you for your reply. The reason for this is actually the fact that the defsec rule us not configured correctly to only apply to relevand kinds (i.e. Pods). It raises false positives on the all other resources e.g. NetworkPolicy etc.

Is there any other way to deal with the situation? Some other way to override it on operator?

I would suggest to add support for policy exception

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. target/kubernetes Issues relating to kubernetes cluster scanning
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants