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

Begin working on exercise 6.

Browse Source
This commit is contained in:
James Blair
2024-09-01 22:46:03 +12:00
parent d2b26d41c9
commit 7871b1ce08
4 changed files with 29 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
data/workshop/exercise3.mdx
View File

@ -115,6 +115,13 @@ spec:
finalizers:
- kubernetes
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: rhdh-operator
namespace: rhdh-operator
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription

2
data/workshop/exercise4.mdx
View File

@ -95,7 +95,7 @@ Time to bring up our RHACS dashboard. We'll first retrieve the `admin` user pass
</Zoom>
## 4.4 Securing our hub cluster
## 4.4 - Securing our hub cluster
To begin securing our OpenShift "hub" cluster with RHACS we need to:

6
data/workshop/exercise5.mdx
View File

@ -87,7 +87,7 @@ timeout: 30m0s
```
## 5.2 Review cluster compliance
## 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.
@ -110,7 +110,7 @@ Navigate to **Compliance** > **Coverage** and review the overall result for the
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
## 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.
@ -143,7 +143,7 @@ A default policy is available out of the box called **Pod Service Account Token
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
## 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.

18
data/workshop/exercise6.mdx Normal file
View File

@ -0,0 +1,18 @@
---
title: Installing red hat developer hub
exercise: 6
date: '2024-09-02'
tags: ['openshift','containers','kubernetes','disconnected']
draft: false
authors: ['default']
summary: "Upping our dx in a disconnected environment"
---
We've had a good dig into cluster 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.
## 6.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