OpenShift Secure Routes¶

Introduction¶

OpenShift Routes publish a Service through the cluster router. Route troubleshooting should confirm the route host, service target, endpoints, TLS termination mode, and router events.

Why This Matters¶

OpenShift adds security defaults such as SCCs, project isolation, and integrated OAuth/RBAC behavior. These protections are useful only when permissions are granted narrowly and verified.

Step-by-Step Configuration¶

oc get route web -n app

oc describe route web -n app

oc get service web -n app

oc get endpoints web -n app

curl -Ik https://web-app.apps.ocp.example.com

Example output:

NAME   HOST/PORT                         PATH   SERVICES   PORT   TERMINATION   WILDCARD
web    web-app.apps.ocp.example.com              web        8080   edge          None

Example YAML¶

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: web
spec:
  host: web-app.apps.ocp.example.com
  to:
    kind: Service
    name: web
  port:
    targetPort: 8080
  tls:
    termination: edge

Verification¶

oc get route web -n app

oc get endpoints web -n app

curl -Ik https://web-app.apps.ocp.example.com

Security Best Practices¶

Grant the smallest role or SCC that works, prefer service-account-specific access, keep secrets out of Git, and verify permissions with oc auth can-i.

Common Mistakes¶

• Debugging the route before checking service endpoints.
• Using edge TLS when the backend expects passthrough TLS.
• Forgetting that route hostnames must be unique unless wildcard policy is configured.

Troubleshooting¶

Compare the failing user or service account with the role binding, SCC admission error, project quota, or OAuth status shown in OpenShift events.

Related Guides¶

• Openshift Security Context Constraints Explained
• Openshift RBAC Security Explained
• Openshift Security Checklist

Summary¶

OpenShift Secure Routes is safest when permissions are explicit, namespace-scoped where possible, and validated from the same identity that runs the workload.