November 17, 2020·4 min read·engineeringkubernetessecuritycertification

CKS makes Kubernetes security a practical examination

The new Certified Kubernetes Security Specialist exam builds on current CKA certification and tests security across application build, deployment, and runtime. Its scope reflects the limits of treating cluster administration as sufficient security preparation.

Administering a working Kubernetes cluster and securing its applications overlap, but they require different judgments. The new Certified Kubernetes Security Specialist qualification makes that distinction explicit. Candidates must already hold a current Certified Kubernetes Administrator certification, then demonstrate security competence in a separate practical examination. The sequence treats administration as a prerequisite for the security work.

The November 17 launch announcement makes CKS generally available through CNCF and the Linux Foundation. The exam lasts two hours and uses a performance-based format. Candidates take it remotely, with a live proctor observing through webcam and screen sharing. The awarded certification is valid for two years.

I welcome the focus on practical work because Kubernetes security depends on the behavior produced by configuration. An API accepting a resource does not establish that the resulting workload has appropriate permissions. A useful qualification needs to examine whether a candidate can work with those controls, alongside knowing their names.

The scope extends beyond cluster setup

The launch identifies six domains. Cluster Setup and Cluster Hardening address the platform, while System Hardening recognizes the system beneath it. Minimize Microservice Vulnerabilities brings applications into scope. Supply Chain Security covers the path by which software reaches deployment, and Monitoring, Logging, and Runtime Security concerns what happens during execution.

Those domains matter because a cluster is only one part of the application's security story. Build-time choices can introduce a problem before any pod exists. Runtime controls operate on software that has already passed through that process. The examination's stated coverage spans build, deployment, and runtime rather than equating security with a successful installation.

CNCF had set out the same broad scope in its July announcement of the certification's development. That notice described a performance-based examination for people who had passed CKA and wanted external validation of their container security knowledge. November changes the program's availability. It does not introduce a different set of domains from the earlier notice.

The prerequisite also provides a boundary for interpreting CKS. It assumes sufficient Kubernetes expertise to perform the security tasks. The new credential supplements that foundation with a more specific examination. It should not be read as a way to skip the operational knowledge needed to understand the platform being secured.

Resource enforcement illustrates the needed reasoning

An earlier security disclosure shows why configuration knowledge has to connect with implementation. The July advisory for CVE-2020-8557 describes a kubelet omission in ephemeral storage accounting. A pod able to write its own /etc/hosts file could consume node storage without that usage entering the pod's eviction calculation.

The exposure depended on permissions as well as the vulnerable kubelet. The advisory identified CAP_DAC_OVERRIDE and either root execution or permission for privilege escalation among the relevant conditions. It suggested admission controls to constrain those permissions before upgrading, while warning that the restrictions could break applications relying on them.

That example crosses the kinds of concerns named in CKS. It involves the node's implementation, the workload's security context, and the operator's ability to identify a runtime symptom. The advisory's detection method examines the host-side backing files for unusually large sizes. An observation can identify a symptom, while the kubelet version identifies whether the accounting defect remains present. Those are different forms of evidence about the same risk. This is an illustration of the subject matter, not a claim that the examination contains that vulnerability or any particular task derived from it.

The distinction is important because the published launch describes competency domains, not a public catalog of live examination questions. The useful public discussion is about what an engineer needs to understand. It should not imply knowledge of unpublished exam content.

Supply chain and runtime need separate attention

Including supply chain security gives the examination a scope wider than the state of running pods. The release describes security throughout the build and deployment process. That recognizes that platform controls act on inputs whose provenance and preparation also matter. Runtime enforcement cannot, by itself, explain how a particular artifact came to be the deployed artifact.

Monitoring and logging have another role. They provide information for understanding execution and responding when behavior differs from the intended policy. The launch places them in a domain with runtime security. That grouping makes observation part of the stated security competence, alongside preventative configuration.

My interest is in whether the candidate can connect those stages without assuming one successful control proves the whole system secure. A correct deployment setting answers a specific question about a workload. It does not establish every property of the build process or every possible behavior after the application starts.

The six-domain outline is therefore useful as a statement of coverage. It does not claim that a single setting secures the platform, or that the examination can assess every system an engineer may later operate. The performance-based format provides evidence of competence within the program's tasks and conditions.

Certification supplies bounded evidence

The announcement presents CKS as validation of skills and competence. Its two-year validity also puts a time boundary on the credential. That matters for a platform whose controls and operational practices require continuing attention. The launch establishes the credential's duration without claiming that passing it permanently resolves the holder's learning needs.

A current CKA is required when candidates sit for the CKS. For someone who lacks that prerequisite, the program's path begins with establishing the administration qualification. For an eligible candidate, the exam is available to schedule immediately. These are concrete entry conditions, separate from an employer's decision about the weight to give the result.

The strongest use of the qualification is as one defined piece of evidence about practical Kubernetes security knowledge. Its published scope includes the host system and application lifecycle as well as cluster controls. An assessment of an actual deployment still needs the configuration and runtime facts of that deployment, including whether the relevant controls are present and effective for its workloads.