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 four classes of ingress: default, default-non-prod, modsec and modsec-non-prod.
defaultutilises the standard NGINX Ingress controller setup and it’s supported configurations (production workloads only)default-non-prodsame as above for non-production workloads onlymodsecextends the capabilities of your ingress resource to enable ModSecurity Web Application Firewall (WAF) rules (production workloads only)modsec-non-prodsame as modsec, but for non-production workloads only
We split our production and non-production workloads for a 2 main reasons:
- We can roll out upgrades to the non-production ingress classes first and spot issues early before rolling out to production
- Production classes are more stable as they experience less NGINX Reloads because of their isolation from inherently unstable workloads
We highly encourage users to separate their ingress workloads between production and non-production environments by using the appropriate ingress class (default or modsec for production, default-non-prod or modsec-non-prod for non-production).
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 recommend that all production services are setup with the
modsecingress class for additional security.
Here is an example of an ingress resource:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
namespace: [namespace]
annotations:
external-dns.alpha.kubernetes.io/aws-weight: "100"
external-dns.alpha.kubernetes.io/set-identifier: my-ingress-[namespace]-green
spec:
ingressClassName: default
rules:
- host: my-shiny-app.internal.cloud-platform.service.justice.gov.uk
http:
paths:
- backend:
service:
name: shiny-app-service
port:
number: 8080
path: /
pathType: ImplementationSpecific
Changing or migrating the ingress class
If you want to change or migrate the ingress class (for example, from a production class to a non-production class, or vice versa), you can update the ingressClassName field in your ingress resource:
spec:
ingressClassName: default-non-prod # change to the desired class
Please note that changing the ingress class will result in some downtime as the ingress resource is recreated.
Some teams manage their ingress configuration through a Helm chart, in which case the ingressClassName value may be defined as a chart value rather than directly in the manifest. If that is the case, you may want to contact your SRE team for guidance on how to make the change safely.
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.