CloudGuard WAF
Search
K

Kubernetes Ingress

Overview

CloudGuard WAF for Kubernetes protects vulnerable applications and APIs running in Kubernetes environments. It integrates with the most popular NGINX Ingress Controller, as well as Kong Ingress Controller, and serves as a secure HTTP/S load balancer for one or more Services inside Kubernetes clusters.
Kubernetes Ingress exposes HTTP/S routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource. You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.
The NGINX/Kong Ingress controller and CloudGuard WAF for Kubernetes agent are deployed together with a single Helm chart. The configuration of the NGINX/Kong Ingress controller is done with common methods for configuring Ingress using both Kubernetes Ingress resources or NGINX/Kong Ingress resources.
This diagram shows an example of a Kubernetes service exposed outside the Kubernetes cluster with an Ingress controller protected with CloudGuard WAF.

Prerequisites

  • AWS Elastic Kubernetes Service (EKS) or Azure Kubernetes Service (AKS)
  • For an NGINX-based ingress controller: Kubernetes 1.16.0+ cluster with RBAC enabled with Cluster admin permissions For a Kong-based ingress controller: Kubernetes 1.22.0+ cluster with RBAC enabled with Cluster admin permissions
  • Helm 3 Package Manager 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:
1.22.0 and above
1.19.0-1.21.*
1.16.0 - 1.18.20

NGINX-based ingress controller:

wget https://github.com/CheckPointSW/Infinity-Next/raw/main/deployments/cp-k8s-appsec-nginx-ingress-4.0.1.tgz -O cp-k8s-appsec-nginx-ingress-4.0.1.tgz

Kong-based ingress controller:

wget https://github.com/CheckPointSW/Infinity-Next/raw/main/deployments/cp-k8s-appsec-kong-2.22.0.tgz -O cp-k8s-appsec-kong-2.22.0.tgz
wget https://github.com/CheckPointSW/Infinity-Next/raw/main/deployments/cp-k8s-appsec-nginx-ingress-4.0.1.tgz -O cp-k8s-appsec-nginx-ingress-4.0.1.tgz
wget https://github.com/CheckPointSW/Infinity-Next/raw/main/deployments/cp-k8s-appsec-nginx-ingress-3.35.0.tgz -O cp-k8s-appsec-nginx-ingress-3.35.0.tgz

Step 2: Install Helm chart

Make sure you obtained the token from the Enforcement Profile page first, you will need it in the command to deploy the Helm chart.
Obtain the <token> from the Profile page, Authentication section.
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):
1.22.0 and above
1.19.0-1.21.*
1.16.0 - 1.18.20

NGINX-based ingress controller:

helm install cp-k8s-appsec-nginx-ingress-4.0.1.tgz --name-template cp-appsec --set appsec.agentToken="<token>"

Kong-based ingress controller:

helm install cp-k8s-appsec-kong-2.22.0.tgz --name-template cp-appsec --set appsec.agentToken="<token>" --create-namespace -n kong
helm install cp-k8s-appsec-nginx-ingress-4.0.1.tgz --name-template cp-appsec --set appsec.agentToken="<token>"
helm install cp-k8s-appsec-nginx-ingress-3.35.0.tgz --name-template cp-appsec --set appsec.agentToken="<token>"

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.
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 <certificate-name> --key <private-key-file> --cert $<certificate-file>

Step 4: Configure the Ingress resource

  1. 1.
    Edit your ingress.yaml with your favorite editor
  2. 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
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. 1.
    Redirect your DNS traffic from the old ingress to the new ingress
  2. 2.
    Log traffic from both controllers during this changeover
  3. 3.
    Uninstall the old ingress once traffic has fully drained from it