Does my app need an ingress?
Internet facing services
If your application is accessed over the internet, then you’ll need to configure an ingress resource, making sure you’ve considered the security implications associated with this.
Cloud Platform offers two classes of ingress: default or modsec. default utilises the standard NGINX Ingress controller setup and it’s supported configurations, whereas modsec extends the capabilities of your ingress resource to enable ModSecurity Web Application Firewall (WAF) rules.
We have a detailed guide on ModSecurity and how to configure it here.
It is the responsibility of the application team to consider and select the appropriate ingress class for their service. However, Cloud Platform strongly recommmend that all production services are setup with the
modsecingress class for additional security.
Internal cluster-bound services
Often, Cloud Platform applications exist to provide a service to other workload(s) running in the cluster. If this is the case, you can use the internal service address. Your service address is in the format:
<service-name>.<namespace>.svc.cluster.local
You can query your service using kubectl -n $namespace describe service $yourservice.
For guidelines on configuring networking rules for cross-namespace traffic, refer to our NetWork Policies guide.
Applications in development
If your application is in development and contains sensitive information or requires authentication but does not have it set up, then adding an ingress may not be a good idea.
Port Forwarding
Instead of opening up your development application to the world, you can instead use Kubernetes built in port forwarding. This feature forwards the port defined in your service to your local machine:
kubectl -n $namespace port-forward 8080:8080
This will forward your applications port 8080 to your local machines port 8080. If you visit localhost:8080 in your browser, you should see your development application.
A tutorial on using port-forward can be found here.