Accessing from External Networks
Objective
Expose and secure applications for access from external networks. You will learn about different methods such as NodePort, load balancer services, and OpenShift routes, as well as how to secure these routes to ensure safe and efficient external access to your applications.
Prerequisites
- Access to an OpenShift cluster or a terminal emulator connected to one.
- Familiarity with Kubernetes service types (NodePort, LoadBalancer) and OpenShift routes.
- Basic knowledge of network security concepts and TLS encryption.
Introduction
In the kingdom of OpenShift, connecting with the outside world is vital for trade, communication, and expansion. Just as a castle has gates and watchtowers to manage and secure traffic, OpenShift provides various methods to expose applications to external networks, ensuring secure and efficient access.
Exposing Applications
You can expose your applications using different methods, including service types like NodePort or load balancer, and API resources such as Ingress and Route. OpenShift routes are particularly useful for providing a unique, publicly accessible hostname for your applications.
NodePort and Load Balancer Services
These services act like the castle gates, allowing controlled access to the internal workings of your applications. However, for more sophisticated routing and secure access, OpenShift routes are the preferred method.
OpenShift Routes
OpenShift routes are like the drawbridges of your castle, providing a way for external traffic to reach your applications with a unique hostname. These routes rely on a router plug-in to redirect traffic from the public IP to the appropriate pods.
Creating a Route
To create a route, you might use a command like this:
This command sets up a basic route, exposing your application to the world. But in the kingdom of OpenShift, security is paramount.
Securing Routes
Secured routes encrypt traffic to and from the pods, specifying the TLS termination of the route. The available terminations are Edge, Passthrough, and Re-encryption.
Edge Routes
Edge routes encrypt traffic between the client and the router. It’s like having guards inspect and secure all goods entering the castle gates, but once inside, the goods are not monitored.
First, you need a TLS certificate. Then you can create the edge route with the certificate:
oc create route edge --service=api-frontend --hostname=api.apps.acme.com --key=api.key --cert=api.crt
Passthrough Routes
Passthrough routes are akin to a secret passage that ensures end-to-end encryption. The application exposes its TLS certificate, so traffic is encrypted from the client to the application directly.
To set this up, you provide the certificate via OpenShift TLS secrets, exposing the secrets as a mount point into the container.
Re-encrypt Routes
Re-encrypt routes offer end-to-end encryption with an additional layer of security. It’s like having a secure tunnel that encrypts the traffic both at the entrance and within the castle walls.
Re-encrypt routes terminate external client-router encryption with a trusted certificate using a fully qualified domain name (FQDN), then re-encrypt connections to internal services using certificates with OpenShift FQDNs, generated by the OpenShift PKI and stored in service-specific secrets.
Conclusion
In the digital kingdom of OpenShift, managing external access to your applications is as crucial as guarding the gates of a castle. By understanding and utilizing routes and securing them appropriately, you ensure that your applications are both accessible and protected, maintaining the integrity and security of your realm.
May your applications flourish, and your connections to the outside world be both strong and secure!
