Ingress and Security
The Fusion proxy service serves as an API gateway and provides authentication and authorization. Route all external access to Fusion services through the Fusion proxy service. The most common approach is to set up a Kubernetes Ingress that routes Fusion service requests to the proxy service as shown in the example ingress definition below. It’s also common to do TLS termination at the Ingress, so that all traffic to and from the Kubernetes cluster is encrypted.
|Internal requests happen over unencrypted HTTP.|
apiVersion: v1 items: - apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: ... labels: ... name: <RELEASE>-api-gateway namespace: <NAMESPACE> spec: rules: - host: <HOSTNAME> http: paths: - backend: serviceName: proxy servicePort: 6764 path: "/*" tls: - hosts: - <HOSTNAME> secretName: <RELEASE>-api-gateway-tls-secret status: loadBalancer: ingress: - ip: <SOME_IP>
For deployments that run on EKS, the setup_f5_eks.sh setup script creates a classic elastic load balancer (ELB) to expose the Fusion proxy service for demonstration purposes. However, you’re strongly encouraged to configure a Kubernetes Ingress with TLS termination in front of the proxy service. See How do I terminate HTTPS traffic on Amazon EKS workloads with ACM? for more information.
You can also opt to use an Application Load balancer instead of the proxy service.
If your deployment runs on OpenShift using a cluster created with OpenShift Infrastructure Provider, the setup_f5_k8s.sh setup script will install Fusion 5 on your existing cluster. OpenShift Online services are not supported.
See the RedHat OpenShift section of the readme for more tips toward a successful installation.
This process uses Let’s Encrypt.
For other Kubernetes providers, refer to provider’s documentation on creating an Ingress and TLS certificates.