The Kubernetes and Cloud Security Associate (KCSA) is a new security cert that’s officially coming out in Q3 of 2023. However, the beta signup is available if you’re interested.

In this blog post, you’ll learn about what the new cert is, the objectives, and why you should care about it.

What Is It

The purpose of the KCSA is to test your knowledge of security fundamentals when it comes to cloud-native and Kubernetes. That essentially means there are some key best practices when it comes to Kubernetes security and you’re expected to know them. If you’re familiar with the Certified Kubernetes Security Specialist (CKS) certification, it’s like a “lite” version of that.

There is some verbiage on the certifications landing page that the cert will help you with overall cloud-native security, but once you see the objectives in the next section, you’ll notice that there’s one module for overall security and the rest are geared towards Kubernetes.

You’ll see topics like:

• RBAC
• Kubernetes secrets
• Pod standards
• Malicious attacks

And a few other topics which you’ll learn more about in the next section.

Please note that this is a multiple-choice exam like the KCNA. As you get into higher level certifications like the CKA and CKS, they aren’t multiple choice, but lab-based.

Cert Objectives

There are five domain objectives:

• Overview of Cloud Native Security
• Kubernetes Security Fundamentals
• Kubernetes Trust Boundaries and Data Flow
• Kubernetes Threat Model
• Additional Controls

Source: https://training.linuxfoundation.org/certification/kubernetes-and-cloud-security-associate-kcsa/

Let’s break these down.

💡 Please note: This exam is still in beta and because of that, things will change. I will also be putting in my assumption for a few of these, which I will call out.

Overview of Cloud Native Security

The Cloud Native Security section goes over the basics:

• Infrastructure security
• Cluster security
• Container security

If you’re confident in all of the other sections in the objectives, you should be fine here.

Going over this section will help for not only this objective but for the full exam: https://kubernetes.io/docs/concepts/security/overview/

You’ll notice how under the security category in the link above, it covers a lot of what’s on the exam.

Come to think of it, it definitely looks like the Linux Foundation got a big chunk of the cert objectives/topics from the link below.

Kubernetes Security Fundamentals

The Kubernetes Security Fundamentals section will go over the best practices for Pods and API security.

There are certain standards and best practices that everyone should follow when it comes to Pods:

• Pod Security Standards (policies that cover the broad security spectrum. Restricted, Privileged, and Baseline).
• Pod Security Admissions (Pod isolation)

Then, there are the overall best practices when it comes to the Control Plane/API server access:

• Secrets (API keys, passwords, etc. that you don’t want in plain text).
• RBAC (permissions/authorization to Kubernetes)
• Multitenancy (more than one user/application/workload on a cluster)

There’s also mention of Pod Security Policies (PSP). Because PSP has officially been taken out of Kubernetes v1.25, it wouldn’t make much sense for Linux Foundation to have PSP on the cert. With that being said, my assumption is it’ll be taken out and replaced with OPA and/or Kyverno.

Kubernetes Trust Boundaries and Data Flow

The Kubernetes Trust Boundaries and Data Flow section will go over how to secure individual Kubernetes components including:

• API Server
• Controller
• Scheduler
• Kubelet
• Kube-proxy
• Containerd (seems to be the default container runtime to know for this exam).

The key advice here is to ensure that you understand in full the components mentioned above.

When it comes to securing them, check out a scanning tool like Kube-Bench or Kubescape and also understand the CIS Benchmarks for Kubernetes. The CIS Benchmarks are free and contain a ton of great information. You can see a video going over them here: https://www.youtube.com/watch?v=RuVwhj3EXgc

There’s one more topic in this section, which is “Image Repository” (where you store container images). The assumption here is to know how to secure the container image repo from a permissions perspective (who can access it and push images to the repo) and any scanning that may occur on the container image repo.

Kubernetes Threat Model

The Kubernetes Threat Model section appears to go over a broad range of general security topics:

• Persistence
• Denial of Service
• Malicious Code Execution
• Compromised Application in Container
• Attacker on the Network
• Access to Sensitive Data

This objective is a bit harder to digest in terms of where to get the proper information from because the topics are not only incredibly broad, the incredibly high level. For example, Denial of Service means one thing, but it could be looked at in multiple different ways.

Because of that, there isn’t a specific recommendation on which way to go like the other objectives. Instead, there are a few different resources below to get an idea about what this objective will look like.

Marco Lancini, Principal Security Engineer at Gitlab came up with some pretty great docs around the threat model: https://cloudsecdocs.com/container_security/theory/threats/k8s_threat_model/#security-boundaries

Another option is, if you have Nigel Poulton The Kubernetes Book, he has an entire chapter in the book on the Kubernetes Threat Model.

Additional Controls

The last objective is Additional Controls.

• SECComp (Allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit, sigreturn, read and write to already-open file descriptors.)
• APPArmor (A Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles)

Both of the above are Linux-specific. If you have a Sysadmin background, these are probably familiar to you.

The other two are:

• Admission Controllers (allows you to set best practices and rules for Kubernetes resources).
• Network Policies (Control ingress/egress traffic based on IPs, Namespaces, and Kubernetes resources).

Admission Controllers and Network Policies are a big part of the Kubernetes ecosystem overall and you can find a ton of information about each.

For Network Policies, I’d recommend learning how to implement a basic one (example here: https://github.com/AdminTurnedDevOps/kubernetes-examples/blob/main/networking/network_policies/policy.yaml).

For Admission Controllers, understand the theory and the “why” behind it, but don’t worry about implementing your own.

Is It Worth It?

The KCSA is worth it if you’re looking to enhance your skills. Think about the knowledge that you gain from the KCSA as almost like a pre-req to the CKS. You don’t need to pass the KCSA to obtain the CKS, but the knowledge that you gain from the KCSA will transfer over nicely to the CKS.

From an employer perspective, employers probably wouldn’t be all that interested in you getting this cert. They would care more about the CKA, CKS, and CKAD. That doesn’t mean you shouldn’t get it. It just means you shouldn’t bank on it getting you a job (much like any other cert).

If you want to obtain security fundamental knowledge for Kubernetes, this is a great certification to start with. Even if you don’t take the exam, the overall knowledge that you’ll gain from it will be very beneficial.

Where To Learn More

You can find more information about the KCSA here: https://training.linuxfoundation.org/certification/kubernetes-and-cloud-security-associate-kcsa/