feat: Support more granular policy selectors

[simar7]

User Story

As a: Trivy misconfiguration scanning user,
I would like to: see pass or fail for only those policies which are relevant,
So that: I don't see passes for those policies that don't apply to my configuration.

What exists today

1. When running a k8s misconfiguration scan, we evaluate all policies regardless if they are applicable to the resource under scan. For example, if the resource under scan is only Kubernetes primitives such as Pod and we run policies that don't apply to Pods, such policies will be marked as a PASS.
2. Technically marking such policies as pass is incorrect as they were not applicable to the resource under scan.
3. Such a problem does not exist with Cloud Scanning. The reason for this is because Cloud policies specify which service the policy is applicable for in the metadata and as a result are only loaded when the service they are applicable for is specified to be scanned. Example here: https://github.com/aquasecurity/defsec/blob/master/internal/rules/policies/cloud/policies/aws/rds/disable_public_access.rego#L11-L12

What is desired

1. Policies should only be evaluated if it makes sense to do so. Primary reason for them to be loaded and evaluated should be if they service they are covering is under scan.
2. A way to define more granular selectors per policy. An example below:

# METADATA
# title: "CPU not limited"
# description: "Enforcing CPU limits prevents DoS via resource exhaustion."
# scope: package
# schemas:
# - input: schema["input"]
# related_resources:
# - https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits
# custom:
#   id: KSV011
#   avd_id: AVD-KSV-0011
#   severity: LOW
#   short_code: limit-cpu
#   recommended_action: "Set a limit value under 'containers[].resources.limits.cpu'."
#   input:
#     selector:
#     - type: kubernetes
#     - resource: pod

Note the extra input.selector.resource annotation that specifies a pod as a resource.

In such a case, this policy would only be evaluated if a k8s scan for Pod was run. In other words, it will not be evaluated if only DeploymentSet or StatefulSet were under scan.

Acceptance Criteria

1. Policies should only be evaluated if they are applicable to the resources under scan.
2. Granular selectors can be specified if a policy is only applicable for certain kinds of resources.
3. Policies unrelated to the resources under scan should not be marked as PASS. Instead they should not be evaluated and not be counted in the results.

Signed-off-by: Simar [email protected]

[simar7]

@chen-keinan - I would also like to hear your thoughts on this, any suggestions or improvements to what is currently drafted?

[chen-keinan]

@simar7 it will be great to define the known suggested selectors per each type example :

1. type:kubernetes , resource: pod
2. type:cloud , resource: ?
3. etc

[simar7]

@itaysk - can you link the previously stated document you mentioned here which has the historical context for this issue?

[itaysk]

the example looked like this:

__rego_input__ := {
    "combine": false,
    "selector": [
        {
          "type": "kubernetes",
          "group": "batch",
          "version": "v1", 
          "kind": "job"
        }
    ]
}

[itaysk]

we should add to acceptance criteria that this should replace the "resource" that cloud scanning uses

[itaysk]

@simar7 @giorod3 IIUC aquasecurity/defsec#1174 doesn't fully implement this issue, and it's not included in the milestone. Should we

1. close this issue with the milestone and open a new one for the gaps
2. keep this open for next milestone, and create a smaller issue that can be closed in this milestone

[github-actions]

This issue is stale because it has been labeled with inactivity.

[itaysk]

ping @simar7

[simar7]

As of today and this PR aquasecurity/defsec#1174, selectors are available for usage in cloud policies. For kubernetes (and docker as well) the basic framework exists but the policies themselves need to implement using selectors.

We should open another issue that specifically targets those two.

we should add to acceptance criteria that this should replace the "resource" that cloud scanning uses

We can add this as a separate issue as well, this would be more of a chore than a feature. More details with context here aquasecurity/defsec#1174 (comment)