What is Kubernetes Security?

Learn how to secure Kubernetes

Implementing Kubernetes security may seem daunting due to the complexity and volume of its components. However, looking at Kubernetes security at each of its layers individually makes the process of implementation much easier to understand.

To secure Kubernetes, you should start by focusing on the Kubernetes cluster itself. The nodes of the Kubernetes cluster need to be hardened, and the control plane components of both the master and the worker nodes should follow best practices for a secure cluster.

The next step is to verify the supply chain of the container images designated to run in the cluster while ensuring that no security vulnerabilities or misconfigurations exist in the images.

However, even when the utmost care has been taken to secure the Kubernetes cluster and the container images, there is always a possibility that security vulnerabilities or misconfigurations may still occur in the Kubernetes cluster. It’s therefore critical to implement security policies to monitor and respond to runtime threats as they arise.

Kubernetes is a popular platform for container orchestration. By utilizing Kubernetes clusters, containers can be operated and managed in a way that maximizes resources, builds in repairs and redundancies, and automates many repetitive and granular tasks. Kubernetes is often selected over other options because of its compatibility across operating systems, robust feature set, and highly active community to provide support and tools.

Securing the Kubernetes nodes and Kubernetes components

A Kubernetes cluster is made of nodes that run either the Linux or Windows operating system (OS). Some general guidelines for securing a node include the following:

• Installing the minimum applications and libraries for the cluster to operate
• Using root only when necessary
• Real-time auditing and monitoring to detect possible security breaches
• Hardening the OS with tools such as AppArmor and SELinux

Each Kubernetes cluster is composed of master and worker nodes.

• Master nodes contain crucial services that run the Kubernetes cluster. These components include the Kubernetes API server, the scheduler, the controller, and the etcd key store.
• Kubernetes worker nodes run the applications in a cluster. Each node has a kubelet for communicating with the control plane and a kube-proxy for managing communication with services deployed in the cluster.

The Center for Internet Security (CIS) provides a set of security benchmarks for both master and worker nodes. Users can scan their clusters to assess how they measure up against CIS benchmarks using tools such as Kube-bench. Each scan also provides fixes to remediate any configuration that does not adhere to CIS best practices.

Kubernetes supply chain security

To secure the supply chain, you must focus on securing container images. To achieve this, you should adhere to best practices for building secure images with the following:

• Using minimal operating system resource
• Installing only packages required to run the application
• Ensuring tools, applications, and images are up to date

These guidelines reduce the chance of introducing vulnerabilities into the environment and thus minimize risk.

Images should be scanned for Common Vulnerabilities and Exposures (CVEs) and misconfiguration. This process should start as early as possible in the image creation process, preferably at the code development stage. During the build phase of the code, code should also be scanned for CVEs. Many popular tools exist to scan code for CVEs, including Snyk and WhiteSource. Developers also often use third-party libraries to accelerate the process. However, these libraries can also contain security vulnerabilities that ultimately compromise the security of the Kubernetes cluster and should be checked as well.

After the code is built, it’s packaged into a base container image. At this stage, the container image should be scanned again to check for any CVEs that may have been introduced with the base image and for any configuration in the container image that doesn’t follow security guidelines. There are many tools for image scanning with many of them being open source, including Oracle Cloud Infrastructure image scanning.

Development teams should also sign the images to provide a way to verify the integrity and origin of the image when they are handed off for deployment. This capability is a feature of the image registry where the code is stored; examples include Docker Content Trustand Oracle Cloud Infrastructure image scanning.

Runtime security

Scanning container images for CVEs and misconfigurations is not enough to guarantee that an organization’s applications remain secure during runtime, as scanning only detects known vulnerabilities and issues. To completely minimize risk, a runtime security strategy must be in place. Runtime security helps protect workloads from attacks such as

• Activation of malware hidden within a container image
• Privilege escalations in which malicious containers utilize vulnerabilities in Kubernetes or the host operating system
• Unauthorized access to sensitive information held in the cluster due to gaps in access control
• Malicious containers that use vulnerabilities or access control in the cluster

Runtime security should start before a container image is deployed into the cluster. Checks should be in place to answer the following questions:

• Is a pod requesting too many resources?
• Are the container images used to spawn the microservice pods secure?
• Is the Kubernetes deployment manifest following best practices for a secure pod, such as having the proper privileges and using a non-root user to start the process?

Kubernetes has a built-in admission controller to check the deployment against a set of policies. If the deployment doesn’t meet established policies, the admission controller can take actions such as rejecting the instantiation of the resource in the cluster. The Kubernetes admission controller has built-in policies. It can also integrate with other tools, such as an image scanner, to create more advanced policies that check for the number of CVEs in an image or if an image has been signed.

Once the application is running in the cluster, rules should be established to ensure the detection of unauthorized behavior and, upon detection, trigger appropriate action. Detection and enforcement can be executed at the network level or process level or via system calls. At the network level, you can configure Kubernetes network policiesto only authorize communication between services. A service meshprovides similar protection while enabling each service to authenticate the other before communicating using Mutual TLS.

Tools such as Sysdigand NeuVectoralso allow policies to be created at the process level. If an unauthorized process is spawned, the tools can issue an alert, block the process from starting, or isolate the offending service. To create even more-granular policies, you can use system calls to define specifics such as which users are allowed to write to designated files or which processes are allowed to make connections on particular ports. The Cloud Native Computing Foundation (CNCF) project Falcois a popular tool for defining policies based on system calls.

Many of the specialized tools designed for Kubernetes can baseline an application-deployed Kubernetes cluster. This involves learning the behavior of each service (such as the generated network connections, processes, or system calls) and automatically creating the policies for each service. For visibility, the Kubernetes-native feature known as audit logging should be enabled to record actions within a particular cluster. This ensures that security issues will be detected while providing a log of data to help investigate any security incidents that arise after the fact.

Discover Oracle Container Engine for Kubernetes

From encryption to role-based permissions to private Kubernetes clusters, Oracle Container Engine for Kubernetes provides thorough security options while ensuring high performance and flexibility.