Welcome to Course 7 in the KubeCampus learning series—the first lab in learning module 3- Understanding Kubernetes Security
This lab is for those who want to understand how to secure cloud native applications on a Kubernetes cluster. Complete the lab to learn about the different security approaches in Kubernetes.
What is the structure of the lab?
The lab consists of two sections. The first covers Kubernetes Security theory. The second provides hands-on keyboard command line experience. Each section is approximately 30 minutes long, however, your time may vary, depending on how quickly you pass either section. There are a total of 9 challenges to complete during this lab.
Important: On multiple-choice questions, note that more than one answer may be correct. The lab is timed, so it’s best to complete in one sitting.
Security Theory
This section will cover background topics and terminology for Kubernetes security. Each topic will review material on-screen, then pose a challenge question. You must answer the question correctly to proceed to the next section. The theory section includes the following topics:
- The 4C’s of Cloud Native Security
- Cloud Native Security in Depth
- Cluster Hardening
- Container Security
- Code Security
Topic 1: The 4 C’s of Cloud Native Security
This overview defines a model for thinking about Kubernetes security in the context of Cloud Native security.
You can think about security in layers. The 4C’s of Cloud Native security are Cloud, Clusters, Containers, and Code.
Each layer of the Cloud Native security model builds upon the next outermost layer.
The Code layer, for example, benefits from three strong best practices (Cloud, Cluster, Container) security layers. Security standards and practices in the base layers cannot be addressed retroactively at the Code level.
Topic 2: Cloud Native Security in Depth
In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the trusted computing base of a Kubernetes cluster. If the Cloud layer is vulnerable (or configured in a vulnerable way) then there is no guarantee that the components built on top of this base are secure.
Each cloud provider makes security recommendations for running workloads securely in their environment.
- Alibaba Cloud
- Amazon Web Services
- Google Cloud Platform
- IBM Cloud
- Microsoft Azure
- Oracle Cloud Infrastructure
- VMWare VSphere
Topic 3: Cluster Hardening
When securing Kubernetes, one should focus on two particular areas:
- Securing the configuration of the cluster components.
As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions they are allowed to perform is the first line of defense. So, it is recommended to control access to the Kubernetes API and Kubelet components. - If you want to protect your cluster from accidental or malicious access and adopt good information practices, read and follow the advice about securing your cluster.
- Securing the applications which run in the cluster.
Depending on the attack surface of your application, you may want to focus on specific aspects of security. For example: If you are running a service (Service A) that is critical in a chain of other resources and a separate workload (Service B) which is vulnerable to a resource exhaustion attack, then the risk of compromising Service A is high if you do not limit the resources available to Service B.
Topic 4: Container Security
Here are general recommendations to explore this topic:
- As part of an image build step, you should scan your containers for known vulnerabilities. There are several image scanning tools available such as Anchore Engine and Trivy.
- Sign container images to maintain a system of trust for the content of your containers.
- When constructing containers, consult your documentation for creating users inside the containers that have the least level of operating system privileges necessary to carry out the goal of the container.
- Select container runtime classes that provider stronger isolation. For example, gVisor is a sandboxed runtime, which provide further isolation of the host from the containerized process. Instead of sharing the host kernel, the containerized process runs on a unikernel or kernel proxy layer, which then interacts with the host kernel on the container’s behalf. Because of this increased isolation, these runtimes have a reduced attack surface and make it less likely that a containerized process can have a maleffect on the host.
Topic 5: Code Security
Application code is one of the primary attack surfaces you have the most control over. While securing application code is outside of the Kubernetes security topic, here are recommendations to protect application code:
- It’s a good idea to encrypt network traffic between services. This can be done through a process known as mutual TLS authentication or mTLS which performs a two sided verification of communication between two certificate holding services.
- Limit port ranges of communication. Wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering.
- Regularly scan your application’s third party libraries for known security vulnerabilities.
- Perform checks using automated tooling such as SonarQube that can scan codebases for common security errors.
Section 2: Hands-on Commands — Security
In this section, you will use hands-on commands to support CIS benchmarks and how those impact network isolation and image security. Each section of the hands-on exercise will provide the most important commands you need to understand to build a solid Kubernetes security profile for applications using common commands.
Is there pre-work for the lab?
Yes. Be sure to complete reading and studying this blog post, the video showing the work to be performed during the lab, and the accompanying slides.
Note: Additional Learning
To extend the learning experience, Kasten offers a variety of resources such as whitepapers, case studies, data sheets and eBooks on Kubernetes backup.
