Implementing Zero-Trust Security With Service Mesh and Kubernetes
IBM’s recent Cost of a Data Breach report revealed that data breaches cost companies an average of $4.35 million in 2022, up 12.7% from 2020. This report also noted that 79% of critical infrastructure organizations didn’t deploy a zero-trust architecture. And in Hashicorp’s 2022 State of Cloud Strategy survey, 89% of respondents said security is important or very important to cloud success.
Securing infrastructure, data and access across different clouds and on-premises data centers is becoming more complex and challenging. The perimeter-based security precautions enterprises employed to protect their proprietary data centers become outmoded when they transitioned to multi-cloud and hybrid architectures. This traditional security model assumed the goal is to prevent attack from outside the perimeter. However, in modern hybrid environments where remote workforces need constant access to shared resources, the perimeter is dynamic and ephemeral; attacks may come from anywhere, inside or outside the network. That means IP-based identity and perimeter-based access controls may no longer be effective.
As the threat landscape evolves, organizations are increasingly turning to a zero-trust security approach. But what does zero-trust security really mean, and how do you move toward it?
To answer that question, we’ll explain what zero-trust security is and discuss six identity and access management (IAM) best practices to be applied across your runtimes, clouds and platforms. And we’ll take a closer look at applying a service mesh to bring zero-trust security to Kubernetes clusters.
What Is Zero-Trust Security?
Zero-trust security (ZTS) is a new approach to IT security that moves past the assumption that endpoints and networks are inherently trustworthy. Instead, ZTS assumes that every endpoint and network connection is malicious. ZTS requires every user and device to authenticate themselves prior to receiving access to any infrastructure or application. ZTS also requires every endpoint to access an application or service only via an encrypted channel and only after successful authentication. In other words, every user, endpoint and connection must be authenticated and authorized before being granted access.
This is the opposite of traditional security models, where access is granted based on who the user is or where the connection is coming from. This is why we need to rethink how we approach cybersecurity and adopt a zero-trust mindset to ensure that we are protecting our data, systems and users from any possible attack vector.
Implementing Zero-Trust Security in Your Organization
The move to zero-trust is not binary; it’s never fully completed. Instead, ZTS is an ongoing approach that requires a fundamental shift to your architecture and your thinking. Fortunately, these six best practices and zero-trust principles can help point the way:
1. Every Interaction Must Be Authorized and Authenticated by a Trusted Identity Source
Traditional approaches to security require static IP addresses. But that approach breaks down with dynamic IPs, ephemeral infrastructure and multi-cloud deployments that transcend physical perimeters.
The only constant in this multi-cloud world is identity. When every action is authenticated and authorized by a trusted identity source, administrators can be more confident that they are allowing the right level of access and information sharing for each interaction.
2. Each Service-to-Service Interaction Must be Mutually Authenticated
Each service must be verified to be the service it claims to be. Mutual authentication (with TLS and client x509 certificates) prevents communication from unauthorized access to network components within the cluster.
3. Service-to-Service Interaction Must Be Authorized
As the number of microservices in your enterprise continues to grow, ensuring services interact only with authorized services—rather than all services by default—helps limit the attack surface available to hackers.
4. Access Must be Time-Bound
Service-to-service interactions must be protected with time-bound access. After a given period of time—say a few hours—valid credentials for access expire, terminating a request for connection. This limits the danger presented by leaked credentials.
5. Service-to-Service Traffic Must be Encrypted in Transit
Data transmissions between services must be encrypted in transit, ideally with TLS encryption. This is a best practice for modern security and protects against man-in-the-middle attacks.
6. Every Interaction Must be Logged and Audited
Every interaction between applications, networks and humans should be logged to a central database. This simplifies audits and accelerates troubleshooting during incidents.
Zero-Trust Security in Kubernetes Environments
To achieve a strong zero-trust security posture, organizations need to apply these principles to all human-to-machine and machine-to-machine access and communication. Bringing zero-trust security to Kubernetes environments, in particular, can benefit from these best practices.
A service mesh is one of the simplest ways to enable zero-trust security in Kubernetes. A service mesh allows you to assign service identities to each service running on the Kubernetes cluster. Based on service identity, the mesh can authenticate service identities using mTLS, and service-access requests can be authorized or blocked using intentions, which allow operators to define service-to-service communication permissions by service name. For example, with a service mesh in place, the logging service can access the database service only if both services can mutually authenticate their credentials.
Using credentials for the Kubernetes control plane, whether for managing identities or secrets, increases the attack surface, is difficult to manage and goes against the principles of zero-trust security. Kubernetes secrets have particular weaknesses from the zero-trust point of view: they’re base-64 encoded by default, not encrypted and they are not time-limited so they don’t expire.
This challenge can be addressed with a service mesh and a secrets broker. The goal is to ensure that secrets are encrypted at rest with centralized access control and auditing. The workflow should support both single Kubernetes clusters and federated multicluster deployments. In addition, certificate autorotation can help operators reduce the time-to-live (TTL) values of their TLS certificates, strengthening their security posture.
To further strengthen Kubernetes security, it’s critical to understand what’s happening inside the cluster and monitor any service-access requests. Security teams should examine event data in audit logs to determine whose credentials have been used, what actions have been performed and the timestamps related to these transactions.
With each service running in the cluster, a service mesh deploys sidecar proxies that can output metrics and log all communication and access requests between services. An ideal integration between the service mesh and open source monitoring tools like Prometheus and Grafana would facilitate the analysis of service-networking trends and improve security.
Zero-Trust Security Principles and Service Mesh for Kubernetes
Facing the ongoing rise of cybercrime and a constant stream of data breaches, the case for adopting a zero-trust security model is clear. Organizations must design their security architecture with the mindset that every user authenticates themselves, every endpoint authenticates itself and every connection between endpoints and services is encrypted.
To achieve this level of security, organizations must integrate the core principles of identity and access management into their security model. And in Kubernetes environments, specifically, implementing a service mesh can help organizations get close to zero-trust.
