Support for "meta" policies - groups of policies

[GuillaumeRoss]

Goal

TODO Fleet currently supports policies, which are essentially saved queries that return output if successful, or nothing. Fleet considers it a success if there is output, a failure otherwise. This is useful for implementing policies like "Are all of my laptops encrypted?".

However, it becomes limiting in scenarios where multiple queries are required to answer a question. For example, an org using Fleet for Mac and Windows laptops needs two policies to track full disk encryption status on them, as the Mac and Windows tables and data for checking this are completely different.

There are also scenarios where someone might want to implement a policy that is made of MANY checks, for example, the CIS Benchmarks. Currently, each check would be separate, and there is no way to see the overall compliance levels of systems, in the UI or API, without checking every single policy.

How?

A type of "meta" policy could be created, which would be a grouping of policies. In our encryption example above, we would have:

• Meta policy called "Full disk encryption enabled"
• A Mac policy with a query checking the status of Filevault linked to the meta policy, filtered to run on Macs.
• A Windows policy with a query checking the status of Bitlocker, filtered to run on Windows.
• A Linux policy with a query checking the status of LUKS, filtered to run on Linux laptops.

Then, we could easily see the total compliance with "Full disk encryption enabled" by seeing the totals of successes and failures for all 3 operating systems together.

For the CIS Benchmark example, you would have queries per operating systems, similar to the full disk encryption example, but you would likely have dozens and dozens of queries for each OS. The meta policy and atomic policies would again be linked together and filtered, except in this case, some multiple atomic policies would target the same machines (ex: 12 queries for macOS). We'd then need to show at the top level, which machines are fully compliant and NOT fully compliant, and let the user drill down so they can identify which machine is failing which policy.

I think the design of the UX is extremely important for this, if we decided to do it, as well as the design of APIs to support this cleanly with as little impact as possible on existing policies.

[GuillaumeRoss]

@noahtalerman as discussed yesterday!