Context You must fully integrate a container image scanner into the kubeadm provisioned cluster. Task Given an incomplete configuration located at /etc/kubernetes/bouncer and a functional container im

Question

Explanation

To integrate the image scanner, the candidate must modify the provided ValidatingWebhookConfiguration file to set the failurePolicy to Deny and the clientConfig.url to the scanner's endpoint, then apply this configuration, and finally test it by deploying a vulnerable resource.

Approach. The core task is to implement a validating admission controller for image scanning. In modern Kubernetes, this is achieved using a ValidatingWebhookConfiguration resource. Although the question uses the term 'ImagePolicyWebhook configuration' and mentions 'AdmissionConfiguration', the requirements for failurePolicy: Deny and a specific URL for the backend align perfectly with the structure of a ValidatingWebhookConfiguration.

Here's the detailed approach:

1. Connect to the Master Node: SSH into the master node: ssh kssh00301-master. This is necessary for potentially modifying the kube-apiserver manifest and for having kubectl access.
2. Ensure kubectl context: Verify or set the kubectl context using the provided command: kubectl config use-context KSSH00301.
3. Verify/Enable ValidatingAdmissionWebhook Plugin: Review the kube-apiserver static pod manifest located at /etc/kubernetes/manifests/kube-apiserver.yaml. Ensure that ValidatingAdmissionWebhook is included in the --enable-admission-plugins list. For kubeadm provisioned clusters, this plugin is typically enabled by default. No modification to --admission-control-config-file should be made for a ValidatingWebhookConfiguration resource, as these are applied dynamically via kubectl.
4. Edit the Webhook Configuration File: Open and edit the incomplete configuration file: sudo vi /etc/kubernetes/bouncer. This file is expected to contain a ValidatingWebhookConfiguration manifest.
   • Locate the webhooks array within the configuration.
   • For the relevant webhook entry (usually the one designed for image policy), set the failurePolicy field to Deny.

     failurePolicy: Deny
     

   • Within the same webhook entry, locate or add the clientConfig section and set the url to the image scanner's endpoint.

     clientConfig:
       url: https://smooth-yak.local/review
       # In a real-world scenario, a 'caBundle' (base64 encoded CA certificate) would also be required here
       # to establish trust for the HTTPS connection. Since it's not mentioned as incomplete, we focus on the explicit requirements.
     

   • Ensure other required fields like rules, sideEffects, and admissionReviewVersions are correctly defined within the webhook entry.
5. Apply the Webhook Configuration: Save the changes to /etc/kubernetes/bouncer. Then, apply this ValidatingWebhookConfiguration resource to the cluster: kubectl apply -f /etc/kubernetes/bouncer This registers the webhook with the Kubernetes API server.
6. Test the Configuration: Deploy the provided test resource: kubectl apply -f /home/candidate/vulnerable.yaml. The expected outcome is that the pod creation will be denied by the admission controller.
7. Verify Scanner Logs (Optional but good practice): If possible, check the scanner's log file (/var/log/nginx/access_log on the smooth-yak.local host) to confirm that the webhook request was received by the scanner.

Common mistakes.

• common_mistake. A common mistake is misinterpreting the phrasing 'AdmissionConfiguration' and 'ImagePolicyWebhook configuration' as referring to the legacy ImagePolicyWebhook plugin and its associated ImagePolicyConfiguration object, or trying to pass the /etc/kubernetes/bouncer file via the kube-apiserver's --admission-control-config-file flag. If /etc/kubernetes/bouncer is indeed a ValidatingWebhookConfiguration resource (which is implied by the explicit need for failurePolicy and clientConfig.url), then applying it via kubectl apply is the correct method, not via a static API server flag. Attempting to force failurePolicy into a legacy ImagePolicyConfiguration (which uses allowUnauthenticated for similar behavior) or an incorrect file format will result in errors. Other mistakes include syntax errors in the YAML file, providing an incorrect URL for the scanner, setting failurePolicy to Ignore (which would allow images even if the scanner backend fails), or forgetting to apply the ValidatingWebhookConfiguration with kubectl apply after editing.

Concept tested. The core technical concept being tested is the implementation and configuration of Kubernetes Validating Admission Webhooks. This includes understanding the ValidatingWebhookConfiguration resource, its key fields (failurePolicy, clientConfig.url), how to modify and apply such configurations, and the role of the ValidatingAdmissionWebhook plugin in the Kubernetes API server. It also implicitly tests knowledge of kube-apiserver static pod manifests and kubectl commands.

No community discussion yet for this question.