Master Kubernetes CKS Exam 1.28 Curriculum

Let’s have a look at the official syllabus-wise resources for the CKS exam. All the topics mentioned are as per the official Linux Foundation Certified Kubernetes Security Specialist Exam CKS Exam Curriculum.

CKS Exam aims to test your skills in different security aspects. The following table shows the different domains and their weightage for the CKS Exam Curriculum.

Cluster Setup10%
Cluster Hardening15%
System Hardening15%
Minimize Microservice Vulnerabilities20%
Supply Chain Security20%
Monitoring, Logging, and Runtime Security20%

Cluster Setup 10%

This section carries 10% weightage in the CKS Exam Curriculum

Under Cluster setup , The security features of the cluster components are more the center of attention. The CKS questions accord this portion a 10% weighting.

Use Network security policies to restrict cluster-level access

Use CIS benchmarks to check the security configuration of Kubernetes components (etcd, kubelet, kubedns, kubeapi)

The benchmarks for Kubernetes security requirements were developed by the Center for Internet Security (CIS) and the Kubernetes community.

The Kubernetes CIS benchmarks can help organisations meet compliance and security needs.

Configure the security settings of the ingress

Protect node metadata and endpoints

Minimize the use and access to the dashboard

Kubernetes dashboard access must be secured because cluster users from many networks inside an organization use it. Additionally, numerous Kubernetes hacking issues were caused by incorrect Kubernetes dashboard security configurations.

You must get knowledgeable about all the configurations and best practices needed to build up a safe Kubernetes dashboard.

Verify platform binaries before deployment

Learn how to use the checksum to validate the Kubernetes binaries. The version numbers and SHA ids needed to validate the binaries are available on the Kubernetes Github release page.

Cluster Hardening 15%

This section carries 15 % weightage in the CKS Exam Curriculum

Restrict access to the Kubernetes API

When it comes to Kubernetes production implementation, restricting API access is crucial. Only services with the necessary permissions should have access to the Kubernetes API, including those running within the cluster.

Bootstrap tokens, RBAC, ABAC, service accounts, and admission webhooks would be the main topics under this area.

Use RBAC to minimize resource exposure

To uphold the principle of least privilege, Kubernetes RBAC enables you to create fine-grained control over who has access to the Kubernetes API. A common error made during Kubernetes implementations is granting unnecessary cluster-wide access to everyone.

Exercise caution in using service accounts e.g., disable defaults, minimize permissions on newly created ones

The ideal way to grant applications or pods that need access to the Kubernetes API is through service accounts.

If you don’t specifically specify a service account, the default service account for each namespace will be associated to the pod. There are no privileges associated with the standard service account. However, if you assign a role to it, all of the access indicated in the role will be granted to it, and it will be applicable to every pod in the namespace.

To uphold the principle of least privilege, it is common practice to deploy various workloads with several service accounts.

Update Kubernetes frequently

To ensure the availability of the application, you should adhere to the suggested measures whenever you upgrade a Kubernetes cluster.

System Hardening 15%

This section carries 15 % weightage in the CKS Exam Curriculum

System hardening tries to decrease attack surfaces by addressing vulnerabilities in infrastructure and application components

The typical system hardening tasks include :

  • patching up as needed
  • removing all auxiliary utilities
  • limiting access using tools and firewall rules.
  • logging every system action.

We have the following list of system hardening efforts for CKS.

Minimize host OS footprint (reduce attack surface

Minimize IAM roles

Minimize external network access

Appropriate use of kernel hardening tools, such as AppArmor, seccomp

Minimize Microservice Vulnerabilities 20%

This section carries 20% weightage in the CKS Exam Curriculum

This section focuses mainly on service-to-service communications, as the title suggests. The fundamental ideas and Kubernetes objects involved in safeguarding communication between pods must all be mastered.

Improve security with PSP, OPA, security context

Manage Kubernetes secrets

Use container runtime sandboxes in multi-tenant environments (e.g. gvisor, kata containers)

Implement Pod-to-Pod encryption using mTLS

The process of enabling mTLS across pods is not documented. However, you can create certificates for use in the pod-to-pod encryption using the Kubernetes API.

Supply Chain Security 20%

This section carries 20% weightage in the CKS Exam Curriculum

The course outline for the Linux Foundation emphasises the following key ideas :

Considering that this area accounts for 20% of the total points, it is reasonable to anticipate 3-5 supply chain security-related questions. 
The various ideas that the CKS will emphasize in the supply chain security area are summarized below.

Minimize base image footprint

Secure the supply chain: whitelist allowed image repositories, sign and verify images

Use static analysis of user workloads (e.g.Kubernetes resources, Docker files)

Scan images for known vulnerabilities

Monitoring, Logging and Runtime Security 20%

The sixth and last section of the CKS Exam focuses on cluster monitoring, logging, and runtime security. 
The Linux Foundation emphasises the following fundamental ideas :

  • Conduct behavioral analytics on host- and container-level syscall process and file activity to look for malicious activity.
  • Detect threats within a physical infrastructure, apps, networks, data, users, and workloads
  • Detect every stage of an attack, no matter where it starts or how it spreads.
  • Conduct in-depth analysis to find problematic actors in the environment and identify them.
  • At runtime, make sure containers are immutable.
  • Monitoring access with audit logging

20% of the points scored are allocated to this section, and it is reasonable to expect 3-5 questions concerning runtime security, logging, and monitoring. During the exam
The various concepts that the CKS will highlight in the monitoring, logging, and runtime security are outlined below.

Perform behavioral analytics of syscall process and file activities at the host and container level to detect malicious activities

Detect threats in physical infrastructure, applications, networks, data, users and workloads

A threat detection engine in Kubernetes is called Falco. It can easily identify threats and notify users to any abnormal program behavior.

Detect all phases of an attack, no matter where it occurs and how it spreads

Perform deep analytical investigation and identification of bad actors within the environment

Ensure immutability of containers at runtime

Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using either or both:

Kubernetes Audit

[lasso ref=”cks-exam” id=”3592″]
Leave a Reply
You May Also Like