updates

content/modules/ROOT/pages/02-vulnerability-management-lab.adoc

@@ -118,6 +118,8 @@ image::acs-vuln-dashboard-01.png[link=self, window=blank, width=100%, Riskiest D
 
 image::acs-vuln-dashboard-02.png[link=self, window=blank, width=100%, Top Policy Buttons]
 
+image::acs-vuln-dashboard-03.png[link=self, window=blank, width=100%, Top Policy Buttons]
+
 [start=3]
 
 . Locate the *Top riskiest images* panel. 
@@ -214,8 +216,6 @@ image::02-vuln2-4.png[link=self, window=blank, width=100%]
 
 You will get the same information from the previous section. 
 
-image::02-vuln2-5.png[link=self, window=blank, width=100%]
-
 However, if you click the deployments tab, you will see the specific deployments with all these vulnerabilities. This ability to see the individual deployments as well as their images is crucial. When you're talking about multiple clusters and thousands of vulnerabilities, you're going to have the same workloads across different clusters, and you will need to drill down into the individual deployments.
 
 [start=3]
@@ -331,7 +331,10 @@ However, you don't have to wait until Monday to view the report.
 [start=16]
 . Click the vertical ellipses on the right side of the UI and click *Generate Download*
 
-NOTE: You may have to wait for the report to generate. Feel free to listen to elevator music during this time.
+image::02-vr-8.png[link=self, window=blank, width=100%]
+image::02-vr-9.png[link=self, window=blank, width=100%]
+
+NOTE: You will not be able to download the report unless you've set up the email notifier and integration correctly. 
 
 == What would you do?
 

content/modules/ROOT/pages/03-risk-profiling.adoc

@@ -8,7 +8,7 @@
 
 == The Configuration Management Tab
 
-Another configuration management tab has much information that directs you to other dashboards. It is currently undergoing an overhaul, so we are open to whatever you want to see in the configuration management dashboard. However, here are the four top use cases that we tend to see from people looking into security configuration management.
+The configuration management tab contains a lot fo useful information that directs you to other dashboards. It is currently undergoing an overhaul, so we are open to whatever you want to see in the configuration management dashboard. However, here are the four top use cases that we tend to see from people looking into security configuration management.
 
 - Policy Violations
 - CIS Kubernetes 1.5
@@ -48,8 +48,6 @@ policies in the cluster, the policy status, whether it's disabled, whether it's
 .Procedure
 . Click the *View all* button on the "Policy violations by severity" widget.
 
-image::03-cm-5.png[link=self, window=blank, width=100%]
-
 IMPORTANT: Notice in this tab that nothing should say enforced. This is because, by default, in ACS, there is no policy that is being enforced by default. This avoids the eviction of any workloads prematurely and allows you to ingest all of this security information at the beginning of your security journey.
 
 Now, as you add policies, this page will continue to fill up. It is useful to have the ability to export all of the policies and their status.

content/modules/ROOT/pages/04-policy-management.adoc

@@ -7,7 +7,7 @@
 
 == RHACS Policy Management Basics
 
-RHACS has many built-in policies to detect activity related to attacker goals: gain a foothold, maintain a presence, move laterally, and exfiltrate data. The continuous runtime monitoring observes all container activity and will automatically respond to events with appropriate enforcement and notification. However, that would be missing out on an opportunity - RHACS wants to go one step further, to take advantage of containers' ephemeral, immutable nature, to improve security in a measurable way from now on.
+RHACS has many built-in policies to detect activity related to attacker goals: gain a foothold, maintain a presence, move laterally, and exfiltrate data. The continuous runtime monitoring observes all container activity and will automatically respond to events with appropriate enforcement and notification. However, that would be missing out on an opportunity - RHACS wants to go one step further, to take advantage of containers' ephemeral, immutable nature, to improve security in a measurable way.
 
 We want to use runtime incidents and vulnerabilities as a learning opportunity to improve security going forward by constraining how our containers can act. We achieve this by creating policies and implementing them early in the CI/CD process.
 
@@ -232,39 +232,39 @@ image::acs-deploy-05.png[link=self, window=blank, width=100%]
 
 Now, let's test it out! We're going to deploy a simple Ubuntu application to the cluster.
 
-[source,sh,subs="attributes",role=execute]
+[source,YAML,]
 ----
-cat <<EOF > ubuntu-deployment.yml
+cat << EOF > ubuntu-deployment.yml
 apiVersion: apps/v1
 kind: Deployment
 metadata:
- name: ubuntu-deployment
- labels:
- app: ubuntu
+  name: ubuntu-deployment
+  labels:
+    app: ubuntu
 spec:
- replicas: 3
- selector:
- matchLabels:
- app: ubuntu
- template:
- metadata:
- labels:
- app: ubuntu
- spec:
- containers:
- - name: ubuntu
- image: ubuntu:latest
- command: ["/bin/bash", "-c", "--"]
- args: ["while true; do echo hello world; sleep 10; done"]
- ports:
- - containerPort: 80
- resources:
- limits:
- memory: "128Mi"
- cpu: "500m"
- requests:
- memory: "64Mi"
- cpu: "250m"
+  replicas: 3
+  selector:
+    matchLabels:
+      app: ubuntu
+  template:
+    metadata:
+      labels:
+        app: ubuntu
+    spec:
+      containers:
+      - name: ubuntu
+        image: ubuntu:latest
+        command: ["/bin/bash", "-c", "--"]
+        args: ["while true; do echo hello world; sleep 10; done"]
+        ports:
+        - containerPort: 80
+        resources:
+          limits:
+            memory: "128Mi"
+            cpu: "500m"
+          requests:
+            memory: "64Mi"
+            cpu: "250m"
 EOF
 ----