Utilizing Cloud Native Kubernetes Deployment for a More Secure Configuration

August 13, 2021

Team Copado

Copado DevSecOps - Blog Series

Originally published by New Context.

The first thing to know about cloud native Kubernetes is that it’s not a plug-and-play option. Kubernetes doesn’t provide any security benefit by default. It has a lot of supportive features, but that’s never the primary focus. Where the program really shines is in its policy enforcement, which is essential in a cloud native environment.

The most important factor in cloud native Kubernetes’ success is working with the right people. An experienced developer will know the best possible options to manage a specific system. However, there are some tools and strategies that work for just about every system and bear consideration.

The Four Layers of Cloud Native Kubernetes

In the most general terms, Kubernetes is a cloud native containerization tool that boasts a wide range of features and open-source options for developers. Understanding it starts by breaking it down into four layers:

Code	The code is up to the client and fully under their control. As such, Kubernetes offers very few security protocols around it. All security here requires the enterprise establish and follow best practices related to application security, CI/CD pipelines, and version control. Otherwise, the code will be open to illicit modification which will give bad actors a consistent foothold in the Kubernetes environment.
Containers	Containers are another thing that are under the control of the client. They need to evaluate theirs for potential vulnerabilities and establish trust protocols. Prior to deployment, it’s vital to scan them thoroughly and ensure they’re not running as root. Otherwise, bad actors can use them as a vehicle for entry to the node’s filesystem and establish a presence in the overall cluster.
Clusters	Cluster issues in Kubernetes break down into two areas: the cluster component’s configuration and the management of the cluster’s applications. Specific matters at this level may include secrets management, authentification, API access, admissions control, networking and security policies.
Clouds	The cloud is the broadest aspect of Kubernetes layers. It depends entirely on the cloud provider that the client chooses, whether it be Amazon Web Services, Microsoft Azure, IBM cloud, or another infrastructure as a service provider.

A failure in one of these layers will trickle into others. Focusing on the interplay between them is necessary to ensure protection and mitigate the blast radius of any issues. Aside from that, it’s wise to consider certain Kubernetes features that will enhance security systemwide.

The Four Layers of Cloud Native Kubernetes - Copado

Features to Focus on in Kubernetes

Kubernetes shines in many areas. One of the most evident is role-based access control. Kubernetes RBAC allows the cluster administrator to establish permissions for any objects within a cluster at an extremely granular level. It allows them to establish exactly what users can do within the Kubernetes cluster. It’s best to take advantage of this, rather than running all containers as root. Keep in mind that simply avoiding root does not entirely limit what a user can do inside the system. It just restricts attackers from making it outside the container’s boundaries and establishing a more persistent cluster presence.

Other than that, there are a few other key tools to leverage:

Tools within Kubernetes

Third Party Tools

API logging: API logging should also be enabled, though these logs should not be kept in the same container where they run. Removing the logs outside of the cluster will protect their integrity.

Encryption keys: Encryption keys should be used at the cluster level to protect information. These keys require regular rotation. In some instances, this rotation happens automatically. In others, it will need to be manually completed.

NetworkPolicies: In base-level Kubernetes, pods will accept all traffic by default. NetworkPolicies can minimize this by restricting these communications and better controlling traffic.

Container network interface: CNI acts as the connection between Kubernetes itself and the vendor-specific networking.

HashiCorp Vault: HashiCorp Vault isn’t a part of Kubernetes. Instead, it can work alongside it to build secrets management inside of applications and the overall infrastructure of the program.

Service mesh: This infrastructure layer allows the administrator to leverage load balancing, encryption, authentification, and other abilities that enhance security while speeding results.

Open Policy Agent: OPA is a policy engine pipeline that’s incredibly useful in continuous integration and continuous deployment (CI/CD). It can automate policy enforcement and governance based on the needs specific to an organization.

Aside from these tools, it’s also essential to establish Kubernetes best practices and avoid certain behaviors that will open a program up to risk. One of the foremost is defaults. Defaults should never be used. Bad actors specifically target defaulted systems because there are known vulnerabilities. Regular scans, especially during builds and deployment, will help to eliminate issues that can filter from a container through an entire system.

The open-source nature of the Kubernetes ecosystem has given rise to a wide range of tools that can enhance infrastructure and app security. As a result, there will never be an exhaustive list of features that enterprises need to use to protect their system. The offerings will be ever-evolving as new threats and strategies emerge.

Cloud native Kubernetes is a viable method for managing and protecting a system, provided the user understands that security is not the primary purpose. By recognizing the weaknesses of the program, it’s possible to come up with solutions that leverage the many tools and features available to support all the layers in play in a cloud native environment.