Study Guide: Kubernetes Certified Security Associate (KCSA)

2024-07-23 22 min read Certification

I’ve been studying for the Kubernetes Certified Security Associate (KCSA) exam, and I thought it would be helpful to document my study notes and share them with others who are also preparing for the exam.

This article is a bit long but it will cover everything you need to know to pass the KCSA exam. I’ll be updating this article as I find additional content to share, so make sure to bookmark it and check back often.

Exam Overview

First thing you should do is take a read through the KCSA Exam Domains & Competencies to get a better understanding of what topics are covered in the exam and register for the exam if you haven’t already.

As noted in the doc above, this exam is designed to test your knowledge of Kubernetes security concepts and best practices. The exam covers a wide range of topics, including:

Overview of Cloud Native Security
Kubernetes Cluster Component Security
Kubernetes Security Fundamentals
Kubernetes Threat Model
Platform Security
Compliance and Security Frameworks

I’ll dive into each of these topics in more detail. Also note that unlike other Kubernetes certification exams, the KCSA exam is multiple choice and does not require you to complete any hands-on tasks. But to get a better understanding of the concepts, I highly recommend setting up a local Kubernetes cluster and practicing the security concepts covered in the exam.

So let’s get that out of the way.

Kubernetes Cluster Setup

For most of the practice exercises, you can use Minikube. Minikube is a tool that you can use it to create a single-node Kubernetes cluster on your local machine.

Follow the installation instructions appropriate for your operating system to install Minikube.

Once you have Minikube installed, you can start a local Kubernetes cluster by running the following command:

minikube start

Enable the metrics server by running the following command:

minikube addons enable metrics-server

To interact with your cluster you will need to have kubectl installed. You can install kubectl by following the installation instructions appropriate for your operating system.

Verify that kubectl is installed and configured correctly by running the following command:

kubectl cluster-info

Let’s run a quick sample application to test that our cluster is up and running. Create a simple deployment by running the following command:

kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080

Using the minikube dashboard, you can view the deployment you just created. Run the following command to open the dashboard:

minikube dashboard

Hit Ctrl+C to exit the dashboard.

Where applicable, you can use this local Kubernetes cluster to practice the security concepts covered in the exam. Just note that not all security actions can be performed on a minikube cluster, you may need to deploy a cluster on local infrastructure or use a cloud provider.

Overview of Cloud Native Security - 14%

Cloud Native Security is the practice of securing cloud native applications and infrastructure. It involves securing the entire cloud native stack, from the code running in your containers to the infrastructure running your cluster. Cloud Native Security is a shared responsibility between the cloud provider and the customer, and it requires a combination of security controls, best practices, and tools to ensure that your cloud native environment is secure.

The 4Cs of Cloud Native Security

The 4Cs of Cloud Native Security are:

Code
Container
Cluster
Cloud

Each C represents a different layer of the cloud native stack and has its own set of security challenges and best practices. Each layer builds on the previous one, so it’s important to have a good understanding of all four layers to ensure a secure cloud native environment. The Code layer is the innermost layer and the Cloud layer is the outermost layer. Each layer greatly affects the layers within it and once cannot protect everything from the Code layer if there are vulnerabilities in the Cluster or Cloud layer.

Additional Reading:

Cloud Provider and Infrastructure Security

Cloud providers for managed Kubernetes services are often used due to the shared responsibility model that comes with the cloud. The cloud provider will provide cluster-level security especially within control plane components, and you as an end-user will be responsible for workload security. However, it is important to note that vulnerabilities within your cloud configuration puts your entire cluster at risk. Therefore it’s important to follow your cloud provider’s best practices for securing your infrastructure. This includes securing your cloud credentials, setting up network security groups, and enabling encryption at rest and in transit. There’s a lot of information in the reading material below, but you don’t need to know everything in detail for the exam. Just make sure you have a good understanding of the security best practices for your cloud provider.

Additional Reading:

Controls and Frameworks

Controls and frameworks for Kubernetes are tools and practices designed to help you operate your cluster securely and efficiently. It’s important to understand the different compliance frameworks and tools available to you to help you secure your cluster. Compliance frameworks that you should familiarize yourself with are PCI DSS, NIST, HIPAA, MITRE ATT&CK® Framework for Kubernetes. There are also best practice guidance such as the CIS Kubernetes Benchmark, OWASP Top 10 for Kubernetes, as well as security tools such as Falco, Aqua, Kubescape, Twistlock, and Sysdig to help you secure your cluster.

