Guides: Kubernetes Security

Kubernetes Security: 8 Best Practices to Secure Your Cluster

What Is Kubernetes Security?

Kubernetes is growing in popularity, and its use within organizations is maturing. According to the latest Cloud Native Computing Foundation (CNCF) annual survey, 93% of organizations are using or planning to use containers in production, and 96% are using or evaluating Kubernetes. According to a previous survey, 28% of organizations have more than 11 Kubernetes production clusters.

At the same time, security concerns around Kubernetes are mounting. A Red Hat survey of Kubernetes adoption and security showed that, of 500 DevOps professionals surveyed:

55% delayed an application release due to security issues.
94% experienced at least one Kubernetes security incident in the past year.
59% said security is their biggest concern with regard to continued use of Kubernetes and containers.

Read on to better understand the security risks facing Kubernetes environments, understand what security mechanisms Kubernetes natively provides, and discover best practices for improving your Kubernetes security posture.

In this article, you will learn:

8 Kubernetes Security Best Practices

Below are critical best practices you must implement to secure your Kubernetes clusters, divided into the three main stages of the development lifecycle: build, deploy, and runtime.

Build-Time Security

Here are key best practices that will help you secure containers during the build phase of your software development lifecycle (SDLC).

1. Image Scanning

It is essential to make sure that container images are free of vulnerabilities, because every container created from an image will inherit its vulnerabilities. This is typically done by scanning the base image and all packages against a vulnerable database.

Image-scanning tools verify that:

Applications or libraries included in container images are free from Common Vulnerabilities and Exposures (CVEs) and other vulnerabilities shared by public sources.
The base image, on which the container image was built, is free of vulnerabilities that could affect the operating system (if included) or any other libraries.

Images must be scanned at all stages of the CI/CD pipeline, and access to image registries must be controlled to avoid tampering.

2. Host Operating System Hardening

Ensure that containers only have the minimal required privileges on the host. Use a hardened host operating system with adequate controls to restrict system calls and file system access, and have strong isolation between processes. This can help prevent privilege escalation attacks, where a compromised container gains access to the host operating system, or other containers running on the system.

3. Minimizing the Attack Surface: Base Container Images

When selecting a base image for your containers, use an image with the minimal software packages absolutely necessary for your container to function. It is even better to build a container without a full base image:

Use the Docker FROM scratch directive to create a minimal image and explicitly select the packages you want to add to it.
Start from a slimmed down Linux distribution image (“distroless” image) or an Alpine minimal image.

Deploy-Time Security

When the time comes to deploy your containers to production, you can secure them using the following measures.

4. Harden Your Kubernetes Clusters

Kubernetes cluster configuration is not secure by default. To ensure your clusters are secure, follow these steps:

Perform a review of current Kubernetes cluster configuration and identify gaps with security best practices. You can use automated tools like kube-bench to scan your clusters for compliance with benchmarks like the CIS Benchmark for Kubernetes.
Build a trust model for each component of your cluster by identifying probable threats and specifying how the cluster will respond to and mitigate each threat.
Use label taxonomies and label governance to implement your trust model.
Set up Role Based Access Control (RBAC) to define access to the cluster, aligning it with your threat model and label structure.
Secure etcd, the Kubernetes datastore, and the Kubernetes API server with multi-factor security and Transport Layer Security (TLS) for data in transit, and limit access to public networks.

5. Integrating Security Tools with Kubernetes Clusters

Integrating your Kubernetes clusters with existing security tools allows perimeter security systems to work together with security measures deployed inside your clusters.

An effective way to do this is to feed the IP addresses and TCP/UDP ports used by your workloads into perimeter security tools, on an ongoing basis, to allow them to identify and secure Kubernetes assets.

Runtime Security

Here are best practices that can help you secure Kubernetes cluster infrastructure and workloads during runtime.

6. Network Security Controls

To achieve network security in a Kubernetes environment, you must build network security definitions into your workloads, using a declarative model. Security definitions must be an inseparable part of Kubernetes workloads, and must be portable across Kubernetes distributions and data centers. Wherever the workload runs, it must always carry its security definitions with it. This can be achieved in two ways:

