In the context of Kubernetes clusters, zero trust network access solutions can help apply consistent security policies between the Kubernetes environment and the rest of the organization.
The zero trust security model is a new approach to designing network and IT systems, which states that resources on a network should never trust other resources and should always verify them before granting access. Even if a device is connected to a managed corporate network and has been previously authenticated, it should not be trusted by default.
Modern enterprise environments consist of complex networks with many interconnected parts, including cloud-based services, connections to remote and mobile environments, and non-traditional systems such as containerized and Kubernetes environments.
In this highly diverse and distributed environment, the traditional approach of trusting devices on the local network, or connecting via VPN and gaining access to the entire network perimeter, does not provide adequate security. Instead, the zero-trust approach advocates mutual authentication—verifying the identity and integrity of users and devices regardless of their location and providing granular access to networks, applications, and data based on the current security context.
See also: Why Observability is Essential for Kubernetes
What Is Zero Trust Network Access?
Zero trust network access (ZTNA) is a technology that is a fundamental building block of zero trust networks. It authenticates access requests based on identity to establish trust and provide access while hiding physical network locations (i.e., IP addresses).
ZTNA gives security and IT teams centralized control over highly distributed systems, letting them set policies that provide access to specific data and applications for specific times, locations, or devices. The technology operates across on-premise, cloud, and operational technology (OT), identifying anomalous activity such as requests to access sensitive systems at unusual times or download unusual amounts of data. Security teams can then react to these anomalies and update policies to prevent similar incidents in the future.
In the context of Kubernetes clusters, ZTNA solutions can help apply consistent security policies between the Kubernetes environment and the rest of the organization. Kubernetes RBAC can integrate with external systems, and using ZTNA to define RBAC roles and policies can create a unified access control system across the enterprise.
See also: Researchers Find 380,000 Open Kubernetes Servers
Securing Containers with Zero Trust
Containerized applications introduce complexity into enterprise networks. Containers often communicate using overlay networks, which create a distributed network that can easily be ported to any infrastructure.
However, while flexible and powerful, this networking model also reduces visibility and makes it difficult to regulate traffic using traditional tools such as firewalls. Traditional network access controls operate at the host level and are unaware of containerized resources running within a host. This means that attackers might gain access to the host, gain access to sensitive workloads, and use them to move laterally across the network.
Here are three principles that can help you overcome these challenges and implement zero trust in a containerized environment:
- Containers should not trust each other—by default, communication between two containers should not be allowed unless it is absolutely necessary. All connections should be authenticated and denied if they are not authorized. This means that cyber attackers gaining access to one resource will not be able to move laterally to others.
- Local server certificate—deploying a certificate on servers that run containers can help create a consistent record that can help identify and respond to security issues.
- Identity and access management (IAM)—container authorization should be integrated with IAM to robustly identify users, access attempts, and certificates and apply the most appropriate role-based controls. This is highly effective against both external attackers and insider threats.
Applying Zero Trust Principles to Your Kubernetes Environment
The central component of the Kubernetes control plane is the API Server. API calls are the mechanism for querying and manipulating the state of every Kubernetes object, including namespaces, pods, and ConfigMaps. This means that controlling API usage is paramount to managing Kubernetes access, which is the primary focus for enabling zero trust in Kubernetes.
A first step in your Kubernetes security strategy can be to secure access to the API server. You can use Transport Layer Security (TLS) to secure API server traffic. Once the transport is secure, Kubernetes provides four key capabilities that can help you implement zero trust principles and regulate API server access—authentication, authorization, admission control, and logging.
Kubernetes Authentication
Kubernetes zero trust must authenticate all users and service accounts before making API calls. There are several Kubernetes security modules and plugins that support secure authentication.
It is a good idea to use at least two or more of the following authentication methods to ensure strong authentication: client certificates, HTTP Basic Auth, bearer tokens, OIDC tokens, webhook token authentication, and authentication proxies.
Authorization
In Kubernetes, each request specifies which username is performing the request, what actions it wants to perform, and which Kubernetes objects are affected. Kubernetes zero trust requires that every request must be appropriately authorized. Authorization should follow the least privileged principle—a user or account should only have access to a resource or operation if they absolutely need it for their role.
Kubernetes provides two primary authorization models. Attribute-based access control (ABAC) is available in Kubernetes but is considered deprecated and is not recommended for use. The main reason is that it can be difficult to set up, and misconfigurations are common, which can lead to security issues.
The model of choice is role-based access control (RBAC), which authorizes access based on the role of a username (which might be administrator, developer, and so on). This is easier to manage and provides sufficiently granular access to implement zero trust in Kubernetes.
Admission Control
You can use business logic to implement a more sophisticated Kubernetes zero trust implementation. Kubernetes Admission Controllers provide a way to respond to any requests made in a cluster to create, connect to, modify, or delete a Kubernetes object. The admission controller applies business logic defined by cluster operators, and if the request does not comply with the rules, it is immediately denied.
You can use various built-in admission controllers to apply policies and enforce different actions. There are also dynamic controllers that let you change requests on the fly to comply with a set of rules. For instance, the ResourceQuota controller monitors incoming requests to ensure that they do not violate the Namespace’s ResourceQuota, and if so, reduce the resources requested to appropriate levels.
Logging and Auditing
Robust Kubernetes security requires the ability to audit all activity in a Kubernetes cluster. Kubernetes provides built-in auditing capabilities that allow you to monitor actions taken within your cluster – for example, actions by users, the control plane, and applications. You can also determine the location of audit event logs. The logging backend logs each event to the cluster’s local file system, and the webhook backend forwards the audit events to a third-party logging system.
Conclusion
In this article, I explained the basics of zero trust and provided a few best practices that can help you implement this innovative security model in your Kubernetes environment:
- Implement Kubernetes authentication – ensure that any requests to the Kubernetes API server use strong authentication.
- Authorization – implement RBAC to apply the least privilege principle across your Kubernetes cluster.
- Admission control – build custom logic to control sensitive operations on Kubernetes objects.
- Logging and auditing – ensure you have an audit trail of all activities in your cluster, preferably storing log information in a secure external system.
I hope this will be useful as you transition your containerized environment to a zero trust security model.