It is also important to understand the types of compliance policies that would be necessary for certain industries like PCI DSS for retail and HIPAA for healthcare, and NIST for government related workloads. Take a read through the following resources to get a better understanding of the controls and frameworks available to you.

Additional Reading:

Isolation Techniques

Isolation techniques are used to separate workloads and protect them from each other. There are several isolation techniques available in Kubernetes, including Namespaces, Network Policies, Pod Security Standards, Pod Security Admission, and Runtime Class. It’s important to understand how these isolation techniques work and when to use them.

Namespaces are soft isolation techniques used to group resources together and provide a mechanism for isolating groups of resources within a cluster. This is often used when sharing of cluster resources is necessary but you want to ensure that resources are isolated from each other.

Network Policies are used to control the flow of traffic between pods and enforce network segmentation. When defining network policies, you can specify which pods are allowed to communicate with each other and which pods are not. You can also scope network policies to specific namespaces and traffic can be allowed or denied based on IP blocks, ports, and protocols.

Pod Security Standards are used to define security controls to be enforced on Pods. There are three levels of policies that range from highly-permissive to highly-restrictive.

Profile	Description
Privileged	Unrestricted policy also known for privilege escalations. Aimed at infrastructure-level workloads.
Baseline	Minimally restrictive policy that blocks privilege escalations. Aimed at non-critical workloads.
Restricted	Most restive policy which follows Pod hardening best practices. Aimed at security critical workloads and lower-trust users.

Pod Security Admission is a feature that allows you to enforce Pod Security Standards on your cluster. You can use Pod Security Admission to automatically reject Pods that do not meet the security standards you have defined. Kubernetes provides a built-in Pod Security Admission controller that can be used to enforce Pod Security Standards. Note that this is a feature that replaced the PodSecurityPolicy admission controller.

Runtime Class is a feature of Kubernetes that allows you to configure a container runtime configuration for a Pod. It allows you to surface runtime properties to the control plane so that the kubelet can make informed decisions about how to run the Pod.

Additional Reading:

Artifact Repository and Image Security

When it comes to image security, the guidance is to only run the bare minimum of software in your container images. This reduces the attack surface and makes it easier to maintain and secure your images. Use a secure image repository to store your images and ensure that your images are scanned for vulnerabilities before they are deployed to your cluster. You can use tools like Trivy to scan your images for vulnerabilities. When referencing images in your Kubernetes manifests, always use the sha226 digest instead of the latest or version tags as these tags are mutable and can be overwritten. The sha256 digest is immutable and ensures that the image you are deploying is the same image you intended to deploy.

You should also look to sign your images to ensure that they have not been tampered with and validate the image signatures with an admission controller. Tools like Cosign and Sigstore can be used to sign your images and verify the signatures with an admission controller.

It is common to perform vulnerability scans as part of the CI/CD process.

Additional Reading:

Workload and Application Code Security

Workload security is the practice of securing the applications and services running in your cluster. This includes isolating the workloads from each other using methods mentioned in the section above, but also ensuring that the applications are secure and free from vulnerabilities. You should follow best practices for securing your applications, such as using secure coding practices, keeping your dependencies up to date, and using security tools like Falco, Aquasecurity’s Trivy, and PrismaCloud’s Twistlock to monitor and protect your workloads.

Additional Reading:

Kubernetes Cluster Component Security - 22%

In order to understand how to secure your Kubernetes cluster, you need to have a good understanding of the components that make up the cluster. The Kubernetes control plane is made up of several components, each of which has its own security considerations. Let’s take a look at some of the key components of the Kubernetes control plane and how they can be secured.

API Server

The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. It is the access point for the Kubernetes control plane and is responsible for validating and configuring API objects. The API server is the only component of the control plane that communicates with the etcd database.

Additional Reading:

Controller Manager

The Controller Manager is a component of the Kubernetes control plane that runs controller loops. These controller loops watch the state of your cluster and make changes to bring the current state closer to the desired state. There are several built-in controllers in Kubernetes, such as the Node controller, Job controller, EndpointSlice controller, and ServiceAccount controller.

Additional Reading:

Scheduler

The Scheduler is a component of the Kubernetes control plane that is responsible for scheduling pods to nodes in the cluster. The Scheduler watches for unscheduled pods and assigns them to nodes based on resource requirements, affinity, anti-affinity, and other constraints.

Additional Reading:

https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler

Kubelet

