CKS Question #60: Real Exam Question with Answer & Explanation

Question

Context You must implement auditing for the kubeadm provisioned cluster. Task First, reconfigure the cluster 's API server, so that: . the basic audit policy located at /etc/kubernetes/logpolicy/audit-policy.yaml is used, . logs are stored at /var/log/kubernetes/audit-logs.txt, . and a maximum of 2 logs are retained for 10 days. The cluster uses the Docker Engine as its container runtime . If needed, use the docker command to troubleshoot running containers. The basic policy only specifies what not to log. Next, edit and extend the basic policy to log: . namespaces interactions at RequestResponse level . the request body of deployments interactions in the namespace webapps . ConfigMap and Secret interactions in all namespaces at the Metadata level . all other requests at the Metadata level Make sure the API server uses the extended policy. Failure to do so may result in a reduced score.

Explanation

To implement Kubernetes API server auditing, the test-taker must modify the kube-apiserver static pod manifest on the master node to enable auditing flags and hostPath volumes, then create/update the audit policy file with the specified rules in the correct order.

Approach. The correct approach involves two main phases: reconfiguring the API server and then defining the audit policy.

Phase 1: Reconfigure Kubernetes API Server on the Master Node

1. Access the Master Node: SSH into kssh00301-master as specified in the exhibit. The kubectl config use-context KSSH00301 command is for local kubectl context, but the task requires direct modification on the master node.
2. Locate API Server Manifest: The kube-apiserver runs as a static pod managed by kubelet. Its manifest file is typically located at /etc/kubernetes/manifests/kube-apiserver.yaml.
3. Edit kube-apiserver.yaml: Open this file with a text editor (e.g., vi or nano).
4. Add Audit Flags: Under spec.containers[0].command, add the following flags:
   • --audit-policy-file=/etc/kubernetes/logpolicy/audit-policy.yaml
   • --audit-log-path=/var/log/kubernetes/audit-logs.txt
   • --audit-log-maxage=10
   • --audit-log-maxbackup=2
5. Add HostPath Volumes: To allow the static pod to access the policy file and write logs to the host, add volumes under spec and volumeMounts under spec.containers[0]:
   • For policy file:

     # In spec.containers[0].volumeMounts
     - mountPath: /etc/kubernetes/logpolicy/audit-policy.yaml
       name: audit-policy-volume
       readOnly: true
       subPath: audit-policy.yaml
     # In spec.volumes
     - hostPath:
         path: /etc/kubernetes/logpolicy
         type: DirectoryOrCreate
       name: audit-policy-volume
     

   • For log directory:

     # In spec.containers[0].volumeMounts
     - mountPath: /var/log/kubernetes
       name: audit-log-volume
     # In spec.volumes
     - hostPath:
         path: /var/log/kubernetes
         type: DirectoryOrCreate
       name: audit-log-volume
     

6. Save and Verify: Save the kube-apiserver.yaml file. Kubelet will automatically detect the change and restart the kube-apiserver pod. Verify its status (e.g., docker ps | grep kube-apiserver).

Phase 2: Edit and Extend the Audit Policy File

1. Create/Edit Policy File: Ensure the directory /etc/kubernetes/logpolicy exists (sudo mkdir -p /etc/kubernetes/logpolicy). Then, create or modify the file /etc/kubernetes/logpolicy/audit-policy.yaml.
2. Define Audit Rules: The audit policy is a YAML file with apiVersion: audit.k8s.io/v1 and kind: Policy. Rules are evaluated in order; the first matching rule applies. The new rules must be placed at the beginning of the rules array, before any existing general level: None rules from the 'basic policy'.

   apiVersion: audit.k8s.io/v1
   kind: Policy
   # The basic policy might have top-level omitStages or general 'None' rules.
   # New specific rules must come first.
   rules:
     # 1. Namespaces interactions at RequestResponse level
   - level: RequestResponse
     resources:
     - group: ""
       resources: ["namespaces"]
   
     # 2. Request body of deployments interactions in the namespace webapps
   - level: Request
     resources:
     - group: "apps"
       resources: ["deployments"]
     namespaces: ["webapps"]
   
     # 3. ConfigMap and Secret interactions in all namespaces at the Metadata level
   - level: Metadata
     resources:
     - group: ""
       resources: ["configmaps", "secrets"]
   
     # 4. All other requests at the Metadata level (catch-all)
   - level: Metadata
     # If the basic policy includes a top-level 'omitStages' that would conflict with this,
     # it might need to be overridden or carefully placed. Generally, 'Metadata' level
     # implies logging RequestReceived and ResponseComplete stages with only metadata.
   
     # Existing 'basic policy' rules (which 'only specifies what not to log') would follow here, e.g.:
   - level: None
     users: ["system:kube-proxy"]
     verbs: ["watch"]
     resources:
     - group: ""
       resources: ["endpoints", "services"]
   # ... other rules from the basic policy.
   

3. Verify Logs: After the API server restarts and the policy is in place, commands like tail -f /var/log/kubernetes/audit-logs.txt should show the new audit entries according to the defined rules.

Common mistakes.

• common_mistake. Common mistakes include:

1. Incorrect Master Node: Attempting to modify configuration on a worker node instead of the master node (kssh00301-master). The API server only runs on the master.
2. Typos or YAML Syntax Errors: Incorrect flags or malformed YAML in kube-apiserver.yaml or audit-policy.yaml can prevent the API server from starting or applying the policy.
3. Missing Volumes/VolumeMounts: Forgetting to add hostPath volumes and volumeMounts for the policy file and log directory will prevent the API server pod from reading the policy or writing logs.
4. Incorrect Audit Policy Rule Order: Audit rules are evaluated sequentially. Placing more general rules (e.g., level: None or a catch-all Metadata rule) before more specific rules can cause the specific rules to be ignored.
5. Incorrect level for audit rules: Using Metadata when RequestResponse or Request is required (e.g., for 'request body' for deployments, Request level is needed) or vice-versa.
6. Incorrect Resource Groups: Specifying resources: ["deployments"] without group: "apps" or resources: ["namespaces"] without group: "".
7. Not creating directories: If /etc/kubernetes/logpolicy or /var/log/kubernetes don't exist, the API server might fail to start or log errors.

Concept tested. This question primarily tests the understanding of Kubernetes API server auditing, including:

• How to configure the Kubernetes API server (a static pod) by modifying its manifest (/etc/kubernetes/manifests/kube-apiserver.yaml).
• The specific API server flags for audit logging (--audit-policy-file, --audit-log-path, --audit-log-maxage, --audit-log-maxbackup).
• The use of hostPath volumes and volumeMounts to enable static pods to access host filesystems.
• The structure and components of a Kubernetes Audit Policy (apiVersion, kind, rules, level, resources, group, namespaces, verbs, omitStages).
• The importance of audit policy rule order for effective filtering and logging.

Reference. null

No community discussion yet for this question.