EX280 Security And SCC — 30 Questions

Question 1

An administrator has created a custom SCC named restricted-custom. During testing, pods using this SCC still fail because they are assigned the non-root UID range automatically, but the application container requires writing to a specific directory owned by UID 1000. How should the administrator configure the SCC to ensure the container runs consistently as UID 1000?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Set runAsUser.type to MustRunAs and specify uid: 1000 in the uidRange. Setting runAsUser.type to MustRunAs with uid: 1000 in the uidRange forces the container to run as UID 1000, matching the ownership of the target directory. MustRunAs requires the pod to specify a runAsUser that falls within the configured range, ensuring consistent UID assignment. RunAsAny would allow any UID, which does not guarantee UID 1000 and could still cause permission failures.

Answer

Set runAsUser.type to RunAsAny and add securityContext.runAsUser: 1000 in the pod spec

Answer

Configure fsGroup.type to MustRunAs with uid: 1000

Answer

Set privileged: true and map the container user via supplementalGroups

Question 2

A pod fails to start in a restricted namespace because it attempts to bind to a privileged host port (port 80). The administrator wants to create a custom SCC that permits binding to privileged ports only for this specific application workload, without granting full root privileges. Which custom SCC configuration field should be explicitly set?

Accepted Answer

allowHostPorts: true. The allowHostPorts field in a Security Context Constraint controls whether pods can bind to privileged ports (below 1024) on the host. Setting allowHostPorts: true permits the workload to bind to port 80 without granting root-level privileges or privileged container access. This is the minimal, targeted permission that satisfies the requirement while keeping the SCC otherwise restrictive.

Answer

runAsUser.type: RunAsAny

Answer

allowPrivilegedContainer: true

Answer

privileged: true

Question 3

An administrator is auditing Pod Security Standards compliance across several namespaces in an OpenShift cluster. Which namespace label must be applied to enforce the restricted Pod Security standard while logging violations?

Accepted Answer

pod-security.kubernetes.io/enforce: restricted. The label pod-security.kubernetes.io/enforce: restricted is the correct namespace label to enforce the restricted Pod Security Standard. When applied, the Pod Security Admission controller blocks any pod that violates the restricted policy. To also log violations, you would add pod-security.kubernetes.io/audit: restricted and pod-security.kubernetes.io/warn: restricted, but the enforce label is the one that actively prevents non-compliant pods from being created. This label is part of the upstream Kubernetes Pod Security Admission (PSA) feature, which OpenShift 4.11+ uses alongside Security Context Constraints (SCCs).

Answer

pod-security.openshift.io/standard: restricted

Answer

security.openshift.io/scc.enforce: restricted

Answer

openshift.io/cluster-monitoring: "true"

Question 4

An administrator needs to configure a new project so that pods deployed within it run with the restricted-v2 Security Context Constraint by default. Which action should the administrator perform?

Accepted Answer

Annotate the Namespace with security.openshift.io/scc: restricted-v2. OpenShift determines which SCC applies to a pod by first checking the namespace annotation security.openshift.io/scc. When set, the SCC admission plugin restricts pods in that namespace to the named SCC (restricted-v2), overriding the default assignment logic. This is the supported, non-destructive way to pin a namespace to a specific SCC without altering cluster-wide defaults.

Answer

Edit the default cluster-wide SCC object directly to set restricted-v2 as priority zero

Answer

Create a RoleBinding linking the restricted-v2 ClusterRole to the system:authenticated group

Answer

Patch the PodSecurity standards admission configuration in the APIServer resource

Question 5

A developer deploys a custom application pod that requires the hostIPC capability, but the pod creation is rejected by the apiserver. Upon inspecting the cluster SCCs, the administrator determines that the application uses a ServiceAccount named app-sa in the production namespace. How should the administrator grant the restricted SCC privileges safely without compromising cluster security?

Accepted Answer

