documentation updates

samples/README.md

@@ -1,6 +1,6 @@
 # Best Practice Policies
 
-Best practice policies are recommended policies that can be applied to yoru Kubernetes clusters with minimal changes. To import these policies [install Kyverno](../documentation/installation.md) and import the resources as follows:
+Best practice policies are recommended policies that can be applied to your Kubernetes clusters with minimal changes. To import these policies [install Kyverno](../documentation/installation.md) and import the resources as follows:
 
 ````bash
 kubectl create -f https://github.com/nirmata/kyverno/raw/master/samples/best_practices/
@@ -11,7 +11,7 @@ More information on each best-practice policy is provided below:
 
 ## Run as non-root user
 
-By default, processes in a container run as a root user (uid 0). To prevent compromising the host, a best practice is to specify a least privileged user ID when building the container image, and require that application containers run as non root users. 
+By default, processes in a container run as a root user (uid 0). To prevent compromising the host, a best practice is to specify a least-privileged user ID when building the container image, and require that application containers run as non-root users. 
 
 ***Policy YAML***: [deny_runasrootuser.yaml](best_practices/deny_runasrootuser.yaml) 
 
@@ -21,50 +21,49 @@ By default, processes in a container run as a root user (uid 0). To prevent comp
 
 ## Disallow automounte API credentials
 
-One can access the API from inside a pod using automatically mounted service account credentials by default. To restrict access, opt out of automounting API credentials for any pod by setting `automountServiceAccountToken` to `false`.
+One can access the API from inside a pod using automatically mounted service account credentials by default. To restrict access, opt-out of automounting API credentials for any pod by setting `automountServiceAccountToken` to `false`.
 
 ***Policy YAML***: [disallow_automountingapicred.yaml](best_practices/disallow_automountingapicred.yaml) 
 
 
 ## Disallow use of default namespace
 
-Namespaces are a way to divide cluster resources between multiple users. When multiple users or teams are sharing a single cluster, it is recommended to isolate different workloads and aviod using default namespace.
+Namespaces are a way to divide cluster resources between multiple users. When multiple users or teams are sharing a single cluster, it is recommended to isolate different workloads and avoid using default namespace.
 
 ***Policy YAML***: [disallow_default_namespace.yaml](best_practices/disallow_default_namespace.yaml) 
 
 
 ## Disallow use of host filesystem
-
-Using the volume of type hostpath can easily lose data when a node crashes. Disable use of hostpath prevent data loss. 
+The volume of type `hostpath` bounds the pods to host, and data persisted in the volume is based on the life of the node. It is suggested to disable the use of a volume of type hostpath.
 
 ***Policy YAML***: [disallow_host_filesystem.yaml](best_practices/disallow_host_filesystem.yaml) 
 
 
 ## Disallow `hostNetwork` and `hostPort`
 
-Using `hostPort` and `hostNetwork` limits the number of nodes the pod can be scheduled on, as the pod is bound to the host thats its mapped to.
+Using `hostPort` and `hostNetwork` limits the number of nodes the pod can be scheduled on, as the pod is bound to the host node. 
 To avoid this limitation, use a validate rule to make sure these attributes are set to null and false.
 
 ***Policy YAML***: [disallow_host_network_hostport.yaml](best_practices/disallow_host_network_hostport.yaml)
 
 ## Disallow `hostPID` and `hostIPC`
 
-Sharing the host's PID namespace allows vibility of process on the host, potentially exposing porcess information. 
-Sharing the host's IPC namespace allows container process to communicate with processes on the host. 
-To avoid pod container from having visilbility to host process space, we can check `hostPID` and `hostIPC` are set as `false`.
+Sharing the host's PID namespace allows visibility of process on the host, potentially exposing process information. 
+Sharing the host's IPC namespace allows the container process to communicate with processes on the host. 
+To avoid pod container from having visibility to host process space, we can check `hostPID` and `hostIPC` are set as `false`.
 
 ***Policy YAML***: [disallow_hostpid_hostipc.yaml](best_practices/disallow_hostpid_hostipc.yaml)
 
 ## Disallow node port
 
 Node port ranged service is advertised to the public and can be scanned and probed from others exposing all nodes.
