Problem Statement:
Currently, mTLS is enabled by directly mounting certificates into the main container. This requires changes or dependencies in the main application for certificate handling and TLS termination. Many legacy or third-party applications cannot be modified easily, which makes adoption harder.
Solution:
Introduce a sidecar mode where mTLS is handled by injecting an Envoy sidecar container.
- The sidecar will manage certificate lifecycle, TLS termination, and secure communication.
- The main container will communicate with Envoy over plain HTTP (localhost).
- Envoy will transparently handle inbound and outbound TLS with mTLS enforcement.
Benefits:
- No changes needed in the main container/application code.
- Works seamlessly with legacy or black-box workloads.
- Aligns with common service mesh practices (e.g., Istio, Linkerd).
Additional context
- The operator can expose a toggle in the CRD or annotation (e.g., auto-mtls.kupher.io/mode=sidecar) to enable Envoy injection.
- Certificates can still be provisioned via cert-manager and mounted into the Envoy container.
- This feature will make the solution more flexible and usable for a wider range of workloads.
Problem Statement:
Currently, mTLS is enabled by directly mounting certificates into the main container. This requires changes or dependencies in the main application for certificate handling and TLS termination. Many legacy or third-party applications cannot be modified easily, which makes adoption harder.
Solution:
Introduce a sidecar mode where mTLS is handled by injecting an Envoy sidecar container.
Benefits:
Additional context