Create a RoleBinding in the production namespace referencing the system:openshift:scc:hostaccess cluster role and the app-sa ServiceAccount. The correct approach is to create a RoleBinding in the production namespace that references the system:openshift:scc:hostaccess ClusterRole and the app-sa ServiceAccount. This grants the ServiceAccount permission to use the hostaccess SCC, which allows hostIPC. The hostaccess SCC is a predefined ClusterRole that provides access to the hostaccess SCC, and binding it via RoleBinding ensures the grant is namespace-scoped and follows least privilege. This method is the standard OpenShift way to grant SCC access to a ServiceAccount without modifying the SCC itself.

Answer

Add a subject entry referencing system:serviceaccount:production:app-sa to the users list inside the restricted SCC definition

Answer

Annotate the app-sa ServiceAccount with openshift.io/scc.constraint: hostaccess

Answer

Create a ClusterRoleBinding that binds the system:openshift:scc:restricted cluster role to system:serviceaccount:production:app-sa

Question 6

An administrator wants to prevent developers from creating pods that run as the root user across the entire cluster. Which OpenShift resource or admission mechanism is best suited to enforce this restriction globally?

Accepted Answer

Modifying the restricted-v2 SCC to ensure root execution is disallowed via user ID restrictions. The restricted-v2 SecurityContextConstraint (SCC) is the default SCC applied to pods in OpenShift and is specifically designed to prevent containers from running as root by forcing them to run with an arbitrary, non-root UID assigned by the cluster. Modifying this SCC to enforce user ID restrictions cluster-wide ensures that any pod admitted under it cannot run as UID 0, which is the standard OpenShift mechanism for enforcing this policy globally.

Answer

Disabling the ServiceAccount controller in the cluster operator configuration

Answer

Adding a cluster-wide ValidatingWebhookConfiguration that intercepts Route creations

Answer

Creating a global ConfigMap in the openshift-config namespace named root-blocker

Question 7

An administrator is troubleshooting an Ingress routing issue where external clients receive a 503 error when trying to access a secure application through a Route configured with passthrough TLS termination. What is the most likely cause of this issue?

Accepted Answer

The target application pod is not configured to terminate TLS and present a valid certificate matching the route hostname. In a passthrough TLS termination Route, the Ingress controller does not decrypt TLS; it simply forwards the encrypted TCP stream to the backend pod. Therefore, the application pod itself must be configured to terminate TLS and present a certificate that matches the Route's hostname. If the pod is not listening for TLS or its certificate does not match the hostname, the router cannot establish a secure connection, resulting in a 503 error.

Answer

The Route manifest is missing the spec.tls.destinationCACertificate field

Answer

The default Ingress controller wildcard certificate has expired

Answer

The Route object lacks an annotation specifying openshift.io/router.router-credentials

Question 8

An administrator needs to ensure that a newly created ServiceAccount automatically receives a long-lived API token when created in OpenShift 4.14+. What is the correct procedure?

Accepted Answer

Create a Secret of type kubernetes.io/service-account-token and reference the ServiceAccount name in the secret metadata annotations. In OpenShift 4.14+, the legacy behavior of automatically creating a long-lived service-account token Secret was removed. To obtain a long-lived token, an administrator must manually create a Secret of type kubernetes.io/service-account-token and annotate it with the ServiceAccount name (kubernetes.io/service-account.name). The token controller then populates the Secret with a token, which is the supported procedure for long-lived credentials.

Answer

Patch the default cluster authentication profile to revert to automountServiceAccountToken globally

Answer

Add the annotation serviceaccounts.openshift.io/want-token: "true" to the ServiceAccount metadata

Answer

Execute the oc create token command and store the output in a ConfigMap

Question 9

An auditor requests a report of all security context constraints currently assigned to a specific user named alice in the cluster. Which OpenShift CLI command should the administrator run?

Accepted Answer

oc adm policy who-can use scc. The oc adm policy who-can command or oc get scc with appropriate filtering, or checking SCC matches via adm can-i commands, but the dedicated command to see which SCCs apply to a user is oc adm policy who-can use scc.

Answer

oc get scc --user=alice

Answer

oc describe user alice --with-scc

Answer

oc auth can-i use scc --as=alice

Question 10

