feat: add Persistent Volume resources

[afdesk]

Description

This PR is a small PoC for adding new resources with minimum changes.

$ kubectl get clusterconfigauditreports.aquasecurity.github.io -A -o wide
NAME                       SCANNER   AGE   CRITICAL   HIGH   MEDIUM   LOW
persistentvolume-demo-pv   Trivy     41m   0          0      0        1

$ kubectl describe clusterconfigauditreports.aquasecurity.github.io persistentvolume-demo-pv
Name:         persistentvolume-demo-pv
Namespace:
Labels:       plugin-config-hash=6ddf87c668
              resource-spec-hash=579589976
              trivy-operator.resource.kind=PersistentVolume
              trivy-operator.resource.name=demo-pv
              trivy-operator.resource.namespace=
Annotations:  <none>
API Version:  aquasecurity.github.io/v1alpha1
Kind:         ClusterConfigAuditReport
Metadata:
  Creation Timestamp:  2025-02-21T10:20:56Z
  Generation:          1
  Owner References:
    API Version:           v1
    Block Owner Deletion:  false
    Controller:            true
    Kind:                  PersistentVolume
    Name:                  demo-pv
    UID:                   3edb48c5-109b-4896-8d98-4c1487769869
  Resource Version:        4485
  UID:                     630647c7-4395-44d3-8db3-a60baba58d90
Report:
  Checks:
    Category:     Kubernetes Security Check
    Check ID:     PVC_CHECK
    Description:  A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand.
    Messages:
      the check should always fail
    Remediation:  Take full advantage of using recommended labels and apply them on every resource object.
    Severity:     LOW
    Success:      false
    Title:        PVC labels
  Scanner:
    Name:     Trivy
    Vendor:   Aqua Security
    Version:  dev
  Summary:
    Critical Count:  0
    High Count:      0
    Low Count:       1
    Medium Count:    0
  Update Timestamp:  2025-02-21T10:20:56Z

custom REGO check

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: trivy-operator-policies-config
  namespace: trivy-operator
  labels:
    app.kubernetes.io/name: trivy-operator
    app.kubernetes.io/instance: trivy-operator
    app.kubernetes.io/version: "0.23.0"
    app.kubernetes.io/managed-by: kubectl
data:
  policy.recommended_labels.kinds: "PersistentVolume"
  policy.recommended_labels.rego: |
   package builtin.policy.k8s.custom

   __rego_metadata__ := {
      "id": "PVC_CHECK",
      "title": "PVC labels",
      "severity": "LOW",
      "type": "Kubernetes Security Check",
      "description": "A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand.",
      "recommended_actions": "Take full advantage of using recommended labels and apply them on every resource object.",
      "url": "https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/",
   }

   alwaysTrue {
      1 == 1
   }

   deny[res] {
        alwaysTrue
        res := {
           "msg": "the check should always fail",
        }
   }

pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: demo-pv
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  storageClassName: standard
  hostPath:
    path: /tmp/demo-pv

Checklist

• I've read the guidelines for contributing to this repository.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[simar7]

I think @itaysk's original question was would setting the supportedConfigAuditKinds type be enough for a new resource to be picked up, rather than us adding an additional resource within the operator code to be scanned.

I would assume that would work based on the logic I see in the operator but could you verify that behavior?

As for adding new resources to scan within the operator codebase by default, we have to be mindful of what the defaults are. That's why I feel leaving the door open for the user to specify what they want to scan is better rather than us scanning it by default. This is crucial as if we scan too many resources by default, it could lead to a slow (negative) user experience for those that are just getting started with trivy-operator and are unaware of all the knobs they can tune.