External access to applications

Conceptual models for external access

From an OpenShift point of view there are three progressively “more external” layers:

1. In-cluster access
• Pods talk to each other via ClusterIP Services and the cluster network.
• Already covered in the general networking chapter.
2. Cluster edge access
• Traffic reaches the OpenShift ingress routers (implemented via the OpenShift Router / Ingress Controller running as pods).
• This is where Route and Ingress objects are consumed.
3. Outside the cluster / Internet access
• DNS records, public / corporate load balancers, firewalls, and NAT devices direct traffic to the cluster ingress endpoints.
• This is mostly infrastructure outside OpenShift, but OpenShift exposes the endpoints and certificates that these components use.

“External access to applications” is about how you move from layer 1 to 3 in a controlled, secure, and manageable way.

Main mechanisms for external access

NodePort and LoadBalancer Services

While the “Services and service discovery” chapter explains the basic Service types, here the focus is on when and why they are used specifically for external access.

NodePort

A NodePort Service:

• Opens the same TCP/UDP port on every node in the cluster.
• Forwards traffic from nodeIP:nodePort to the backend pods selected by the Service.
• Can be reached from:
• Inside the cluster (like a normal Service).
• Outside, if your network/firewall routes to node IPs and allows the port.

Typical characteristics:

• Pros
• Simple; works in almost any environment.
• No cloud-specific integration required.
• Cons
• Fixed port range; often not standard HTTP(S) ports.
• You must manage external load balancing, DNS, and firewall rules yourself.
• Exposes every node as an ingress point (not always desirable).

NodePort is usually used for:

• Internal corporate access where you have existing load balancers and want to terminate traffic at node IPs.
• Low-level or debugging access (e.g., testing a Service before exposing via Route).

LoadBalancer

In cloud or integrated environments, a LoadBalancer Service:

• Asks the underlying infrastructure (e.g., AWS ELB, Azure LB, on-prem LB integration) to provision an external load balancer.
• Obtains an externally reachable IP (and sometimes a DNS name).
• Balances traffic across node ports that back the Service.

Characteristics:

• Pros
• Simple, direct external access: one external IP (or hostname), one port.
• Integrates with cloud infrastructure; often supports health checks.
• Cons
• Ties you to underlying platform features and costs.
• Each LoadBalancer may create a separate external LB (cost/quotas).
• Does not include HTTP routing by hostname/path (L4, not L7, unless the LB is L7 aware and configured accordingly).

In OpenShift, LoadBalancer Services are commonly used for:

• Cluster-level components (e.g., API, ingress controller exposure).
• Workloads that need raw TCP/UDP access (databases, message brokers) without HTTP routing.

In many OpenShift deployments, application-level external HTTP(S) access is not done by creating a LoadBalancer per app, but by using Routes and Ingress behind shared ingress controllers.

HTTP(S) external access with Routes

Role of the OpenShift Router / Ingress Controller

OpenShift deploys router pods (Ingress Controllers):

• Typically as a DaemonSet or Deployment in an infrastructure namespace.
• Listening on HTTP and HTTPS ports (usually 80 and 443) on selected nodes.
• Acting as a reverse proxy and load balancer (based on HAProxy or other implementations, depending on OpenShift version).

These routers:

• Terminate incoming connections.
• Decide which Service to route to based on hostname and path.
• Use Route and/or Ingress objects to build their configuration.

External traffic must first reach these routers (via NodePorts, LoadBalancer, or external L4 load balancers); once there, the router uses OpenShift network primitives to reach the application pods.

Route basics in the context of external access

A Route:

• Associates a host (e.g., myapp.apps.example.com) and optionally a path (e.g., /api) with a Service.
• Is consumed by the router which:
• Listens on the public interface.
• Accepts HTTP(S) traffic for that host/path.
• Sends it to the backend Service and ultimately to pods.

Routes are the primary mechanism OpenShift provides to expose HTTP(S) services externally in a cluster-agnostic, OpenShift-specific way.

Key aspects concerning external access:

• Hostnames
  You can:
• Let OpenShift generate a host under the cluster’s default wildcard (e.g., myapp-myproj.apps.cluster.example.com).
• Or specify a custom hostname that you later map via DNS to your cluster’s ingress endpoint(s).
• Paths
  Multiple routes with different paths can share the same hostname, allowing path-based routing (e.g., /api vs /ui).
• TLS configuration
  Routes define how TLS is terminated and validated, which is critical when exposing applications to the internet.

