add env policy section to docs

docs.kosli.com/content/faq/_index.md

@@ -131,8 +131,8 @@ API-TOKEN = "123456abcdef"
 
 When calling Kosli command you can skip the file extension. For example, to list environments with `org` and `api-token` in the configuration file you would run:
 
-```
-$ kosli list environments --config-file kosli-conf
+```shell {.command}
+kosli list environments --config-file kosli-conf
 ```
 
 `--config-file` defaults to `kosli`, so if you name your file `kosli.<yaml|toml|json>` and the file is in the same location as where you run Kosli commands from, you can skip the `--config-file` altogether.
@@ -163,8 +163,8 @@ part of the template, the state of the extra evidence will affect the overall co
 
 The `--compliant` flag is a [boolean flag](#boolean-flags). 
 To report generic evidence as non-compliant use `--compliant=false`, as in this example:
-```
-$ kosli report evidence artifact generic server:1.0 \
+```shell {.command}
+kosli report evidence artifact generic server:1.0 \
   --artifact-type docker \
   --name test \
   --description "generic test evidence" \

docs.kosli.com/content/getting_started/approvals.md

@@ -1,10 +1,10 @@
 ---
-title: "Part 9: Approvals"
+title: "Part 10: Approvals"
 bookCollapseSection: false
 weight: 300
 summary: "When an artifact is ready to be deployed to a given environment, an approval may be reported to Kosli. An approval can be requested which will require a manual action, or reported automatically. This will be recorded in Kosli so the decision made outside your CI system won't be lost."
 ---
-# Part 9: Approvals
+# Part 10: Approvals
 
 When an artifact is ready to be deployed to a given [environment](/getting_started/environments/), an approval may be reported to Kosli. An approval can be requested which will require a manual action, or reported automatically. This will be recorded in Kosli so the decision made outside your CI system won't be lost.
 

docs.kosli.com/content/getting_started/artifacts.md

@@ -28,8 +28,8 @@ By establishing and maintaining binary provenance for artifacts, Kosli enables y
 
 To attest an artifact, you can run a command similar to the one below:
 
-```shell
-$ kosli attest artifact project-a-app.bin \
+```shell {.command}
+kosli attest artifact project-a-app.bin \
 	--artifact-type file \
 	--build-url https://exampleci.com \
 	--commit-url https://github.com/ProjectA/ProjectAApp/commit/e67f2f2b121f9325ebf166b7b3c707f73cb48b14 \
@@ -63,8 +63,8 @@ This will allow you to instantly turn off all Kosli CLI commands if Kosli is dow
 
 The `--dry-run` flag is also useful when trying commands locally. For example:
 
-```shell
-$ kosli attest artifact cyberdojo/differ:dde3b2a \
+```shell {.command}
+kosli attest artifact cyberdojo/differ:dde3b2a \
   --artifact-type=docker \
   --org=cyber-dojo \
   --flow=differ-ci \

docs.kosli.com/content/getting_started/attestations.md

@@ -39,8 +39,8 @@ When you make an attestation, you have the choice of what `name` to attach it to
 
 The `jira-ticket` attestation belongs to a single trail and is not linked to a specific artifact. In this example, the id of the trail is the git commit.
 
-```shell
-$ kosli attest jira \
+```shell {.command}
+kosli attest jira \
     --flow backend-ci \
 	--trail $(git rev-parse HEAD) \	
     --name jira-ticket 
@@ -51,8 +51,8 @@ $ kosli attest jira \
 
 Some attestations are attached to a specific artifact, like the unit tests for the `backend` artifact. Often, evidence like unit tests are created _before_ the artifact is built. To attach the evidence to the artifact before its creation, use `backend` (the artifact's `name` from the template), as well as `unit-tests` (the attestation's `name` from the template).
 
-```shell
-$ kosli attest junit \
+```shell {.command}
+kosli attest junit \
     --name backend.unit-tests \
     --flow backend-ci \
     --trail $(git rev-parse HEAD) \
@@ -65,8 +65,8 @@ This attestation belongs to any artifact attested with the matching `name` from
 
 Once the artifact has been built, it can be attested with the following command.
 
-```shell
-$ kosli attest artifact my_company/backend:latest \
+```shell {.command}
+kosli attest artifact my_company/backend:latest \
 	--artifact-type docker \
     --flow backend-ci \
 	--trail $(git rev-parse HEAD) \	
@@ -88,8 +88,8 @@ Often, evidence like snyk reports are created _after_ the artifact is built. In
 
 The following attestation will only belong to the artifact `my_company/backend:latest` attested above and its fingerprint, in this case calculated by the Kosli CLI.
 
-```shell
-$ kosli attest snyk \
+```shell {.command}
+kosli attest snyk \
     --artifact-type docker my_company/backend:latest \
     --name backend.security-scan \
     --flow backend-ci \
@@ -107,12 +107,12 @@ Typically, the Flow and Trail are explicitly setup before making the attestation
 This is done with the `create flow` and `begin trail` commands, either of which can specify the name of the template yaml file above 
 (e.g. `.kosli.yml`) whose contents define overall compliance. For example:
 
-```shell
-$ kosli create flow backend-ci \
+```shell {.command}
+kosli create flow backend-ci \
     --template-file .kosli.yml
     ...
 
-$ kosli begin trail $(git rev-parse HEAD) \
+kosli begin trail $(git rev-parse HEAD) \
     --flow backend-ci \
     ...    
 ```
@@ -142,7 +142,6 @@ Attestations are append-only immutable records. You can report the same attestat
 However, only the latest version of the attestation is considered when evaluating compliance.
 
 
-
 ## Evidence Vault
 
 Along with attestations data, you can attach additional supporting evidence files. These will be securely stored in Kosli's **Evidence Vault** and can easily be retrieved when needed. Alternatively, you can store the evidence files in your own preferred storage and only attach links to it in the Kosli attestation.

docs.kosli.com/content/getting_started/environments.md

@@ -2,11 +2,11 @@
 title: "Part 8: Environments"
 bookCollapseSection: false
 weight: 280
-summary: "Kosli environments allow you to record the artifacts running in your runtime environments and how they change. Every time an environment change (or a set of changes) is reported, Kosli creates a new environment snapshot containing the status of the environment at a given point in time."
+summary: "Kosli environments allow you to record the artifacts running in your runtime environments and how they change. Every time an environment change (or a set of changes) is reported, Kosli creates a new environment snapshot containing the status of the environment at a given point in time. The change record created in Kosli enables you to retrospectively perform runtime forensics about what ran where and when."
 ---
 # Part 8: Environments
 
-Kosli environments allow you to record the artifacts running in your runtime environments and how they change. Every time an environment change (or a set of changes) is reported, Kosli creates a new environment snapshot containing the status of the environment at a given point in time.
+Kosli environments allow you to record the artifacts running in your runtime environments and how they change. Every time an environment change (or a set of changes) is reported, Kosli creates a new environment snapshot containing the status of the environment at a given point in time. The change record created in Kosli enables you to retrospectively perform runtime forensics about what ran where and when.
 
 ## Create an environment
 
@@ -21,7 +21,7 @@ Make sure that type of Kosli environment matches the type of the environment you
 To create an environment via CLI, you would run a command like this:
 
 ```shell {.command}
-$ kosli create environment quickstart \
+kosli create environment quickstart \
     --environment-type docker \
     --description "quickstart environment for tutorial"
 ```
@@ -42,8 +42,8 @@ After the new environment is created you'll be redirected to its page, which wil
 
 ## Snapshoting an environment
 
-To record the current status of your environment you need to make Kosli CLI snapshot the running artifacts in it and report it to Kosli. 
-When Kosli receives an environment report, if the received list of running artifacts is different than what is in the latest environment snapshot, a new environment snapshot is created. Snapshots are immutable and can't be tampered with.
+To record the current status of your environment you need to use the Kosli CLI to snapshot the running artifacts in it and report it to Kosli. 
+When Kosli receives an environment report, if the received list of running artifacts is different than what is in the latest environment snapshot, a new snapshot is created. Snapshots are immutable and can't be tampered with.
 
 Currently, the following environment types are supported:
 - Kubernetes
@@ -52,6 +52,7 @@ Currently, the following environment types are supported:
 - AWS Simple Storage Service (S3)
 - AWS Lambda
 - AWS Elastic Container Service (ECS)
+- Azure Web Apps and Function Apps
 
 You can report environment snapshots manually using the `kosli snapshot [...]` commands for testing. For production use, however,  you would configure the reporting to happen automatically on regular intervals, e.g. via a cron job or scheduled CI job, or on certain events. 
 

docs.kosli.com/content/getting_started/flows.md

@@ -16,8 +16,8 @@ In all the commands below we skip the required `--api-token` and `--org` flags f
 
 To create a Flow, you can run:
 
-```shell
-$ kosli create flow process-a --description "My SW delivery process" \
+```shell {.command}
+kosli create flow process-a --description "My SW delivery process" \
     --use-empty-template
 ```
 
@@ -46,8 +46,8 @@ trail:
 
 To create a Flow with a template, you can run:
 
-```shell
-$ kosli create flow process-a --description "My SW delivery process" \
+```shell {.command}
+kosli create flow process-a --description "My SW delivery process" \
  --template-file sw-delivery-template.yml
 ```
 

docs.kosli.com/content/getting_started/install.md

@@ -163,6 +163,6 @@ API-TOKEN = "123456abcdef"
 When using the `--config-file` flag you can skip the file extension. For example, 
 to list environments with `org` and `api-token` in the configuration file you would run:
 
-```
-$ kosli list environments --config-file=kosli-conf
+```shell {.command}
+kosli list environments --config-file=kosli-conf
 ```

docs.kosli.com/content/getting_started/next.md

@@ -1,11 +1,11 @@
 ---
-title: "Part 10: Next Steps"
+title: "Part 11: Next Steps"
 bookCollapseSection: false
 weight: 310
 summary: "In the previous chapters, you explored Kosli Flows and Environments and have reported some data to Kosli. 
 The next steps would be to harness the benefits of your hard work. Here are a few areas to look at next:"
 ---
-# Part 10: Next Steps
+# Part 11: Next Steps
 
 In the previous chapters, you explored Kosli Flows and Environments and have reported some data to Kosli. 
 The next steps would be to harness the benefits of your hard work. Here are a few areas to look at next: