In this guide, you will get a complete roadmap to study for the Kubernetes and Cloud Native Security Associate (KCSA) exam.
What is KCSA Certification?
KCSA (Kubernetes and Cloud Security Associate) is a certification offered by the Linux Foundation and CNCF (Cloud Native Computing Foundation).
This certification will be given to individuals who have passed the KCSA exam. The exam tests your knowledge about standard Kubernetes security.
Also tests your knowledge about cloud native tools and secure supply chain management.
The exam will be online, and you have to answer 60 questions in 90 minutes. Exam format is similar to KCNA certification.
Who is Eligible to take KCSA Exam?
There is no eligibility criterion for taking the KCSA certification exam, any interested individual can take the exam.
But it will be more suitable for DevOps Engineers, Cloud admins, and individuals whose role is in Kubernetes security.
KCSA Certification Exam Overview
Given below is an overview of the KCSA certification exam, such as syllabus, exam type, etc.
KCSA Exam Details
| Exam Type | Multiple Choice Exam |
| No. of Questions | 60 |
| Exam Duration | 90 minutes |
| Pass Percentage | 75% |
| KCSA Validity | 2 Years |
| Exam Cost | $250 USD |
| Exam Retake | One retake |
The exam will be online and watched by a proctor throughout the exam.
The exam is taken on PSI’s Proctoring Platform 'Bridge', using the PSI Secure Browser (a web browser created to guarantee a secure exam delivery over a virtual connection).
Read more about the system and testing environment requirements.
KCSA Exam Syllabus
Below is the KCSA exam syllabus and its weightage.
| Topic | Concepts | Weightage |
|---|---|---|
| Overview of Cloud Native Security |
|
14% |
| Kubernetes Cluster Component Security |
|
22% |
| Kubernetes Security Fundamentals |
|
22% |
| Kubernetes Threat Model |
|
16% |
| Platform Security |
|
16% |
| Compliance and Security Frameworks |
|
10% |
KCSA Exam Study Resources
Given below are the official and free Linux courses.
CNCF Tools
Below are the resources you can refer to for cloud native security tools.
KCSA Exam Preparation Roadmap
To prepare for the exam, you have to spend a minimum of 1 hour for 60 days to cover all topics.
There is no better way to understand a concept than through hands-on experience, so keep a Kind or Minikube cluster ready before starting the preparation.
In this section, we will go through six sections according to the syllabus with official and relevant documents.
Overview of Cloud Native Security - 14%
In this section, we will cover the basics, such as core security concepts, image security, and securing a workload.
4Cs of Cloud Native Security
Code, Container, Cluster, and Cloud are the 4Cs of cloud native security.
This is a layered approach for cloud native security, starting from code development, containerizing it, deploying it in a cluster, and finally hosting it in the cloud.
Refer to the 4Cs documentation for more details.
Cloud Provider and Infrastructure Security
Running a Kubernetes cluster in the cloud securely is an important task.
The cloud provider may take care of the hardware and underlying infrastructure, but your duty is to secure the cluster, such as who can access it and what they are allowed to do in the cluster.
Infrastructure Security involves cluster access management, securing public cluster nodes by opening only the required ports, ETCD encryption, etc.
Controls and Frameworks
Just securing the cluster using tools and using security features is not enough, running workloads with best practices and security guidelines is also necessary.
Running and managing a Kubernetes cluster with best practices helps you to prevent common security issues.
Relevant official docs and tools:
Isolation Techniques
Isolation techniques refer to separating the workloads from other workloads using namespaces, RBAC, and Network Policies.
Not just workloads, but also for every user's permissions on what they are allowed to do.
Relevant official docs:
Artifact Repository and Image Security
The Artifact registry is a place where we store and share the application packages that we built.
Docker Hub and ECR are examples of artifact registries.
Even though a Kubernetes cluster is secure, the vulnerabilities in the image can cause serious security issues, so following the best practices is very important while building the container image.
Some of the best practices are listed below:
- Always use verified images for the base image, using verified alphine images is even secure
- Never use old or not maintained images, even if they are verified. They may contain serious vulnerabilities.
- Always use the latest supported version.
- Create a non-root user and give only the required permissions.
- Scan the images for vulnerabilities using tools like Trivy.
- Sign the images before pushing as proof of trust.
Relevant official docs and tools:
Workload and Application Code Security
Even before image level security, there is application level security. This is about building the code without any security vulnerabilities.
You may be managing the cluster securely, but if the application running inside the container has a vulnerability, it's also a serious security issue.
While building the application, make sure that no secrets are hardcoded and proper error handling is added to the application code.
You can use SonarCube to scan the application source code for code issues.
Kubernetes Cluster Component Security - 22%
In this section, we will look into the core Kubernetes components security.
Core Cluster Components
Below is the list of core cluster components and what its does.
- API Server - This component exposes the cluster's API and is responsible for authentication and authorization.
- Controller Manager - It does tasks such as managing all Kubernetes controllers.
- Scheduler - Schedules pods on a suitable node.
- KubeProxy - This is the component that manages the cluster's network rules and is responsible for pod to pod communication.
- Container Runtime - This is responsible for running containers in the cluster.
- ETCD - This stores all data in the cluster in key-value format.
- Kubelet - Its task is to connect worker nodes to the control plane and make sure every container is running.
Refer to the Kubernetes Architecture blog for a detailed understanding of each component.
Pod Security
A pod is an object in Kubernetes that can be used to deploy one or more containers.
As a security practice, it's important to run it in an isolated environment and with minimal permissions.
We can use pod security standards and security content to limit the permissions for each pod.
Refer to this Kubernetes Pod blog for more details.
Relevant docs:
Container Networking Security
In Kubernetes networking, it is managed by KubeProxy.
By default, there will be no restriction between pods for communication, which may also cause a serious networking issue.
We can network using Network Policy, in that we can define which resources can communicate and which cannot.
Official documentation - NetworkPolicy
Client Security
In Kubernetes, the clients referred to are the users, and restricting permission for each user is important.
For client security, you need to learn about creating service account and tokens, RBAC, and user authentication.
Storage Security
Storage security is to prevent attackers from accessing our data, either the application data or the credentials in secrets.
You can enable encryption for storage like AWS EBS, Azure disk, and it is very important to enable encryption for ETCD because it will contain every data in the cluster.
Relevant documentation: Kubernetes storage
Kubernetes Security Fundamentals - 22%
In this section, you will learn about core security features in Kubernetes.
Pod Security Standards
This is a set of guidelines that allows us to apply restrictions on pods using three different policies.
The three policies are:
- privileged - This policy has no restriction, this gives the pod every permission. Use this only for system pods like CNI pods.
- baseline - This policy allows the pod to use only the required permissions. You can use this for mostly every application pod, eg, web apps.
- restricted - Use of this policy restricts the pod heavily by using all security best practices. Use this for pods that need the most security, eg, payment service pods.
Pod Security Admissions
Pod security admission is an admission controller that automatically applies pod security standards to pods during creation if they have pod security standards labels.
This has three modes:
- enforce - This mode fails the pod creation if the pod does not meet the specified security standards.
- audit - This mode allows the pod to create even if it does not meet the specified security standards, but logs the violations it makes.
- warn - This allows the pod to create and only gives a warning message for the violations.
Refer to this for more details about pod security standards and pod security admission.
Authentication and Authorization
Authentication means who is allowed to access the cluster using the Kubernetes API.
It can be done using client certificates, bearer tokens, service account tokens, and OIDC.
Authorization means what are the permissions a user has on the cluster, and it is done by RBAC.
Secrets
Secrets are used to store sensitive information like credentials and tokens.
In Kubernetes, secrets are not encrypted by default they are base64-encoded, which means anyone can decode the secrets.
Isolation and Segmentation
Isolation means separating workload from other workloads, and it is done by namespaces and network policies.
Segmentation means grouping certain workloads based on their use case, like databases in a separate namespace and backend in a separate namespace.
You can use taint and tolerations to schedule only certain workloads on a node.
Audit Logging
Audit logging tracks everything that happens in the cluster through the API server.
It tracks every API request made, actions performed by the users, which information should be logged, failed, and successful requests.
Network Policy
Network Policies are resources in Kubernetes that can be used to restrict traffic in the cluster, they can be ingress, egress, or both.
By default, traffic between all pods is open, and every pod can communicate with each other.
Kubernetes Threat Model - 16%
This section covers common security risks in a cluster.
Kubernetes Trust Boundaries and Data Flow
Trust boundaries are setting up permission on certain resources on who can access and who cannot.
Data flow is the flow of requests across the cluster, for example, requests from outside go to the API server and from there to the correct pod.
Persistence
Persistence means attackers still have access even after deleting the compromised resources.
This can happen because of a backdoor container created by the attacker before detection, compromised RBAC, token, etc.
You can prevent it by scanning the images used by the container regularly, checking audit logs, and creating network policies, etc.
Denial of Service (DoS)
The attacker attempts to create more objects like pods, using all node resources to overload the cluster components.
This may cause important pods to be evicted, service breakdown, etc.
To prevent this, you can assign resource limits and requests for pods and create quotas for each namespace.
Malicious Code Execution and Compromised Applications in Containers
This is caused by running a containerized image using an untested base image, which allows the attacker to run a container with more privileges than the host.
You can prevent this by using verified images and by using a security context to run containers with the least privileges.
Attacker on the Network
Every action in Kubernetes is by API network, if an attacker gets access to the cluster network, the attacker can:
- Intercept cluster communication
- Access pods that are in secure nodes
- Tamper with service discovery
We can prevent it by using network policies, and even if you need to expose an application, use Ingress with TLS certificates.
Access to Sensitive Data
Sensitive data referred to credentials and certificates in secrets, important configuration details on configmaps, user data in volumes, and logs.
This may be due to no proper isolation, open RBAC rules, and no proper file system restrictions.
You can prevent it by enabling encryption for ETCD and volumes and storing secrets in external secret managers like AWS Secrets Manager.
Privilege Escalation
Privilege escalation is getting access to more than is required.
To prevent escalation, do the following:
- Give only the required permission to the user
- Always run pods as a non-root user
- Set privileged escaltion false on pod configuration
Platform Security - 16%
In this section, we will see about platform security.
Supply Chain Security
Supply chain security secures the entire development and deployment process.
It covers securing source code, building and pushing, and deploying.
Image Repository
An image repository is a place where container images are stored.
Best practices for image registry:
- Use private registries
- Restrict who can access it
- Sign and scan the images before pushing them to the registry
Observability
Like the name, observability is the process of monitoring an application, it involves metrics, logs, traces, and alerting.
Some of the tools involved in Observability:
- Metrics - Prometheus
- Logs - Loki
- Traces - Jaeger
For more details, refer to this observability blog.
Service Mesh
Service mesh is a layer that manages and secures communication between services.
For more details, refer to this service mesh guide.
Public Key Infrastructure(PKI)
In Kubernetes, PKI is responsible for creating, managing, and validating TLS certificates.
And this is the same framework that is responsible for creating certificates for cluster components during cluster creation.
Refer to this official PKI documentation for more details.
Connectivity
Connectivity is the process of controlling the communication between cluster components and also managing communication with external applications securely.
Some of the best practices are:
- Using networkpolicy
- Making the clusters private and using a jump server to access the cluster securely.
- Using Ingress with TLS to expose the application outside he cluster
Admission Control
Admission Control is a mechanism in Kubernetes that intercepts and validates the requests to the API server before they are saved in ETCD.
It uses two types of validation, one type just accepts or rejects the request, and the second type modifies the request and then saves it.
Modifications are made to data that are not secure for saving by adding security policies.
We can use the tools Kyverno and OPA Gatekeeper for this.
Detailed official documentation on Admission Control.
Compliance and Security Frameworks - 10%
In this section, we will focus on frameworks and tools we can use to secure the cluster.
Compliance Frameworks
A set of guidelines and best practices that make sure the workloads on the cluster follow security standards.
Some of the compliance frameworks in Kubernetes are listed below:
- NIST
- PCI DSS
- HIPAA
- GDPR
Threat Modelling Frameworks
This framework analyzes and identifies security threats in the cluster.
Some of the popular threat modelling frameworks are listed below:
- STRIDE
- OCTAVE
- NIST
Supply Chain Compliance
This refers to the components used in the supply chain that follow the security best practices.
Some of the supply chain best practices are listed below:
- Scanning source code for vulnerabilities
- Scanning created images for vulnerabilities before pushing to registries
- Signing the images
Automation and Tooling
We can automate tasks like security and compliance using tools.
Below is the list of tools you can use:
- Trivy for scanning images for vulnerability.
- Kubescape and kube-bench for auditing CIS benchmarks.
- Kyverno and OPA Gatekeeper for applying security policies.
- Falco for threat detection.
Conclusion
KCSA certification preparation will teach you Kubernetes security foundations.
It is the first step towards CKS certification which is a hands-on exam.
Hope this study guide will help you preapre of the KCSA exam.
Over to you.
How are you planning to prepare for the exam?