Route TLS termination and external traffic

External access is not just about connectivity; it also involves encryption and trust. Routes support several TLS termination modes:

1. Edge termination
• TLS is terminated at the router (ingress).
• Browser ↔ Router: HTTPS
• Router ↔ Application: HTTP (inside the cluster).
• Certificates live on the router (provided via the Route or operator configuration).

Suitable for:

• Most web apps where internal traffic is trusted network-wise.
• Simpler certificate management at the cluster edge.

2. Passthrough termination
• Router does not terminate TLS; it passes encrypted bytes through.
• Browser ↔ Application pod: end-to-end TLS (router just forwards TCP).
• Application must present the certificate; hostname must match the SNI.

Suitable for:

• Applications that need full control over TLS (e.g., custom protocols over TLS).
• Scenarios requiring client certificate handling at the app.

3. Re-encrypt termination
• Router terminates TLS from the client and establishes a new TLS connection to the backend.
• Browser ↔ Router: HTTPS (public certificate).
• Router ↔ Application: HTTPS (internal certificate; may be different CA).

Suitable for:

• Compliance requirements where all hops must be encrypted.
• Situations where app uses internal PKI different from public-facing cert.

Considerations for external access:

• Trusted certificates
  Public-facing Routes should typically use certificates from a CA trusted by end users (or corporate trust stores). This often involves:
• Custom certificates on specific Routes.
• Wildcard certificates for the cluster’s application domain.
• Redirects and HSTS
  For internet-facing applications, you might enforce HTTPS:
• HTTP → HTTPS redirects at the router.
• HSTS headers set by the application itself.

Securing external access at the Route layer

While general security (RBAC, SCCs, network policies) is covered elsewhere, Route-specific considerations include:

• Limiting exposure
• Only create Routes for Services that must be reachable from outside.
• Use separate projects / namespaces to isolate externally exposed apps.
• Hostname control
• Use predictable hostnames for production (e.g., api.example.com, app.example.com).
• Avoid exposing internal or descriptive hostnames that leak environment details.
• Route annotations and policies
  Depending on the router implementation and version, you can:
• Restrict TLS versions and ciphers.
• Configure custom timeouts, limits, and headers (e.g., for security headers or proxy behavior).
• Enable or disable HTTP/2 where relevant.
• Access control behind the router
  For applications not meant for the internet:
• Place the router on internal-only networks.
• Use firewall rules or IP allowlists with annotations (if supported) or external infrastructure.

Using Kubernetes Ingress with OpenShift

While Route is an OpenShift-specific resource, OpenShift also supports Kubernetes Ingress.

From an external access perspective:

• The same ingress controllers can watch both Route and Ingress objects.
• Ingress allows you to:
• Use upstream Kubernetes primitives and tooling.
• More easily port manifests between vanilla Kubernetes and OpenShift.

Considerations:

• Feature coverage between Route and Ingress is not identical; some advanced OpenShift features (such as specific TLS options or route sharding) may be easier via Routes.
• For teams with existing Kubernetes manifests, using Ingress can reduce duplication when targeting multiple platforms.

When deciding between Route and Ingress for external access:

• Use Routes when:
• You are targeting OpenShift specifically.
• You want first-class support and integrations with OpenShift features.
• Use Ingress when:
• You maintain cross-platform manifests.
• Your organization standardizes on Kubernetes-native objects.

DNS and external entry points

DNS configuration patterns

DNS is managed outside OpenShift but is critical to making Routes and LoadBalancer addresses usable:

1. Wildcard DNS for app domain
   Example:
• *.apps.example.com → resolves to one or more ingress endpoints (IP(s) of the OpenShift routers / external LB).
• OpenShift-generated and custom Routes under *.apps.example.com become reachable without per-host DNS records.
2. Individual DNS records
   Example:
• myapp.example.com → ingress endpoint.
• You then define a Route myapp.example.com pointing to the Service.
3. Split-horizon DNS
• Internal users resolve to internal ingress IPs.
• External users resolve to public ingress IPs or a different cluster.
• Useful for internal-only vs internet-facing variants.

From the application’s perspective, external access generally assumes DNS is correctly configured to map hostnames used in Routes/Ingress objects to the relevant ingress IPs or load balancer DNS names.

External load balancers and firewalls

Often, there is an external load balancer (hardware or cloud-based) in front of OpenShift routers:

• Balances traffic across multiple router pods / nodes.
• May perform:
• TCP or HTTP termination.
• Global traffic management (multiple clusters, regions).
• Web Application Firewall (WAF) policies.

For external access design, you need to consider:

• Port exposure: Typically 80/443; ensure firewalls and security groups allow this.
• Health checks: External LBs often perform HTTP or TCP health checks against routers.
• TLS termination location:
• Terminate at the external LB (then forward HTTP or TLS to routers).
• Or pass TLS through to routers for OpenShift-managed certificates.

OpenShift itself does not configure external LBs or firewalls, but exposes:

• Node IPs / NodePorts.
• LoadBalancer Service front-ends.
• Ingress Controller status (e.g., external IPs).

These are then consumed by infrastructure teams when configuring external access.

Common external access patterns

Simple public web application

Characteristics:

• HTTP(S) web app, stateless or simple session handling.
• Needs a public URL.

Typical pattern:

1. Cluster has a default *.apps.example.com wildcard DNS pointing at its ingress.
2. Developer:
• Creates a Service for the app.
• Creates a Route myshop.apps.example.com to that Service, with edge or re-encrypt TLS.
3. No additional DNS records required, as hostname is under the wildcard.

Corporate-internal application

Characteristics:

• Only accessible from internal network or VPN.
• May still use HTTPS with internal CA.

Pattern:

• Routers are exposed only on internal IP ranges / load balancers.
• DNS names (e.g., hr-app.corp.local) resolve only on internal DNS.
• Routes use internal hostnames and internal PKI certificates.

Custom domain with public DNS and certificates

Characteristics:

• Application must be reachable under organization’s primary domain, e.g., app.example.com.

Pattern:

1. Infrastructure team configures:
• app.example.com → external load balancer fronting OpenShift routers.
2. Developer:
• Creates a Route app.example.com with appropriate TLS cert (possibly a certificate provided by infra/security team).
3. Application is reachable via the custom domain, independently of cluster-generated hosts.

Non-HTTP/TCP services

Some workloads need external access for protocols like:

• Databases (PostgreSQL, MySQL).
• Message queues (AMQP, Kafka).
• Custom TCP/UDP protocols.

These are typically not exposed via Routes, but via:

• LoadBalancer Services (cloud environments).
• NodePort + external L4 load balancers.
• Tunnels or VPNs for administrative access.

Considerations:

• Carefully restrict who can reach these services.
• Use TLS and authentication at the application level.
• Avoid exposing stateful backends directly to the internet unless necessary.

Operational considerations for external access

Environments and lifecycle

External exposure strategy often differs by environment:

• Development
• Use automatically generated hostnames (e.g., myapp-dev.apps.cluster.local).
• Often no strict certificate requirements; self-signed or cluster-issued certs may be acceptable.
• Staging / pre-production
• Mirror production URLs where possible (e.g., staging-app.example.com).
• Use real certificates to test browser behaviors and integrations.
• Production
• Strict URL and certificate management.
• Monitoring and logging of external access patterns.
• WAF, DDoS protection, and rate limiting potentially in front of OpenShift.

Automation and GitOps

For large environments:

• Treat external access configuration (Routes, Ingress, Services) as code:
• Store manifests in Git.
• Apply via CI/CD or GitOps tools (e.g., Argo CD).
• Ensure:
• Changes to hostnames and TLS certs are traceable and auditable.
• Rollbacks are possible if an external exposure misconfiguration occurs.

Auditing and compliance aspects

From an audit/compliance perspective, external access raises questions like:

• Which namespaces and applications are externally reachable?
• Under which hostnames and certificates?
• How is traffic encrypted and where is TLS terminated?
• Are there security policies (e.g., WAF, rate limiting) at the edge?

Maintaining an inventory of:

• All Routes/Ingresses and their hosts.
• Corresponding DNS records and certificates.
• External load balancer configurations.

is a common operational practice for regulated environments.

Summary

External access to applications in OpenShift is primarily about:

• Choosing the right Service type (NodePort, LoadBalancer) and external load balancer configuration.
• Using Routes or Ingress to provide HTTP(S) access with hostnames and TLS policies.
• Coordinating with DNS and external network infrastructure to make applications reachable under the desired domains.
• Applying appropriate security, certificate, and operational practices at the cluster edge.

The combination of these elements lets you expose only the right applications, in the right way, to the right users, while keeping the rest of the cluster safely internal.