Using a Kubernetes-native network policy solution – Examples include Calico, Weavenet, Kube-router, and Antrea.
Using a Kubernetes-native proxy – A commonly used proxy is Envoy. This can help define application layer policy to secure communication between microservices.

7. Enterprise Security Controls

In addition to network security controls, apply the following enterprise security controls to your Kubernetes environment:

Encrypt data in transit – Enable TLS encryption for workloads, or leverage a service mesh to enable mutual TLS.
Automate compliance reports – Ensure you collect data in a way that enables automated reports for relevant compliance standards.
Aim for continuous compliance – Use Kubernetes-native automation to check and remediate compliance issues, such as automatically updating container images that fail checks.

8. Threat Defense

To defend a Kubernetes cluster against threats, you need two key capabilities:

Intrusion detection – The ability to analyze data, identify anomalies, and triage security incidents.
Intrusion prevention – The ability to block malicious activity and respond to attacks.

Use the following guidelines to make data more manageable, and derive security insights:

Aggregate by pods – Group together “similar” pods communicating on a certain port.
Leverage machine learning – Use tools that can automatically analyze pod traffic metrics to detect anomalies.
Use threat intelligence – Leverage databases of known malicious IPs and domains to identify malicious traffic in your cluster.

Kubernetes Security Solutions

Advanced Kubernetes security tools offer various capabilities, including detecting vulnerabilities and ensuring each container runs as intended. Container security processes must run continuously to protect the container host, its management stack, and its network traffic while monitoring the build pipeline’s integrity and the application’s security.

What Are the Main Kubernetes Security Issues?

The following are some of the main risks facing Kubernetes production deployments.

Compromised Images and Image Registries

To ensure the security of images, organizations should implement strong governance policies that ensure images are securely built and stored in trusted registries.

Compromised Containers or Malicious Traffic

Containers and pods need to communicate with each other, but this communication can be exploited by threat actors. To ensure communication is secured, organizations should put in place network policies that limit communication to the minimum necessary for workloads to function.

Lack of Visibility

Visibility is critical to ensure security is maintained. However, it can be challenging to achieve visibility in complex, distributed, containerized environments.

Unsecure Default Configurations

While Kubernetes provides a wide range of controls that can help organizations effectively secure clusters and applications, it does not provide secure configurations out of the box.

Compliance Challenges

Achieving compliance in cloud-native environments is a highly challenging endeavor. Organizations are required to implement certain security measures, enforce best practices, and provide proof of compliance.

Kubernetes Security Fundamentals: What You Need to Secure Your Cluster

Kubernetes provides several concepts and mechanisms that can help secure your clusters. Here are the most important ones:

Network Policy

Kubernetes uses a flat network model that allows each pod to communicate with any other pod in the cluster by default. To secure pod-to-pod communications, Kubernetes uses the concept of network policies.

Pod Security Policy

Kubernetes originally used the PodSecurityPolicy (PSP) object to control security-related pod configuration. However, PSP has been found to be difficult to use and is being deprecated.

Kubernetes Secrets

The built-in Kubernetes Secrets feature lets you store sensitive information within a secret object in Kubernetes.

Kubernetes RBAC

Kubernetes uses the concept of ClusterRoles and Roles, which specify what each user can perform in a cluster or an entire Kubernetes namespace.

Authentication

The primary access point for a Kubernetes cluster is the Kubernetes API, which is protected by Transport Layer Security (TLS).

TLS For Kubernetes Ingress

To secure an Ingress object, you specify a secret containing two keys—tls.crt and tls.key.

Quality of Service

Kubernetes automatically assigns a Quality of Service (QoS) class to pods, which helps optimize scheduling and eviction of pods.

Kubernetes Security and Observability with Calico

Tigera’s commercial solutions provide Kubernetes security and observability for multi-cluster, multi-cloud, and hybrid-cloud deployments. Both Calico Enterprise and Calico Cloud provide features for security and observability.