Default to TLS for performance-insensitive additional services¶
- Status: accepted
- Deciders: arch meeting
- Date: 2022-02-16
Context and Problem Statement¶
We run additional services in the Workload Cluster, currently databases (PostgreSQL), in-memory caches (Redis) and message queues (RabbitMQ). Traditionally, when these services are provided as managed services, they are exposed via a TLS-encrypted endpoint. See examples for:
In Compliant Kubernetes, the network is assumed trusted, either because we performed a provider audit or because we enabled Pod-to-Pod encryption via WireGuard. Hence, TLS does not improve data security.
How should we expose additional services in Compliant Kubernetes? With or without TLS?
- We want to stick to best practices and sane defaults.
- We want to make it easy to port applications to Compliant Kubernetes and its additional services.
- Some services are performance-sensitive: Redis suffers a significant performance drop with TLS.
- The Spotahome Redis Operator does not support TLS.
- Some services are performance-insensitive: PostgreSQL and RabbitMQ feature negligible performance impact with TLS.
- Always disable TLS, since the network in Compliant Kubernetes is trusted.
- Always enable TLS.
- By default, enable TLS for performance-insensitive services and disable TLS for performance-sensitive services. Allow TLS to be disabled if the user requests it.
Chosen option: "By default, enable TLS for performance-insensitive services and disable TLS for performance-sensitive services. Allow TLS to be disabled if the user requests it."
- Never enable TLS for Redis: Performance impact is huge and the network is already trusted. Furthermore, the Spotahome Redis Operator does not support TLS.
- Enable TLS by default for PostgreSQL and RabbitMQ: Performance impact is negligible and most application are already configured for it.
- Allow TLS to be disabled if requested for PostgreSQL and RabbitMQ.