feat(policy): Enable selectors for providers

[simar7]

This PR adds support for subtype selectors for policies.

Addresses: aquasecurity/trivy#3441

Small example:

Cloud

# METADATA
# title: "RDS Publicly Accessible"
# description: "Ensures RDS instances are not launched into the public cloud."
# scope: package
# schemas:
# - input: schema.input
# related_resources:
# - http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.html
# custom:
#   avd_id: AVD-AWS-0999
#   provider: aws
#   service: rds
#   severity: HIGH
#   short_code: enable-public-access
#   recommended_action: "Remove the public endpoint from the RDS instance'"
#   input:
#     selector:
#     - type: cloud
#       subtypes:
#         - service: rds

Kubernetes

# METADATA
# title: "Process can elevate its own privileges"
# description: "A program inside the container can elevate its own privileges and run as root, which might give the program control over the container and node."
# scope: package
# schemas:
# - input: schema["input"]
# related_resources:
# - https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted
# custom:
#   id: KSV001
#   avd_id: AVD-KSV-0999
#   severity: MEDIUM
#   short_code: no-self-privesc
#   recommended_action: "Set 'set containers[].securityContext.allowPrivilegeEscalation' to 'false'."
#   input:
#     selector:
#     - type: kubernetes
#       subtypes:
#         - kind: Pod

Signed-off-by: Simar [email protected]

[simar7]

Note: I've left this in as "failing example" that should "pass" when we add selectors to all Kubernetes policies.

[simar7]

cc @chen-keinan just a heads up.

[itaysk]

looks promising! will need to add relevant documentation (separate PR)

we should define (and test) the following cases:

1. selector is not defined (IMO policy applies to all)
2. selector is empty (IMO policy applies to none)
3. selector is defined without subtype (IMO policy applies to all of type)
4. selector is defined with empty subtype (IMO policy applies to none)
5. selector is conflicting with service field (IMO we should remove service field)
6. subtype is partially defined, for example only kind is defined on k8s check (should apply to matching types)
7. subtype is mixing fields from different types, for example using service on k8s check (should consider just what's relevant)

[itaysk]

how does this apply to other types besides k8s and cloud? (e.g Dockerfile)

[giorod3]

can we make the cloud selector more specific. When we get to multi-cloud what will happen if subtype is IAM (AWS) or IAM (GCP). I believe currently it will try to evaluate policies for both clouds.

[simar7]

how does this apply to other types besides k8s and cloud? (e.g Dockerfile)

we can easily extend this to other types as well. at the moment, only cloud and kubernetes are supported.

[simar7]

can we make the cloud selector more specific. When we get to multi-cloud what will happen if subtype is IAM (AWS) or IAM (GCP). I believe currently it will try to evaluate policies for both clouds.

right, actually this gave me another idea which I think will help us eliminate some of the extra fields in the custom metadata in the future and instead make them common with the input selectors (specifically, I'm talking about provider and service custom metadata fields).

I've implemented that in the next few commits.

[simar7]

looks promising! will need to add relevant documentation (separate PR)

we should define (and test) the following cases:

1. selector is not defined (IMO policy applies to all)
2. selector is empty (IMO policy applies to none)
3. selector is defined without subtype (IMO policy applies to all of type)
4. selector is defined with empty subtype (IMO policy applies to none)
5. selector is conflicting with service field (IMO we should remove service field)
6. subtype is partially defined, for example only kind is defined on k8s check (should apply to matching types)
7. subtype is mixing fields from different types, for example using service on k8s check (should consider just what's relevant)

thanks for these, I've opened new issues to track them.

https://github.com/aquasecurity/defsec/issues/1201
https://github.com/aquasecurity/defsec/issues/1200

[itaysk]

thanks for these, I've opened new issues to track them.

sure we can add tests later but the reason I wrote those cases was to make sure the code (in this PR) works according to this desired (IMO) behavior. If that's the case, then great, if not we should fix it here

[itaysk]

I've implemented that in the next few commits.

not sure I see the change in the code, can you please explain what you mean by that?

[simar7]

I've implemented that in the next few commits.

not sure I see the change in the code, can you please explain what you mean by that?

In this commit I've implemented the support for providing provider as part of the selector logic 5edd823 - the idea is that these selectors are common for any provider (cloud, docker, k8s..)

in the future we should be able to remove the "provider" and "service" fields that are only meant for cloud for now https://github.com/aquasecurity/defsec/blob/master/rules/cloud/policies/aws/rds/disable_public_access.rego#L11-L12 - This can be tracked in a separate issue.