“A service mesh can be an essential element in securing a Kubernetes cluster by providing a management layer with zero-trust principles in place.”

Earlier this year, the White House issued an Executive Order on Improving National Cybersecurity to lay the foundation for a Zero Trust architecture for federal agencies. Additionally, the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) jointly published Kubernetes Hardening Guidance, which outlines key Zero Trust security principles best practices for Kubernetes.

Such documents highlight the need for organizations and developers to rethink how they secure applications and infrastructure. Above all, given the changing security requirements driven by the adoption of cloud infrastructure, it is important to understand the overall runtime process and how these principles apply across clouds and platforms, particularly Kubernetes clusters.

One of the core approaches recommended by the NSA guidelines is to use a service mesh in your Kubernetes environment to authorize, authenticate, and encrypt inter-service communication. So, let’s take a closer look at how an open source service mesh can enhance your security posture and promote zero-trust networking.

■ Zero Trust Security

Before we look at how a zero trust approach applies to Kubernetes, we need to look at the context of zero trust principles and why they are becoming important.

Securing infrastructure, data, and access is becoming increasingly complex and challenging in multi-cloud and on-premises data centers. As enterprises transition to multi-cloud and hybrid infrastructures, the measures they took to secure traditional private data centers are now outdated. IP-based identity and perimeter-based access are no longer relevant in a work environment where users are constantly accessing shared resources with constantly changing, transient IP addresses and working remotely.

To cope with this change, a different approach to security is needed: one that trusts nothing, including its own services and users, and authenticates and authorizes everything before granting access. The important thing is that the move to zero trust is not a binary approach, but an ongoing approach that requires a fundamental change in architecture. The following three best practices will help you understand the direction that the Zero Trust principles suggest.

1. Provide identity-based access and communication between services: Services should be based on service identities. Authentication should use service identities, not IP addresses. And services should mutually authenticate these identities when establishing a connection.

2. Secret and certificate management, including enhanced Kubernetes encryption: Secrets should be encrypted and time-bound, and should work with a global service identity that supports encryption of data in transit. Access credentials should be time-bound so that users or applications can refresh them at defined intervals.

3. Support observability with auditing and logging: All access attempts must be audited and logged.

■ Applying Zero Trust Principles to Kubernetes

As mentioned earlier, in a dynamic environment, perimeter-based security may not be a sufficient alternative, so there is a need to reduce the reliance on network perimeter control. Enterprises can take the following steps to implement zero trust principles in their Kubernetes environments:

1. Providing access and communication between identity-based services

Every Kubernetes cluster provides a flat network that allows all containers and services to communicate with each other without restrictions. Kubernetes considers the container network and the applications running on it to be trusted and does not require authentication. For example, if a database service and a logging service are running on the same Kubernetes cluster, they are accessible to each other at the network level by default.

Users can create Kubernetes policies with default rules that deny both ingress and egress traffic from the cluster. However, even with these restrictions, authentication and authorization between services are still required to ensure that only the necessary resources are available to the services.

This problem can be solved by introducing a service mesh that can assign a service identity to each service running on a Kubernetes cluster. The mesh can authenticate service identities using mTLS based on service identities, and operators can define communication permissions between services by service name, allowing them to grant or block service access requests based on intents. With the service mesh running, the logging service can access the database service only if the two services have authenticated each other’s credentials.

2. Includes secret and certificate management and enhanced Kubernetes encryption.

Using Kubernetes control plane credentials for identity or secret management increases the attack surface, makes maintenance more difficult, and violates the principles outlined above. Kubernetes secrets have several weaknesses when it comes to zero-trust security architecture.

· By default, secrets are base-64 encoded and not encrypted.
· Secrets can be at risk because they do not expire (there is no time limit).
· Kubernetes can manage resources like Secrets only within the cluster boundaries. If you have a set of clusters, you need to manage resources used across multiple clusters separately.

A service mesh with a Secret Broker can solve this problem. For example, Kubernetes-based Consul integrates with HashiCorp’s Vault, a centralized secret management solution that can bridge the gap in Kubernetes Secrets.

The goal is to enable encryption of secrets at rest with centralized access control and auditing. The workflow should support both single Kubernetes cluster and federated multi-cluster deployments. It can also help operators strengthen their security posture by reducing the Time-to-Live (TTL) value of TLS certificates through automatic certificate rotation.

3. Supporting observability with auditing and logging

To improve Kubernetes security, it is important to understand what service access requests are being made within the cluster. Audit teams can examine event data through audit logs to determine what credentials were used, what actions were performed, and the timestamps associated with these transactions. This can greatly improve security team accountability and insight.

A service mesh deploys a sidecar proxy that can derive metrics along with each service running in the cluster, and maintains a record of all inter-service communications and access requests. Ideally, a service mesh would integrate with open source monitoring tools like Prometheus and Grafana to make it easier to analyze service networking patterns and harden security.

■ Conclusion

As service deployment environments become more complex with multiple Kubernetes clusters, multiple runtimes, multi-cloud and on-premises deployments, and diverse interconnections, compliance with zero-trust security principles is required.

A service mesh like HashiCorp’s Consul, which provides identity-based service networking for mutual authentication and authorization for all access, and supports a management layer that enforces zero-trust principles, will be an essential part of this process. Consul makes it easy to enforce granular security policies across Kubernetes and multiple environments without having to code all security parameters into the application itself, and quickly gets you on the road to an improved zero-trust security posture that’s easier to manage.

※ Author: Kim Jong-deok, CEO of HashiCorp Korea