The kubelet is a component of the Kubernetes node that is responsible for managing the pods running on the node. The kubelet communicates with the API server to receive pod specifications and ensure that the pods are running as expected. It exposes a REST API that can be used to interact with the Kubelet and manage the pods running on the node. It is important to know that requests to the kubelet’s HTTPS endpoint is not authenticated by default and treated as anonymous requests. Therefore, you must disable anonymous requests by starting the kubelet with the --anonymous-auth=false flag. Also, the default authorization mode is AlwaysAllow which allows all requests to the kubelet’s HTTPS endpoint. You should change this to Webhook or Node authorization mode to ensure that requests to the kubelet’s HTTPS endpoint are authorized.

Additional Reading:

Container Runtime

The Container Runtime is the software that is responsible for running containers on a node. Kubernetes supports several container runtimes, including Docker, containerd, and CRI-O. The Container Runtime is responsible for pulling container images, creating containers, and managing the lifecycle of containers.

Additional Reading:

KubeProxy

KubeProxy is a component of the Kubernetes node that is responsible for managing network traffic to and from the pods running on the node. KubeProxy implements the Kubernetes Service abstraction by managing iptables rules that route traffic to the correct pods. It runs as a DaemonSet on each node in the cluster.

Additional Reading:

https://kubernetes.io/docs/concepts/overview/components/#kube-proxy

Pod

Pods are the smallest deployable units in Kubernetes. A Pod is a group of one or more containers that share storage, network, and other resources. Pods are scheduled to run on nodes in the cluster and are managed by the kubelet.

Additional Reading:

https://kubernetes.io/docs/concepts/workloads/pods

Etcd

etcd (pronounced “et see dee”) is a distributed key-value store that is used to store the state of the Kubernetes cluster. etcd is a critical component of the Kubernetes control plane and is responsible for storing all configuration data, state data, and metadata about the cluster. This is the heart of the Kubernetes cluster and if etcd is compromised, so is your cluster.

Additional Reading:

https://kubernetes.io/docs/concepts/overview/components/#etcd

Container Networking

Container Networking is enabled via Container Network Interface (CNI) plugins. By default, CNI plugins gives you a flat open network that allows you to communicate between pods and services. Since it is an open network, you need to secure it by using network policies to control the flow of traffic between pods and enforce network segmentation. Make sure to review each CNI provider’s documentation to understand how network policies are implemented since each provider may have different implementations.

Additional Reading:

Client Security

Client Security in Kubernetes is about securing the clients that interact with the Kubernetes API. This includes securing the kubeconfig file, using RBAC to control access to the API, and using secure communication channels to communicate with the API server.

Additional Reading:

Storage

Storage in Kubernetes is about securing the storage volumes that are used by your pods. This includes encrypting your storage volumes, application configuration stores such as ConfigMaps and Secrets, and ServiceAccount token mounts. The difference between ConfigMaps and Secrets. ConfigMaps are used to store non-sensitive configuration data, such as environment variables, and Secrets are used to store sensitive data, such as passwords and API keys. However, when working with Secrets in Kubernetes, it is important to note that Kubernetes does not encrypt secrets, it merely obfuscates the value by base64 encoding the values. So you should consider using a 3rd party secret management tool such as HashiCorp Vault or Azure Key Vault and using the Kubernetes Secrets Store CSI Driver to inject secrets into your pods at runtime.

Additional Reading:

Kubernetes Security Fundamentals - 22%

With a basic understanding of the Kubernetes cluster components, you should have a better idea on how to better secure them. Let’s dive into some of the security fundamentals that you should be aware of when securing your Kubernetes cluster.

Pod Security Standards

Review the Pod Security Standards section above. The idea here is to define different isolation levels for Pods. The three levels are: Privileged, Baseline, and Restricted. The level you choose will depend on the security requirements of your workloads.

Pod Security Admissions

Review the Pod Security Admissions section above along with Enforce Pod Security Standards by Configuring the Built-in Admission Controller to learn how to enforce Pod Security Standards using the built-in admission controller.

Practice Exercises:

Enforce Pod Security Standards with Namespace Labels

Authentication

Authentication in Kubernetes is the process of verifying the identity of users and services that are interacting with the Kubernetes API. Kubernetes supports several authentication mechanisms, including client certificates, bearer tokens, and service accounts.

Practice Exercises:

Authorization

Authorization in Kubernetes is the process of determining what actions a user or service is allowed to perform in the cluster. Kubernetes supports several authorization mechanisms, including Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Webhook Authorization. Make sure you understand how these authentication mechanisms work and how to configure them in your cluster.

Practice Exercises:

Secrets