An administrator is configuring an OAuth identity provider and needs to map claims from an external provider to OpenShift usernames. Which field in the OAuth configuration specifies the claim to use as the username?

Accepted Answer

mappingMethod and attributes.username. In OpenShift, the OAuth identity provider configuration uses the `mappingMethod` to define how identities are mapped to users, and the `attributes.username` field (under the identity provider's `providerConfig`) specifies which claim from the external provider's response should be used as the username. This is part of the `OAuth` custom resource (CR) in OpenShift 4.x, where `spec.identityProviders` contains the provider configuration. The `attributes` section allows mapping of standard claims like `username`, `displayName`, and `email` to OpenShift user attributes.

Answer

metadata.annotations['oauth.openshift.io/username-claim']

Answer

spec.identityProviders.providerConfig.userField

Answer

status.providerStatus.usernameMapping

Question 11

A security engineer needs to configure the cluster-wide OAuth identity provider to use an existing LDAP server. The administrator creates an LDAP identity provider object in the cluster OAuth configuration resource (cluster). Which configuration property specifies the attribute mapping to map the LDAP entry's unique identifier to the OpenShift user name?

Accepted Answer

mappingMethod: lookup with attributes.id set to the unique attribute like uid or sAMAccountName.. In the LDAP identity provider configuration, the 'mappingMethod' field determines how user identities are mapped. When set to 'lookup', OpenShift looks up the user by the attribute specified in 'attributes.id', which should be the unique identifier like 'uid' or 'sAMAccountName'. This maps the LDAP entry's unique identifier to the OpenShift user name.

Answer

url specifying the bind DN and attributes.username set to cn.

Answer

identityProviders.ldap.mapping.rules pointing to a ConfigMap containing user maps.

Answer

bindPassword referencing a Secret containing the attribute translation matrix.

Question 12

An application pod needs to run with a specific user ID (UID 10005000) that falls outside the restricted-v2 SCC default allocated range for the namespace. The administrator decides to create a custom SCC. Which SCC security context strategy parameter must be adjusted to allow this specific UID?

Accepted Answer

runAsUser with type: RunAsAny or specifying the UID range in uidRanges.. To allow a pod to run with a specific UID outside the namespace's allocated range, the SCC's runAsUser strategy must be set to RunAsAny or MustRunAs with a uidRange that includes the desired UID. This overrides the default restricted-v2 SCC which uses MustRunAsRange and enforces the namespace's UID range.

Answer

supplementalGroups with type: RunAsAny and fsGroup set to 10005000.

Answer

seLinuxContext with type: MustRunAs and level set to s0:c100,c200.

Answer

runAsUser with type: MustRunAs and uidRange or uid settings covering the required value.

Question 13

An administrator needs to secure a Route using a custom wildcard certificate. The certificate and private key are stored in a TLS Secret named wildcard-tls-secret in the same namespace as the Route. Which section of the Route manifest should reference this Secret?

Accepted Answer

spec.tls with termination: edge and certificate, key, and caCertificate fields pointing to the secret keys.. To secure a Route with a custom wildcard certificate stored in a TLS Secret, the Route manifest must include a spec.tls section with termination set to edge (or reencrypt/passthrough as appropriate) and specify the certificate, key, and caCertificate fields referencing the keys in the Secret. This configures the Route to use the provided certificate for TLS termination.

Answer

spec.backend.tlsSecret.

Answer

spec.wildcardPolicy with secretName: wildcard-tls-secret.

Answer

metadata.annotations using the route.openshift.io/tls-secret annotation.

Question 14

Which command checks if a specific service account can use a restricted SCC?

Accepted Answer

oc adm policy can-i use scc restricted --as=system:serviceaccount:myns:mysa. The 'oc adm policy can-i' command is used to verify permissions, including SCC usage.

Answer

oc check scc restricted -z mysa

Answer

oc describe scc restricted

Answer

oc auth can-i use scc restricted

Question 15

Which THREE restrictions or behaviors are enforced by the default restricted-v2 Security Context Constraint in OpenShift Container Platform?

Accepted Answer

Containers are prohibited from running with privileged mode enabled.. Option A is correct because restricted-v2 sets allowPrivilegedContainer to false, so containers cannot run with privileged: true. Option C is correct because restricted-v2 requires that all Linux capabilities be dropped (requiredDropCapabilities: ALL), while permitting NET_BIND_SERVICE to be added back via allowedCapabilities. Option E is correct because restricted-v2 enforces MustRunAsNonRoot, rejecting any pod whose container runs as UID 0. Option B is wrong because restricted-v2 forbids hostNetwork, hostIPC, and hostPID (they must be false). Option D is wrong because the automatic random UID assignment from the namespace's pre-allocated UID range is performed by the openshift.io/sa.scc.uid-range annotation and the MustRunAsRange strategy, not by restricted-v2's default behavior for arbitrary pods.

Answer

Containers are allowed to mount host network, host IPC, and host PID namespaces.

Answer

Pods are automatically assigned a random UID from the namespace's pre-allocated UID range.

Question 16

A pod fails to start with 'container has runAsNonRoot and image will run as root'. Which SCC field needs to be adjusted in a custom SCC to allow this image to run?

Accepted Answer

runAsUser: RunAsAny. The error 'container has runAsNonRoot and image will run as root' occurs when the container image is configured to run as UID 0 (root) but the SCC enforces runAsNonRoot. To allow the image to run as root, the SCC's runAsUser strategy must be set to RunAsAny, which permits any UID including root. This overrides the MustRunAsRange or MustRunAsNonRoot restrictions.

Answer

runAsUser: MustRunAsRange

Answer

readOnlyRootFilesystem: false

Answer

allowPrivilegedEscalation: true

Question 17

You have a private image registry that requires credentials. Where should you place the 'imagePullSecret' so that it is automatically injected into all pods created by a specific service account?

Accepted Answer

oc secrets link default . To automatically inject an image pull secret into all pods created by a specific ServiceAccount, the administrator should link the secret to that ServiceAccount using 'oc secrets link --for=pull'. This adds the secret to the ServiceAccount's imagePullSecrets field, and any pod using that ServiceAccount will inherit the credentials. The 'default' ServiceAccount is commonly used for this purpose.

Answer

oc annotate sa default imagePullSecret=<secret-name>

Answer

oc edit namespace --add-secret=

Answer

oc set image-pull-secret <secret-name>

Question 18

You want to ensure that all pods in a namespace are denied access to the host network. Which policy mechanism is most effective for this?

Accepted Answer

Configure an SCC with 'hostNetwork: false'. Security Context Constraints (SCCs) in OpenShift control pod-level security attributes, including whether a pod can use the host network (hostNetwork). Setting hostNetwork: false in an SCC and binding it to the namespace's service accounts denies pods the ability to request host networking. This is the most effective mechanism because SCCs are enforced by the API server at pod admission time, preventing the pod from being created with hostNetwork: true.

Answer

Configure the IngressController

Answer

Use a NetworkPolicy

Answer

Use an ImagePolicyWebhook

Question 19

You are hardening a cluster. Which Pod Security Standard level is the default in OpenShift 4.14 for new projects?

Accepted Answer

restricted. In OpenShift 4.14, the default Pod Security Standard (PSS) level enforced for new projects is restricted, aligning with the upstream Kubernetes Pod Security Admission restricted profile. This is set via the cluster-wide pod security configuration and applied through the restricted-v2 SCC. New namespaces get labels like pod-security.kubernetes.io/enforce: restricted by default.

Answer

baseline

Answer

privileged

Answer

enforce

Question 20

A pod requires access to the hostPath volume. Which SCC field must be configured to allow this?

Accepted Answer

volumes: ["hostPath"]. The SCC field that controls hostPath volume access is 'volumes', which is a list of allowed volume plugin types. To permit hostPath mounts, the SCC must include 'hostPath' in its volumes list, e.g., volumes: ["hostPath", "configMap", "secret"]. This is the exact field the SCC admission controller checks against the pod's volume definitions.

Answer

allowHostPath: true

Answer

privileged: true

Answer

mounts: host