SECURITY: Should containers run TLS or can they rely on its sidecar?
In environments where you want a high level of security for Kubernetes clusters it is now common to apply principles from Zero Trust Networking. For the networking in a Kubernetes cluster this typically means:
- Encrypt all network traffic
- Use authentication for all network traffic
- Granular firewall rules - applied for micro segmentation around each app
- Least Privileges access control using RBAC, Service Accounts, JWT and OpenPolicyAgent
The two first points is now usually solved with a Service Mesh product, like Linkerd, Istio and the cloud providers offer managed solutions like AWS App Mesh. These products apply encryption between each Pod in the form of TLS, but also authentication using client certificates and mutual TLS, mTLS in an automated fashion. The Service Mesh usually has a control plane part that is responsible for e.g. rotation of certificates with automation.
The third point is usually done using Kubernetes Network Policies to get dynamic, but granular firewall rules applied to each app instance (Pod) even if it can dynamically be scheduled to different nodes in the cluster. These policies is usually declared in a higher level using e.g. Pod labels instead of hard coded IP addresses.
I wonder, now that a secured traffic "already reached" the pod, should a container use TLS as well, or is it safe enough to communicate with the sidecar without TLS? I'd like to hear the security aspect between the container and its sidecar. Should a sidecar be treated as a stand-alone container and thus the communication with a container should also be TLS secured?
Pods are the units of scheduling in Kubernetes, they are tightly coupled containers - always scheduled together. The containers within a Pod share some resources like linux namespaces, filesystem volumes and cgroups:
The shared context of a Pod is a set of Linux namespaces, cgroups, and potentially other facets of isolation.
In addition the containers in a Pod share the network identity, the IP address, and use localhost to communicate within the Pod. I would consider trust within the Pod, but you should apply granular Kubernetes Network Policies to lock down e.g. what ports the Pod can receive traffic on, and from what Pods.