docs: updated config/template docs

docs/getting-started/README.md

@@ -63,4 +63,8 @@ See the following tutorials for some introductory lessons on how to use Lula. If
 
 Lula Validation manifests are the underlying mechanisms that dictates the evaluation of a system against a control as resulting in `satisfied` or `not satisfied`. A Lula Validation is linked to a control within a component definition via the OSCAL-specific property, [links](../oscal/oscal-validation-links.md).
 
-Developing Lula Validations can sometimes be more art than science, but generally they should aim to be clear, concise, and robust to system changes. See our guide for [developing Lula Validations](./develop-a-validation.md) and the [references](../reference/README.md) for additional information.
+Developing Lula Validations can sometimes be more art than science, but generally they should aim to be clear, concise, and robust to system changes. See our guide for [developing Lula Validations](./develop-a-validation.md) and the [references](../reference/README.md) for additional information.
+
+### Configuration
+
+Lula supports the addition of a configuration file for specifying CLI flags and templating values. See our [configuration](./configuration.md) guide for more information.

docs/getting-started/configuration.md

@@ -0,0 +1,139 @@
+# Configuration
+
+Lula allows the use and specification of a config file in the following ways:
+- Checking current working directory for a `lula-config.yaml` file
+- Specification with environment variable `LULA_CONFIG=<path>`
+
+Environment Variables can be used to specify configuration values through use of `LULA_<VAR>` -> Example: `LULA_TARGET=il5` 
+
+## Identification
+
+If identified, Lula will log which configuration file is used to stdout:
+```bash
+Using config file /home/dev/work/lula/lula-config.yaml
+```
+
+## Precedence
+
+The precedence for configuring settings, such as `target`, follows this hierarchy:
+
+### **Command Line Flag > Environment Variable > Configuration File**
+
+1. **Command Line Flag:**  
+   When a setting like `target` is specified using a command line flag, this value takes the highest precedence, overriding any environment variable or configuration file settings.
+
+2. **Environment Variable:**  
+   If the setting is not provided via a command line flag, an environment variable (e.g., `export LULA_TARGET=il5`) will take precedence over the configuration file.
+
+3. **Configuration File:**  
+   In the absence of both a command line flag and environment variable, the value specified in the configuration file will be used. This will override system defaults.
+
+## Support
+
+Modification of command variables can be set in the configuration file:
+
+lula-config.yaml
+```yaml
+log_level: debug
+target: il4
+summary: true
+```
+
+### Templating Configuration Fields
+
+Templating values are set in the configuration file via the use of `constants` and `variables` fields.
+
+#### Constants
+
+A sample `constants` section of a `lula-config.yaml` file is as follows:
+
+```yaml
+constants:
+  type: software
+  title: lula
+
+  resources:
+    name: test-pod-label
+    namespace: validation-test
+    imagelist:
+      - nginx
+      - nginx2
+```
+
+Constants will respect the structure of a map[string]interface{} and can be referenced as follows:
+
+```yaml
+# validaiton.yaml
+metadata:
+  name: sample {{ .const.type }} validation for {{ .const.title }}
+domain:
+  type: kubernetes
+  kubernetes-spec:
+    resources:
+      - name: myPod
+        resource-rule:
+          name: {{ .const.resources.name }}
+          version: v1
+          resource: pods
+          namespaces: [{{ .const.resources.namespace }}]
+provider:
+  type: opa
+  opa-spec:
+    rego: |
+      package validate
+      import rego.v1
+
+      validate if {
+        input.myPod.metadata.name == {{ .const.resources.name }}
+        input.myPod.containers[_].name in { {{ .const.resources.imagelist | concatToRegoList }} }
+      }
+```
+
+And will be rendered as:
+```yaml
+metadata:
+  name: sample software validation for lula
+domain:
+  type: kubernetes
+  kubernetes-spec:
+    resources:
+      - name: myPod
+        resource-rule:
+          name: myPod
+          version: v1
+          resource: pods
+          namespaces: [validation-test]
+provider:
+  type: opa
+  opa-spec:
+    rego: |
+      package validate
+      import rego.v1
+
+      validate if {
+        input.myPod.metadata.name == "myPod"
+        input.myPod.containers[_].image in { "nginx", "nginx2" }
+      }
+```
+
+The constant's keys should be in the format `.const.<key>` and should not contain any '-' or '.' characters, as this will not respect the go text/template format. 
+
+#### Variables
+
+A sample `variables` section of a `lula-config.yaml` file is as follows:
+
+```yaml
+variables:
+  - key: some_lula_secret
+    sensitive: true
+  - key: some_env_var
+    default: this-should-be-overridden
+```
+
+The `variables` section is a list of `key`, `default`, and `sensitive` fields, where `sensitive` and `default` are optional. The `key` and `default` fields are strings, and the `sensitive` field is a boolean.
+
+A default value can be specified in the case where an environment variable may or may not be set, however an environment variable will always take precedence over a default value.
+
+The environment variable should follow the pattern of `LULA_VAR_<key>` (not case sensitive), where `<key>` is the key specified in the `variables` section.
+
+When using `sensitive` variables, the default behavior is to mask the value in the output of the template.