Sign in Subscribe
Concepts

Openshift TLS Configuration Done Right

Andrios Robert

• 1 min read

The cluster was silent except for the hum of encrypted traffic. Every request flowed through layers of TLS, every packet inspected, every handshake verified. This is Openshift TLS configuration done right—fast, strict, and uncompromising.

TLS in Openshift is not optional. It is the backbone of secure communication between services, pods, and external clients. Correct configuration ensures data integrity, authentication, and resilience against man-in-the-middle attacks. Misconfiguration leaves gaps attackers exploit, so every setting matters.

Core TLS Configuration in Openshift

Openshift uses service-serving certificates and routes to handle TLS. The main components:

  • Cluster Certificates – Automatically managed by the Service CA operator for internal service traffic.
  • Ingress Certificates – Configured on Routes to expose applications securely to the outside world.
  • Custom Certificates – Replace auto-generated certs with your own trusted CA if compliance demands it.

For internal services, TLS is tied to Kubernetes secrets. To enable TLS in a Deployment:

  1. Generate server certificates and keys.
  2. Store them in a Kubernetes Secret.
  3. Mount the secret in your pod.
  4. Configure the application to use the mounted certs.

For external routes, Openshift offers multiple TLS termination options:

  • Edge Termination – TLS at the router, plain HTTP to your pods.
  • Passthrough – TLS directly to your pods, no router decryption.
  • Re-encrypt – TLS at the router, re-encrypted TLS to your pods.

Choose the right mode based on security and performance needs. Passthrough delivers end-to-end encryption but limits router inspection. Re-encrypt allows router-level policies with strong encryption to the backend.

Enforcing Strong Protocols and Ciphers

You can control TLS versions and cipher suites by customizing the Ingress Controller. Avoid weak ciphers and TLS 1.0/1.1. Always test configuration changes with tools like openssl s_client or automated scanners to ensure compliance and compatibility.

Automated Renewal and Rotation

Certificates expire. Openshift’s Service CA handles automatic renewal for internal services, but custom certs need manual renewal scripts or external automation. Make certificate rotation part of your deployment pipeline to avoid outages.

Common Pitfalls

  • Forgetting to update secrets after renewing certs.
  • Mixing TLS modes on the same hostname.
  • Allowing insecure fallbacks for legacy clients.

Secure-by-default should be the standard. Every Openshift TLS configuration should start with minimal attack surface—tight cipher lists, updated certs, and strict termination.

You have the tools. You have the control. Now make your cluster bulletproof.

See how secure TLS setup flows end-to-end on hoop.dev—deploy and watch it live in minutes.