jmhbnz/workshops
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Begin scaffolding security hackathon.

Browse Source
This commit is contained in:
James Blair
2024-09-26 16:31:52 +12:00
parent 47aa8c9e4c
commit d87cb4a04e
11 changed files with 172 additions and 165 deletions
Download Patch File Download Diff File Expand all files Collapse all files

165
data/workshop/README.org
View File

@ -1,168 +1,7 @@
#+TITLE: Openshift disconnected security & compliance workshop
#+DATE: <2024-08-26 Mon>
#+TITLE: Openshift security hackathon
#+DATE: <2024-09-26 Thu>
#+AUTHOR: James Blair
This document captures the steps required to set up an instance of the workshop.
* Connect to the low side instance
#+begin_src tmux
ssh lab-user@3.143.149.146
#+end_src
* Install required tools low side
#+begin_src tmux
cd /mnt/low-side-data/
curl -L -o oc-mirror.tar.gz https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.14.35/oc-mirror.tar.gz
tar -xzf oc-mirror.tar.gz
rm -f oc-mirror.tar.gz
chmod +x oc-mirror
sudo cp -v oc-mirror /bin
curl -L -o mirror-registry.tar.gz https://mirror.openshift.com/pub/openshift-v4/clients/mirror-registry/latest/mirror-registry.tar.gz
curl -L -o openshift-install.tar.gz https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.14.35/openshift-install-linux.tar.gz
tar -xzf openshift-install.tar.gz openshift-install
rm -f openshift-install.tar.gz
curl -L -o oc.tar.gz https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.14.19/openshift-client-linux.tar.gz
tar -xzf oc.tar.gz oc
rm -f oc.tar.gz
sudo cp -v oc /bin
ls -1 /mnt/low-side-data/
#+end_src
* Mirror installation content low side
#+begin_src tmux
mkdir -v $HOME/.docker
cp -v $HOME/pull-secret-example.json $HOME/.docker/config.json
cat << EOF > /mnt/low-side-data/imageset-config.yaml
---
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
local:
path: ./
mirror:
platform:
channels:
- name: stable-4.14
type: ocp
minVersion: 4.14.35
maxVersion: 4.14.35
additionalImages:
- name: registry.redhat.io/rhel8/support-tools
EOF
cd /mnt/low-side-data
oc-mirror --config imageset-config.yaml file:///mnt/low-side-data
#+end_src
* Install mirror registry high side
#+begin_src tmux
rsync -avP /mnt/low-side-data/mirror-registry.tar.gz highside:/mnt/high-side-data/
ssh highside
cd /mnt/high-side-data
tar -xzvf mirror-registry.tar.gz
./mirror-registry install --initPassword discopass
#+end_src
* Trust mirror registry high side
#+begin_src tmux
sudo cp -v $HOME/quay-install/quay-rootCA/rootCA.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust
podman login -u init -p discopass $(hostname):8443
#+end_src
* Transfer mirror content from low to high
#+begin_src tmux
exit
rsync -avP /mnt/low-side-data/ highside:/mnt/high-side-data/
ssh highside
sudo mv -v /mnt/high-side-data/oc /bin/
sudo mv -v /mnt/high-side-data/oc-mirror /bin/
sudo mv -v /mnt/high-side-data/openshift-install /bin/
cd /mnt/high-side-data
oc-mirror --from=/mnt/high-side-data/mirror_seq1_000000.tar docker://$(hostname):8443
#+end_src
* Install openshift high side
#+begin_src tmux
cat << EOF > /mnt/high-side-data/install-config.yaml
---
apiVersion: v1
metadata:
name: disco
baseDomain: lab
compute:
- architecture: amd64
hyperthreading: Enabled
name: worker
replicas: 0
controlPlane:
architecture: amd64
hyperthreading: Enabled
name: master
replicas: 1
platform:
aws:
type: m5.8xlarge
networking:
clusterNetwork:
- cidr: 10.128.0.0/14
hostPrefix: 23
machineNetwork:
- cidr: 10.0.0.0/16
networkType: OVNKubernetes
serviceNetwork:
- 172.30.0.0/16
platform:
aws:
region: us-east-2
subnets:
- $(aws ec2 describe-subnets --output json | jq '.Subnets[0].SubnetId' -r)
publish: Internal
additionalTrustBundlePolicy: Always
EOF
if ! test -f "/mnt/high-side-data/id_rsa"; then
ssh-keygen -C "OpenShift Debug" -N "" -f /mnt/high-side-data/id_rsa
fi
echo "sshKey: $(cat /mnt/high-side-data/id_rsa.pub)" | tee -a /mnt/high-side-data/install-config.yaml
echo "pullSecret: '$(jq -c . $XDG_RUNTIME_DIR/containers/auth.json)'" | tee -a /mnt/high-side-data/install-config.yaml
if (test -e /mnt/high-side-data/oc-mirror-workspace/results-*/imageContentSourcePolicy.yaml)
then
echo -e "\n\n Looks good, go ahead! \n\n"
else
echo -e "\n\n Uh oh, something is wrong... \n\n"
fi
cat << EOF >> /mnt/high-side-data/install-config.yaml
imageContentSources:
$(grep "mirrors:" -A 2 --no-group-separator /mnt/high-side-data/oc-mirror-workspace/results-*/imageContentSourcePolicy.yaml)
EOF
tail -22 /mnt/high-side-data/install-config.yaml
cat << EOF >> /mnt/high-side-data/install-config.yaml
additionalTrustBundle: |
$(sed 's/^/ /' /home/lab-user/quay-install/quay-rootCA/rootCA.pem)
EOF
cat /mnt/high-side-data/install-config.yaml
cp -v /mnt/high-side-data/install-config.yaml /mnt/high-side-data/install-config.yaml.backup
openshift-install create cluster --dir /mnt/high-side-data
#+end_src
* Disable default catalog sources high side
#+begin_src tmux
oc login https://api.disco.lab:6443 --username kubeadmin -p "$(more /mnt/high-side-data/auth/kubeadmin-password)" --insecure-skip-tls-verify=true
oc patch OperatorHub cluster --type merge -p '{"spec": {"disableAllDefaultSources": true}}'
oc create -f /mnt/high-side-data/oc-mirror-workspace/results-*/catalogSource-cs-redhat-operator-index.yaml
#+end_src

40
data/workshop/exercise1.mdx
View File

@ -1,40 +0,0 @@
---
title: Understanding our lab environment
exercise: 1
date: '2024-08-22'
tags: ['ssh','novnc','workshop','setup']
draft: false
authors: ['default']
summary: "Let's get familiar with our lab setup."
---
Welcome to the OpenShift 4 Disconnected security & compliance workshop! Here you'll learn about operating a secure and compliant OpenShift 4 cluster in a disconnected network using the following key OpenShift features:
- [Red Hat Advanced Cluster Security](https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes)
- [Red Hat OpenShift Compliance Operator](https://www.redhat.com/en/blog/a-guide-to-openshift-compliance-operator-best-practices)
To level set, [Red Hat OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift) is a unified platform to build, modernize, and deploy applications at scale. OpenShift supports running in disconnected networks, though this does change the way the cluster operates because key ingredients like container images, operator bundles, and helm charts must be brought into the environment from the outside world via mirroring.
There are of course many different options for installing OpenShift in a restricted network; this workshop will not cover the deployment of a cluster, instead you will have an existing installed cluster allocated to you which has been created in advance. Your tasks during this workshop will be to improve the security and compliance of the cluster and workloads running on it.
**Let's get started!**
## 1.1 - Reserve a lab environment
An OpenShift `4.14` cluster has already been provisioned for you to complete these excercises. To reserve an environment go to [this Google Sheets spreadsheet](https://docs.google.com/spreadsheets/d/1tddgRA6suefTaITyRx87IoRCfCJ7El9Hdr6HB8K7Mvo/edit?usp=sharing). Update your name next to an `Available` environment and change the status to `Allocated`.
<Zoom>
|![workshop](/static/images/compliance/environments.png) |
|:-----------------------------------------------------------------------------:|
| *Workshop environment worksheet* |
</Zoom>
## 1.2 - Login via ssh and vnc
To complete the lab exercises you'll use a mix of an `ssh` terminal session for running OpenShift client `oc` commands, and then a browser based vnc session in order to access the OpenShift cluster web console.
Links to a browser based terminal and vnc session are available in the spreadsheet, along with any credentials required. You are welcome to use your own terminal or vnc software if you prefer.
Once you have both a terminal and vnc session working you're ready to get underway with the workshop, please move on to exercise 2 🚀

228
data/workshop/exercise2.mdx
View File

@ -1,228 +0,0 @@
---
title: Mirror required content
exercise: 2
date: '2024-08-23'
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 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 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
Our first step to prepare to mirror content is to get connected to our low side jump host via `ssh`. You can use the web terminal link in your browser or alternatively your own local terminal with the command below (replacing the placeholder ip with the one you have been allocated).
```bash
ssh lab-user@<ip address>
```
You'll be prompted to enter a password which you can find in your allocated environment details.
After connecting change directory to the low side workspace where the intial cluster installation was already completed for you and review the folder contents:
```bash
cd /mnt/low-side-data
ls -lah
```
Your workspace will look similar to the one below:
```bash
[lab-user@jump low-side-data]$ ls -lah
total 21G
drwxr-xr-x. 4 lab-user lab-user 4.0K Sep 2 12:46 .
drwxr-xr-x. 3 root root 27 Aug 31 22:00 ..
-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 Sep 2 12:37 mirror-registry.tar.gz
-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 Aug 7 06:30 oc-mirror
-rw-------. 1 lab-user lab-user 160K Sep 2 12:41 .oc-mirror.log
drwxr-xr-x. 3 lab-user lab-user 17 Sep 2 12:38 oc-mirror-workspace
-rwxr-xr-x. 1 lab-user lab-user 631M Aug 7 07:40 openshift-install
drwxr-x---. 2 lab-user lab-user 28 Sep 2 12:46 publish
```
## 2.2 - Get familiar with oc-mirror
To mirror content into our disconnected environment we will be using the [`oc-mirror`](https://github.com/openshift/oc-mirror) openshift client utility.
To configure what content `oc-mirror` will download and mirror for us we use a YAML formatted file called an `ImageSetConfiguration`. This file declares:
1. **What to download** which can include (OpenShift itself, operator bundles, helm charts, or specific container images)
2. **What versions of each item to download**
3. **Where to store the downloaded content**
The `oc-mirror` utility also has some features for listing available content for mirroring, let's try that now! Run the following commands in your ssh terminal:
```bash
# List available openshift release versions
oc-mirror list releases
# List operator catalogs for a specific openshift release
oc-mirror list operators --catalogs --version=4.14
# List all operators in a specific catalogs
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
oc-mirror describe mirror_seq1_000000.tar | more
```
This bundle archive was created by the `oc-mirror` utility using the configuration file called `imageset-config.yaml` which is also in the same directory. Let's review that file:
```bash
cat imageset-config.yaml
```
Your file should look something like the example below, we can see the the `4.14.35` version of OpenShift is specified to be downloaded, along with the `registry.redhat.io/rhel8/support-tools` additional standalone container image.
```yaml
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
local:
path: ./
mirror:
platform:
channels:
- name: stable-4.14
type: ocp
minVersion: 4.14.35
maxVersion: 4.14.35
additionalImages:
- name: registry.redhat.io/rhel8/support-tools
```
## 2.3 - Confirm local cache is up to date
A local cache of content already exists from when the cluster installation was initially performed in advance of this workshop. Let's confirm everything is still up to date by re-running the `oc-mirror` command specifying our configuration file and the location on our disk.
```bash
oc-mirror --config imageset-config.yaml file:///mnt/low-side-data --verbose 3
```
> Note: This command may take several minutes to complete but should complete with `No new images detected, process stopping` to confirm the existing cache is up to date.
## 2.4 - Add new mirror content
For our workshop exercises today we need to mirror some additional operators, namely the **OpenShift Compliance Operator**, **Red Hat Advanced Cluster Security**, and **Red Hat Developer Hub**. Run the command below to update your `imageset-config.yaml` file to match the example below
```bash
cat << EOF > /mnt/low-side-data/imageset-config.yaml
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
local:
path: ./
mirror:
platform:
channels:
- name: stable-4.14
type: ocp
minVersion: 4.14.35
maxVersion: 4.14.35
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
packages:
- name: rhdh
channels:
- name: fast
minVersion: '1.1.1'
maxVersion: '1.1.1'
- name: compliance-operator
channels:
- name: stable
- name: rhacs-operator
channels:
- name: stable
additionalImages:
- name: registry.redhat.io/rhel8/support-tools
helm: {}
EOF
```
After updating the configuration file we can re-run our `oc-mirror` command to bring the new content into our local collection on disk in `/mnt/low-side-data`.
```bash
oc-mirror --config imageset-config.yaml file:///mnt/low-side-data --verbose 3
```
> Note: This command may take up to 10 minutes to complete depending on connection speeds.
## 2.5 - Mirror updated content to high side registry
Once the local mirror update has completed we now need to transfer this content to our high side and mirror it from disk into the OpenShift Mirror Registry running in our disconnected high side.
In this workshop we will use `rsync` to copy our content to our high side system, let's do that now:
```bash
rsync -avP /mnt/low-side-data/ highside:/mnt/high-side-data/
```
> Note: `oc-mirror` creates incremental mirror content files in order to prevent duplicating content. You will notice your low side mirror workspace includes a new file `mirror_seq2_000000.tar` which is significantly smaller than the original mirror archive.
Once the transfer has completed we need to log into our high side disconnected system and run `oc-mirror` from that side to upload the content from the new archive into our disconnected container registry
```bash
ssh highside
```
```bash
cd /mnt/high-side-data
podman login -u init -p discopass $(hostname):8443
oc-mirror --from=/mnt/high-side-data/mirror_seq2_000000.tar docker://$(hostname):8443
```
## 2.6 - Verify new operators are available
After a couple of minutes the mirror process will complete. We then need to tell OpenShift about the new content that is available by running the commands below.
```bash
oc login https://api.disco.lab:6443 --username kubeadmin -p "$(more /mnt/high-side-data/auth/kubeadmin-password)" --insecure-skip-tls-verify=true
for file in $(find ./oc-mirror-workspace -type f -name '*.yaml'); do oc apply -f $file; done
```
> Note: In our `oc-mirror-workspace` directory each time we mirror new content a new `results-<id>` directory will be created which may contain `imageContentSourcePolicy.yaml` or `catalogSource-cs-<index>.yaml` files which we need to apply to our cluster to tell it about the new content that is available.
Once the updates are applied we can then check that our new operators are available in the OpenShift Web Console using our browser based vnc session:
1. Open your vnc browser tab
2. Use the left menu panel, click **Settings** and then select **Remote Resizing** as the scaling mode to improve viewing experience.
3. Click **Connect** and when prompted enter the password in your environment spreadsheet row, then click **Send credentials**.
4. A Firefox browser window should already be open, you can manually start if using the top left applications menu if needed.
5. Click the bookmark toolbar option for **DISCO - OpenShift**.
6. Log in when prompted with the username **kubeadmin** and the kubeadmin password listed in your environment spreadsheet (you can also find this password in your highside bastion ssh session by running `cat /mnt/high-side-data/auth/kubeadmin-password`). Note that to paste in the web based vnc session you need to use the left hand panel to pass the clipboard content through to the session.
7. Navigate to **Operators** on the left menu, and then click **OperatorHub**, you should see the newly mirrored operators are now available in your disconnected cluster!
<Zoom>
|![workshop](/static/images/compliance/check-operators.gif) |
|:-----------------------------------------------------------------------------:|
| *Check disconnected operator hub* |
</Zoom>
If your mirroring has completed successfully you are ready to move on to exercise 3 and install the three new operators 🎉

150
data/workshop/exercise3.mdx
View File

@ -1,150 +0,0 @@
---
title: Install operators on a disconnected cluster
exercise: 3
date: '2024-08-27'
tags: ['openshift','operators','operator-hub','disconnected']
draft: false
authors: ['default']
summary: "Operators?!? 🤔 - Think app store for Kubernetes 🌟"
---
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.
In a broad sense many OpenShift features are added via [Operators](https://www.redhat.com/en/technologies/cloud-computing/openshift/what-are-openshift-operators). Operators automate the creation, configuration, and management of instances of Kubernetes-native applications. Operators can provide automation at every level of the stack—from managing the parts that make up the platform all the way to applications that are provided as a managed service.
In the previous exercise we mirrored some new operator bundles into our disconnected network. In this exercise we'll install those operators and explore the features they provide us via [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources) they provide.
> Note: For some trivia, Red Hat created and open sourced the [Operator Framework](https://github.com/operator-framework), then later contributed the project to the Cloud Native Computing Foundation in 2021, ensuring all organisations can benefit from our experience building and supporting operator driven clusters since ~2016.
>
> ![workshop](/static/images/compliance/operator-framework.png)
## 3.1 - Installing compliance operator
First up let's install the [Red Hat OpenShift Compliance Operator](https://docs.openshift.com/container-platform/4.14/security/compliance_operator/co-overview.html).
For some brief context the Compliance Operator assists platform teams by automating the inspection of numerous technical implementations and compares those against certain aspects of industry standards. For our purposes today that industry standard will be **NIST 800-53**.
The Compliance Operator assesses compliance of both the Kubernetes API resources of OpenShift Container Platform, as well as the nodes running the cluster. The Compliance Operator uses [OpenSCAP](https://www.open-scap.org), a NIST-certified tool, to scan and enforce security policies provided by the content.
To install the operator we can use either the OpenShift Web Console, or the terminal with `oc` cli. In this workshop we will install the operator with the Web Console using our vnc browser tab. Thanks to our previous exercise mirroring content and making it available via the cluster disconnected OperatorHub catalogs we can enjoy the same user experience to install the operator as if our cluster was fully connected.
1. Open your vnc browser tab and return to the OpenShift Web Console browser tab you opened in the previous exercise.
2. Click on the **Compliance Operator** in **OperatorHub** to open the right hand panel, then click the blue **Install** button at the top of the panel.
3. On the install details screen stick with all the default values and simply click **Install**
4. After a short wait the Compliance Operator will be installed and ready for use 🎉
<Zoom>
|![workshop](/static/images/compliance/install-compliance-operator.gif) |
|:-----------------------------------------------------------------------------:|
| *Install OpenShift Compliance Operator* |
</Zoom>
With the Compliance Operator installed feel free to explore which new Custom Resources the Operator makes available. We'll return to these in future exercises to begin using them.
## 3.2 - Installing the rhacs operator
Next up we'll install the [Red Hat Advanced Cluster Security](https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes) Operator.
Red Hat Advanced Cluster Security (RHACS) has direct integration with the Compliance Operator to provide a frontend user experience for running compliance scans along with viewing results.
To try the alternative operator installation method this time we will install the operator via the `oc` cli in our terminal.
Run the commands below in your terminal session to create the required `Namespace` and `Subscription` resources which will trigger the operator installation.
```bash
cat << EOF | oc apply --filename -
---
apiVersion: v1
kind: Namespace
metadata:
name: rhacs-operator
spec:
finalizers:
- kubernetes
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: rhacs-operator
namespace: rhacs-operator
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: rhacs-operator
namespace: rhacs-operator
spec:
channel: stable
installPlanApproval: Automatic
name: rhacs-operator
source: cs-redhat-operator-index
sourceNamespace: openshift-marketplace
startingCSV: rhacs-operator.v4.5.1
EOF
```
If you check back on your web console, after a short wait the **Advanced Cluser Security for Kubernetes** operator should now show as `✅ Succeeded`.
<Zoom>
|![workshop](/static/images/compliance/installed-operators-1.png) |
|:-----------------------------------------------------------------------------:|
| *List of installed operators* |
</Zoom>
## 3.3 - Installing the developer hub operator
The final operator we will install for this workshop relates to [Red Hat Developer Hub](https://developers.redhat.com/rhdh/overview).
Red Hat Developer Hub is an Internal Developer Portal (IDP) based on the upstream [Backstage](https://backstage.io) project initially created at Spotify. With Red Hat Developer Hub combined with Red Hat OpenShift we can enable platform engineering teams to offer software templates and pre-architected and supported approaches to make life easier for development teams, ease onboarding and reduce friction and frustration.
We'll also install the Red Hat Developer Hub using the `oc` cli in our terminal. Run the commands below in your terminal session to create the required `Namespace` and `Subscription` resources which will trigger the operator installation.
```bash
cat << EOF | oc apply --filename -
---
apiVersion: v1
kind: Namespace
metadata:
name: rhdh-operator
spec:
finalizers:
- kubernetes
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: rhdh-operator
namespace: rhdh-operator
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: rhdh
namespace: rhdh-operator
spec:
channel: fast
installPlanApproval: Automatic
name: rhdh
source: cs-redhat-operator-index
sourceNamespace: openshift-marketplace
startingCSV: rhdh-operator.v1.1.1
EOF
```
If you check back on your web console, after a short wait the **Red Hat Developer Hub** operator should now show as `✅ Succeeded`.
<Zoom>
|![workshop](/static/images/compliance/installed-operators-2.png) |
|:-----------------------------------------------------------------------------:|
| *List of installed operators* |
</Zoom>
If all three operators are now installed congratulations you are ready to move on to Exercise 4 🎉

191
data/workshop/exercise4.mdx
View File

@ -1,191 +0,0 @@
---
title: Deploy advanced cluster security
exercise: 4
date: '2024-08-31'
tags: ['openshift','rhacs','container','security']
draft: false
authors: ['default']
summary: "Time to up our security & compliance game! 🔒"
---
With our Red Hat Advanced Cluster Security Operator installed and standing by to do some work for us, let's give it some work to do by telling it to deploy Red Hat Advanced Cluster Security onto our cluster.
## 4.1 - Getting familiar with rhacs
Before we get into the technical implementation let's take a moment to get up to speed with Red Hat Advanced Cluster Security works.
Fundamentally you install RHACS as a set of containers in your OpenShift Container Platform or Kubernetes cluster. RHACS includes the following services:
1. **Central** services you install on a designated "hub" cluster. Central installs the Central, Scanner, and Scanner DB services. The Central service provides access to a user interface through a web UI or the RHACS portal. It also handles API interactions and provides persistent storage. Scanner analyzes images for known vulnerabilities. It uses Scanner DB as a cache for vulnerability definitions.
2. **Secured cluster** services you install on each cluster you want to secure by RHACS. This installs the Collector, Sensor, and Admission Controller services. Collector collects runtime information on container security and network activity. It then sends data to Sensor, which monitors your Kubernetes cluster for policy detection and enforcement. Admission Controller monitors workloads and prevents users from creating them in RHACS when they violate security policies.
<Zoom>
|![workshop](/static/images/compliance/acs-architecture-kubernetes.png) |
|:-----------------------------------------------------------------------------:|
| *Red Hat Advanced Cluster Security high level architecture* |
</Zoom>
> Note: For an overview of which sources Red Hat Advanced Cluster Security uses for vulnerability information and a more detailed walkthrough of each component, take a moment to review https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.5/html-single/architecture/index.
## 4.2 - Deploying central services
Let's now create our **Central** services on our cluster by creating a new `Central` custom resource which our newly installed operator will then manage and deploy on our behalf. We'll deploy these services into a new namespace called `acs-central`.
```bash
cat << EOF | oc apply --filename -
---
apiVersion: v1
kind: Namespace
metadata:
name: acs-central
spec:
finalizers:
- kubernetes
---
apiVersion: platform.stackrox.io/v1alpha1
kind: Central
metadata:
name: stackrox-central-services
namespace: acs-central
spec:
central:
exposure:
route:
enabled: true
egress:
connectivityPolicy: Offline
EOF
```
> Note: The values we used for the `Central` instance are all defaults, aside from `connectivityPolicy: Offline`, which tells Red Hat Advanced Cluster Security it will be operating in a disconnected environment. For more details on how RHACS works in a disconnected environment refer to https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.5/html/configuring/enable-offline-mode.
Once the `Central` resource has been created you can check the state of the RHACS pods by running `oc get pods -n acs-central` in your highside terminal. Or navigating to **Workloads** > **Pods** for the `acs-central` project in the OpenShift Web Console.
<Zoom>
|![workshop](/static/images/compliance/acs-central-pods.png) |
|:-----------------------------------------------------------------------------:|
| *Red Hat Advanced Cluster Security central pods* |
</Zoom>
Once all pods are `Running` and `Ready` you can move on to the next step.
## 4.3 - Logging into rhacs dashboard
Time to bring up our RHACS dashboard. We'll first retrieve the `admin` user password which was auto generated by the operator and stored in a **Secret**. Then we can open the **Route** for RHACS in a new browser tab and log in.
1. Return to your vnc session and the open tab with our OpenShift Web Console.
2. Click **Workloads** > **Secrets**, ensuring you are looking at the `acs-central` **Project**.
3. Click into the `central-htpasswd` **Secret**
4. Scroll down and click **Reveal values** on the right hand side.
5. Copy the `password` field, we'll need this shortly.
6. Navigate to **Networking** > **Routes** in the left hand menu.
7. Click on the **Location** URL for the route named `central`.
8. Login with the username `admin` and the password you copied earlier.
> Note: Ironically (given the subject matter), you may receive a tls verification warning when opening the rhacs dashboard. This is expected in this short lived workshop environment (because James is lazy) and should be accepted (Kids please don't do this at home 😂).
<Zoom>
|![workshop](/static/images/compliance/central-login.gif) |
|:-----------------------------------------------------------------------------:|
| *Logging into Red Hat Advanced Cluster Security dashboard* |
</Zoom>
## 4.4 - Securing our hub cluster
To begin securing our OpenShift "hub" cluster with RHACS we need to:
1. Generate an init bundle to download and apply to the cluster.
2. Create and apply a `SecuredCluster` custom resource.
We'll start with generating the init bundle. Just for future familiarity for this step we'll use and follow the official RHACS documentation: https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.5/html/installing/installing-rhacs-on-red-hat-openshift#portal-generate-init-bundle_init-bundle-ocp
Follow the steps in `4.3.1.1` to generate an init bundle named `hub` using the RHACS dashboard, selecting the **Operator** based installation method.
Once the `hub-Operator-secrets-cluster-init-bundle.yaml` file has been downloaded we'll apply it to the cluster using the OpenShift Web Console **Import YAML** feature.
1. Create a new project in the Web Console named `acs-securedcluster`.
2. Click **Import YAML** in the top right of the OpenShift Web Console.
3. Open your **Downloads** directory in the file browser using the **Places** top left menu.
4. Open the `hub-Operator-secrets-cluster-init-bundle.yaml` file in a text editor and copy the contents.
5. Paste the contents into the **Import YAML** text field and click the blue **Create** button.
<Zoom>
|![workshop](/static/images/compliance/init-bundle-import.gif) |
|:-----------------------------------------------------------------------------:|
| *Importing an init bundle into our hub cluster* |
</Zoom>
> Note: These init bundles contain secrets enabling a secured cluster to communicate with RHACS Central so it's important to store these securely. For automation purposes you can also generate init bundles with the RHACS API or the `roxctl` CLI, for example `roxctl -e <ACS CONSOLE URL>:443 central init-bundles generate demo-cluster --output-secrets /tmp/demo-cluster.yaml --password <ACS ADMIN PASSWORD>`.
Once our init bundle has been created we can create our `SecuredCluster` custom resource to complete the cluster onboarding process. We'll do that with our `oc` terminal session.
Copy the command below and run it in your highside web terminal:
```bash
cat << EOF | oc --namespace acs-securedcluster apply --filename -
apiVersion: platform.stackrox.io/v1alpha1
kind: SecuredCluster
metadata:
name: stackrox-secured-cluster-services
spec:
monitoring:
openshift:
enabled: true
auditLogs:
collection: Auto
network:
policies: Enabled
admissionControl:
listenOnUpdates: true
bypass: BreakGlassAnnotation
contactImageScanners: ScanIfMissing
listenOnCreates: true
replicas: 3
timeoutSeconds: 10
listenOnEvents: true
scannerV4:
db:
persistence:
persistentVolumeClaim:
claimName: scanner-v4-db
indexer:
scaling:
autoScaling: Enabled
maxReplicas: 5
minReplicas: 2
replicas: 3
scannerComponent: Default
scanner:
analyzer:
scaling:
autoScaling: Enabled
maxReplicas: 5
minReplicas: 2
replicas: 3
scannerComponent: AutoSense
perNode:
collector:
collection: CORE_BPF
forceCollection: false
imageFlavor: Regular
taintToleration: TolerateTaints
clusterName: hub
centralEndpoint: 'https://central-acs-central.apps.disco.lab:443'
EOF
```
After a short wait for pods to initialise in the `acs-securedcluster` namespace you should be able to see the cluster is now secured in RHACS by checking the **Platform Configuration** > **Clusters** overview which should show the `hub` cluster as `✅ Healthy`.
<Zoom>
|![workshop](/static/images/compliance/securedcluster-completed.png) |
|:-----------------------------------------------------------------------------:|
| *Hub cluster is now secured by Red Hat Advanced Cluster Security* |
</Zoom>
If you now have Red Hat Advanced Cluster Security **Central** and **SecuredCluster** components deployed then congratulations your RHACS instance is fully deployed and you're ready to start improving your cluster security and compliance posture in Exercise 5! 🎉

216
data/workshop/exercise5.mdx
View File

@ -1,216 +0,0 @@
---
title: Running a cluster compliance scan
exercise: 5
date: '2024-09-01'
tags: ['openshift','compliance','nist-800-53','scanning']
draft: false
authors: ['default']
summary: "Let's check our cluster compliance against NIST 800-53 👀"
---
We've done the work to set the OpenShift Compliance Operator and Red Hat Advanced Cluster Security up on our cluster, now let's make the most of it by using them to schedule and run a compliance scan on our cluster.
For the scan we'll be using the included `NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift` and `NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - Node level` scan profiles that are included with the OpenShift Compliance Operator.
Two scan profiles are required as we need to scan both the OpenShift cluster, as well as each individual node running [RHEL CoreOS](https://docs.openshift.com/container-platform/4.14/architecture/architecture-rhcos.html).
For more details on these compliance profiles please take some time to review:
- https://static.open-scap.org/ssg-guides/ssg-ocp4-guide-moderate.html
- https://static.open-scap.org/ssg-guides/ssg-ocp4-guide-moderate-node.html
- https://docs.openshift.com/container-platform/4.14/security/compliance_operator/co-scans/compliance-operator-supported-profiles.html
## 5.1 - Scheduling a scan
There are two methods you can use to schedule Compliance Operator scans:
1. Creating a `ScanSetting` and `ScanSettingBinding` custom resource. This does not require Red Hat Advanced Cluster Security, and can be easily managed by GitOps, however is not beginner friendly and lacks any graphical frontend to easily explore cluster compliance status. For an overview of this approach please take a few minutes to review https://docs.openshift.com/container-platform/4.14/security/compliance_operator/co-scans/compliance-scans.html#compliance-operator-scans
2. Creating a **Scan Schedule** in Red Hat Advanced Cluster Security. This is the approach we will be using in this workshop as it is the most intuitive option.
Complete the steps below to create your scan schedule:
1. Return to your browser tab in the vnc session with the Red Hat Advanced Cluster Security dashboard open.
2. Navigate to **Compliance** > **Schedules** in the left hand menu.
3. Click the blue **Create Scan Schedule** button in the middle of the screen.
4. Enter the name `daily-nist-800-53-moderate` and set the **Time** field to `00:00` then click **Next**.
5. On the next screen select your `hub` cluster, then click **Next**.
6. On the profile screen tick `ocp4-moderate` and `ocp4-moderate-node`, then click **Next**.
7. Click **Next** once more on the **Reports** screen and the click **Save**.
<Zoom>
|![workshop](/static/images/compliance/compliance-scan-results.gif) |
|:-----------------------------------------------------------------------------:|
| *Creating a compliance scan schedule in Red Hat Advanced Cluster Security* |
</Zoom>
After creating the scan schedule results will be shortly available in the RHACS console. While we wait for the automatically triggered initial scan to complete, let's use the `oc` cli to review the `ScanSetting` that was created behind the scenes when we created the **Scan Schedule** in the RHACS dashboard.
Run the commands below to review your `ScanSetting` resource:
```bash
oc get scansetting --namespace openshift-compliance daily-nist-800-53-moderate
oc get scansetting --namespace openshift-compliance daily-nist-800-53-moderate --output yaml
```
You should see details output similar to the example below. Notice the more advanced settings available in the custom resource including `rawResultsStorage.rotation` and `roles[]` which you may want to customize in your environment.
```yaml
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
maxRetryOnTimeout: 3
metadata:
annotations:
owner: stackrox
labels:
app.kubernetes.io/created-by: sensor
app.kubernetes.io/managed-by: sensor
app.kubernetes.io/name: stackrox
name: daily-nist-800-53-moderate
namespace: openshift-compliance
rawResultStorage:
pvAccessModes:
- ReadWriteOnce
rotation: 3
size: 1Gi
roles:
- master
- worker
scanTolerations:
- operator: Exists
schedule: 0 0 * * *
showNotApplicable: false
strictNodeScan: false
suspend: false
timeout: 30m0s
```
## 5.2 - Review cluster compliance
Once your cluster scan completes return to your vnc browser tab with the Red Hat Advanced Cluster Security Dashboard open. We'll take a look at our overall cluster compliance now against the compliance profile.
> Note: Please be aware of the usage disclaimer shown at the top of the screen *"Red Hat Advanced Cluster Security, and its compliance scanning implementations, assists users by automating the inspection of numerous technical implementations that align with certain aspects of industry standards, benchmarks, and baselines. It does not replace the need for auditors, Qualified Security Assessors, Joint Authorization Boards, or other industry regulatory bodies."*.
Navigate to **Compliance** > **Coverage** and review the overall result for the `ocp4-moderate` and `ocp4-moderate-node` profiles. The results should look something similar to the examples below:
<Zoom>
|![workshop](/static/images/compliance/compliance-scan-results-1.png) |
|:-----------------------------------------------------------------------------:|
| *Compliance scan results in Red Hat Advanced Cluster Security* |
</Zoom>
<Zoom>
|![workshop](/static/images/compliance/compliance-scan-results-2.png) |
|:-----------------------------------------------------------------------------:|
| *Compliance scan results in Red Hat Advanced Cluster Security* |
</Zoom>
Your cluster should come out compliant with ~65% of the `ocp4-moderate` profile and ~93% of the `ocp4-moderate-node` profile. Not a bad start, let's review an example of an individual result now.
## 5.3 - Review indvidual `Manual` compliance results
Reviewing the detailed results any checks that are not passing will either be categorised as `Failing` or `Manual`. While we do everthing we can to automate the compliance process there are still a small number of controls you need to manage outside the direct automation of the Compliance Operator.
Looking at the `ocp4-moderate` results for our `hub` cluster. A good example of a `Manual` check is `ocp4-moderate-accounts-restrict-service-account-tokens`. Let's get an overview of the check, the rationale and our instructions to address it manually by clicking into that check in the list, and opening the **Details** tab. You can jump directly to it with this url: https://central-acs-central.apps.disco.lab/main/compliance/coverage/profiles/ocp4-moderate/checks/ocp4-moderate-accounts-restrict-service-account-tokens?detailsTab=Details
<Zoom>
|![workshop](/static/images/compliance/compliance-scan-results-3.png) |
|:-----------------------------------------------------------------------------:|
| *Compliance scan result details in Red Hat Advanced Cluster Security* |
</Zoom>
We can see in this example it's essentially a judgement call. Our instructions are:
> For each pod in the cluster, review the pod specification and ensure that pods that do not need to explicitly communicate with the API server have `automountServiceAccountToken` configured to `false`.
Now just because this check is classified as `Manual`, does not mean that we are now all on our own. There are extremely powerful policy engine & policy violation tracking features in RHACS that we can use investigate the status of this check further.
A default policy is available out of the box called **Pod Service Account Token Automatically Mounted**. By default this policy is in **Inform only** mode, which means deployments that violate this policy will not be prevented by the RHACS admission controller, or scaled down if already running by the RHACS runtime protection. However we can still use this policy as is to inform on the current state of any cluster in our fleet that is secured by RHACS.
1. First let's navigate to **Platform Configuration** > **Policy Management** in the left hand menu.
2. In the Policy list scroll down to find **Pod Service Account Token Automatically Mounted** and click the policy title.
3. Have a read of the policy details, then scroll down to review the **Scope exclusions**. You will see Red Hat has already done some work for you to define some standard OpenShift cluster control plane deployments which do need the token mounted and are safely & intentionally excluded from the policy to save you time.
4. The policy should already be enabled so let's click on **Violations** in the left hand menu to review any current instances where this policy is currently being violated. You should have one entry in the list for the `kube-rbac-proxy`. This is actually a standard openshift pod in the `openshift-machine-config-operator` namespace, and does actually require the api token mounted, so we could safely add this deployment to our policy exclusions.
<Zoom>
|![workshop](/static/images/compliance/rhacs-violation-exclude.gif) |
|:-----------------------------------------------------------------------------:|
| *Reviewing a policy & policy violations in Red Hat Advanced Cluster Security* |
</Zoom>
At this point as a platform engineer we have some flexibility about how we handle this particular compliance check, one option would be to switch the **Pod Service Account Token Automatically Mounted** policy to `Inform & enforce` mode, to prevent any future deployments to any cluster in your fleet secured by RHACS from having this common misconfiguration. As a result of implementing this mitigation you could consider adjusting the compliance profile to remove or change the priority of this `Manual` check as desired. Refer to https://docs.openshift.com/container-platform/4.14/security/compliance_operator/co-scans/compliance-operator-tailor.html
## 5.4 - Review individual `Failed` compliance results
For our last task on this exercise let's review a `Failed` check, and apply the corresponding remediation automatically to improve our compliance posture.
This time, rather than using the RHACS Dashboard we'll review the check result and apply the remediation using our terminal and `oc` cli.
Let's start by retrieving one of our failed checks:
```bash
oc get ComplianceCheckResult --namespace openshift-compliance ocp4-moderate-api-server-encryption-provider-cipher --output yaml
```
Each `ComplianceCheckResult` represents a result of one compliance rule check. If the rule can be remediated automatically, a `ComplianceRemediation` object with the same name, owned by the `ComplianceCheckResult` is created. Unless requested, the remediations are not applied automatically, which gives an OpenShift Container Platform administrator the opportunity to review what the remediation does and only apply a remediation once it has been verified.
> Note: Not all `ComplianceCheckResult` objects create `ComplianceRemediation` objects. Only `ComplianceCheckResult` objects that can be remediated automatically do. A `ComplianceCheckResult` object has a related remediation if it is labeled with the `compliance.openshift.io/automated-remediation` label.
Let's inspect the corresponding `ComplianceRemediation` for this check:
```bash
oc get ComplianceRemediation --namespace openshift-compliance ocp4-moderate-api-server-encryption-provider-cipher --output yaml
```
You should see output similar to the example below. We can see in the `spec:` that it essentially contains a yaml resource patch for our `APIServer` resource named `cluster` to specify `spec.encryption.type` be set to `aescbc`.
```yaml
apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
annotations:
compliance.openshift.io/xccdf-value-used: var-apiserver-encryption-type
labels:
compliance.openshift.io/scan-name: ocp4-moderate
compliance.openshift.io/suite: daily-nist-800-53-moderate
name: ocp4-moderate-api-server-encryption-provider-cipher
namespace: openshift-compliance
spec:
apply: false
current:
object:
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
name: cluster
spec:
encryption:
type: aescbc
outdated: {}
type: Configuration
status:
applicationState: NotApplied
```
Let's apply this automatic remediation now:
```bash
oc --namespace openshift-compliance patch complianceremediation/ocp4-moderate-api-server-encryption-provider-cipher --patch '{"spec":{"apply":true}}' --type=merge
```
> Note: This remediation has impacts for pods in the `openshift-apiserver` namespace. If you check those pods quickly with an `oc get pods --namespace openshift-apiserver` you will notice a rolling restart underway.
Now it's time for some instant gratification. Let's bring up this compliance check in our vnc browser tab with the RHACS dashboard open by going to: https://central-acs-central.apps.disco.lab/main/compliance/coverage/profiles/ocp4-moderate/checks/ocp4-moderate-api-server-encryption-provider-cipher?detailsTab=Results
You will see it currently shows as `Failed`. We can trigger a re-scan with the `oc` command below in our terminal:
> Note: Due to the api server rolling restart when this remediation was applied you may need to perform a fresh terminal login with `oc login https://api.disco.lab:6443 --username kubeadmin -p "$(more /mnt/high-side-data/auth/kubeadmin-password)" --insecure-skip-tls-verify=true`
```bash
oc --namespace openshift-compliance annotate compliancescans/ocp4-moderate compliance.openshift.io/rescan=
```
Hitting refresh, the check should now report `Pass`, and our overall percentage compliance against the baseline should have also now increased. Congratulations, time to move on to exercise 6 🚀

174
data/workshop/exercise6.mdx
View File

@ -1,174 +0,0 @@
---
title: Retrieving raw compliance results
exercise: 6
date: '2024-09-02'
tags: ['openshift','compliance','nist-800-53','scanning']
draft: false
authors: ['default']
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.
In this exercise, we'll briefly step through retrieving raw compliance results, in the well known **Asset Reporting Framework** (ARF) format.
The Asset Reporting Format is a data model to express the transport format of information about assets, and the relationships between assets and reports. The standardized data model facilitates the reporting, correlating, and fusing of asset information throughout and between organizations. ARF is vendor and technology neutral, flexible, and suited for a wide variety of reporting applications.
For more details on the format specification refer to https://www.nist.gov/publications/specification-asset-reporting-format-11
## 6.1 - Understanding raw result storage
When the Compliance Operator runs a scan, raw results are stored in a `PersistentVolume`. The following `oc` command shows the mapping `PersistentVolume` name for a given scan name.
Let's use our scan name that we set up previously, `daily-nist-800-53-moderate`:
```bash
oc get --namespace openshift-compliance compliancesuites daily-nist-800-53-moderate --output json | jq '.status.scanStatuses[].resultsStorage'
```
We should see results showing the name of each `PersistentVolume` for each profile that was scanned, below is an example:
```json
{
"name": "ocp4-moderate",
"namespace": "openshift-compliance"
}
{
"name": "ocp4-moderate-node-master",
"namespace": "openshift-compliance"
}
{
"name": "ocp4-moderate-node-worker",
"namespace": "openshift-compliance"
}
```
We can view the details of these `PersistentVolumes` as follows:
```bash
oc get pvc --namespace openshift-compliance ocp4-moderate
```
## 6.2 - Retrieving results from a volume
Let's retrieve some specific results files from a volume by mounting the volume into a pod, and then using `oc` to copy the volume contents to our highside ssh host.
We can create a pod using the `rhel8/support-tools` additional image that was mirrored into our disconnected environment.
> Note: Note the use of the pinned sha256 image digest below rather than standard image tags, this is a requirement of the mirroring process.
```bash
cat << EOF | oc --namespace openshift-compliance apply --filename -
apiVersion: "v1"
kind: Pod
metadata:
name: pv-extract
spec:
containers:
- name: pv-extract-pod
image: registry.redhat.io/rhel8/support-tools@sha256:ab42416e9e3460f6c6adac4cf09013be6f402810fba452ea95bd717c3ab4076b
command: ["sleep", "3000"]
volumeMounts:
- mountPath: "/ocp4-moderate-scan-results"
name: ocp4-moderate-scan-vol
volumes:
- name: ocp4-moderate-scan-vol
persistentVolumeClaim:
claimName: ocp4-moderate
EOF
```
> Note: Spawning a pod that mounts the `PersistentVolume` will keep the claim as `Bound`. If the volume’s storage class in use has permissions set to `ReadWriteOnce`, the volume is only mountable by one pod at a time. You must delete the pod upon completion, or it will not be possible for the Operator to schedule a pod and continue storing results in this location.
With the volume mounted we can copy the results out to our machine:
```bash
mkdir /mnt/high-side-data/compliance-results
oc cp pv-extract:/ocp4-moderate-scan-results --namespace openshift-compliance .
```
After the copy has completed we should delete our helper pod to unbind the volume:
```bash
oc delete pod pv-extract --namespace openshift-compliance
```
## 6.3 - Reviewing raw result files
Now that we have a copy of the raw result files, let's see what they look like.
Starting with an `ls -lah` in our highside terminal we can see each scan result is stored in a numbered directory, yours should look similar to the example below:
```bash
drwxr-xr-x. 5 lab-user lab-user 42 Sep 1 20:35 .
drwxr-xr-x. 7 lab-user lab-user 4.0K Sep 1 20:28 ..
drwxr-xr-x. 2 lab-user lab-user 52 Sep 1 20:35 0
drwxr-xr-x. 2 lab-user lab-user 52 Sep 1 20:35 1
drwxr-xr-x. 2 lab-user lab-user 6 Sep 1 20:35 lost+found
```
If we take a look at one of the specific directories with `ls -lah compliance-results/1/` we'll see an archive file:
```bash
-rw-r--r--. 1 lab-user lab-user 251K Sep 1 20:35 ocp4-moderate-api-checks-pod.xml.bzip2
```
Let's drop into that directory and extract it now to take a look at the contents, run the commands below in your highside ssh terminal:
> Note: If you get an error from the `bunzip2` command below you may need to first install it with `sudo yum install --yes bzip2`.
```bash
cd /mnt/high-side-data/compliance-results/1
bunzip2 ocp4-moderate-api-checks-pod.xml.bzip2
mv ocp4-moderate-api-checks-pod.xml.bzip2.out ocp4-moderate-api-checks-pod.xml
ls -lah
```
Now we're getting somewhere, we can see we have `.xml` file. Let's take a quick peek at the contents:
```bash
head ocp4-moderate-api-checks-pod.xml
```
You should see an xml document snippet similar to the example below:
```xml
<core:relationships xmlns:arfvocab="http://scap.nist.gov/specifications/arf/vocabulary/relationships/1.0#">
<core:relationship type="arfvocab:createdFor" subject="xccdf1">
<core:ref>collection1</core:ref>
</core:relationship>
<core:relationship type="arfvocab:isAbout" subject="xccdf1">
<core:ref>asset0</core:ref>
</core:relationship>
</core:relationships>
```
## 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.
Run the commands below in your high side terminal, we'll start by installing the `openscap-scanner` package.
```bash
sudo yum install -y openscap-scanner
```
One the tooling is installed let's generate the report:
```bash
oscap xccdf generate report ocp4-moderate-api-checks-pod.xml > report.html
```
So far we've done all this on our high side terminal. We need to get this report artifact to our low side server where our Firefox vnc session is running, let's copy it out now:
```bash
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! Once you've reviewed the report you can move on to exercise 7 🚀

76
data/workshop/exercise7.mdx
View File

@ -1,76 +0,0 @@
---
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?
## 7.3 - Exploring the rhacs policy engine
Red Hat Advanced Cluster Security for Kubernetes allows you to use out-of-the-box security policies and define custom multi-factor policies for your container environment.
Configuring these policies enables you to automatically prevent high-risk service deployments in your environment and respond to runtime security incidents.
All of the policies that ship with the product are designed with the goal of providing targeted remediation that improves security hardening.
Take some time to reivew the default policies by clicking **Platform Configuration** > **Policy Management**. You’ll see this list contains many **Build** and **Deploy** time policies to catch misconfigurations early in the pipeline, but also **Runtime** policies that point back to specific hardening recommendations.
These policies come from us at Red Hat - our expertise, our interpretation of industry best practice, and our interpretation of common compliance standards, but you can modify them or create your own.
If you have some time take a look at the options for editing default policies to change their enforcement behavior or scope.
<Zoom>
|![workshop](/static/images/compliance/acs-policies.png) |
|:-----------------------------------------------------------------------------:|
| *Policy management in Red Hat Advanced Cluster Security* |
</Zoom>
If you're ready for a different topic, head over to Exercise 8, for the final tasks today to deploy Red Hat Developer Hub 🙂

78
data/workshop/exercise8.mdx
View File

@ -1,78 +0,0 @@
---
title: Bonus - Installing red hat developer hub
exercise: 8
date: '2024-09-02'
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 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
Earlier in exercise 3 we deployed the Red Hat Developer Hub Operator. We'll now instruct that operator to deploy an instance of Developer Hub for us by creating a `Backstage` custom resource.
Run the following command in your highside terminal session:
```bash
cat << EOF | oc apply --filename -
---
apiVersion: v1
kind: Namespace
metadata:
name: rhdh
spec:
finalizers:
- kubernetes
---
apiVersion: rhdh.redhat.com/v1alpha1
kind: Backstage
metadata:
name: developer-hub
namespace: rhdh
spec:
application:
appConfig:
mountPath: /opt/app-root/src
extraFiles:
mountPath: /opt/app-root/src
replicas: 1
route:
enabled: true
database:
enableLocalDb: true
EOF
```
Once the pods in the `rhdh` namespace are `Ready` we can retrieve and open the `Route` for our new Developer Hub instance and complete our first time login.
```bash
oc get route --namespace rhdh backstage-developer-hub --output jsonpath='{.spec.host}'
```
<Zoom>
|![workshop](/static/images/compliance/developer-hub.gif) |
|:-----------------------------------------------------------------------------:|
| *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.