Final polish for exercises.

data/workshop/exercise1.mdx

@@ -2,7 +2,7 @@
 title: Understanding our lab environment
 exercise: 1
 date: '2024-08-22'
-tags: ['openshift','containers','kubernetes','disconnected']
+tags: ['ssh','novnc','workshop','setup']
 draft: false
 authors: ['default']
 summary: "Let's get familiar with our lab setup."

data/workshop/exercise2.mdx

@@ -2,18 +2,24 @@
 title: Mirror required content
 exercise: 2
 date: '2024-08-23'
-tags: ['openshift','containers','kubernetes','disconnected']
+tags: ['oc-mirror','mirror-registry','openshift','disconnected']
 draft: false
 authors: ['default']
 summary: "You want features? Mirror them in!🪞"
 ---
 
-The disconnected OpenShift cluster you have been allocated is the result of a standard installation using the IPI install method, and does not have any post installation features added.
+The disconnected OpenShift cluster you have been allocated is the result of a standard installation for a private cluster on AWS using the [IPI install method](https://docs.openshift.com/container-platform/4.14/installing/installing_aws/installing-aws-private.html#installing-aws-private), and does not have any post installation features added.
 
-During this workshop we want to secure the cluster with Red Hat Advanced Cluster Security, understand our compliance posture against [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) with the OpenShift Compliance Operator and then make it easy for our Developers to do the right thing with Red Hat Developer Hub.
+During this workshop we want to secure the cluster with Red Hat Advanced Cluster Security, understand our compliance posture against [NIST 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) with the OpenShift Compliance Operator and then explore some bonus activities like deploying Red Hat Developer Hub.
 
 To install and configure these features we first need to mirror some additional content into our disconnected environment, let's get started.
 
+<Zoom>
+|![workshop](/static/images/compliance/workshop-environment.svg)                |
+|:-----------------------------------------------------------------------------:|
+| *Workshop environment summary*                                                |
+</Zoom>
+
 
 ## 2.1 - Open a terminal on your low side
 
@@ -37,18 +43,18 @@ Your workspace will look similar to the one below:
 
 ```bash
 [lab-user@jump low-side-data]$ ls -lah
-total 25G
+total 21G
-drwxr-xr-x. 4 lab-user lab-user 4.0K Aug 22 00:22 .
+drwxr-xr-x. 4 lab-user lab-user 4.0K Sep  2 12:46 .
-drwxr-xr-x. 3 root     root       27 Aug 19 04:10 ..
+drwxr-xr-x. 3 root     root       27 Aug 31 22:00 ..
--rw-r--r--. 1 lab-user lab-user  473 Aug 22 00:10 imageset-config.yaml
+-rw-r--r--. 1 lab-user lab-user  305 Sep  2 12:38 imageset-config.yaml
--rw-r--r--. 1 lab-user lab-user 696M Aug 21 23:57 mirror-registry.tar.gz
+-rw-r--r--. 1 lab-user lab-user 696M Sep  2 12:37 mirror-registry.tar.gz
--rw-r--r--. 1 lab-user lab-user  24G Aug 22 00:22 mirror_seq1_000000.tar
+-rw-r--r--. 1 lab-user lab-user  20G Sep  2 12:46 mirror_seq1_000000.tar
 -rwxr-xr-x. 1 lab-user lab-user 146M Mar 26 22:17 oc
--rwxr-x--x. 1 lab-user lab-user 144M Mar 22 18:34 oc-mirror
+-rwxr-x--x. 1 lab-user lab-user 144M Aug  7 06:30 oc-mirror
--rw-------. 1 lab-user lab-user 183K Aug 22 00:16 .oc-mirror.log
+-rw-------. 1 lab-user lab-user 160K Sep  2 12:41 .oc-mirror.log
-drwxr-xr-x. 3 lab-user lab-user   17 Aug 22 00:13 oc-mirror-workspace
+drwxr-xr-x. 3 lab-user lab-user   17 Sep  2 12:38 oc-mirror-workspace
--rwxr-xr-x. 1 lab-user lab-user 630M Mar 22 19:32 openshift-install
+-rwxr-xr-x. 1 lab-user lab-user 631M Aug  7 07:40 openshift-install
-drwxr-x---. 2 lab-user lab-user   28 Aug 22 00:22 publish
+drwxr-x---. 2 lab-user lab-user   28 Sep  2 12:46 publish
 ```
 
 
@@ -75,6 +81,8 @@ oc-mirror list operators --catalogs --version=4.14
 oc-mirror list operators --catalog registry.redhat.io/redhat/redhat-operator-index:v4.14
 ```
 
+Using the built in help have a go at using `oc-mirror` to identify details of a specific operator.
+
 We can also use the `oc-mirror` utility to understand the state of any existing mirror content bundles. We have a content bundle called `mirror_seq1_000000.tar` available from the initial installation of your OpenShift cluster, let's inspect that now.
 
 ```bash

data/workshop/exercise3.mdx

@@ -1,8 +1,8 @@
 ---
-title: Install operators
+title: Install operators on a disconnected cluster
 exercise: 3
 date: '2024-08-27'
-tags: ['openshift','containers','kubernetes','disconnected']
+tags: ['openshift','operators','operator-hub','disconnected']
 draft: false
 authors: ['default']
 summary: "Operators?!? 🤔 - Think app store for Kubernetes 🌟"
@@ -146,5 +146,5 @@ If you check back on your web console, after a short wait the **Red Hat Develope
 | *List of installed operators*                                                 |
 </Zoom>
 
-If all three operators are now installed congratulations you are ready to move on to Exercise 3 🎉
+If all three operators are now installed congratulations you are ready to move on to Exercise 4 🎉
 

data/workshop/exercise4.mdx

@@ -2,7 +2,7 @@
 title: Deploy advanced cluster security
 exercise: 4
 date: '2024-08-31'
-tags: ['openshift','containers','kubernetes','disconnected']
+tags: ['openshift','rhacs','container','security']
 draft: false
 authors: ['default']
 summary: "Time to up our security & compliance game! 🔒"

data/workshop/exercise5.mdx

@@ -2,7 +2,7 @@
 title: Running a cluster compliance scan
 exercise: 5
 date: '2024-09-01'
-tags: ['openshift','containers','kubernetes','disconnected']
+tags: ['openshift','compliance','nist-800-53','scanning']
 draft: false
 authors: ['default']
 summary: "Let's check our cluster compliance against NIST 800-53 👀"

data/workshop/exercise6.mdx

@@ -2,10 +2,10 @@
 title: Retrieving raw compliance results
 exercise: 6
 date: '2024-09-02'
-tags: ['openshift','containers','kubernetes','disconnected']
+tags: ['openshift','compliance','nist-800-53','scanning']
 draft: false
 authors: ['default']
-summary: "Need to integrate results with another platform?"
+summary: "Need to integrate results with another platform? No problem!"
 ---
 
 Often organisations will have dedicated software for managing governance, risk and compliance or need to provide results to external auditors. In these situations while the dashboards within Red Hat Advanced Cluster Security, or `ComplianceCheckResult` objects in the OpenShift APIServer are helpful, what we really need to do is integrate these results into our third party compliance management platform or pass results in a standardised format to third parties.
@@ -97,7 +97,7 @@ oc delete pod pv-extract --namespace openshift-compliance
 ```
 
 
-## 6.3 Reviewing raw result files
+## 6.3 - Reviewing raw result files
 
 Now that we have a copy of the raw result files, let's see what they look like.
 
@@ -148,7 +148,7 @@ You should see an xml document snippet similar to the example below:
 ```
 
 
-## 6.4 Generating reports with openscap tooling
+## 6.4 - Generating reports with openscap tooling
 
 To finish off this exercise let's go one step further and use OpenSCAP tooling to generate an html based report we can open in our vnc Firefox browser.
 
@@ -171,6 +171,4 @@ exit # Return to low side server
 rsync highside:/mnt/high-side-data/compliance-results/1/report.html /home/lab-user/Downloads/report.html
 ```
 
-Finally - we can open up our report in our web based Firefox vnc session!
+Finally - we can open up our report in our web based Firefox vnc session! Once you've reviewed the report you can move on to exercise 7 🚀
-
-

data/workshop/exercise7.mdx

@@ -0,0 +1,54 @@
+---
+title: Bonus - Making the most of rhacs
+exercise: 7
+date: '2024-09-02'
+tags: ['openshift','rhacs','container','security']
+draft: false
+authors: ['default']
+summary: "Optional challenge - if you have time"
+---
+
+So you've deployed Red Hat Advanced Cluster Security and completed some day one configuration. Now what?? One of the key day two activities for RHACS in a disconnected environment is ensuring you can keep the vulnerability database up to date.
+
+At a high level, the RHACS **Scanner** component maintains a database of vulnerabilities. When Red Hat Advanced Cluster Security for Kubernetes (RHACS) runs in normal mode, **Central** retrieves the latest vulnerability data from the internet, and Scanner retrieves vulnerability data from Central.
+
+However, if you are using RHACS in offline mode, **you must manually update the vulnerability data**. To manually update the vulnerability data, you must upload a definitions file to Central, and Scanner then retrieves the vulnerability data from Central.
+
+In both online and offline mode, Scanner checks for new data from Central every `5` minutes by default. In online mode, Central also checks for new data from the internet approximately every `5-20` minutes.
+
+The offline data source is updated approximately every 3 hours. After the data has been uploaded to Central, Scanner downloads the data and updates its local vulnerability database.
+
+
+## 7.1 - Update rhacs definitions with roxctl
+
+To update the definitions in offline mode, perform the following steps:
+
+1. Download the definitions.
+2. Upload the definitions to Central. 
+
+As a challenge, try following the documentation https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.5/html/configuring/enable-offline-mode#download-scanner-definitions_enable-offline-mode to perform the update.
+
+> Note: I suggest exploring `roxctl` CLI as the method for downloading updates in your low side environment. You could then copy both `roxctl` and the definitions update to your high side environment and use `roxtctl` once more (this time with an API token) in order to update the definitions.
+
+
+## 7.2 - Prioritise security remediation by risk
+
+Completed your vulnerability definitions update? Awesome! Feel free to explore some of the other features of Red Hat Advanced Cluster Security using your web based vnc session and the RHACS dashboard.
+
+Let’s take a look at the **Risk** view, where we go beyond the basics of vulnerabilities to understand how deployment configuration and runtime activity impact the likelihood of an exploit occurring and how successful those exploits will be.
+
+<Zoom>
+|![workshop](/static/images/compliance/acs-risk.png)                            |
+|:-----------------------------------------------------------------------------:|
+| *Understanding risk exposure in Red Hat Advanced Cluster Security*            |
+</Zoom>
+
+Risk is also influenced by runtime activity - and Deployments that have activity that could indicate a breach in progress have a red dot on the left. Obviously - the first one in the list should be our first focus.
+
+The reality of security is that it’s just not possible to tackle all sources of Risk, so organizations end up prioritizing their efforts. We want RHACS to help inform that prioritization.
+
+As a challange have a go at mirroring and deploying a new additional container image into your disconnected environment repeating steps we completed earlier. Try creating a deployment for that image to bring it up on your cluster, the **Developer** perspective in the OpenShift Web Console can save you some time here.
+
+Once the container is running, use the RHACS dashboard to check what the deployments risk level is? What are the factors contributing to that?
+
+If you're ready for a different topic, head over to Exercise 8, for the final tasks today to deploy Red Hat Developer Hub 🙂

data/workshop/exercise8.mdx

@@ -2,13 +2,18 @@
 title: Bonus - Installing red hat developer hub
 exercise: 8
 date: '2024-09-02'
-tags: ['openshift','containers','kubernetes','disconnected']
+tags: ['openshift','backstage','developer-hub','operator']
 draft: false
 authors: ['default']
 summary: "Upping our dx in a disconnected environment"
 ---
 
-We've had a good dig into cluster security and compliance. Let's change gears for this next exercise to get some experience deploying [Red Hat Developer Hub](https://developers.redhat.com/rhdh/overview) in a disconnected cluster.
+We've had a good dig into cluster security and compliance. Let's change gears for this final exercise to get some quick practice deploying [Red Hat Developer Hub](https://developers.redhat.com/rhdh/overview) in a disconnected cluster.
+
+<Zoom>
+|![workshop](/static/images/compliance/developer-hub-graphic.png)               |
+|:-----------------------------------------------------------------------------:|
+</Zoom>
 
 
 ## 8.1 - Deploying red hat developer hub
@@ -60,3 +65,14 @@ oc get route --namespace rhdh backstage-developer-hub --output jsonpath='{.spec.
 | *First login for Red Hat Developer Hub*                                       |
 </Zoom>
 
+
+## 8.2 - Understanding developer hub
+
+With Developer Hub deployed, you will notice by default there isn't much going on in the dashboard. This is because Developer Hub is a platform that has to be specifically customised for your environment through the extraordinary plugin ecosystem.
+
+Take a moment to explore what directions you could potentially take your deployment via the plugin marketplace https://backstage.io/plugins. 
+
+Red Hat support a curated and opinionated set of plugins, you can take a look at those here https://developers.redhat.com/rhdh/plugins
+
+We don't have time in this workshop to fully dig into Red Hat Developer Hub however if you do finish the security and compliance focused tasks ahead of schedule please feel free to review https://www.youtube.com/watch?v=tvVOC0mFR_4 to get a feel for how Developer Hub templates can be used.
+