EX380 Questions and Answers

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: Verify the cluster name, namespace, and user name that should be referenced.

The lab uses cluster api-ocp4-example-com:6443, namespace audit-ns, and user audit-sa.

Step 2: Run the command:

oc config set-context audit --cluster api-ocp4-example-com:6443 --namespace audit-ns --user audit-sa --kubeconfig audit.config

Step 3: Confirm context creation.

The lab output shows:

Context "audit" created.

Detailed explanation:

A kubeconfig context ties together three things: a cluster endpoint, a user identity, and optionally a default namespace. This Task creates a context named audit in the file audit.config. Contexts are useful because they simplify repeated administration by letting the user switch between prepared working environments instead of re-entering cluster and namespace details each time. The namespace portion is especially helpful for project-scoped operations, because commands run under that context default to the chosen namespace. Accuracy matters here: if the user name in the context does not match the credentials entry or the cluster name does not exist in the kubeconfig, the context will not function as intended.

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

Patch deployment with toleration

oc -n payments patch deploy api --type=merge -p '{

"spec":{"template":{"spec":{"tolerations":[

{"key":"dedicated","operator":"Equal","value":"payments","effect":"NoSchedule"}

]}}}

}'

Toleration allows pods to schedule onto tainted nodes.

Verify scheduling

oc -n payments get pods -o wide

==========

Step 1: Identify the pending certificate signing request.

The lab names it audit-csr.

Step 2: Run the approval command:

oc adm certificate approve audit-csr

Step 3: Confirm approval.

The lab output shows:

certificatesigningrequest.certificates.k8s.io/audit-csr approved

Detailed explanation:

In Kubernetes and OpenShift, a CSR must be approved before the requester can use the signed certificate for authentication. This Task approves the CSR named audit-csr, which is likely associated with the audit user or service account access flow in the lab. Certificate-based authentication is commonly used for kubeconfig access because it enables secure client identity without relying solely on tokens. Until the CSR is approved, the certificate cannot be trusted by the cluster API for authenticated operations. Administrative approval is therefore a gatekeeping step that ensures only intended certificate requests become valid credentials. This Task is part of a broader kubeconfig workflow that continues with setting credentials and defining context.

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

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.

==========

Step 1: Make sure the context already exists in the kubeconfig file.

This follows the context creation Task SIMULATION .

Step 2: Run the command:

oc config use-context audit --kubeconfig audit.config

Step 3: Confirm the active context switches successfully.

The lab output shows:

Switched to context "audit".

Detailed explanation:

This command activates the audit context inside the specified kubeconfig file. Once selected, subsequent oc commands using that kubeconfig will default to the cluster, user, and namespace associated with that context. This is operationally important because many administration mistakes come from running commands against the wrong cluster or project. Using explicit context switching reduces that risk and makes the kubeconfig usable for the intended audit workflow. In exams and real environments alike, the context is what turns separate kubeconfig elements into a working session configuration. Without switching to the correct context, even a well-formed kubeconfig may not be used as expected.

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

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

==========