Secrets in Kubernetes are used to store sensitive information, such as passwords, API keys, and certificates. Secrets are stored in etcd and are encrypted at rest. As mentioned in the section above, Kubernetes Secret is not secure by itself since secrets are not encrypted but rather base64 encoded. You can ensure all data is encrypted at rest by following this Kubernetes documentation.

Practice Exercises:

Isolation and Segmentation

Isolation is relatively easy to implement in Kubernetes using Namespaces and Network Policies. Namespaces are used to group resources together and provide a mechanism for isolating groups of resources within a cluster. Network Policies are used to control the flow of traffic between pods and enforce network segmentation. Also be vigilant about process namespace sharing as it can lead to container escape vulnerabilities.

Practice Exercises:

Audit Logging

Audit Logging is important for monitoring and troubleshooting your cluster. Kubernetes provides an audit log that records all requests to the API server. You can use the audit log to track who is accessing your cluster and what actions they are performing.

Practice Exercises:

Network Policy

Network Policy has been noted several times in this study guide. So you can see how important it is when it comes to securing your ingress and egress traffic from Pods within your Kubernetes cluster. Securing egress can save you from potential data exfiltration attacks and securing ingress can prevent unauthorized access to your cluster.

Practice Exercises:

Kubernetes Threat Model - 16%

A Kubernetes threat model is a structured representation of the security threats that your Kubernetes cluster faces. It helps you identify potential security risks and vulnerabilities in your cluster and develop a plan to mitigate them. A threat model is a useful tool for understanding the security risks in your cluster and prioritizing security controls to protect against them.

Kubernetes Trust Boundaries and Data Flow

Trust boundaries and data flow is all about knowing who the actors are and what they are capable of. Trust boundaries segregate different parts of the system based on the level of trust that can be placed in them. Data flow is the movement of data between different parts of the system. It’s important to understand the trust boundaries and data flow in your Kubernetes cluster to ensure that your cluster is secure.

Additional Reading:

Persistence

Persistence is the ability of an attacker to maintain access to a Kubernetes cluster after initial compromise. Persistence can be achieved through various means, such as creating backdoors, modifying configuration files, and creating new service accounts.

Additional Reading:

https://microsoft.github.io/Threat-Matrix-for-Kubernetes/tactics/Persistence

Denial of Service

Denial of service is the ability of an attacker to disrupt the availability of a Kubernetes cluster by overwhelming the cluster with resource requests causing disruption of service to legitimate users. Denial of service attacks can be targeted at various components of the cluster, such as the API server, the etcd database, and the network.

Additional Reading:

Malicious Code Execution and Compromised Applications in Containers

Malicious code execution is the ability of an attacker to execute arbitrary code on a Kubernetes cluster. This can be achieved through various means, such as exploiting vulnerabilities in the cluster components, injecting malicious code into containers, and compromising the build pipeline.

Additional Reading:

Attacker on the Network

An attacker on the network is an attacker who has gained access to the network where the Kubernetes cluster is running. This can be achieved through various means, such as exploiting vulnerabilities in the network infrastructure, compromising a node on the network, or gaining access to the network through a compromised credentials, or through an application vulnerability.

Additional Reading:

https://microsoft.github.io/Threat-Matrix-for-Kubernetes/tactics/InitialAccess

Access to Sensitive Data

Access to sensitive data is the ability of an attacker to gain access to sensitive data stored in the Kubernetes cluster. This can be achieved through various means, such unauthorized access to the cluster which compromises access to Kubernetes secrets (remember that Kubernetes Secrets are not encrypted but rather base64 encoded), or through a compromised application or admission controller.

Additional Reading:

Privilege Escalation

Privilege escalation is the ability of an attacker to gain higher privileges in a Kubernetes cluster than they are authorized to have. This can be achieved through various means, such as exploiting vulnerabilities in the cluster components, compromising a node on the network, or gaining access to the network through a compromised credentials. It’s important to understand how an attacker can escalate their privileges in your cluster and how to prevent it. One way to prevent privilege escalation is to use Role-Based Access Control (RBAC) to control access to the API server and limit the permissions that users have in the cluster.

Additional Reading:

Platform Security - 16%

Platform security is about securing the underlying infrastructure that your Kubernetes cluster runs on. This includes securing the cloud provider, the network, and the physical hardware that your cluster runs on. Let’s take a look at some of the key aspects of platform security that you should be aware of when securing your Kubernetes cluster.

Supply Chain Security

