docs: revisit documentation pages for consistency (aquasecurity#905)

Signed-off-by: Daniel Pacak <pacak.daniel@gmail.com>

build/mkdocs-material/Dockerfile

@@ -1,4 +1,4 @@
-FROM squidfunk/mkdocs-material:7.3.6
+FROM squidfunk/mkdocs-material:8.1.7
 
 RUN pip install mike
 RUN pip install mkdocs-macros-plugin

docs/cli/getting-started.md

@@ -106,17 +106,16 @@ starboard get configauditreports deployment/nginx -o yaml
 
 or
 
-```console
-kubectl get configauditreport -o wide \
-    -l starboard.resource.kind=Deployment,starboard.resource.name=nginx
+```
+kubectl get configauditreport -o wide
 ```
 
 <details>
 <summary>Result</summary>
 
 ```
-NAME               SCANNER   AGE   DANGER   WARNING   PASS
-deployment-nginx   Polaris   5s    0        8         9
+NAME                          SCANNER   AGE    DANGER   WARNING   PASS
+replicaset-nginx-6d4cf56db6   Polaris   155m   1        9         7
 ```
 </details>
 

docs/index.md

@@ -36,7 +36,7 @@ Starboard can be used:
 - Learn how to install the Starboard command [From the Binary Releases](./cli/installation/binary-releases.md) and
   follow the [Getting Started](./cli/getting-started.md) guide to generate your first vulnerability and configuration
   audit reports.
-- Install the Starboard Operator with [Static YAML Manifests](./operator/installation/kubectl.md) and follow the
+- Install the Starboard Operator with [kubectl](./operator/installation/kubectl.md) and follow the
   [Getting Started](./operator/getting-started.md) guide to see how vulnerability and configuration audit reports are
   generated automatically.
 - Read more about the motivations for the project in the [Starboard: The Kubernetes-Native Toolkit for Unifying Security]

docs/operator/getting-started.md

@@ -10,7 +10,7 @@ of these Kubernetes playgrounds:
 * [Play with Kubernetes]
 
 You also need the Starboard Operator to be installed in the `starboard-system` namespace, e.g. with
-[static YAML manifests](./installation/kubectl.md) or [Helm](./installation/helm.md).
+[kubectl](./installation/kubectl.md) or [Helm](./installation/helm.md).
 
 ## Workloads Scanning
 
@@ -26,7 +26,7 @@ creates the Kubernetes Job in the `starboard-system` namespace to scan the `ngin
 It also creates the Job to audit the Deployment's configuration for common pitfalls such as running the `nginx`
 container as root:
 
-```console
+```
 kubectl get job -n starboard-operator
 ```
 
@@ -46,7 +46,7 @@ If everything goes fine, the scan Jobs are deleted, and the operator saves scan
 a VulnerabilityReport for each different container defined in the active ReplicaSet. In this example there is just one
 container image called `nginx`:
 
-```console
+```
 kubectl get vulnerabilityreports -o wide
 ```
 <details>
@@ -105,7 +105,7 @@ kubectl set image deployment nginx nginx=nginx:1.17
 
 Even this time the operator will pick up changes and rescan our Deployment with updated configuration:
 
-```console
+```
 kubectl tree deploy nginx
 ```
 
@@ -132,8 +132,10 @@ collection. For example, when the previous ReplicaSet named `nginx-6d4cf56db6` i
 `replicaset-nginx-6d4cf56db6-nginx` as well as the ConfigAuditReport named `replicaset-nginx-6d4cf56db6` are
 automatically garbage collected.
 
-If you only want the latest replicaset in your deployment to be scanned for vulnerabilities you can define `OPERATOR_VULNERABILITY_SCANNER_SCAN_ONLY_CURRENT_REVISIONS=true`
-in your operator deployment. This can be useful if you only want to know about vulnerability that is currently a potential issue.
+!!! tip
+    If you only want the latest ReplicaSet in your Deployment to be scanned for vulnerabilities you can set the value
+    of the `OPERATOR_VULNERABILITY_SCANNER_SCAN_ONLY_CURRENT_REVISIONS` environment variable to `true` in the operator's
+    deployment descriptor. This is useful to identify vulnerabilities that impact only the running workloads.
 
 !!! tip
     You can get and describe `vulnerabilityreports` and `configauditreports` as built-in Kubernetes objects:
@@ -193,12 +195,12 @@ No resources found in default namespace.
 !!! Tip
     Use `vuln` and `configaudit` as short names for `vulnerabilityreports` and `configauditreports` resources.
 
-To be sure that your vulnerabilityreports is is up to date with the latest CVE:s you can define
-how long your vulnerabilityreports should be in the cluster before automatically getting deleted.
-For example setting `OPERATOR_VULNERABILITY_SCANNER_REPORT_TTL=24h` would delete the report after 24 hours.
-When the vulnerabilityreports gets deleted starboard will automatically create a new job and scan the images again.
-Assuming that your image scan solution have updated it's DB the new vulnerabilityreports that gets created will contain the latest CVE:s.
-This feature is disabled by default.
+!!! Note
+    You can define the validity period for VulnerabilityReports by setting the duration as the value of the
+    `OPERATOR_VULNERABILITY_SCANNER_REPORT_TTL` environment variable. For example, setting the value to `24h`
+    would delete reports after 24 hours. When a VulnerabilityReport gets deleted Starboard Operator will automatically
+    rescan the underlying workload. Assuming that the vulnerability scanner has updated its vulnerability database,
+    new VulnerabilityReports will contain the latest vulnerabilities.
 
 ## Infrastructure Scanning