Building cloud-native software requires multiple solutions at different stages of the software development lifecycle. Deploying the software and maintaining its security become an essential part. Software development evolved over time and recent trends are Microservices, that is a software development technique architectural style that structures an application as a collection of loosely coupled services. To host the software in the cloud with a cost-effective scalable and reliable way cloud infrastructure another tooling like virtualization also evolved. The Container technology comes that is a standardized unit of software that packages up the code and all its dependencies so the application runs quickly and reliably from one computing environment to another. Then the orchestrate those containers and scale container-based workloads challenges are approached many ways like docker compose, Apache Mesos, nomad, Kubernetes(k8s).
After forming The Cloud Native Computing Foundation(CNCF) in 2015 to promote containers, Kubernetes(k8s) 1.0 was announced as container cluster manager and become hugely popular. Now the almost all cloud providers AWS, Azure, Google Cloud adopted it as the default way to orchestrate and scale their container-based workloads. However, any new and rapidly developing technology, questions remain around how best to secure those Kubernetes deployments.
CNCF Cloud Native Definition - "Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.”-https://github.com/cncf/toc/blob/master/DEFINITION.md
Kubernetes Vulnerabilities and Attack Vectors
An Attacker can use application misconfiguration or vulnerability to get into a container and take control of the process, network, or file system. Then the compromised containers can attempt to connect with other running pods on the same cluster. An attacker can do data exfiltration from a pod, also by combining of techniques the attacker can get a reverse shell from the pod, and lateral movement to other pods and the hosted nodes. If the k8s cluster does not setup keep in mind these items the cluster remains in risk.
“A Kubernetes pod is a group of containers that are deployed together on the same host.”
Increasing Security with a Service Mesh
In the computing world, everything is evolving too fast, Microservices architecture also not stopped just after setting new trends it evolving a lot during the last couple of years and the ‘Service Mesh’ concept is born. ‘Service Mesh’ addresses the challenges developers and operators face as monolithic applications transition towards a distributed microservice architecture. While the developers building microservices to architect for portability, the operators who are responsible for managing extremely large polyglot and multi-cloud deployments ‘Service Mesh’ comes to rescue and that offer a "Layer 7 network" exclusively for applications.
linked, Consul, Istio are some of ‘Service Mesh’ implementation gives observability, reliability, and security for microservices. Those have advanced routing capability, Both Ingress and egress traffic rule, automatically negotiate Transport Layer Security (TLS) for application communication moreover CNI plugin that rewrites each pod's iptables rules automatically. Out of the box Retries and Timeouts, Telemetry and Monitoring become possible.
CNI (Container Network Interface)- “The Container Network Interface (CNI) is a library definition, consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, under the umbrella of the Cloud Native Computing Foundation project.”
The high-level security architecture of istio service mesh
Security needs like protecting against the man-in-the-middle attack by traffic encryption, flexible service access control, and service to service mutual TLS and fine-grained access policies are implemented in istio with the zero-trust networking model.
Istio Security Architecture
Istio Service Mesh offers mutual TLS as a full stack solution for transport authentication. By choosing the implementation of Service mesh it is possible to mitigate man-in-the-middle attacks. By default, Kubernetes does not have any egress rule, So that not preventing from creating any outbound connection from a compromise pod, But in istio no outbound connection can be done outside mesh unless that is explicitly allowed by a ServiceEntry.
Other common threat like the rapid rate to exfiltrate data/DoS are mitigated by authorization and traffic control. Rich network policy with Rate Limiting, Circuit Breaking and Whitelisting/Blacklisting enforced via mixer can shut down traffic that exceeds that exhibited in normal operation.
Summary
Even if after done hardened Kubernetes cluster and other cloud infrastructure we need to take steps to mitigate against supply-chain attacks in our Continuous Integration/Continuous Deployment (CI/CD) pipeline. Application vulnerability or 0day from third party library can give an external attacker control of a container or host. It is better to assume this is going to happen, and the infrastructure needs to design for it.
Getting authentication, encryption and access control features from infrastructure (Service Mesh) enable to limit the damage and protect the organization’s valuable assets from compromise and exfiltration. The service mesh design allows this without modifying the application code.