Document output states

Also describe how tests can be omitted by editing the YAML

README.md

@@ -114,6 +114,13 @@ For each type of node (*master*, *node* or *federated*) there is a list of compo
 * **confs** - If one of the listed config files is found, this will be considered for the test. Tests can continue even if no config file is found. If no file is found at any of the listed locations, and a *defaultconf* location is given for the component, the test will give remediation advice using the *defaultconf* location.
 * **unitfiles** - From version 1.2.0 of the benchmark  (tests for Kubernetes 1.8), the remediation instructions were updated to assume that kubelet configuration is defined in a service file, and this setting defines where to look for that configuration.
 
+## Output
+
+There are three output states
+- [PASS] and [FAIL] indicate that a test was run successfully, and it either passed or failed
+- [WARN] means this test needs further attention, for example it is a test that needs to be run manually 
+- [INFO] is informational output that needs no further action.
+
 ## Test config YAML representation
 The tests are represented as YAML documents (installed by default into ./cfg).
 
@@ -146,6 +153,20 @@ Recommendations (called `checks` in this document) can run on Kubernetes Master,
 Checks are organized into `groups` which share similar controls (things to check for) and are grouped together in the section of the CIS Kubernetes document.
 These groups are further organized under `controls` which can be of the type `master`, `node` or `federated apiserver` to reflect the various Kubernetes node types.
 
+### Omitting checks
+
+If you decide that a recommendation is not appropriate for your environment, you can choose to omit it by editing the test YAML file to give it the check type `skip` as in this example: 
+
+```yaml
+  checks:
+  - id: 2.1.1
+    text: "Ensure that the --allow-privileged argument is set to false (Scored)"
+    type: "skip"
+    scored: true
+```
+
+No tests will be run for this check and the output will be marked [INFO].
+
 ## Tests
 Tests are the items we actually look for to determine if a check is successful or not. Checks can have multiple tests, which must all be successful for the check to pass.
 
@@ -188,4 +209,4 @@ Next you'll have to build the kube-bench docker image using `make build-docker`,
 
 Finally we can use the `make kind-run` target to run the current version of kube-bench in the cluster and follow the logs of pods created. (Ctrl+C to exit)
 
-Everytime you want to test a change, you'll need to rebuild the docker image and push it to cluster before running it again. ( `make build-docker kind-push kind-run` )
+Everytime you want to test a change, you'll need to rebuild the docker image and push it to cluster before running it again. ( `make build-docker kind-push kind-run` )