EX380 Red Hat Certified Specialist in OpenShift Automation and Integration Questions and Answers

Taint nodes

oc adm taint nodes worker-1 dedicated=payments:NoSchedule

oc adm taint nodes worker-2 dedicated=payments:NoSchedule

NoSchedule blocks new pods that do not tolerate the taint.

Confirm taints

oc describe node worker-1 | grep -i taints -A2

Ensures taints are present.

Validate effect

A normal deployment without tolerations will remain Pending if it can only land on those tainted nodes.

==========

Collect Keycloak details

Issuer URL (realm), client ID, and client secret.

Confirm Keycloak client has correct redirect URI for OpenShift OAuth callback.

Create a secret with the OIDC client secret

oc -n openshift-config create secret generic keycloak-oidc-secret \

--from-literal=clientSecret=' < SECRET > '

OAuth reads the OIDC client secret from this secret.

Edit OAuth and add OpenID provider

oc edit oauth cluster

Add under spec.identityProviders:

- name: keycloak

mappingMethod: claim

type: OpenID

openID:

issuer: "https://keycloak.example.com/realms/ocp"

clientID: "openshift"

clientSecret:

name: keycloak-oidc-secret

claims:

preferredUsername: ["preferred_username"]

name: ["name"]

email: ["email"]

issuer must match Keycloak realm issuer URL.

claims determines which token claims map to OpenShift username/name/email.

Restart OAuth pods

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

Verify by logging in through the web console

You should be redirected to Keycloak, authenticate, then return to OpenShift.

Confirm users/identities:

oc get users

oc get identities

==========

Export objects to YAML

oc -n orders get deploy,svc,route,cm,secret -o yaml > orders-app.yaml

Exports key application resources.

Create target namespace

oc new-project orders-copy

Apply exported YAML

oc -n orders-copy apply -f orders-app.yaml

Recreates resources (some fields may need adjustment, like namespaces or immutable fields).

Validate

oc -n orders-copy get all

==========

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.

==========

Generate private key and CSR

openssl genrsa -out audit2.key 2048

openssl req -new -key audit2.key -out audit2.csr -subj "/CN=audit2/O=auditors"

CN becomes username; O can map to groups in some setups.

Base64 encode CSR for the API object

CSR=$(base64 -w0 audit2.csr)

Kubernetes CSR object expects base64-encoded request data.

Create the CSR object

cat < < EOF | oc apply -f -

apiVersion: certificates.k8s.io/v1

kind: CertificateSigningRequest

metadata:

name: audit2-csr

spec:

request: ${CSR}

signerName: kubernetes.io/kube-apiserver-client

usages:

- client auth

EOF

Approve the CSR

oc adm certificate approve audit2-csr

Approval triggers certificate issuance.

Extract the signed certificate

oc get csr audit2-csr -o jsonpath='{.status.certificate}' | base64 -d > audit2.crt

Produces the client certificate file.

Build kubeconfig using cert/key

oc config set-credentials audit2 \

--client-certificate=audit2.crt --client-key=audit2.key \

--embed-certs=true --kubeconfig=audit2.kubeconfig

oc config set-cluster lab \

--server="$(oc whoami --show-server)" \

--insecure-skip-tls-verify=true \

--kubeconfig=audit2.kubeconfig

oc config set-context audit2 \

--cluster=lab --user=audit2 --namespace=default \

--kubeconfig=audit2.kubeconfig

Creates a kubeconfig that authenticates using client certificates.

Test

oc --kubeconfig=audit2.kubeconfig get ns

==========

Step 1: Confirm the service account exists in auth-audit.

It must exist before a role can be assigned to it.

Step 2: Run the command:

oc adm policy add-cluster-role-to-user cluster-reader system:serviceaccount:auth-audit:audit

Step 3: Verify the binding is added.

The lab output shows:

clusterrole.rbac.authorization.k8s.io/cluster-reader added: "system:serviceaccount:auth-audit:audit"

Detailed explanation:

This binds the cluster-reader cluster role to the audit service account. The full subject format system:serviceaccount:namespace:name is required because OpenShift RBAC needs the exact service account identity. The cluster-reader role is broader than a project-scoped view role because it allows read-level access across cluster resources. This is appropriate for auditing or inspection use cases where the account must observe but not modify. The distinction between cluster roles and namespaced roles is important: cluster roles apply to non-namespaced resources and broad cluster visibility, while local roles are limited to individual projects. This Task is a classic RBAC operation that combines identity creation with controlled privilege assignment.

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

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.

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