Kubernetes Security

Risks and Challenges

Applications run through build, deploy, and runtime cycles, and Kubernetes provides intrinsic security advantages at each stage of the application lifecycle. However, it can still pose many challenges.

‍

Greater Attack Surface

Your system will likely use or create countless containers, and containers are everywhere. Although using containers gives you the ability to leverage microservice architectures and operate with greater speed and higher portability, using them can also create security blind spots that expose your system to vulnerabilities.

Maintaining visibility into system operations and security as you deploy more and more containers becomes increasingly difficult. Furthermore, there are also the tasks of investigating individual issues, responding to them, or reconfiguring misconfigured containers.

‍

Misused Registries and Images

How secure are the images that you build and the registries in which you store them? Do you regularly scan them? A failure to do so can be detrimental to your application and system security across your networks – not just in the Kubernetes environment.

‍

Network Effects

Since containers communicate with other containers and other network endpoints, a breach in container security can spread across your entire network, depending on the level of system access the breached container has with the rest of the network.

Successfully addressing these challenges and others that you may face will require you to integrate security into your build, deploy, and run cycles. At a very high level, your images must be free of dangerous vulnerabilities, deployments must follow security best practices, and your container workloads must be secure from runtime threats.

‍

Container Best Practices

In the sections below, we outline in greater detail some of the Kubernetes best practices you should follow for all three stages of the container lifecycle.

‍

Build Phase

First and foremost, you must secure your container images. This involves first building secure images and then scanning for vulnerabilities.

Best practices are to use minimal base images and avoid using images with shells or OS package managers — these can bring unknown vulnerabilities into your system. Also, avoid adding unnecessary components and only use up-to-date images. You must ensure that any tools, applications, and all images are up to date.

Regular scanning is an important part of Kubernetes security, so make sure to use a scanner that can identify image vulnerabilities, as well as OS package and third-party runtime vulnerabilities. These scans and security checks should be built into and automated as part of your continuous integration/continuous deployment (CI/CD) pipeline. For example, the Validating Admission Controller in Kubernetes allows you to reject deployment creation if images are not scanned before deployment or if the images are over 90 days old.

Keep in mind that the best security policy is defense in depth. So, a vulnerability in one area, such as in a container, a cluster, the cloud, or in your code, can be addressed before it has production impact and before it can reach other parts of your network.

‍

Deploy Phase

You must securely configure your Kubernetes infrastructure before workloads are deployed. You need to know what you are deploying and how, and from there, you can identify and respond to potential security threats or violations.

Knowing exactly what you are deploying requires an understanding of:

• Components
• Known vulnerabilities
• Pods that will be deployed
• All clusters, namespaces, and nodes involved
• Whether it will run privileged
• What deployments it will communicate with

‍

You also need to know what it can access and whether the deployment is already in compliance with – or violation of – any security or policy requirements.

From there, you can implement deploy-phase recommendations. These include using namespaces to isolate sensitive workloads to contain potential attacks, limiting the impact of any errors or malicious actions taken by authorized users, and controlling traffic between pods and clusters via network segmentation to prevent unauthorized lateral movement across containers.

As a general rule, you must always evaluate access privileges by anyone and anything in your system, including access permissions of your containers. Only give your containers the privileges and capabilities it needs to perform its required function(s).

Also, never deploy code from an unknown source, which in Kubernetes means only using images from known registries or those with authorized access. Relevant business resources such as developers and programmers should know how to label deployments with the correct name or alias so that the relevant teams can address the security issues they are responsible for should any arise.

‍

Runtime Phase

You can manage Kubernetes’ security challenges by gaining visibility into the runtime environment and detecting and then responding to runtime threats as they arise.

This involves monitoring process activity, network communications between different containers and containerized services, and communications between containers, containerized services, and third-parties, clients, or external servers.

By comparing observed versus expected activity, you can identify and then stop suspicious activity. By extending vulnerability scanning to running deployments will help you catch runtime vulnerabilities that did not appear before. Many Kubernetes built-in controls such as read-only root file systems can prevent attacks that require software installation, and you should monitor network traffic to limit unnecessary or unsecured communications.

‍

Built-In Features

While Kubernetes security during the build, deploy, and runtime phases are important, security issues should be tackled holistically. This means you must start with infrastructure security and then scale your way up or down your network by first taking a wider view, then a more granular, cluster/container/code view of your systems.

Always update your Kubernetes to the latest version if possible, and secure etcd, which is a key-value store used by Kubernetes for data access. Ensure that all client connections are served only over TLS, and actively embed security as early as possible in the container lifecycle. Also, familiarize yourself with Kubernetes’ native controls.

The following are examples of built-in Kubernetes features that can turbocharge your container orchestration:

• Open Policy Agent (OPA): OPA unifies policy enforcement via a high-level declarative language through which you can specify policy as code. Doing this removes the burden of policy decision-making from your software. Use OPA to enforce whatever custom policies you want on Kubernetes objects without having to recompile or reconfigure your Kubernetes API server.
• Pod Security Policy (PSP): Use PSP to define the conditions that specific pods must run with for them to be accepted into the system. PSP security settings, applied using security contexts, also allow you to define privilege and access controls for specific pods.
• Role-Based Access Control (RBAC): The RBAC manages authorization decisions. This allows admins to dynamically configure access policies via role bindings and permissions for specific users or sets of users.
• Network Policy: Communication policies that govern how groups of pods can communicate with each other and other network endpoints.

‍

It can take time to learn when, where, and how to use these and other built-in tools to leverage Kubernetes the right way. The same applies to getting defense in depth right, identifying and addressing security vulnerabilities when they appear, securing your clusters, ensuring pod security, reducing your attack surface, and managing network traffic. However, ensuring Kubernetes security is critical if you want to enjoy the scalability, replicability, simplified management, and quick deployment of containers for which Kubernetes was designed.

‍

Conclusion

If you are making your initial forays into Kubernetes, a third-party Kubernetes specialist can help you quickly get up and running with cluster orchestration based on the kinds of applications your organization builds and the kinds of deployments you need.          

‍

Learn more

Discover how Zero Trust Segmentation secures container deployments, including Kubernetes and RedHat OpenShift platforms.