Zero Trust Network

Zero Trust Network: Why It’s Important and Implementing Zero Trust for K8s

What Is a Zero Trust Network (ZTN)?

A Zero Trust Network (ZTN) is a network that operates according to the zero trust security model. This requires strong authentication for users and devices trying to access resources from inside and outside the private network.

Traditional network security is based on the concept of a protected network perimeter, which is difficult to access from the outside but implicitly trusts everything inside. The problem with this approach is that once an attacker gains access to the network, they can move freely within the network and elevate privileges to gain access to sensitive assets.

In today’s IT environment, with data and systems distributed between on-premises data centers and public clouds, and employees often working from remote locations, traditional network security models are no longer relevant. A network perimeter approach cannot achieve consistent security controls in a modern IT environment.

Moving to a zero-trust security model means that no one inside or outside the network can be trusted. ZTN solutions continuously ensure that each user and device has access to only the specific resources they need. When authorizing requests, these solutions are sensitive to the time, place and nature of their activity. They can immediately detect unusual access attempts, block them, and alert security teams.

In this article:

The Importance of a Zero Trust Network Model

Zero trust networking is an important part of the modern security puzzle, focusing on securing internal application traffic. It replaces the traditional assumption that traffic behind a firewall can be implicitly trusted, replacing it with the assertion that no connection should be trusted until proven to be safe.

The Network Perimeter is Dead

Traditionally, network administrators trusted every entity within the internal network—applications, servers, network software or hardware. Many applications did not require client authentication, and were not encrypted, even for sensitive services. Many systems relied on static shared credentials. For example, database passwords were often trivial to guess and shared freely within the corporate network—under the assumption that attackers were outside of the secure network perimeter.

Many corporate networks still follow this pattern. However, it is now understood that threat actors can easily penetrate a network environment, either by compromising credentials of trusted entities, infecting the network with malware that deploys a Trojan or backdoor, or exploiting vulnerabilities in software or hardware. Through these and other attack vectors, threat actors can perform sniffing of network packets to detect application passwords, and compromise databases, servers, and network devices, leading to catastrophic data breaches.

Related content: Read our guide to zero trust architecture

Network Security by Default

The zero trust model enables a production infrastructure that is secure by default. ZTN systems go beyond not trusting client connections—they also verify that the network fabric itself is secure from compromise.

The zero trust network model is not a standard network implementation—it describes a set of principles and goals and leaves the specific technical details of implementation to each organization or solution provider. However, all ZTN solutions have these common features:

  • Never trust / always verify – Access to any network resource is not based on one-time identification and authentication, but rather on continuous evaluation of multiple criteria such as the user’s identity, device health, geographic location, and time of access.
  • Least privilege access – In a zero trust network, user access is restricted to authorized users, with a strict least privilege access model. Access rights can be defined using a variety of role-based and behavioral criteria, and can be limited based on dynamic risk analysis.
  • Reduce blast radius of successful attacks – Zero trust networks perform microsegmentation to create small trust boundaries around protected resources. They analyze user, device, and request attitudes before providing access to a network segment. This means that when a breach occurs, the attacker’s ability to perform lateral movement is severely limited.

Related content: Read our guide to zero trust security

Zero Trust Networks with Containers and Kubernetes

Organizations can apply zero trust principles to containerized environments by building on their traditional network security strategy and adding internal security mechanisms to the network perimeter. A combination of firewalls and client-based zero trust security measures can help secure internal network communication between microservices and containers.

6 Keys to Implementing Zero Trust in a Containerized Environment

In this context, implementing zero trust involves the following principles:

  1. Internal access control – There must not be implicit trust between different containers, only authenticated inter-service access. This mandatory authentication prevents hackers from moving laterally between different containers within the same cluster, insulating the compromised system and limiting the attack’s blast radius.
  2. Authorization certificates – Every server must demonstrate a root of trust using a local authentication certificate in the hardware TPM. These authenticate administrator access requests and help secure configuration or code changes. If the entity initiating a system update or application is not an authorized administrator, the system rejects the request.
  3. Hashing – The local server certificate allows the system to hash any code or infrastructure change cryptographically. Logs provide immutable records for compliance and troubleshooting purposes.
  4. Virtualization – The system should sandbox all containers that share an operating system using virtual networks or VMs.
  5. Encryption – Inter-service and inter-container communication must be encrypted using the TPM and local certificate to avoid implicit trust based on the local IP address.
  6. Management – A service like identity and access management (IAM) or public key infrastructure (PKI) helps organizations manage their security policies centrally. These tools are important for keeping track of security in a complex network with many objects (i.e., users, 2FA integrations, role-based access control (RBAC) policies, machine, code, and user certificates).

These zero trust principles and control measures collectively allow organizations to secure their containerized applications in the cloud. They restrict the communication between microservices and containers to prevent any transaction not explicitly authorized.

Adapting Kubernetes to Zero Trust

As a popular container orchestration solution, Kubernetes offers flexibility, scalability, and automation, helping organizations manage their secrets. However, using Kubernetes does not automatically imply a zero trust security model.

Implementing a zero trust approach in Kubernetes requires special configurations and practices. For example:

  • Identifying all the resources in a deployment.
  • Authenticating every request.
  • Applying the principle of least privilege.
  • Authenticating every workload just-in-time.
  • Removing privileges when their usefulness expires.
  • Continuously monitoring, controlling, and auditing all network activity.

Organizations can apply these practices to all users, programs, and access requests, ensuring a robust Kubernetes security posture. Controlling access to each Kubernetes pod also helps prevent internal or external attacks.

Zero Trust Security with Calico

Calico Enterprise and Calico Cloud enable a zero trust environment built on three core capabilities: encryption, least privilege access controls, and identity-aware microsegmentation.

  • Encryption – Calico utilizes WireGuard to implement data-in-transit encryption. WireGuard runs as a module inside the Linux kernel and provides better performance and lower CPU utilization than IPsec and OpenVPN tunneling protocols. Calico supports WireGuard for self-managed environments such as AWS, Azure, and Openshift, and managed services such as EKS and AKS.
  • Least privilege access controls – Calico implements least privilege access controls by denying all network traffic by default and only allowing connections that have been authorized. This applies to traffic between microservices as well as ingress and egress outside the cluster. Calico also integrates with native Kubernetes RBAC to provide authorization and authentication for various users and teams.
  • Identity-aware microsegmentation – Calico leverages its cloud-native model to divide workloads into smaller security segments and then applies security policies for these segments. This prevents lateral movement of threats by reducing and minimizing the attack surface.

Next steps:

Join our mailing list​

Get updates on blog posts, workshops, certification programs, new releases, and more!