# NGINX Application Security {% hint style="warning" %} **Update on Ingress NGINX Retirement and CloudGuard WAF Migration Options** With the recent announcement about the retirement of Ingress NGINX on Kubernetes, we want to clarify how this affects existing CloudGuard WAF + Ingress NGINX deployments. While Ingress NGINX will receive best-effort maintenance only until **March 2026**, CloudGuard WAF will continue to provide updated Helm charts and full support for as long as new Ingress NGINX Helm charts are available. However, because long-term updates are not guaranteed, we recommend planning a transition to a supported Gateway API–based solution. **Compatibility When Using theManagement UI** Management UI remain fully compatible with Gateway API–based ingress solutions and other Kubernetes APIs, as all CloudGuard WAF configuration is performed centrally and does not depend on the specific ingress controller. **Supported Gateway API Solutions** Cloud Guard already integrates with several ingress/gateway controllers: * **Kong API Gateway** — Supported via Helm + Webhook integration. * **Istio Ingress Gateway** — Supported via Helm + Webhook integration. We continue to evaluate additional gateway and ingress solutions. Please don't hesitate to reach out to Check point Support for any suggestions or requests. {% endhint %} The NGINX Ingress controller and CloudGuard WAF for Kubernetes agent are deployed together with a single Helm chart. The configuration of the NGINX Ingress controller is done with common methods for configuring Ingress using both Kubernetes Ingress resources or NGINX Ingress resources. This diagram shows an example of a Kubernetes service exposed outside the Kubernetes cluster with an Ingress controller protected with CloudGuard WAF. ![](https://2760087783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEWA4nfgNrSRL8dA6Kap7%2Fuploads%2FieVqE78veX0Xl332kOzx%2Fappsec-assets-k8s-deployment.png?alt=media\&token=cf045c7c-4934-43e9-aadd-f11a3b18034c) ## Prerequisites * AWS Elastic Kubernetes Service (EKS) or Azure Kubernetes Service (AKS) * For an NGINX-based ingress controller: Kubernetes 1.16.0+ cluster with [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) enabled with Cluster admin permissions * [Helm 3 Package Manager](https://helm.sh/docs/intro/install/) installed on your local machine * The `kubectl` and `wget` command-line tools installed on your bastion or platform that you use to access the Kubernetes cluster ## Installation #### Step 1: Download Helm chart Run the following command depending on your Kubernetes version: {% tabs %} {% tab title="1.19.0 and above " %} `wget https://cloudguard-waf.i2.checkpoint.com/downloads/helm/ingress-nginx/cp-k8s-appsec-nginx-ingress-4.12.1.tgz -O cp-k8s-appsec-nginx-ingress-4.12.1.tgz` {% endtab %} {% tab title="1.16.0 - 1.18.20" %} `wget https://cloudguard-waf.i2.checkpoint.com/downloads/helm/ingress-nginx/cp-k8s-appsec-nginx-ingress-3.35.0.tgz -O cp-k8s-appsec-nginx-ingress-3.35.0.tgz` {% endtab %} {% endtabs %} #### Step 2: Install Helm chart Make sure you obtained the token from the [Enforcement Profile](https://waf-doc.inext.checkpoint.com/getting-started/deploy-enforcement-point) page first, you will need it in the command to deploy the Helm chart. {% hint style="info" %} Obtain the \ from the **Profile** page, **Authentication** section. ![](https://2760087783-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEWA4nfgNrSRL8dA6Kap7%2Fuploads%2FodEuUgaIWcxkuTtYrJ2n%2Fappsec-profiles-authentication-token.PNG?alt=media\&token=aaa5d4ad-7a5b-4986-9378-7ec39b22aadd) {% endhint %} Run the following command depending on your Kubernetes version (**Note** - package file names contain the name appsec - short for "Application Security" provided by CloudGuard WAF): {% tabs %} {% tab title="1.19.0 and above" %} `helm install cp-k8s-appsec-nginx-ingress-4.12.1.tgz --name-template cp-appsec`\ `--set appsec.agentToken=""` {% endtab %} {% tab title="1.16.0 - 1.18.20" %} `helm install cp-k8s-appsec-nginx-ingress-3.35.0.tgz --name-template cp-appsec`\ `--set appsec.agentToken=""` {% endtab %} {% endtabs %} #### Step 3: Create SSL/TLS Secret (optional if the servers do not use HTTPS) Kubernetes Secrets are used for TLS termination of the Ingress resource. The public/private key pair must already exist before creating the Secret. Read more about Kubernetes TLS Secrets in the [Official Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets). Create a Kubernetes SSL/TLS Secret using the following command with the public key certificate for `--cert` .PEM-encoded and matching the private key for `--key`: `kubectl create secret tls --key --cert $` #### Step 4: Configure the Ingress resource 1. Edit your ingress.yaml with your favorite editor 2. If needed add the following annotation: `kubernetes.io/ingress.class: "nginx"`
ingress.yaml example The ingress.yaml in this example exposes two Kubernetes Services in the 'applications-ns' namespace: * portal-svc (port 8080) exposed through portal.acme.com on port 443 * api-svc (port 80) exposed through api.acme.com on port 80 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress namespace: applications-ns annotations: kubernetes.io/ingress.class: "nginx" spec: tls: - hosts: - portal.acme.com secretName: tls rules: - host: portal.acme.com http: paths: - path: / pathType: Prefix backend: service: name: portal-svc port: number: 8080 - host: api.acme.com http: paths: - path: / pathType: Prefix backend: service: name: api-svc port: number: 80 ```
#### Step 5: Deploy the Ingress In environments that can allow short downtime, uninstall the older ingress and install the new one. `kubectl apply -f ingress.yaml` In environments that require zero-downtime: 1. Redirect your DNS traffic from the old ingress to the new ingress 2. Log traffic from both controllers during this changeover 3. Uninstall the old ingress once traffic has fully drained from it