-
Notifications
You must be signed in to change notification settings - Fork 11
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
Extend query/check scope decentrally #954
Comments
@arlimus I assume that docs and remediation steps would work the same in that you can have individual steps with each child variant?
|
Thanks for the writeup @arlimus! I do think Option A, as-is, would be very useful. However, I'll note that this doesn't entirely cover my desired workflow (or if it does, it's not clear to me how): Today my biggest annoyance with writing policies is that I have to write multiple queries corresponding to resources that feel the same. For example, if I want to "prevent SSH on port 22" I have to write MQL rules for:
Today these are written as variants within one file. With Option A, I could shard these into separate files. That's great for maintenance but still frustrating from an authorship perspective. What I'd really like is the ability to write queries against multiple resource types at once because they all adhere to the same schema. Example SketchAn example of how this might look in cnspec (maybe this is "Option B") is:
The important bits are:
Mondoo could provide a whole slew of "normalizers" or schemas for similar types of data. Rule authors from specific companies would then only have to worry about writing against those schemas, not against each provider's output. This would, IMO, significantlly lessen the cognitive overhead of Mondoo. |
Kudos to @JosiahOne for reporting and suggesting this idea!
Problem
Variants are centrally managed and cannot be easily extended by other users.
Example: Let's say we write a "Cloud security policy". One of the checks says "Don't expose SSH on containers". We could implement this for AWS, Azure and GCP via variants and release a policy. That policy would not answer the check "Don't expose SSH on containers" for all 3 managed clouds. However, it wouldn't easily be extensible. Someone outside of Mondoo could not add another cloud coverage to that check without asking us to change our (centrally managed) policy.
Current variants are shaped like this:
Discussion
Our goal is to allow users to extend checks in a decentralized way.
Option A:
We leave the variant container empty, i.e. it has no specific queries that it implements. It also doesn't require any filters.
Then we implement queries that attach to the container, which can come from the same or a different policy or bundle:
This can also report into multiple variant queries:
cloud-policy
, without activating any specific e.g.aws-policy
. We now runcloud-ssh-check
as the variant container, but we don't haveaws-ssh-check
in the execution. In this case we get an unknown status forcloud-ssh-check
aws-policy
, but not the generic policy. In this case all referenced checks (e.g. includingaws-ssh-check
) are executed and collected. However no reporting intocloud-ssh-check
is done because we didn't activatecloud-policy
cloud-policy
and specificaws-policy
. Now that we have bothcloud-ssh-check
andaws-ssh-check
in the run, the latter reports into the former and we get results for bothvariants: ...
approach listed aboveClarification
Reporting: If a base and variant query both are present in an execution we
cloud-ssh-check
)cloud-ssh-check
andaws-ssh-check
)Scoring: If both the base and variant policy are selected we
Extensions: Additional mappings:
aws-ssh-check
can map to other policies, but not the other way around)aws-ssh-check
) as well as authors who manage overlays of this query (eg in an overlay policy) can extend existing mappings. However: mappings cannot be removed, they can only be extended.action
field.Illustration of example c:
Solution
...
The text was updated successfully, but these errors were encountered: