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: finalizers:
- kubernetes - kubernetes
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: rhdh-operator
namespace: rhdh-operator
--- ---
apiVersion: operators.coreos.com/v1alpha1 apiVersion: operators.coreos.com/v1alpha1
kind: Subscription 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> </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: 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. 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. 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. 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 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. 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