Supply chain security is the practice of securing the software supply chain to ensure that the software you are using is secure and free from vulnerabilities. This includes securing the build pipeline, scanning images for vulnerabilities, and signing images to ensure that they have not been tampered with. Be sure to pay close attention to the NIST guidance on supply chain risk management.

Additional Reading:

Image Repository

Image repositories like Azure Container Registry can be use to scan images for vulnerabilities before they are deployed to your cluster. You can also use tools like Trivy to scan your images for vulnerabilities.

Additional Reading:

Observability

Observability includes monitoring, logging, and tracing. It’s important to have visibility into your cluster to detect and respond to security incidents. You can use tools like Prometheus and Grafana are the most prominent tools within the cloud native ecosystem to monitor your cluster and alert you to any security incidents.

Additional Reading:

Service Mesh

Service Mesh is a thin layer of infrastructure that is deployed on to your Kubernetes cluster and provides a set of features that help you secure, monitor, and manage your microservices. Service Mesh can help you secure your cluster by providing features like mutual TLS, access control, and observability.

Additional Reading:

PKI

Private Key Infrastructure (PKI) is the main method of authentication within a Kubernetes cluster. It is used to secure the communication between the different components of the cluster. It’s important to understand how PKI works in Kubernetes and how to configure it to ensure that your cluster is secure.

Additional Reading:

https://kubernetes.io/docs/setup/best-practices/certificates

Connectivity

PKI is used throughout the Kubernetes cluster to secure the communication between the different components of the cluster. It’s important to know how certificates are used and how to configure them to ensure that your cluster is secure.

Additional Reading:

https://kubernetes.io/docs/setup/best-practices/certificates/#how-certificates-are-used-by-your-cluster

Admission Control

The Admission Control is a feature of Kubernetes that allows you to enforce security policies on your cluster. You can use Admission Control to automatically reject Pods that do not meet the security standards you have defined. Kubernetes provides a built-in Pod Security Admission controller that can be used to enforce Pod Security Standards. Think of the Admission Control as a gatekeeper that checks the security of the resources before they are admitted to the cluster. Tools like OPA Gatekeeper can be used to enforce policies on your cluster.

Additional Reading:

Compliance and Security Frameworks - 10%

We revisit the compliance and security frameworks that we discussed earlier in this study guide. These frameworks provide guidelines and best practices for securing your Kubernetes cluster and ensuring that it meets the security requirements of your organization.

Compliance Frameworks

Some compliance frameworks that you should be aware of include: CIS Kubernetes Benchmark, PCI DSS, NIST, MITRE ATT&CK® Framework for Kubernetes, and OWASP Top 10 for Kubernetes. These frameworks provide guidelines and best practices for securing your Kubernetes cluster and ensuring that it meets the security requirements of your organization. Note some of these frameworks are defensive minded and some are offensive minded.

See the Controls and Frameworks section above for more information on these compliance frameworks.

Threat Modelling Frameworks

The MITRE ATT&CK® Framework for Kubernetes is a framework that provides a comprehensive list of tactics and techniques that attackers use to compromise Kubernetes clusters. The framework is organized into several categories, such as Initial Access, Execution, Persistence, Privilege Escalation, and Defense Evasion.

See the Microsoft’s Threat Matrix for Kubernetes for more information on the MITRE ATT&CK® Framework for Kubernetes.

Additional Reading:

https://www.microsoft.com/security/blog/2021/03/23/

Supply Chain Compliance

Supply chain compliance is not just Kubernetes specific. It is used throughout all industries to ensure that goods and services are produced in a safe and secure manner and meets legal and ethical standards. This is often proved by a certification or audit which can include artifacts, metadata, attestations, and provenance.

Additional Reading:

Automation and Tooling

As you implement many of the security controls and frameworks mentioned above, you will need to automate the process to ensure that your cluster remains secure. Tools like Falco, Aqua, Kubescape, Prisma Cloud, Sysdig, gVisor, and KubeLinter can help you automate the process of securing your cluster and ensure that your cluster meets the security requirements of your organization.

Additional Reading:

https://developers.redhat.com/articles/2022/06/20/8-open-source-kubernetes-security-tools

Conclusion

That was a lot of information to cover, but I hope you found it helpful as you prepare for the Kubernetes Certified Security Associate (KCSA) exam. Good luck with your studies and reach out if you have any questions on the exam experience or with any of the topics covered in this study guide.

To Kubestronaut and beyond! 🚀

Resources

In addition to the official KCSA Exam Domains & Competencies, and content above, here are some additional resources that you may find helpful as you prepare for the KCSA exam: