Initial refactor for domains and providers

demo/oscal-component-kyverno.yaml

@@ -1,4 +1,3 @@
-# add the descriptions inline
 component-definition:
   uuid: E6A291A4-2BC8-43A0-B4B2-FD67CAAE1F8F
   metadata:
@@ -46,18 +45,20 @@ component-definition:
       rlinks:
         - href: lula.dev
       description: >-
-        target:
-          provider: kyverno
-          domain: kubernetes
-          payload:
+        domain:
+          type: kubernetes
+          kubernetes-spec:
             resources:
             - name: podsvt                      # Identifier for use in the rego below
               resource-rule:                     # Mandatory, resource selection criteria, at least one resource rule is required
                 group:                          # empty or "" for core group
                 version: v1                     # Version of resource
                 resource: pods                  # Resource type
                 namespaces: [validation-test]   # Namespaces to validate the above resources in. Empty or "" for all namespaces or non-namespaced resources
-            kyverno:
+        provider:
+          type: kyverno
+          kyverno-spec:
+            policy:
               apiVersion: json.kyverno.io/v1alpha1
               kind: ValidatingPolicy
               metadata:

demo/oscal-component-opa.yaml

@@ -1,11 +1,10 @@
-# add the descriptions inline
 component-definition:
   uuid: E6A291A4-2BC8-43A0-B4B2-FD67CAAE1F8F
   metadata:
     title: Lula Demo
     last-modified: '2022-09-13T12:00:00Z'
     version: "20220913"
-    oscal-version: 1.1.1
+    oscal-version: 1.1.1 # This version should remain one version behind latest version for `lula dev upgrade` demo
     parties:
       # Should be consistent across all of the packages, but where is ground truth?
     - uuid: C18F4A9F-A402-415B-8D13-B51739D689FF
@@ -46,17 +45,19 @@ component-definition:
       rlinks:
         - href: lula.dev
       description: >-
-        target:
-          provider: opa
-          domain: kubernetes
-          payload:
+        domain:
+          type: kubernetes
+          kubernetes-spec:
             resources:
-            - name: podsvt                      # Identifier for use in the rego below
-              resource-rule:                     # Mandatory, resource selection criteria, at least one resource rule is required
-                group:                          # empty or "" for core group
-                version: v1                     # Version of resource
-                resource: pods                  # Resource type
-                namespaces: [validation-test]   # Namespaces to validate the above resources in. Empty or "" for all namespaces or non-namespaced resources
+            - name: podsvt 
+              resource-rule:   
+                group: 
+                version: v1
+                resource: pods
+                namespaces: [validation-test] 
+        provider: 
+          type: opa
+          opa-spec:
             rego: |
               package validate
 

docs/kubernetes-domain.md

@@ -9,7 +9,7 @@ The validation performed when using the Kubernetes domain is as follows:
 ```yaml
 resources:
 - name: podsvt                      # Required - Identifier for use in the rego below
-  resource-rule:                     # Required - resource selection criteria, at least one resource rule is required
+  resource-rule:                    # Required - resource selection criteria, at least one resource rule is required
     name:                           # Optional - Used to retrieve a specific resource in a single namespace
     group:                          # Required - empty or "" for core group
     version: v1                     # Required - Version of resource
@@ -48,17 +48,19 @@ When Lula retrieves all targeted resources (bounded by namespace when applicable
 
 Let's get all pods in the `validation-test` namespace and evaluate them with the OPA provider:
 ```yaml
-target:
-  provider: opa
-  domain: kubernetes
-  payload:
+domain: 
+  type: kubernetes
+  kubernetes-spec:
     resources:
     - name: podsvt
       resource-rule:
         group:
         version: v1
         resource: pods
         namespaces: [validation-test]
+provider: 
+  type: opa
+  opa-spec:
     rego: |
       package validate
 
@@ -73,15 +75,14 @@ target:
 ```
 
 > [!IMPORTANT]
-> Note how the payload contains a list of items that can be iterated over. The `podsvt` field is the name of the field in the payload that contains the list of items.
+> Note how the rego evaluates a list of items that can be iterated over. The `podsvt` field is the name of the field in the kubernetes-spec.resources that contains the list of items.
 
 Now let's retrieve a single pod from the `validation-test` namespace:
 
 ```yaml
-target:
-  provider: opa
-  domain: kubernetes
-  payload:
+domain: 
+  type: kubernetes
+  kubernetes-spec:
     resources:
     - name: podvt
       resource-rule:
@@ -90,6 +91,9 @@ target:
         version: v1
         resource: pods
         namespaces: [validation-test]
+provider: 
+  type: opa
+  opa-spec:  
     rego: |
       package validate
 
@@ -100,17 +104,16 @@ target:
 ```
 
 > [!IMPORTANT]
-> Note how the payload now contains a single object called `podvt`. This is the name of the resource that is being validated.
+> Note how the rego now evaluates a single object called `podvt`. This is the name of the resource that is being validated.
 
 ## Extracting Resource Field Data
 Many of the tool-specific configuration data is stored as json or yaml text inside configmaps and secrets. Some valuable data may also be stored in json or yaml strings in other resource locations, such as annotations. The "Field" parameter of the "ResourceRule" allows this data to be extracted and used by the Rego.
 
 Here's an example of extracting `config.yaml` from a test configmap:
 ```yaml
-target:
-  provider: opa
-  domain: kubernetes
-  payload:
+domain: 
+  type: kubernetes
+  kubernetes-spec:
     resources:
     - name: configdata
       resource-rule:
@@ -122,6 +125,9 @@ target:
         field:
           jsonpath: .data.my-config.yaml
           type: yaml
+provider: 
+  type: opa
+  opa-spec:
     rego: |
       package validate
 

docs/kyverno-provider.md

@@ -1,25 +1,27 @@
 # Kyverno Provider
 
-The Kyverno provider provides Lula with the capability to evaluate the `domain` in target against a rego policy. 
+The Kyverno provider provides Lula with the capability to evaluate the `domain` in against a Kyverno policy. 
 
 ## Payload Expectation
 
-The validation performed should be in the form of provider, domain, and payload.
+The validation performed should use the form of provider with the `type` of `kyverno` and using the `kyverno-spec`, along with a valid domain.
 
 Example:
 ```yaml
-target:
-  provider: kyverno
-  domain: kubernetes
-  payload:
+domain: 
+  type: kubernetes
+  kubernetes-spec:
     resources:
     - name: podsvt
       resource-rule:
         group:
         version: v1
         resource: pods
         namespaces: [validation-test]
-    kyverno:
+provider: 
+  type: kyverno
+  kyverno-spec:
+    policy:
       apiVersion: json.kyverno.io/v1alpha1          # Required
       kind: ValidatingPolicy                        # Required
       metadata:
@@ -48,20 +50,22 @@ target:
                           (ends_with(@, ':latest')): false
 ```
 
-You can have mutiple policies defined. Optionally, `output.validation` can be specified in the `payload` to control which (Policy, Rule) pair control validation allowance/denial, which is in the structure of a comma separated list of rules: `policy-name1.rule-name-1,policy-name-1.rule-name-2`. If you have a desired observation to include, `output.observations` can be added to payload to observe violations by a certain (Policy, Rule) pair such as:
+You can have mutiple policies defined. Optionally, `output.validation` can be specified in the `kyverno-spec` to control which (Policy, Rule) pair control validation allowance/denial, which is in the structure of a comma separated list of rules: `policy-name1.rule-name-1,policy-name-1.rule-name-2`. If you have a desired observation to include, `output.observations` can be added to payload to observe violations by a certain (Policy, Rule) pair such as:
 ```yaml
-target:
-  provider: "kyverno"
-  domain: "kubernetes"
-  payload:
+domain: 
+  type: kubernetes
+  kubernetes-spec:
     resources:
     - name: podsvt
       resource-rule: 
         group: 
         version: v1 
         resource: pods
         namespaces: [validation-test] 
-    kyverno:
+provider: 
+  type: kyverno
+  kyverno-spec:
+    policy:
       apiVersion: json.kyverno.io/v1alpha1
       kind: ValidatingPolicy
       metadata:

docs/opa-provider.md

@@ -1,24 +1,26 @@
 # OPA Provider
 
-The OPA provider provides Lula with the capability to evaluate the `domain` in target against a rego policy. 
+The OPA provider provides Lula with the capability to evaluate the `domain` against a rego policy. 
 
 ## Payload Expectation
 
-The validation performed should be in the form of provider, domain, and payload.
+The validation performed should use the form of provider with the `type` of `opa` and using the `opa-spec`, along with a valid domain.
 
 Example:
 ```yaml
-target:
-  provider: opa
-  domain: kubernetes
-  payload:
+domain: 
+  type: kubernetes
+  kubernetes-spec:
     resources:
     - name: podsvt
       resource-rule:
         group:
         version: v1
         resource: pods
         namespaces: [validation-test]
+provider:
+  type: opa
+  opa-spec:
     rego: |                                   # Required - Rego policy used for data validation
       package validate                        # Required - Package name
 
@@ -31,17 +33,19 @@ target:
       }
 ```
 
-Optionally, an `output` can be specified in the `payload`. Currently, the default validation allowance/denial is given by `validate.validate`, which is really of the structure `<package-name>.<json-path-to-boolean-variable>`. If you have a desired alternative validation boolean variable, as well as additional observations to include, an output can be added to payload such as:
+Optionally, an `output` can be specified in the `opa-spec`. Currently, the default validation allowance/denial is given by `validate.validate`, which is really of the structure `<package-name>.<json-path-to-boolean-variable>`. If you have a desired alternative validation boolean variable, as well as additional observations to include, an output can be added such as:
 ```yaml
-target:
-  provider: "opa"
-  domain: "kubernetes"
-  payload:
+domain: 
+  type: kubernetes
+  kubernetes-spec:
     resource-rules: 
     - group: 
       version: v1 
       resource: pods
       namespaces: [validation-test] 
+provider:
+  type: opa
+  opa-spec:
     rego: |
       package mypackage 
 
@@ -102,4 +106,4 @@ rego: |
 ```
 
 > [!IMPORTANT]
-> `package validate` and `validate` are required package and rule for Lula use currently. 
+> `package validate` and `validate` are required package and rule for Lula use currently when an output.validation value has not been set. 

docs/version-specification.md

@@ -7,17 +7,19 @@ In cases where a specific version of Lula is desired, either for typing constrai
     No outputs in payload
   description: |
     lula-version: ">=0.0.2"
-    target:
-      provider: opa
-      domain: kubernetes
-      payload:
+    domain: 
+      type: kubernetes
+      kubernetes-spec:
         resources:
         - name: podsvt
           resource-rule:
             group:
             version: v1
             resource: pods
             namespaces: [validation-test]
+    provider:
+      type: opa
+      opa-spec:
         rego: |                                   
           package validate