The New Security Paradigm for Kubernetes and Istio
One of the great benefits of cloud-native technologies such as Kubernetes is the ability to expand and contract based on immediate resource requirements. The elasticity of Kubernetes allows the administrator to automatically provision more space based on expectations of a large load. Similarly, if more worker nodes located anywhere in the world are added to the cluster, Kubernetes can scale quickly and easily.
That flexibility, while very beneficial in terms of efficiency and resource utilization, creates challenges in different places, one of which is security. The new level of abstraction changes the security equation and the old paradigms of establishing perimeters around specific network areas become irrelevant.
Yesterday: Data center + application + data + firewall = security
Today: Cloud + orchestrator + microservice + ??? = security
Security in a cloud-native environment needs to focus on the software—the microservices and the data itself. The network and infrastructure security are becoming much less relevant, simply because the cloud provider has that responsibility and is generally doing a good job.
The most critical thing to ensure is that the right services are connecting to the right data without interference from unauthorized applications while not affecting the elasticity of the system.
Interactions between workloads and data need to be fully secured during every step of the process, from initial request to final disengagement, with broad coverage across different environments and technologies.
Cloud-native security requires a completely new approach than network segmentation and firewalls. You can either eliminate the firewall so everyone can access all Kubernetes or put a restrictive firewall around each Kubernetes workload, which kills the service itself.
Istio is simply a new way to apply the classic network firewall; instead of a network, it’s protecting a workload. Istio uses Kubernetes to identify workloads and then creates a personal firewall for every microservice. Across environments, Istio is bound to Kubernetes and only to one Kubernetes cluster. It does not protect local data or data stored in other managed services.
Also, early adopters of Istio report that they have been struggling with intrusiveness, installation complexity and slowness, and implementations actually require more hardware resources.
In a Kubernetes environment, microservices need to be protected on the network level by creating microservice-to-microservice authentication—a service mesh based on a zero-trust model to strengthen both workload and data security. The mesh needs to be structured in such a way as to deliver cryptographic software identity; seamless, secure communications tunneling; and transparent encryption.
The cryptographic software identity needs to be continuously verified throughout the entire execution session, bringing a better validation factor to the zero-trust equation. Only authenticated software components should be able to communicate with and access encrypted data, keeping data protected at rest, in transit and in use.
Resources need to be signed or encrypted to prevent unauthorized access. With cryptographic software identity, any attempt to hack the application, alter the application code or inject an unsigned code is identified, and the compromised application is excluded from the accessing data or communicating with other applications in the solution. Furthermore, seamless communication tunneling prevents communication eavesdropping as well as cryptographically ensures that only properly signed applications can communicate with each other.
The ideal data and workload security technology work across platforms and clusters so systems can be interconnected while maintaining simplicity and security.
You can build the exact cloud infrastructure you need without having to integrate and orchestrate multiple security solutions by creating seamless security across the entire system without interference.