-NetworkPolicy resources can currently only control NodePorts by allowing or disallowing all traffic on them. Unless required it is recommend to disable use to service type `NodePort`.
+NetworkPolicy resources can currently only control NodePorts by allowing or disallowing all traffic on them. Unless required, it is recommended to disable use to service type `NodePort`.
 
 ***Policy YAML***: [disallow_node_port.yaml](best_practices/disallow_node_port.yaml)
 
 ## Disable privileged containers
 
-A process within priveleged containers get almost the same priveleges that are available to processes outside a container providing almost unrestricited host access. With `securityContext.allowPrivilegeEscalation` enabled the process can gain ore priveleges that its parent.
+A process within privileged containers gets almost the same privileges that are available to processes outside a container providing almost unrestricted host access. With `securityContext.allowPrivilegeEscalation` enabled the process can gain ore privileges that its parent.
 To restrcit the priveleges it is recommend to run pod containers with `securityContext.priveleged` as `false` and 
 `allowPrivilegeEscalation` as `false`
 
@@ -72,20 +71,20 @@ To restrcit the priveleges it is recommend to run pod containers with `securityC
 
 ## Default deny all ingress traffic
 
-When no policies exist in a namespace, Kubernetes allows all ingress and egress traffic to and from pods in that namespace. A "default" isolation policy for a namespace denys any ingress traffic to the pods in that namespace, this ensures that even pods that aren’t selected by any other NetworkPolicy will still be isolated.
+When no policies exist in a namespace, Kubernetes allows all ingress and egress traffic to and from pods in that namespace. A "default" isolation policy for a namespace denies any ingress traffic to the pods in that namespace, this ensures that even pods that aren’t selected by any other NetworkPolicy will still be isolated.
 
 ***Policy YAML***: [require_default_network_policy.yaml](best_practices/require_default_network_policy.yaml)
 
 ## Disallow latest image tag
 
-Using the `:latest` tag when deploying containers in production makes it harder to track which version of the image is running and more difficult to roll back properly. Specifying a none latest image tag prevents a lot of errors from occurring when versions are mismatched.
+Using the `:latest` tag when deploying containers in production makes it harder to track which version of the image is running and more challenging to roll back properly. Specifying a none latest image tag prevents a lot of errors from occurring when versions are inconsistent.
 
 ***Policy YAML***: [require_image_tag_not_latest.yaml](best_practices/require_image_tag_not_latest.yaml)
 
 
 ## Default namesapce quotas
 
-In order to limit the quantity of objects, as well as the total amount of compute resources that may be consumed by an application, it is essential to create one resource quota for each namespace by cluster administrator.
+To limit the number of objects, as well as the total amount of compute resources that may be consumed by an application, it is essential to create one resource quota for each namespace by the cluster administrator.
 
 **Additional Information**
 * [Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
@@ -95,27 +94,30 @@ In order to limit the quantity of objects, as well as the total amount of comput
 
 ## Require pod resource requests and limits
 
-As workloads share the host cluster, it is essential to administer and limit resources requested and consumed by the pod. It is a good practice to always specify `resources.requests` and `resources.limits` per pod.
+As workloads share the host cluster, it is essential to administer and limit resources requested and consumed by the pod. It is a good practice always to specify `resources.requests` and `resources.limits` per pod.
 
 ***Policy YAML***: [require_pod_requests_limits.yaml](best_practices/require_pod_requests_limits.yaml)
 
 ## Default health probe
 
-Setting the health probe ensures an application is highly-avaiable and resilient. Health checks are a simple way to let the system know if an application is broken, and it helps the application quickly recover from failure.
+Health checks mechanism available in kubernetes:
+- `livenessProbe` is carried out by the kubelet to determine when to restart a container
+- `readinessProbe` is used by services and deployments to determine if the pod should recieve traffic.
+Its recommended to define them in pod manifests.
 
 ***Policy YAML***: [require_probes.yaml](best_practices/require_probes.yaml)
 
 
 ## Read-only root filesystem
 
-A read-only root file system helps to enforce an immutable infrastrucutre strategy, the container only need to write on mounted volume that persist the state. An immutable root filesystem can also prevent malicious binaries from writing to the host system.
+A read-only root file system helps to enforce an immutable infrastructure strategy; the container only needs to write on the mounted volume that persists the state. An immutable root filesystem can also prevent malicious binaries from writing to the host system.
 
 ***Policy YAML***: [require_readonly_rootfilesystem.yaml](best_practices/require_readonly_rootfilesystem.yaml)
 
 
 ## Trusted image registries
 
-Images from unrecognized registry can introduce complexity to maintain the application. By specifying trusted registries help reducing such complexity. Follow instructoin [here](https://github.com/nirmata/kyverno/blob/master/documentation/writing-policies-validate.md#operators) to add allowed registries using `OR` operator.
+Images from the unrecognized registry can introduce complexity to maintain the application. By specifying trusted registries help to reduce such complexity. Follow instructions [here](https://github.com/nirmata/kyverno/blob/master/documentation/writing-policies-validate.md#operators) to add allowed registries using `OR` operator.
 
 ***Policy YAML***: [trusted_image_registries.yaml](best_practices/trusted_image_registries.yaml) 
 
@@ -124,23 +126,23 @@ Images from unrecognized registry can introduce complexity to maintain the appli
 Additional policies list some policies that can also assist in maintaing kubernetes clusters.
 
 ## Assign Linux capabilities inside Pod
-Linux divides the privileges traditionally, associated with superuser into distinct units, known as capabilities, which can be independently enabled or disabled by listing them in `securityContext.capabilites`. 
+Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled or disabled by listing them in `securityContext.capabilites`. 
 
 
-***Policy YAML***: [policy_validate_container_capabilities.yaml](best_practices/policy_validate_container_capabilities.yaml)
+***Policy YAML***: [policy_validate_container_capabilities.yaml](additional/policy_validate_container_capabilities.yaml)
 
 **Additional Information**
 * [List of linux capabilities](https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h)
 
 ## Check userID, groupIP & fsgroup used inside a Pod
-All processes inside the pod can be made to run with specific user and groupID by setting runAsUser and runAsGroup respectively. fsGroup can be specified to make sure any file created in the volume with have the specified groupID. These options can be used validate the IDs used for user and group.
+All processes inside the pod can be made to run with specific user and groupID by setting `runAsUser` and `runAsGroup` respectively. `fsGroup` can be specified to make sure any file created in the volume with have the specified groupID. These options can be used to validate the IDs used for user and group.
 
-***Policy YAML***: [policy_validate_container_capabilities.yaml](best_practices/policy_validate_user_group_fsgroup_id.yaml)
+***Policy YAML***: [policy_validate_container_capabilities.yaml](additional/policy_validate_user_group_fsgroup_id.yaml)
 
 ## Configure kernel parameters inside pod
-Sysctl interface allows to modify kernel parameters at runtime and in the pod can be specified under `securityContext.sysctls`. If kernel parameters in the pod are to be modified should be handled cautiosly, and a policy with rules restricting these options will be helpful. We can control minimum and maximum port that a network connection can use as its source(local) port by checking net.ipv4.ip_local_port_range
+The Sysctl interface allows to modify kernel parameters at runtime and in the pod can be specified under `securityContext.sysctls`. If kernel parameters in the pod are to be modified, should be handled cautiously, and policy with rules restricting these options will be helpful. We can control minimum and maximum port that a network connection can use as its source(local) port by checking net.ipv4.ip_local_port_range
 
-***Policy YAML***: [policy_validate_container_capabilities.yaml](best_practices/policy_validate_user_group_fsgroup_id.yaml)
+***Policy YAML***: [policy_validate_container_capabilities.yaml](additional/policy_validate_user_group_fsgroup_id.yaml)
 
 **Additional Information**
 * [List of supported namespaced sysctl interfaces](https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/) 

samples/additional/policy_validate_container_capabilities.yaml

@@ -11,7 +11,7 @@ spec:
         kinds:
         - Pod
     validate:
-      message: "Allow certain capability to be added"
+      message: "Allow certain linux capability"
       pattern:
         spec:
           containers:

samples/additional/policy_validate_fsgroup.yaml

@@ -0,0 +1,22 @@
+apiVersion: kyverno.io/v1alpha1
+kind: ClusterPolicy
+metadata:
+  name: validate-fsgroup
+spec:
+  validationFailureAction: "audit"
+  rules:
+  - name: validate-fsgroup
+    exclude:
+      resources:
+        namespaces: 
+        - kube-system
+    match:
+      resources:
+        kinds:
+        - Pod
+    validate:
+      message: "directory should have group ID 2000"
+      pattern:
+        spec:
+          securityContext:
+            fsGroup: 2000

samples/additional/policy_validate_user_group_fsgroup_id.yaml

@@ -10,7 +10,7 @@ spec:
         kinds:
         - Pod
     validate:
-      message: "user ID should be 1000"
+      message: "User ID should be 1000"
       pattern:
         spec:
           securityContext:
@@ -21,7 +21,7 @@ spec:
         kinds:
         - Pod
     validate:
-      message: "group ID should be 3000"
+      message: "Group ID should be 3000"
       pattern:
         spec:
           securityContext:

samples/best_practices/disallow_default_namespace.yaml

@@ -10,7 +10,7 @@ spec:
         kinds:
         - Pod
     validate:
-      message: "A none 'default' namespace is required"
+      message: "Using 'default' namespace is restricted"
       pattern:
         metadata:
           namespace: "!default"

samples/best_practices/disallow_host_network_hostport.yaml

@@ -10,7 +10,7 @@ spec:
         kinds:
         - Pod
     validate:
-      message: "hostNetwork and hostPort are not allowed"
+      message: "Defining hostNetwork and hostPort are not allowed."
       pattern:
         spec:
           (hostNetwork): false

samples/best_practices/disallow_priviledged_priviligedescalation.yaml

@@ -5,7 +5,6 @@ metadata:
 spec:
   rules:
   - name: deny-privileged-priviligedescalation
-    exclude:
     match:
       resources:
         kinds:

samples/best_practices/policy_validate_deny_runasrootuser.yaml

@@ -0,0 +1,23 @@
+apiVersion: kyverno.io/v1alpha1
+kind: ClusterPolicy
+metadata:
+  name: validate-deny-runasrootuser
+spec:
+  validationFailureAction: "audit"
+  rules:
+  - name: deny-runasrootuser
+    match:
+      resources:
+        kinds:
+        - Pod
+    validate:
+      message: "Root user is not allowed. Set runAsNonRoot to true."
+      anyPattern:
+      - spec:
+          securityContext:
+            runAsNonRoot: true
+      - spec:
+          containers:
+          - name: "*"
+            securityContext:
+              runAsNonRoot: true

samples/best_practices/require_default_network_policy.yaml

@@ -18,4 +18,4 @@ spec:
           # select all pods in the namespace
           podSelector: {}
           policyTypes: 
-          - Ingress
+          - Ingress

samples/best_practices/require_image_tag_not_latest.yaml

@@ -10,7 +10,7 @@ spec:
         kinds:
         - Pod
     validate:
-      message: "image tag not specified"  
+      message: "Image tag not specified"  
       pattern:
         spec:
           containers:
@@ -21,7 +21,7 @@ spec:
         kinds:
         - Pod
     validate:
-      message: "set image tag to a specific version"
+      message: "Using 'latest' image tag is restricted. Set image tag to a specific version"
       pattern:
         spec:
           containers:

samples/best_practices/require_pod_requests_limits.yaml

@@ -1,5 +1,5 @@
 apiVersion: kyverno.io/v1alpha1
-kind: Policy
+kind: ClusterPolicy
 metadata:
   name: check-resource
 spec:

test/scenarios/test/scenario_mutate_pod_disable_automountingapicred.yaml

@@ -0,0 +1,19 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_mutate_pod_disable_automountingapicred.yaml
+  resource: examples/best_practices/resources/resource_mutate_pod_disable_automountingapicred.yaml
+expected:
+  mutation:
+    patchedresource: test/output/output_mutate_pod_disable_automoutingapicred.yaml
+    policyresponse:
+      policy: mutate-pod-disable-automoutingapicred
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: myapp-pod
+      rules:
+        - name: pod-disable-automoutingapicred
+          type: Mutation
+          message: "succesfully process overlay"
+          success: true

test/scenarios/test/scenario_valiadate_require_image_tag_not_latest_deny.yaml

@@ -18,5 +18,5 @@ expected:
           success: true
         - name: image-tag-not-latest
           type: Validation
-          message: "Validation rule 'image-tag-not-latest' failed at '/spec/containers/0/image/' for resource Pod//myapp-pod. set image tag to a specific version"
+          message: "Validation rule 'image-tag-not-latest' failed at '/spec/containers/0/image/' for resource Pod//myapp-pod. Using 'latest' image tag is restricted. Set image tag to a specific version"
           success: false   

test/scenarios/test/scenario_valiadate_require_image_tag_not_latest_notag.yaml

@@ -14,7 +14,7 @@ expected:
       rules:
         - name: image-tag-notspecified
           type: Validation
-          message: Validation rule 'image-tag-notspecified' failed at '/spec/containers/0/image/' for resource Pod//myapp-pod. image tag not specified
+          message: Validation rule 'image-tag-notspecified' failed at '/spec/containers/0/image/' for resource Pod//myapp-pod. Image tag not specified
           success: false
         - name: image-tag-not-latest
           type: Validation

test/scenarios/test/scenario_validate_container_capabilities.yaml

@@ -15,5 +15,5 @@ expected:
       rules:
         - name: validate-container-capablities
           type: Validation
-          message: "Validation rule 'validate-container-capablities' failed at '/spec/containers/0/securityContext/capabilities/add/0/' for resource Pod//add-capabilities. Allow certain capability to be added"
+          message: "Validation rule 'validate-container-capablities' failed at '/spec/containers/0/securityContext/capabilities/add/0/' for resource Pod//add-capabilities. Allow certain linux capability"
           success: false

test/scenarios/test/scenario_validate_container_disallow_priviledgedprivelegesecalation.yaml

@@ -0,0 +1,19 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_container_disallow_priviledgedprivelegesecalation.yaml
+  resource: examples/best_practices/resources/resource_validate_container_disallow_priviledgedprivelegesecalation.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-deny-privileged-disallowpriviligedescalation
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: check-privileged-cfg
+      rules:
+        - name: deny-privileged-disallowpriviligedescalation
+          type: Validation
+          message: "Validation rule 'deny-privileged-disallowpriviligedescalation' failed to validate patterns defined in anyPattern. Privileged mode is not allowed. Set allowPrivilegeEscalation and privileged to false; anyPattern[0] failed at path /spec/securityContext/; anyPattern[1] failed at path /spec/containers/0/securityContext/allowPrivilegeEscalation/"
+          success: false
+

test/scenarios/test/scenario_validate_default_namespace.yaml

@@ -0,0 +1,25 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_default_namespace.yaml
+  resource: examples/best_practices/resources/resource_default_namespace.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-namespace
+      resource:
+        kind: Pod
+        apiVersion: v1
+        # this is set to pass resource NS check
+        # actual valiation is defined through rule success=false
+        namespace: 'default'
+        name: myapp-pod
+      rules:
+        - name: check-default-namespace
+          type: Validation
+          message: "Validation rule 'check-default-namespace' failed at '/metadata/namespace/' for resource Pod/default/myapp-pod. A none 'default' namespace is required"
+          success: false
+        - name: check-namespace-exist
+          type: Validation
+          message: "Validation rule 'check-namespace-exist' succesfully validated"
+          success: true
+

test/scenarios/test/scenario_validate_disallow_default_namespace.yaml

@@ -16,7 +16,7 @@ expected:
       rules:
         - name: check-default-namespace
           type: Validation
-          message: "Validation rule 'check-default-namespace' failed at '/metadata/namespace/' for resource Pod/default/myapp-pod. A none 'default' namespace is required"
+          message: "Validation rule 'check-default-namespace' failed at '/metadata/namespace/' for resource Pod/default/myapp-pod. Using 'default' namespace is restricted"
           success: false
         - name: check-namespace-exist
           type: Validation

test/scenarios/test/scenario_validate_disallow_host_network_hostport.yaml

@@ -14,5 +14,5 @@ expected:
       rules:
         - name: validate-host-network-hostport
           type: Validation
-          message: "Validation rule 'validate-host-network-hostport' failed at '/spec/containers/0/ports/0/hostPort/' for resource Pod//nginx-host-network. hostNetwork and hostPort are not allowed"
+          message: "Validation rule 'validate-host-network-hostport' failed at '/spec/containers/0/ports/0/hostPort/' for resource Pod//nginx-host-network. Defining hostNetwork and hostPort are not allowed."
           success: false   

test/scenarios/test/scenario_validate_host_network_port.yaml

@@ -0,0 +1,18 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_host_network_port.yaml
+  resource: examples/best_practices/resources/resource_validate_host_netwok_port.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-host-network-port
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: "nginx-host-network"
+      rules:
+        - name: validate-host-network-port
+          type: Validation
+          message: "Validation rule 'validate-host-network-port' failed at '/spec/containers/0/ports/0/hostPort/' for resource Pod//nginx-host-network. Host network and port are not allowed"
+          success: false   

test/scenarios/test/scenario_validate_hostpid_hostipc.yaml

@@ -0,0 +1,18 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_hostpid_hosipc.yaml
+  resource: examples/best_practices/resources/resource_validate_hostpid_hostipc.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-hostpid-hostipc
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: "nginx-with-hostpid"
+      rules:
+        - name: validate-hostpid-hostipc
+          type: Validation
+          message: Validation rule 'validate-hostpid-hostipc' failed at '/spec/hostIPC/' for resource Pod//nginx-with-hostpid. Disallow use of host's pid namespace and host's ipc namespace
+          success: false   

test/scenarios/test/scenario_validate_image_tag_notspecified_deny.yaml

@@ -0,0 +1,18 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_image_tag_notspecified_deny.yaml
+  resource: examples/best_practices/resources/resource_validate_image_tag_notspecified_deny.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-image-tag-notspecified
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: myapp-pod
+      rules:
+        - name: image-tag-notspecified
+          type: Validation
+          message: "Validation rule 'image-tag-notspecified' failed at '/spec/containers/0/image/' for resource Pod//myapp-pod. image tag not specified"
+          success: false    

test/scenarios/test/scenario_validate_image_tag_notspecified_pass.yaml

@@ -0,0 +1,18 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_image_tag_notspecified_deny.yaml
+  resource: examples/best_practices/resources/resource_validate_image_tag_notspecified_pass.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-image-tag-notspecified
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: myapp-pod
+      rules:
+        - name: image-tag-notspecified
+          type: Validation
+          message: "Validation rule 'image-tag-notspecified' succesfully validated"
+          success: true    

test/scenarios/test/scenario_validate_namespace_quota.yaml

@@ -0,0 +1,22 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_namespace_quota.yaml
+  resource: examples/best_practices/resources/resource_validate_namespace_quota.yaml
+expected:
+  generation:
+    generatedResources:
+      - name: defaultresourcequota
+        kind: ResourceQuota
+        namespace: test-namespace-quota
+    policyresponse:
+      policy: validate-namespace-quota
+      resource:
+        kind: Namespace
+        apiVersion: v1
+        namespace: ''
+        name: test-namespace-quota
+      rules:
+        - name: validate-namespace-quota
+          type: Generation
+          success: true
+          message: created resource ResourceQuota/test-namespace-quota/defaultresourcequota

test/scenarios/test/scenario_validate_not_readonly_rootfilesystem.yaml

@@ -0,0 +1,18 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_not_readonly_rootfilesystem.yaml
+  resource: examples/best_practices/resources/resource_validate_not_readonly_rootfilesystem.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-not-readonly-rootfilesystem
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: "ghost-with-readonly-rootfilesystem"
+      rules:
+        - name: validate-not-readonly-rootfilesystem
+          type: Validation
+          message: Validation rule 'validate-not-readonly-rootfilesystem' failed at '/spec/containers/0/securityContext/readOnlyRootFilesystem/' for resource Pod//ghost-with-readonly-rootfilesystem. Container should not have read-only rootfilesystem
+          success: false   

test/scenarios/test/scenario_validate_whitelist_image_registries.yaml

@@ -0,0 +1,18 @@
+# file path relative to project root
+input:
+  policy: examples/best_practices/policy_validate_whitelist_image_registries.yaml
+  resource: examples/best_practices/resources/resource_validate_whitelist_image_registries.yaml
+expected:
+  validation:
+    policyresponse:
+      policy: validate-image-registry
+      resource:
+        kind: Pod
+        apiVersion: v1
+        namespace: ''
+        name: nirmata-nginx
+      rules:
+        - name: validate-image-registry
+          type: Validation
+          message: Validation rule 'validate-image-registry' anyPattern[1] succesfully validated
+          success: true