this document is for:

Deployment: Invicti Platform on-premises

Nginx service configuration

The Helm chart exposes configuration options under nginx.service to control how the nginx ingress service is exposed in your Kubernetes cluster. The right choice depends on your infrastructure and how external traffic reaches the cluster.

Service types

LoadBalancer (default)

No configuration is needed to use this mode — it is the default. The cloud provider provisions an external load balancer that routes traffic to the nginx service automatically.

This is the recommended option for managed Kubernetes environments (EKS, AKS, GKE, etc.) where the cloud platform handles load balancer provisioning natively.

# No nginx.service configuration required — LoadBalancer is used by default.

NodePort

Use NodePort when you want to manage your own external load balancer rather than relying on Kubernetes to provision one. This is the typical choice for on-premises deployments where a hardware or software load balancer (e.g. F5, HAProxy, NGINX Plus) already exists in front of the cluster. The service is exposed on a static port on every node, and you configure your external load balancer to distribute traffic to that port across your cluster nodes.

nginx:
  service:
    type: "NodePort"
    nodePort: 30443    # Optional. Defaults to 30443 if omitted.

The service will be reachable at <any-node-ip>:<nodePort>. You can change the port to any value in the Kubernetes NodePort range (default 30000–32767).

ClusterIP

Use ClusterIP when the service should only be reachable from within the cluster. This is useful when an existing ingress controller or reverse proxy already running in the cluster handles inbound traffic and forwards it to the service internally.

nginx:
  service:
    type: "ClusterIP"

No external port is allocated. The service is accessible only via its cluster-internal DNS name.

Custom service annotations

Annotations can be passed under nginx.service.annotations to influence how the underlying service is provisioned. This is most commonly used with the LoadBalancer type to control provider-specific load balancer behavior, but annotations can be applied regardless of the service type.

nginx:
  service:
    annotations:
      my-organization.com/team: "secops"
      my-organization.com/cost-center: "infrastructure"

Typical use cases

Annotations are especially useful for:

• Restricting a load balancer to internal traffic — most cloud providers offer an annotation that prevents the load balancer from receiving a public IP, keeping it accessible only from within your VPC or virtual network.
• Controlling subnet or network placement — on providers like AWS, you can specify which subnets the load balancer should be provisioned in, which is important for multi-AZ deployments or when separating public and private traffic.
• Setting health check parameters — some providers allow you to configure health check paths, intervals, and thresholds through annotations.
• Choosing a load balancer class or SKU — for example, selecting between a standard and a premium tier, or between an NLB and an ALB on AWS.

Refer to your cloud provider's Kubernetes documentation for the full list of supported service annotations. Multiple annotations can be combined freely under the same annotations block.

Client IP resolution and IP restriction

Invicti Platform includes an IP restriction feature that allows you to limit access based on the client's IP address. For this feature to work correctly, the platform must be able to determine the real client IP from incoming requests.

For this to work, two conditions must be met:

1. The load balancer in front of nginx must set the X-Forwarded-For header with the real client IP.
2. The CIDR ranges of your load balancer and any intermediate proxies must be configured so nginx knows to skip those IPs when resolving the client address.

Load balancer requirements

The load balancer must operate at Layer 7 (HTTP) or otherwise inject the client IP into the X-Forwarded-For header. Not all load balancer types do this:

Load balancer type	Sets X-Forwarded-For	Compatible
AWS ALB (Application Load Balancer)	Yes	Yes
AWS NLB (Network Load Balancer)	No (L4)	No, unless proxy protocol is enabled and nginx is configured to read it
AWS Classic ELB in HTTP mode	Yes	Yes
AWS Classic ELB in TCP mode	No	No
HAProxy (L7 mode)	Yes, when configured with option forwardfor	Yes
F5 BIG-IP	Yes, when configured with an HTTP profile and XFF insertion	Yes
NGINX Plus / other reverse proxies	Yes, when configured with proxy_set_header X-Forwarded-For	Yes

If your load balancer operates at Layer 4 (TCP) without setting X-Forwarded-For, the platform will see the load balancer's IP instead of the client's IP, and IP restriction will not work as expected.

Configuring trusted proxy CIDR ranges

Add the CIDR ranges of your load balancer and any intermediate proxies to nginx.vpc.cidr_blocks in your values.yaml. Nginx will treat these as trusted and skip past them when resolving the client IP from the X-Forwarded-For chain.

nginx:
  vpc:
    cidr_blocks: "10.0.0.0/16,172.16.0.0/12"

If this value is not set or does not cover your load balancer's IP range, nginx will treat the load balancer IP as the client IP and IP restriction will not work as expected.

---

Need help?

Invicti Support team is ready to provide you with technical help. Go to Help Center