feat(domains): file domain

[mildwonkey]

Description

This adds a files domain which use's OPA's conftest parser to read in a long list of configuration file types * so that rego validations can be written against the contents.

domain:
  type: file
  file-spec:
    filepaths:
    - name: grafna-config
       path: badconfig.ini

I'm not thrilled with the UX right now and I'm not sure what I want to do about it, so here's a draft PR so we can discuss! The file domain takes an array of files, but the implications are that the output DomainResources map uses the file name as a key, so you need to include the filename in the validation:

      package validate
      import rego.v1

      # Default values
      default validate := false
      default msg := "Not evaluated"
      
      validate if {
       check_grafana_config.result
      }
      msg = check_grafana_config.msg
      
      check_grafana_config = {"result": true, "msg": msg} if {
        config := input["badconfig.ini"]
        protocol := config.server.protocol
        protocol == "https"
        msg := "Server protocol is set to https"
      } else = {"result": false, "msg": msg} if {
        config := input["badconfig.ini"]
        protocol := config.server.protocol
        protocol == "http"
        msg := "Protocol is http. That's bad, mmkay?"
      }

I can make a nice list of arguments why this is good, and why this is bad: on the one hand, we don't risk collision if multiple files have the same field. On the other hand, maybe it's ok if the files domain can only read a single file at a time and then we can leave the filename out of the map, or if we choose to merge all the data into a single "file" first. Both feel like big footguns to me. In the former case - it's entirely valid to have for e.g. a dozen terraform files where one will do. you still want to validate it all at once. in the latter - who's responsibility is it to ensure we aren't losing data due to collisions?.

Also this still needs work, tests, and documentation.

From https://www.conftest.dev/:

As of today Conftest supports:

CUE
CycloneDX
Dockerfile
EDN
Environment files (.env)
HCL and HCL2
HOCON
Ignore files (.gitignore, .dockerignore)
INI
JSON
Jsonnet
Property files (.properties)
SPDX
TextProto (Protocol Buffers)
TOML
VCL
XML
YAML

Related Issue

Relates to # #337

• Creation of a files domain
• Ability to specify a file path (local or remote) in a validation
  • local
  • remote
• Ability to process a json file (otherwise error)
• Ability for each provider to accurately evaluate the data
  • OPA
  • Kyverno

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Schema Updates applied
• Contributor Guide Steps followed

[brandtkeller]

I appreciate the direction this is driving and the conciseness of the current implementation.

Your identified constraints for what we do/do-not allow are certainly worth working through. I believe we're at a phase where constraints are valid if documented such that we can point to them - but would love to continue to weigh approaches.

When it comes to testing - I do want to call out that this should work with any provider - the conftest/opa overlay is obviously very opa heavy (as is much of our implementation with Lula - as OPA/rego is quite powerful) but we do want to ensure we're also testing against the Kyverno baseline. Something we need to practice more often.

[mildwonkey]

@brandtkeller yep! I am VERY CONCERNED about how this works with kyverno - honestly I am a bit surprised by how separate the domains and providers are, because I can see a world where certain providers can only support certain domains, or where the domain resources need to be gathered by the provider so we're certain we're getting a provider-compliant output. That concerns me!

[meganwolf0]

we do want to ensure we're also testing against the Kyverno baseline

Does kyverno polices support any data schema or just Kubernetes resources? I should probably know the answer but a quick parsing of their docs seems to indicate it's highly coupled to that format... if so I don't know how we'd use it here

[mildwonkey]

we do want to ensure we're also testing against the Kyverno baseline

Does kyverno polices support any data schema or just Kubernetes resources? I should probably know the answer but a quick parsing of their docs seems to indicate it's highly coupled to that format... if so I don't know how we'd use it here

kyverno-json can be used with any arbitrary json-formatted data, so it does work reasonably well with the output of DomainResources. The UX is icky though, IMO, but I barely know kyverno and OPA so I'm hoping I come to like it with time (and of course as far as I know I'm doing this the clunkiest way possible):

provider:
  type: kyverno
  kyverno-spec:
    policy:
      apiVersion: json.kyverno.io/v1alpha1
      kind: ValidatingPolicy
      metadata:
        name: grafana-config
      spec:
        rules:
        - name: protocol-is-https
          assert:
            all:
            - check:
                goodconfig.ini:
                  server:
                    protocol: https

[brandtkeller]

Appreciative of the code comments and not withstanding the mention of E2E tests am quite excited about this capability.

[brandtkeller]

We don't yet have a good pattern for the mapping of domain -> provider.

That said - I do like the Kyverno example below. Could we add an OPA provider example as well?

[mildwonkey]

I don't think the writing is very good but I added an OPA example! please nitpick freely.

[mildwonkey]

I'm still working on this, but I'm going to split it up into a couple of smaller PRs (probably, either way I'm cleaning this mess up)(messing with directories is always a fun time)