I've completed DO425 and I'm ready to report the typos, errors and bugs I have noticed in it. As I suggested here, it would be cool to be able to report them directly in the course (wiki-style). An other suggestion I made would be to systematically have a dedicated RHLC thread be created for each course, similarly to what was done for the Red Hat Summit Power Trainings.
Sadly, I started taking note of them close to the end of my preparation for EX425, so I probably missed many.
1.5 Describing Least-Privilege Technology
"In UNIX systems, a process with UID 0 can change itself to a more restricted configuration, but any other process can only demote itself to a more restrictive configuration."
"Model Linux kernels"
2.3 Identifying Trusted Images
"The following except stores new signatures under the filesystem"
3.1 Reviewing the OpenShift Automated Build Process
[user@demo ~]$ oc set build-hook bc/build-config-name \ --post-commit \ --command \ --command
-> here a critical space is missing at the last line which should read: -- command
3.1 Reviewing the OpenShift Automated Build Process
[user@demo ~]$ oc set triggers bc build-config-name \ --from-image="imagestream"
The command syntax is misleading. You should monitor for images stream changes, not container image changes."
-> the actual syntax is: --from-image="imagestream:tag" ; what is actually monitored is an image stream tag (thanks @oldbenko for having taught me that !)
3.2 Guided Exercise: Performing a Source-to-Image Build Process
At section 1.2:
<profile> <id>openshift</id> </profile>
-> those 3 lines are actually not in security.txt
At section 2.2:
"From the terminal window, run the following command to build the image:"
-> the following command actually creates the project
4.4 Guided Exercise: Integrating Red Hat Identity Management and 4.7 Lab: Managing User Access Control
IDM labs are broken when IDM admin password has expired, as I previously mentioned here.
4.6 Guided Exercise: Installing Single Sign-on Authentication
for f in ~/sso72-dev; do oc delete -f $f; done for f in ~/sso72-dev; do oc create -f $f; done
-> This accidentally works, but only because the -f flag also accepts a directory ; each loop actually iterates only once and therefore is needless
4.7 Lab: Managing User Access Control
"This file already contains the oc adm group sync"
-> oc adm groups sync
5.1 Automating Policy-Based Deployments
"On master nodes, define the experimental-encryption-provider-config experimental-encryption-provider-config in the /etc/origin/master/master-config.yaml file."
-> "experimental-encryption-provider-config" is repeated
10.2 Lab: Securing Single Container Applications and 10.3 Lab: Securing Multiple Container Applications
-> Those 2 comprehensive review labs'solutions are not hidden, as previously mentioned here.
10.2 Lab: Securing Single Container Applications
"The jrdevs group has the edit and jruser1 users as members of that group. The password for jruser1 is redhat."
-> 'edit' is actually not an user but a role
-> Both the solution and the grading script refer to a jrdev1 user instead of jruser1
"create an Apache HTTP Server pod named testhttpd [...] Leave the testhttpd pod running..."
-> testhttp (not testhttpd) is the name used in all the rest of the course and in the grading script
"Application pods run with resource limits set to 200 millicores of CPU and 384 Mi of memory."
-> Such limits can only be set to containers, not to pods ; both the lab solution and the grading script rely on 'type=Container' for those limits
"Deploy the compreview-singe/customapp container image from Quay"
At section 2.6:
"You should see a subdirectory named from the httpd-24-rhel7 image."
-> It's actually named compreview-single
At section 6.1:
requests.cpu: "1000m" requests.memory: "1536Mi"
-> Such global requests quotas for the project are not requested by the lab instructions and not checked by the grading script either
Sections 7.10 to 7.17 erroneously repeat section 7.2 to 7.8.
The whole section 9 erroneously repeats section 8.
10.3 Lab: Securing Multiple Container Applications
"Access Jenkins at htps://jenkins-cicd.apps.lab.example.com and log in to Jenkins as the developer user from OpenShift."
"Deploy the egress router pod using the egress-router-pod.yaml file [...]
Edit these files as required to provide access to the external database [...]
The stage environment accesses an external MariaDB database server on the services VM to best mimic the production environment for load testing. [...]"
-> The third (introductory) stanza should be put first here
"To allow secure storage access from compreview-multiple-dev and other development projects, create the devdb-scc security context constraint. This SCC allows containers to run with the GID range from 10000 to 20000."
-> A runAsAny policy (with appropriate range) matches the requirement, but the grading script erroneously expects a mustRunAs policy
Hi @littlebigfab ,
Thank you for sharing your valuable feedback and bringing this to our notice.
I will ensure that they reach the team to take appropiate action.
Your valuable contribution to making the course better is really appreciated.
You may as well raise support request with the Learner Experience team and send such feedbacks or any issues you are facing while doing the courses.
The Comprehensive review (chapter 10) - Lab: Securing Single Container Applications solution is actually not working - it seems like there is a problem with the CA certificate for Quay Enterprise:
oc new-app --name=test --docker-image quay.apps.lab.example.com/compreview-single/customapp
[W0106 14:33:18.789889 6098 dockerimagelookup.go:233] Docker registry lookup failed: Get https://quay.apps.lab.example.com/v2/: x509: certificate signed by unknown authority
I have the same problem... podman on node downloads image fine from quay.
I suppose master api has a problem to validate cert as quay is exposiong externally (passtrough route) certificate with it's internal URL ( quay...svc.cluster.local) not matching HTTP request from master api
This is a fairly recent issue, it crept into the materials during the last update of the course.
The root cause for this is that there is a reference to an additional CA file in the ImageImportPolicy section of master-config.yaml, attribute AdditionalTrustedCA.
There are two possible solutions:
Hope this helped.
I've got another couple of minor ones for the latest release - I'll use the next week's delivery as an opportunity to gather the technical information needed for the tickets. I can add the AdditionalTrustedCA one for you as well if you want.