MQL: No assertions possible below a certain level?

[Manuel Weber]

Describe the bug
It seems that at a certain level it is not possible to do assertions (.contains(), .any()), whereas == still works.

Example 1: for the field Type where you can use the comparision via ==

cnspec> aws.cloudtrail.trails {eventSelectors[0] {DataResources {Type == "AWS::S3::Object"}}}
aws.cloudtrail.trails: [
  0: {
    eventSelectors[0]: {
      DataResources: [
        0: {
          Type == "AWS::S3::Object": true
        }
      ]
    }
  }
]

Example 2: of the same field above not executing the assertion .any

cnspec> aws.cloudtrail.trails {eventSelectors[0] {DataResources.any(Type == "AWS::S3::Object")}}
aws.cloudtrail.trails: [
  0: {
    eventSelectors[0]: {
      DataResources: [
        0: {
          Type: "AWS::S3::Object"
          Values: [
            0: "arn:aws:s3:::"
          ]
        }
      ]
    }
  }
]

To Reproduce
Run the above mentioned commands on a AWS cloudtrail.

Expected behavior
Assertions should work, example 2 should return a true/false bool.

Screenshots or CLI Output
If applicable, add screenshots or the CLI output to help explain your problem.

Desktop (please complete the following information):

 /home/manuel/projects/cloud-security-testing/aws/pass (manuel/gcp/tf-default*)$ cnspec version && cnquery version && cnspec providers
cnspec v10.6.1 (f66a469, unknown)
cnquery v10.6.1 (54c7d8faa, unknown)

→ builtin (found 2 providers)

  core 10.3.1
  mock 9.0.0 with connectors: mock

→ /home/manuel/.config/mondoo/providers (found 21 providers)
  aws 10.3.2 with connectors: aws

Additional context
Add any other context about the problem here.

[Manuel Weber]

Example for the field Equals where the assertion fails

cnquery> aws.cloudtrail.trails[2] {eventSelectors {FieldSelectors{Equals.containsNone("Data")}}}
aws.cloudtrail.trails[2]: {
  eventSelectors: [
    0: {
      FieldSelectors: [
        0: {
          Equals: [
            0: "Data"
          ]
        }
        1: {
          Equals: [
            0: "AWS::S3::Object"
          ]
        }
      ]
    }
    1: {
      FieldSelectors: [
        0: {
          Equals: [
            0: "Management"
          ]
        }
      ]
    }
  ]
}

Example for the field Field, where you can use == comparison:

cnquery> aws.cloudtrail.trails[2] {eventSelectors {FieldSelectors{Field == "eventCategory"}}}
aws.cloudtrail.trails[2]: {
  eventSelectors: [
    0: {
      FieldSelectors: [
        0: {
          Field == "eventCategory": true
        }
        1: {
          Field == "eventCategory": false
        }
      ]
    }
    1: {
      FieldSelectors: [
        0: {
          Field == "eventCategory": true
        }
      ]
    }
  ]
}

[Christoph Hartmann]

Easier to reproduce with a json file:

{
  "eventSelectors": [
    {
      "FieldSelectors": [
        {
          "Equals": [
            "Data"
          ]
        },
        {
          "Equals": [
            "AWS::S3::Object"
          ]
        }
      ]
    },
    {
      "FieldSelectors": [
        {
          "Equals": [
            "Management"
          ]
        }
      ]
    }
  ]
}

parse.json("sample.json").params.eventSelectors { FieldSelectors { Equals } }
parse.json.params.eventSelectors: [
  0: {
    FieldSelectors: [
      0: {
        Equals: [
          0: "Data"
        ]
      }
      1: {
        Equals: [
          0: "AWS::S3::Object"
        ]
      }
    ]
  }
  1: {
    FieldSelectors: [
      0: {
        Equals: [
          0: "Management"
        ]
      }
    ]
  }
] 
 

This is a problem with dicts.

[Dominik Richter]

Double-checked this too, it looks like this is a problem with both the old and new selectors:

parse.json("t").params["eventSelectors"] { _["FieldSelectors"] }

parse.json.params.eventSelectors: [
  0: {
    FieldSelectors: [
      0: {
        Equals: [
          0: "Data"
        ]
      }
      1: {
        Equals: [
          0: "AWS::S3::Object"
        ]
      }
    ]
  }
  1: {
    FieldSelectors: [
      0: {
        Equals: [
          0: "Management"
        ]
      }
    ]
  }
]

[Manuel Weber]

More info on this problem.

Using v8 notation to access fields below a certain level will allow for assertions.
Whereas using v9/v10 notation to access fields will not yield results.

It's easy to run this test on a minikube cluster locally:

Case A: v9/v10 notation to access of fields with .in-function doesn't yield anything

k8s.clusterrolebindings.where(roleRef.name == "cluster-admin") { subjects {name name.in(["system:masters"]) } }

-> Nothing is returned, but the MQL does not fail.

Case B: v8 notation to access fields WORKS (even with v10 .in-function)

k8s.clusterrolebindings.where(roleRef['name'] == "cluster-admin") {subjects { _['name'] _['name'].in(["system:masters"]) } }