Kubernetes & Cloud Native Security Associate (KCSA) Study Notes and Exam Prep = Kubestronaut

Another day, another certification achieved (and Kubestronaut)! This time, I tackled the Kubernetes and Cloud Native Security Associate (KCSA) certification, a relatively new exam introduced in 2023 by the Linux Foundation. The KCSA is quite similar to the Kubernetes and Cloud Native Associate (KCNA) certification, but it has its own unique focus. The exam consists of 60 questions to be completed in 90 minutes, with a passing score of 75%.

From my research and reading others’ experiences (a helpful tip: try searching for “LinkedIn KCSA Exam” and checking Reddit for insights), many have described the KCSA as a knowledge-based version of the Certified Kubernetes Security Specialist (CKS). While this is accurate to some extent, it’s worth noting that the CKS exam requires a deeper dive into technical material.

Having recently retaken the CKS exam, I felt confident yet apprehensive due to the lack of high-quality course materials and practice exams, such as those from KodeKloud or ExamPro. Given that the KCSA was the final exam I needed to earn my Kubestronaut, I recommend the following resources if you have only taken the KCNA exam (see my study notes here). The KCNA is a great precursor to the KCSA, as it covers many fundamental Kubernetes concepts that are essential for the KCSA.

The Exam

My preparation for the exam was fairly ad-hoc, with 1–2 hours of study each day in the week leading up to it. I prefer to organize my study notes as I review each domain and competency. This approach helps me consolidate my understanding and track my progress effectively.

This exam is probably one of the harder ones to find course material. As of writing the only specific course I could find was Kubernetes and Cloud Native Security Associate (KCSA) Cert Prep by Michael Levan.

I managed to clear the exam with relative confidence. However, given that I had already completed the other certifications, this might not be a fair assessment for someone coming directly from the KCNA. The KCNA provides a solid foundation and transitions smoothly into the KCSA, making it a valuable stepping stone if you choose to continue your studies.

The Domains and Competences

Below are the notes I used for my preparation (translated from my handwritten notes). I hope you find them helpful!

Kubestronaut

At the conclusion of this exam I become a Kubestronaut. I’ll bottle that feeling right here too.

Overview of Cloud Native Security (14%)

Cloud Native Security Layers: Cloud → Clusters → Containers → Code

• Cloud: Everything you control is within the shared responsibility model (e.g., cloud provider layer, network layer, infrastructure layer).
• Clusters: Enforce security controls at the cluster level.
• Containers: Ensure vulnerability scans, image signing, running containers as non-root users, and use container runtimes with strong isolation.
• Code: Implement TLS, limit port ranges, manage third-party dependencies, and apply static and dynamic code analysis.

Cloud Provider & Infrastructure Security:

Cloud providers like Azure, AWS, GCP offer similar security services and features. Conduct threat analysis and understand attack vectors relevant to cloud environments.

Security Controls & Frameworks:

• STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
• Standards & Frameworks: CIS Benchmarks, NIST, CSA, MITRE ATT&CK, OCTAVE
• These frameworks guide best practices, standards, and secure procedures for cloud security, covering:
• Data security
• Application security
• Network security
• Compliance

Isolation Techniques:

• Namespaces: Ensure process isolation.
• Network Policies: Apply Ingress and Egress rules.
• Policy Enforcement: Prevent unauthorized actions.
• RBAC (Role-Based Access Control): Manage authentication and permissions effectively.

Artifact Repository & Image Security:

• Ensure images are scanned and secure in artifact repositories.
• Artifact repositories often have built-in scanning and security features to detect vulnerabilities in container images.

Workload & Application Code Security:

• Workload Security: Focus on securing the platform and monitoring (e.g., using tools like sysdig).
• Application Security: Ensure the code in container images is secure by conducting vulnerability scans. Use automated security tools, enforce RBAC policies, and grant only necessary permissions to containers.
• Tools like Kube-bench can enforce security best practices within Kubernetes, including configuring appropriate security contexts.

Security Principles

1. Security by Design: Security should be a design requirement from the start.
2. Secure Configuration: Secure configurations should offer the best user experience.
3. Informed Choices: Selecting insecure configurations should be a deliberate and informed choice.
4. Transition to Security: The system should enable transitioning from insecure to secure states smoothly.
5. Secure Defaults: Defaults should protect against common vulnerabilities and exploits.
6. Support for Exceptions: Exceptions to secure configurations should be supported at a high level.
7. Defend Against Exploits: Secure defaults should defend against widespread vulnerability exploits.
8. Understandable Security Limitations: The security limitations of any system should be clear and explainable.

Kubernetes Cluster Component Security (22%)

API Server

• The API Server is the cluster’s entry point, responsible for controlling access to the Kubernetes cluster. It handles all REST requests for the cluster and ensures security policies are enforced.

Controller Manager

• The Controller Manager is responsible for ensuring the desired state of the cluster. It continuously monitors the state of Kubernetes objects and works to maintain their desired configuration.

Scheduler

• The Scheduler assigns pods to nodes based on resource availability and other factors, ensuring that workloads are balanced across the cluster.

Kubelet

• The Kubelet is the agent that runs on each node and communicates with the API server. It ensures that containers are running as expected on the node.

Container Runtime

• The Container Runtime manages the containers themselves, enforcing policies and ensuring that the security context is applied correctly.

Kube Proxy

• Kube Proxy handles local cluster networking. It facilitates communication within the cluster by managing network rules. Newer technologies like eBPF reduce reliance on Kube Proxy and iptables for network traffic management.

Etcd (Key-Value Datastore)

• Etcd is the backing store for all Kubernetes cluster data.
• It is crucial to enable transport security (e.g., TLS) for etcd.
• Regular backups are critical to preserving the cluster’s state.
• Secrets should be securely stored in etcd by using encryption at rest.

Container Networking

• Kubernetes networking relies on CNI (Container Network Interface) plugins to manage network connectivity.
• Network Policies are used to define allowed traffic for pods, including both Ingress and Egress rules.
• Namespaces are utilized for network isolation.

Client Security

• Ensure proper client security by verifying that data remains encrypted in transit and at rest.
• Storage should be configured to persist important data rather than relying on ephemeral storage, which is temporary and will be lost when containers are restarted.

Kubernetes Security Fundamentals (22%)

Pod Security Standards

• Privileged: Unrestricted access, provides full permissions to containers.
• Baseline: Minimally restrictive, prevents known privilege escalations but allows standard usage.
• Restricted: Heavily locked down; follows pod hardening best practices and enforces strong security controls.

Pod Security Admission

• Kubernetes has a built-in Admission Controller that enforces Pod Security Standards:
• Enforce Mode: Pods violating the policy are rejected.
• Audit Mode: Pods violating the policy are allowed but recorded for auditing purposes.
• Warn Mode: Pods violating the policy are allowed but generate warnings to alert users.

Authentication

• Use OpenID Connect for authentication. It’s important to ensure that all Kubernetes users are authenticated and integrated securely with an external identity provider.

Authorization (RBAC)

• Kubernetes uses RBAC (Role-Based Access Control) for authorization.
• Service Accounts are associated with specific roles, and roles define access to resources by specifying verbs (e.g., get, list, create).

Secrets Management

• Kubernetes Secrets are base64-encoded by default, but more secure methods such as integrating with HashiCorp Vault or another external secret management solution are recommended.

Isolation & Segmentation

• Kubernetes can be configured for either Single-Tenancy or Multi-Tenancy environments.
• Key isolation mechanisms include Namespaces, RBAC, Network Policies, and Policy Enforcement (using tools like OPA or Kyverno).

Audit Logging

• Audit Logs record events from request receipt to response completion.
• Logs capture who made the request, what the request was, when it occurred, and where it originated.
• In managed environments (e.g., EKS, AKS, GKE), the cloud provider manages the control plane audit logging for you.

Network Policies

• Network Policies regulate traffic between pods and across namespaces.
• Kubernetes API traffic goes through multiple layers: authentication, authorization, and admission control before hitting the data plane.
• Data Plane Isolation includes network isolation, storage isolation, sandboxed containers, and mode isolation (e.g., tenants within their own network boundaries).

Control Plane Isolation

• Control plane security measures include:
• Namespaces: Each tenant has their own namespace.
• Access Controls: Role-based access to control plane resources.
• Resource Quotas: Ensure fair usage across tenants by assigning quotas.
• Node Selection: Nodes can be selected to isolate workloads.
• Virtual Control Planes: Tools like vcluster allow each tenant to have their own virtual control plane within the cluster.

Kubernetes Threat Model (16%)

Trust Boundaries & Data Flow

• Trust Boundaries are key points where the system’s security could be compromised. These include the Internet, API Server, Master Components, Master Data, Worker Nodes, and Containers.
• Threat Modeling is the process of identifying, communicating, and understanding potential threats in the context of protecting valuable assets.
• It produces a prioritized list of security improvements based on identified threats.
• Data Flow: In Kubernetes, data flows between nodes and the control plane. Secure communications (e.g., TLS) should be maintained at all points.

Persistence

• HostPath Volumes allow pods to access the underlying host filesystem, which can introduce vulnerabilities. Careful management is required to avoid exposing the host’s filesystem.

Denial of Service (DoS)

• DoS attacks can cause pods or the cluster to become unresponsive. Use Network Policies and cluster hardening techniques (e.g., Ingress controls) to mitigate these risks.

Malicious Code Execution & Compromised Applications

• Attackers may exploit misconfigured applications or containers to execute malicious code.
• Mitigations include changing passwords, keeping software updated, taking regular backups, and applying Network Policies and iptables.
• Monitor and audit logs to detect any signs of compromise.
• Regularly scan container images for vulnerabilities using tools like SonarQube and other security scanners.

Network Attacks

• An attacker could operate at the cluster level, network level, or pod level.
• Use Network Policies, eBPF, iptables, and proper authentication and authorization to secure the network.
• Enforce security policies across the cluster and protect the API Server from unauthorized access.

Access to Sensitive Data

• Attackers may target sensitive data stored in etcd or in persistent volumes. Ensure etcd is encrypted and access to persistent volumes is restricted to authorized entities.

Privilege Escalation

• Privilege Escalation occurs when an attacker gains higher permissions than they should have.
• Mitigations include using RBAC (Role-Based Access Control) and setting Security Contexts on pods to restrict privileges.

Platform Security (16%)

Supply Chain Security

• Supply Chain Security encompasses anything that interacts with your code throughout the SDLC (Software Development Life Cycle).
• This includes development environments, CI/CD pipelines, and external dependencies that may introduce vulnerabilities (e.g., containers and Kubernetes manifests).
• Follow best practices such as CNCF Supply Chain Security guidelines to secure your entire pipeline.

Image Repository

• Use a secure Image Repository to store and manage container images. Some platforms, like Artifactory, provide built-in security features to scan and protect images against vulnerabilities.

Observability

• Ensure comprehensive observability by monitoring:
• Traces: Track requests across services.
• Logs: Collect and analyze logs for auditing and troubleshooting.
• Metrics: Gather performance data and alerts for proactive monitoring.

Service Mesh

• A Service Mesh is a dedicated infrastructure layer that manages communication between services.
• It enhances security, observability, and resilience by providing encryption, load balancing, and tracing at the network level.

PKI (Public Key Infrastructure)

• Kubernetes utilizes PKI for securing communication between components. Tools like kubeadm handle the creation of certificates — Kubernetes uses a large number of certificates to ensure secure communication across nodes.

Connectivity

• Secure and manage connectivity between services, nodes, and external systems using proper encryption and secure communication protocols.

Admission Control

• Admission Controllers are gatekeepers for cluster resources, governing how clusters are used:
• They authenticate API requests and enforce policies before resources are created or modified.
• OPA (Open Policy Agent) Gatekeeper is a common policy enforcement tool.
• There are two types of admission controllers:

1. Mutating Admission Controllers: Modify requests before they reach the API.
2. Validating Admission Controllers: Validate requests and ensure they conform to policies before they are allowed.

Compliance & Security Frameworks (10%)

Compliance Frameworks

• Compliance involves adhering to security standards, protocols, and auditing procedures, essentially following a checklist of required best practices. Common frameworks include:
• CIS Benchmarks: Security configuration benchmarks for Kubernetes clusters.
• NVD (National Vulnerability Database): A database of known vulnerabilities and exposures.
• NIST (National Institute of Standards and Technology): A key resource for security standards and best practices.
• STRIDE: A threat modeling framework that helps identify threats like Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Elevation of Privilege.

Threat Modeling Frameworks

• Threat Modeling helps define security requirements and identify potential vulnerabilities in a system:
• Tools like OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) can be used to identify and mitigate risks.
• Focus on critical areas such as Authentication, Authorization, and Continuous Validation of Access.
• Apply Zero Trust principles to secure your infrastructure.

Supply Chain Compliance

• Use the CNCF Supply Chain Security guidelines to ensure compliance across your software development pipeline. Key elements include:
• Artifacts: Track software components.
• Metadata: Record information about artifacts.
• Attestations: Verify compliance.
• Policies: Apply compliance checks to ensure security throughout the supply chain.

Automation & Tooling

• Automation is key to maintaining compliance and security. Common tools include:
• Kubescape: Scans everything — clusters, pods, and manifests — against CIS benchmarks and outputs results to the terminal.
• Kube-bench: Focuses on scanning clusters for CIS compliance.
• Checkov: Performs static analysis on manifests and checks for security threats.
• These tools help automate remediation and continuously enforce security standards.

Develop -> Distribute -> Deploy -> Runtime

• A security risk management process that spans the development, distribution, deployment, and runtime phases of the software lifecycle. This approach is crucial for identifying, mitigating, and managing risks throughout the entire lifecycle.

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)

• OCTAVE is a risk assessment methodology designed to identify and prioritize information security risks. It consists of three phases:
• Phase 1: Identification of critical assets and threats to the system.
• Phase 2: Assessment of vulnerabilities in the infrastructure.
• Phase 3: Development of a security strategy and implementation plan to mitigate identified risks.

General Threat Actors

• OCTAVE identifies three main types of threat actors:

1. Malicious Insider: An individual with authorized access who intentionally seeks to harm the organization.
2. Uninformed Insider: An individual with authorized access but inadvertently causes harm due to lack of security awareness.
3. Malicious Outsider: An external entity attempting to compromise the system.

Threat Intelligence

• Threat Intelligence involves gathering indicators that can be observed in the system, such as specific behaviors of potential attackers.
• Behavior Indicators: Patterns of behavior that suggest a potential threat actor.
• Use frameworks like the MITRE ATT&CK Framework as a starting point to understand tactics and techniques of attackers. This helps in the development of specific threat mitigation strategies.