Home / server / Questions / 1047254
Accepted
xpepermint
Asked: 2020-12-23 13:32:56 +0800 CST

SECURITY: Should containers run TLS or can they rely on its sidecar?

  • 772

I wonder how security experts think about making container traffic secure. Let's take a simple K8S cluster as an example.

I guess we all agree that running HTTPS instead of HTTP within each container is more secure. I would normally configure a TLS on Ingress and then route to an internal container will TLS configured as well.

Modern mashing solutions usually install proxy sidecar - let's take Linkerd2 for a concrete example. Ingress will upgrade all incoming traffic to TLS, it will then use Linkerd's TLS to forward traffic to the sidecar proxy. Everything transmitted until here is TLS and secured. 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?

security kubernetes containers

1 Answers

  1. Best Answer

    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.

    • 9