RedHat EX380 - Red Hat Certified Specialist in OpenShift Automation and Integration

Find the alert name and labels

Web console: Observe → Alerts → click the alert to view label set.

Open Alertmanager silences

Observe → Alerting → Alertmanager → Silences → Create silence

Explanation: Silences mute alerts matching label filters.

Create the silence

Add matcher: alertname = < ALERT_NAME >

Duration: 2 hours

Save.

Verify the alert shows as silenced

The alert should indicate it is silenced in the UI.

==========

Install OADP via Web Console

Operators → OperatorHub → search OADP / OpenShift API for Data Protection → Install

Explanation: This operator manages Velero and backup integrations.

Verify the operator CSV is installed

oc get csv -A | grep -i -E "oadp|data protection|velero"

Confirms installation succeeded.

Verify pods in the OADP namespace (commonly openshift-adp)

oc get pods -n openshift-adp

You should see Velero/OADP-related pods in Running state.

==========

Verify logging namespace and resources

oc get ns openshift-logging

oc -n openshift-logging get clusterlogforwarder

ClusterLogForwarder configures pipelines and outputs.

Create/Edit ClusterLogForwarder (example structure)

Define an output (external system) and pipeline selecting application logs.

Apply via YAML:

oc -n openshift-logging apply -f clusterlogforwarder.yaml

Validate collector pods are healthy

oc -n openshift-logging get pods

Forwarding relies on collectors (vector/fluentd depending config).

Generate a test log line

oc -n openshift-logging run logger --image=busybox --restart=Never -- /bin/sh -c 'echo hello-forwarding; sleep 5'

This creates a known message to search in the external endpoint.

Confirm logs arrive at destination

Use your external system’s query/search to confirm hello-forwarding.

==========

Run group sync with prune controls

oc adm groups sync --sync-config=groupsync.yaml --confirm --prune-whitelist=/tmp/whitelist.txt

Prune removes stale memberships/groups, but whitelist protects selected groups from pruning.

Verify group membership reflects LDAP

oc describe group < groupname >

Confirms removed users are no longer listed.

==========

Create the MachineConfig YAML (example content encoded in base64)

apiVersion: machineconfiguration.openshift.io/v1

kind: MachineConfig

metadata:

name: 99-worker-motd

labels:

machineconfiguration.openshift.io/role: worker

spec:

config:

ignition:

version: 3.2.0

storage:

files:

- path: /etc/motd

mode: 0644

contents:

source: data:text/plain;charset=utf-8;base64,VGhpcyBpcyBhIHdvcmtlciBub2RlLg==

MachineConfig uses Ignition format; file content is typically base64.

Apply it

oc apply -f 99-worker-motd.yaml

Watch worker MachineConfigPool roll out

oc get mcp worker

MCP will show Updating then Updated.

Validate on a worker node (if you have node access)

Confirm /etc/motd contains the expected text.

==========

Step 1: Ensure the certificate file rhds_ca.crt is available in your current working directory or use the correct path.

The Task requires creating a configmap from this CA certificate file.

Step 2: Run the command:

oc create configmap rhds-ca-config-map --from-file ca.crt=rhds_ca.crt -n openshift-config

Step 3: Confirm the configmap is created.

The lab output shows:

configmap/rhds-ca-config-map created

Detailed explanation:

This creates a configmap named rhds-ca-config-map in the openshift-config namespace and maps the local file rhds_ca.crt to the key name ca.crt inside the configmap. This is important in external identity integration because OpenShift may need to trust a custom certificate authority when communicating with LDAP or another secured external service. By placing the certificate in a configmap, the authentication operator or related cluster configuration can reference it cleanly. The key name matters because many OpenShift resources expect a CA bundle key with a specific filename-like convention. If the file path is wrong, the command fails immediately. If the configmap name or key mapping is wrong, the authentication provider referencing it may not trust the external endpoint.

============

Create a local htpasswd file with a test user

htpasswd -c -B -b /tmp/htpass.txt testuser RedHat123!

-c creates a new file (use only once).

-B uses bcrypt hashing (recommended).

-b supplies password non-interactively (good for labs).

Create the HTPasswd secret in openshift-config

oc -n openshift-config create secret generic htpass-secret --from-file=htpasswd=/tmp/htpass.txt

OAuth reads the htpasswd key from this secret.

Edit OAuth and add the HTPasswd provider (keep LDAP intact)

oc edit oauth cluster

Add another entry under spec.identityProviders:

- name: local-htpasswd

mappingMethod: claim

type: HTPasswd

htpasswd:

fileData:

name: htpass-secret

This adds a second login option while preserving LDAP.

Restart OAuth pods

oc -n openshift-authentication delete pod -l app=oauth-openshift

Ensures the updated list of identity providers is loaded.

Verify login works for htpasswd user

Log in via console using testuser.

Confirm the user is created:

oc get user testuser

==========

Create (or switch to) the project

oc new-project payments

Namespace must exist before applying rolebindings.

Grant edit to the group

oc -n payments policy add-role-to-group edit dev-team

Members of dev-team can modify most resources in payments.

Grant view to a user

oc -n payments policy add-role-to-user view auditor1

auditor1 can read resources but not change them.

Verify rolebindings

oc -n payments get rolebinding

==========

Step 1: Ensure the client certificate and private key files are available.

The lab uses audit.crt and tls.key.

Step 2: Run the command:

oc config set-credentials audit --client-certificate audit.crt --client-key tls.key --embed-certs --kubeconfig audit.config

Step 3: Confirm the user entry is written.

The lab output shows:

User "audit" set.

Detailed explanation:

This command creates or updates the audit user entry inside the kubeconfig file audit.config. It points the user to a client certificate and private key, and the --embed-certs option stores certificate material directly inside the kubeconfig rather than only referencing external files. That makes the kubeconfig more portable because it can be moved and used without separately copying the certificate files, provided the embedded content is valid. In certificate-based authentication, the private key proves client possession while the certificate presents the approved identity. If the certificate and key do not match, authentication will fail. This step does not yet define what cluster or namespace the user works against; it only defines the credential identity.

============