Dynamic policy composition

[anderseknert]

This adds dynamic routing / policy compositon based on the input.resource.type, mapping something like AWS::S3::Bucket to the data.aws.s3.bucket package, where the deny rule(s) will be evaluated, and the result aggregated into the decision. Moved and remodeled the policies and tests to work with this.

Since it's been a while since I worked a full day on policy authoring, here are some random thoughts and findings from this experience:

• Metadata annotations are really nice! Thanks @johanfylling :)
• However, opa inspect -a wasn't intuitive to me for this purpose. It still seems to want a bundle file, although I'm only interested in inspecting annotations in my rego files.
• With policies mapped to a single resource type, being able to use JSON schema for input validation would be killer. But once again we're burnt by the "booleans are strings" fiasco.
• Random idea around annotations - it would be nice to be able to reference the package name from inside an inherited annotation, particularly when using schemas, i.e, something like:

# METADATA
# scope: subpackages
# schemas:
#   - input: schema["${self.package.name}"]
package aws

That way we could apply schemas to all subpackages with a single declaration 🤯 🚀

• opa fmt is pretty annoying, in particular for test files where we construct lots of maps manually. These don't take line length into account, and sometimes makes a well structured map compressed into a single 300 chars long line 🤦
• Wrt opa fmt, also got burnt by opa fmt indentation issues with with/as statements open-policy-agent/opa#4376
• Created some test helpers for getting to know what failed in tests (by simply printing expectation vs reality), and those are definitely a keeper until we have that in OPA proper!
• The new "future" keywords are very nice to use.

[tsandall]

Left a couple minor comments. I think we'll need to test out this composition model with the system type framework in DAS.

[tsandall]

What if there are multiple elements in the security group ingress collection? Should we use some instead?

some ingress in input.resource.properties.SecurityGroupIngress
ingress.CidrIp == "0.0.0.0/0"

[anderseknert]

Heh, yeah I thought of this too when I read this today, and made a note to check later (I only moved this code). Will follow up on this after the PR.