NGINX Ingress Migration Tool

Warning: The community-maintained kubernetes/ingress-nginx project has reached end of maintenance. v1.15.1 (March 19, 2026) is the final release — it will receive no further releases, bugfixes, or security patches. The F5 NGINX Ingress Controller (nginx/kubernetes-ingress) is actively maintained and is the recommended migration target.

Version Reference: This tool is based on Kubernetes Ingress NGINX (Ingress-NGINX) v1.15.1 (final release) and F5 NGINX Ingress Controller v5.5.1.

Overview

This interactive guide helps you migrate from the community-maintained Kubernetes Ingress NGINX (Ingress-NGINX) controller (kubernetes/ingress-nginx) to the F5 NGINX Ingress Controller (nginx/kubernetes-ingress). It covers 130+ annotation mappings, ConfigMap key translations, and CRD migration examples across three tabs:

Getting Started — Background on why to migrate, CRD overviews, installation, and a migration checklist
Ingress NGINX Config Analyzer — Paste an Ingress manifest and get automatic migration suggestions with ready-to-use YAML
Reference Guide — Complete annotation and ConfigMap mapping tables with side-by-side examples

Why Migrate?

The two controllers take fundamentally different approaches to configuring NGINX in Kubernetes.

Kubernetes Ingress NGINX (Ingress-NGINX) is annotation-driven — it relies on annotations and ConfigMap keys to customize NGINX. These are opaque strings with no schema validation — a single Ingress resource may carry dozens of annotations as unstructured key-value pairs.
F5 NGINX Ingress Controller is CRD-native — it uses Custom Resource Definitions (VirtualServer, Policy, TransportServer) as its primary config model, providing structured, schema-validated YAML with IDE autocompletion.

While the F5 NGINX Ingress Controller still supports annotations for common settings, CRDs unlock capabilities that annotations cannot express:

Schema validation — Kubernetes validates CRD fields at apply time, catching misconfigurations before they reach NGINX
Structured configuration — Nested YAML objects replace long annotation strings, making complex routing, traffic splitting, and security policies readable and maintainable
Reusability — Policies (rate limiting, auth, WAF) are defined once and attached to any number of routes
Layer 4 support — TransportServer CRDs handle TCP/UDP workloads that annotations cannot express
IDE and tooling support — CRD schemas enable autocompletion, linting, and documentation in editors and CI pipelines

Phased Migration Strategy

Rather than performing a "big bang" cutover, F5 recommends a phased migration that allows you to validate each workload before decommissioning the community controller. Both controllers can run side-by-side in the same cluster using separate IngressClass resources.

Deploy side-by-side — Install the F5 NGINX Ingress Controller alongside the community controller using a distinct IngressClass (e.g., nginx-nic). This ensures existing traffic is unaffected.
Migrate service-by-service — Update each Ingress resource's ingressClassName to point to the new controller. Convert annotations as described in the Reference Guide, validate routing and TLS behavior, and promote to production before moving on to the next service.
Decommission — After all workloads have been migrated and validated, remove the community controller deployment, its IngressClass, and any unused ConfigMaps.

Tip: Use the Ingress NGINX Config Analyzer tab to process each Ingress manifest during step 2. It will flag unsupported annotations and generate the equivalent F5 NGINX Ingress Controller configuration.

CRDs Summary

The F5 NGINX Ingress Controller uses Custom Resource Definitions (CRDs) to extend Kubernetes with NGINX-specific configuration. CRDs provide type-safe, validated configuration that goes beyond what standard Ingress annotations can offer.

VirtualServer CRD

The primary CRD for configuring HTTP/HTTPS load balancing. It replaces Ingress resources and provides advanced traffic management capabilities with full validation.

Traffic Splitting: Route percentages of traffic to different backends for canary/blue-green deployments
Content-Based Routing: Route based on headers, cookies, arguments, or variables
Path Rewriting: Modify request URIs with regex support before forwarding to backends
Error Pages: Custom responses for specific HTTP error codes
Request/Response Headers: Add, modify, or remove headers in transit
Health Checks: Active health monitoring of upstream servers
Session Persistence: Cookie-based sticky sessions

VirtualServerRoute CRD

Enables delegation of route configuration to different namespaces. Allows teams to manage their own routing rules while maintaining centralized control over the domain.

Cross-Namespace Routing: Reference services in different namespaces
Path Delegation: Delegate path prefixes to other teams/namespaces
Independent Updates: Teams update routes without modifying the parent VirtualServer
Access Control: Limit which namespaces can define routes for a host

Policy CRD

Reusable security and traffic policies that can be attached to VirtualServers or specific routes. Policies enable consistent security controls across multiple applications.

Rate Limiting: Limit request rates by IP, header, or custom key
Access Control: IP allowlists and denylists
Basic Auth: Username/password authentication via htpasswd
JWT Validation: Validate JSON Web Tokens (Plus)
OIDC: Native OpenID Connect integration (Plus)
API Key Auth: Authenticate via API keys in headers/query
mTLS: Client certificate verification (ingress) and backend TLS (egress)
WAF: F5 WAF for NGINX web application firewall (Plus)

TransportServer CRD

Configures TCP/UDP load balancing for non-HTTP protocols. Essential for databases, message queues, gaming servers, and other Layer 4 applications.

TCP Load Balancing: MySQL, PostgreSQL, Redis, custom TCP services
UDP Load Balancing: DNS, RADIUS, gaming protocols
TLS Passthrough: Pass encrypted traffic directly to backends
Health Checks: TCP/UDP health monitoring
Session Persistence: IP hash-based session affinity

GlobalConfiguration CRD

Cluster-wide configuration for the F5 NGINX Ingress Controller. Defines global listeners for TCP/UDP and TLS passthrough that TransportServers can reference.

TCP/UDP Listeners: Define ports for non-HTTP traffic
TLS Passthrough Listeners: Configure SNI-based routing
Global Settings: Controller-wide configuration options

Installing CRDs

CRDs can be installed via Helm or manually using manifests, depending on your deployment method. See the F5 NGINX Ingress Controller installation docs for full instructions.

Helm (example)

If you install the F5 NGINX Ingress Controller via Helm, CRDs are included automatically. To ensure they are enabled:

helm install nginx-ingress oci://ghcr.io/nginx/charts/nginx-ingress --version 2.6.1 --set controller.enableCustomResources=true

The controller.enableCustomResources flag is true by default. If you previously disabled it, re-enable it to use CRD resources. See the Helm installation guide for details.

Manifests (example)

If you deploy using manifests, install CRDs manually before deploying the controller:

kubectl apply -f https://raw.githubusercontent.com/nginx/kubernetes-ingress/v5.5.1/deploy/crds.yaml

Replace the version number with your target controller version. See the manifest installation guide for the full step-by-step process.

Note: The crds.yaml file contains all CRDs (VirtualServer, VirtualServerRoute, Policy, TransportServer, GlobalConfiguration) in a single manifest.

Note: Replace version numbers with your target controller version.

Migration Checklist

Progress is saved in your browser.

Install CRDs via Helm (controller.enableCustomResources=true) or manifests (deploy/crds.yaml)
Review annotation mappings — not all nginx.ingress.kubernetes.io/ annotations have a direct nginx.org/ equivalent (see NGINX Mappings)
Map rewrite-target annotation to nginx.org/rewrite-target (not nginx.org/rewrites)
Migrate ConfigMap keys that differ between controllers (see ConfigMap Mappings)
Convert HSTS ConfigMap keys to nginx.org/hsts annotations for per-Ingress control
Convert server-tokens ConfigMap key to nginx.org/server-tokens annotation
Convert access control annotations to Policy CRD (accessControl)
Convert authentication annotations to Policy CRD (apiKey, basicAuth, externalAuth, jwt, oidc)
Convert canary/traffic splitting to VirtualServer splits/matches
Convert mTLS annotations to ingressMTLS/egressMTLS policies
Convert CORS annotations to the cors Policy CRD via nginx.org/policies (v5.4.0+), falling back to snippets only where needed
Convert custom error pages to VirtualServer errorPages
Convert header manipulation to VirtualServer requestHeaders/responseHeaders
Convert rate limiting annotations to Policy CRD (rateLimit)
Convert redirect annotations to VirtualServer action.redirect
Convert session affinity annotations to VirtualServer upstream sessionCookie
Convert SSL passthrough to TransportServer CRD
Convert TCP/UDP services to TransportServer CRD
Replace ssl-redirect with nginx.org/ssl-redirect (not the deprecated ingress.kubernetes.io/ssl-redirect)
Verify snippets (configuration-snippet, server-snippet) use F5 NGINX Ingress Controller equivalents
Test in staging environment
Update monitoring and alerting

Additional Resources

Version Reference: This tool is based on Kubernetes Ingress NGINX (Ingress-NGINX) v1.15.1 (final release) and F5 NGINX Ingress Controller v5.5.1.

Ingress NGINX Config Analyzer

Paste a Kubernetes Ingress YAML manifest that uses Kubernetes Ingress NGINX (Ingress-NGINX) annotations to get migration suggestions for the F5 NGINX Ingress Controller.

Drop YAML file here

0 lines

Migration strategy:

Prefer Policy CRDs and VirtualServer, fall back to annotations when no CRD path exists

Ctrl+Enter to analyze · in the editor, Tab indents — press Esc then Tab to move focus

Version Reference: This tool is based on Kubernetes Ingress NGINX (Ingress-NGINX) v1.15.1 (final release) and F5 NGINX Ingress Controller v5.5.1.

Key Differences

Aspect	Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
Repository	`kubernetes/ingress-nginx`	`nginx/kubernetes-ingress`
Annotation Prefix	`nginx.ingress.kubernetes.io/`	`nginx.org/` or `nginx.com/` or `appprotect.f5.com/`
ConfigMap Name	`ingress-nginx-controller`	`nginx-config`
CRD Support	None	VirtualServer, VirtualServerRoute, Policy, TransportServer, GlobalConfiguration
NGINX Plus Support	No	Yes (with `nginx.com/` annotations)

Note: Many Kubernetes Ingress NGINX (Ingress-NGINX) capabilities that do not have direct F5 NGINX Ingress Controller annotations or CRDs can still be achieved through NGINX configuration snippets (via either snippet annotations or VirtualServer/VirtualServerRoute CRDs). We recommend that users proceed with caution when using snippets, as they inject raw NGINX configuration and are intended for more advanced use cases.

New in v5.4.0 — Policy CRDs on Ingress objects: Policy CRDs (e.g. accessControl, cors) can now be referenced directly from Ingress resources using the nginx.org/policies annotation — no VirtualServer required. This is the recommended migration path for features that support it. Look for the (Recommended) tab in the mapping examples.

New in v5.5.0 — ExternalAuth Policy and expanded Policy CRDs on Ingress: A brand new externalAuth Policy CRD provides an OSS-capable replacement for the community's generic auth_request annotations (auth-url, auth-signin, auth-snippet) — the headline migration win of this release. The ingressMTLS, egressMTLS, and waf (Plus, via nginx.com/policies) Policy CRDs can now also be attached directly to Ingress resources. New direct annotation mappings arrived for proxy-redirect-from/proxy-redirect-to, alongside a new inline nginx.org/add-header (plus nginx.org/add-header-inherit) for response header injection.

NGINX Mappings

These features are available in both NGINX Open Source and NGINX Plus editions. All items are annotations unless otherwise indicated with a badge (e.g. ConfigMap, Policy CRD, VirtualServer CRD). Community annotations use the nginx.ingress.kubernetes.io/ prefix; F5 NGINX Ingress Controller annotations use nginx.org/.

How to Read the Mappings

Annotation-to-annotation rows ▶: Direct mappings where you change the annotation name/prefix. Click to expand and see before/after Ingress YAML examples.
CRD-based rows ▶: Annotations that map to a CRD (VirtualServer, Policy, or TransportServer). Click to expand for full CRD examples with installation instructions.
Grouped annotations: Related annotations that work together are grouped in a single expandable row, showing how they map to a unified configuration.
F5 NGINX Ingress Controller-only rows: Rows marked No direct equivalent on the left are features unique to the F5 NGINX Ingress Controller with no community equivalent.

Access Control

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/denylist-source-range` `nginx.ingress.kubernetes.io/whitelist-source-range`	Policy CRD `accessControl` + `nginx.org/policies` New v5.4.0— or —Policy CRD `accessControl` + VirtualServer `policies[]`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/denylist-source-range: "192.168.1.100" nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8,172.16.0.0/12"` F5 NGINX Ingress Controller # 1. Create two AccessControl Policies — NIC requires exactly one of # allow or deny per Policy, so they become two separate Policies. apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: access-control-allow spec: accessControl: allow: # whitelist-source-range - 10.0.0.0/8 - 172.16.0.0/12 --- apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: access-control-deny spec: accessControl: deny: # denylist-source-range - 192.168.1.100 --- # 2. Reference from Ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.org/policies: "access-control-allow,access-control-deny" # ... rest of Ingress spec New in v5.4.0: AccessControl policies can now be referenced directly from Ingress resources using the `nginx.org/policies` annotation. This is the simplest migration path — you stay on Ingress resources. Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/denylist-source-range: "192.168.1.100" nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8,172.16.0.0/12"` F5 NGINX Ingress Controller # 1. Create two AccessControl Policies (allow and deny — NIC requires # exactly one of allow or deny per Policy) apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: access-control-allow spec: accessControl: allow: # whitelist-source-range - 10.0.0.0/8 - 172.16.0.0/12 --- apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: access-control-deny spec: accessControl: deny: # denylist-source-range - 192.168.1.100 --- # 2. Reference from VirtualServer apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com policies: - name: access-control-allow - name: access-control-deny upstreams: - name: backend service: backend-svc port: 80 routes: - path: / action: pass: backend Note: The VirtualServer approach has been available since before v5.4.0. Use this if you are already migrating to VirtualServer resources for other reasons (e.g., advanced routing, traffic splitting).
`nginx.ingress.kubernetes.io/satisfy`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/satisfy: "any"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # satisfy satisfy any; # satisfy` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/satisfy: "any"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # satisfy satisfy any; action: pass: backend`

Authentication (Basic)

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/auth-realm
nginx.ingress.kubernetes.io/auth-secret
nginx.ingress.kubernetes.io/auth-secret-type
nginx.ingress.kubernetes.io/auth-type: "basic" Policy CRD basicAuth— or —nginx.org/basic-auth-realm
nginx.org/basic-auth-secret

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/auth-realm` `nginx.ingress.kubernetes.io/auth-secret` `nginx.ingress.kubernetes.io/auth-secret-type` `nginx.ingress.kubernetes.io/auth-type: "basic"`	Policy CRD `basicAuth`— or —`nginx.org/basic-auth-realm` `nginx.org/basic-auth-secret`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-realm: "Protected Area" nginx.ingress.kubernetes.io/auth-secret: "basic-auth" nginx.ingress.kubernetes.io/auth-secret-type: "auth-file" nginx.ingress.kubernetes.io/auth-type: "basic"` F5 NGINX Ingress Controller `# auth-secret-type → Secret type apiVersion: v1 kind: Secret metadata: name: basic-auth type: nginx.org/htpasswd # auth-secret-type data: htpasswd: dXNlcjokYXByMS4uLg== --- annotations: nginx.org/basic-auth-realm: "Protected Area" # auth-realm nginx.org/basic-auth-secret: "basic-auth" # auth-secret` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-realm: "Protected Area" nginx.ingress.kubernetes.io/auth-secret: "basic-auth" nginx.ingress.kubernetes.io/auth-secret-type: "auth-file" nginx.ingress.kubernetes.io/auth-type: "basic"` F5 NGINX Ingress Controller `apiVersion: v1 kind: Secret metadata: name: basic-auth type: nginx.org/htpasswd data: htpasswd: dXNlcjokYXByMS4uLg== --- apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: basic-auth-policy spec: basicAuth: realm: "Protected Area" # auth-realm secret: basic-auth # auth-secret` Note: The community `auth-secret-type` annotation (`auth-file` or `auth-map`) has no F5 NGINX Ingress Controller equivalent. The F5 NGINX Ingress Controller only supports htpasswd format, specified via the Secret's `type: nginx.org/htpasswd` field. The `auth-type` annotation is also implicit — the F5 NGINX Ingress Controller only supports basic auth via these annotations.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/auth-realm: "Protected Area"
  nginx.ingress.kubernetes.io/auth-secret: "basic-auth"
  nginx.ingress.kubernetes.io/auth-secret-type: "auth-file"
  nginx.ingress.kubernetes.io/auth-type: "basic"

F5 NGINX Ingress Controller

# auth-secret-type → Secret type
apiVersion: v1
kind: Secret
metadata:
  name: basic-auth
type: nginx.org/htpasswd  # auth-secret-type
data:
  htpasswd: dXNlcjokYXByMS4uLg==
---
annotations:
  nginx.org/basic-auth-realm: "Protected Area"  # auth-realm
  nginx.org/basic-auth-secret: "basic-auth"  # auth-secret

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/auth-realm: "Protected Area"
  nginx.ingress.kubernetes.io/auth-secret: "basic-auth"
  nginx.ingress.kubernetes.io/auth-secret-type: "auth-file"
  nginx.ingress.kubernetes.io/auth-type: "basic"

F5 NGINX Ingress Controller

apiVersion: v1
kind: Secret
metadata:
  name: basic-auth
type: nginx.org/htpasswd
data:
  htpasswd: dXNlcjokYXByMS4uLg==
---
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: basic-auth-policy
spec:
  basicAuth:
    realm: "Protected Area"  # auth-realm
    secret: basic-auth  # auth-secret

Note: The community auth-secret-type annotation (auth-file or auth-map) has no F5 NGINX Ingress Controller equivalent. The F5 NGINX Ingress Controller only supports htpasswd format, specified via the Secret's type: nginx.org/htpasswd field. The auth-type annotation is also implicit — the F5 NGINX Ingress Controller only supports basic auth via these annotations.

Authentication (External)

New in v5.5.0 — ExternalAuth Policy: The new externalAuth Policy CRD is the recommended migration path for the community's generic auth_request pattern (auth-url, auth-signin, auth-snippet). Unlike the oidc Policy (Plus-only, native OIDC), externalAuth works in NGINX OSS and Plus and can be attached directly to Ingress, VirtualServer, and VirtualServerRoute resources via nginx.org/policies. For native OIDC, see the OIDC Authentication section in Plus Mappings.

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/auth-always-set-cookie`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-always-set-cookie: "true" nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/verify"` F5 NGINX Ingress Controller `# Use snippets to propagate cookies from auth responses annotations: nginx.org/location-snippets: \| # auth-always-set-cookie auth_request /auth; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; # auth-always-set-cookie` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-always-set-cookie: "true" nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/verify"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # auth-always-set-cookie auth_request /auth; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; # auth-always-set-cookie action: pass: backend` Note: The community `auth-always-set-cookie` ensures Set-Cookie headers from the auth service are forwarded to the client regardless of the response code. Use `nginx.org/location-snippets` with `auth_request_set` to capture and forward cookies. (The Plus-only `oidc` Policy handles cookies internally.)
`nginx.ingress.kubernetes.io/auth-cache-duration` `nginx.ingress.kubernetes.io/auth-cache-key` `nginx.ingress.kubernetes.io/auth-method` `nginx.ingress.kubernetes.io/auth-proxy-set-headers` `nginx.ingress.kubernetes.io/auth-request-redirect` `nginx.ingress.kubernetes.io/auth-response-headers` `nginx.ingress.kubernetes.io/auth-signin` `nginx.ingress.kubernetes.io/auth-signin-redirect-param` `nginx.ingress.kubernetes.io/auth-snippet` `nginx.ingress.kubernetes.io/auth-url`	Policy CRD `externalAuth` + `nginx.org/policies` New v5.5.0— or —Policy CRD `externalAuth` + VirtualServer `policies[]` New v5.5.0
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-url: "http://auth-svc.default.svc.cluster.local/auth" nginx.ingress.kubernetes.io/auth-method: "GET" nginx.ingress.kubernetes.io/auth-signin: "https://auth.example.com/login" nginx.ingress.kubernetes.io/auth-snippet: \| proxy_set_header X-Original-URI $request_uri;` F5 NGINX Ingress Controller # 1. Create the ExternalAuth Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: external-auth spec: externalAuth: authURI: "/auth" # auth-url (path) authServiceName: "default/auth-svc" # auth-url (service) authSigninURI: "/login" # auth-signin (path only — NIC authSigninURI is relative) authSnippets: \| # auth-snippet proxy_set_header X-Original-URI $request_uri; --- # 2. Reference from Ingress (new in v5.5.0) apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app annotations: nginx.org/policies: "external-auth" # ... rest of Ingress spec New in v5.5.0: The `externalAuth` Policy CRD can be referenced directly from Ingress resources using the `nginx.org/policies` annotation. This is the simplest migration path — you stay on Ingress resources. `auth-url` is split into `authURI` (path) and `authServiceName` (`<namespace>/<service>`). The community's `auth-method`, `auth-response-headers`, `auth-cache-duration`, `auth-cache-key`, `auth-proxy-set-headers`, `auth-request-redirect`, and `auth-signin-redirect-param` annotations have no dedicated Policy fields — express these through `authSnippets` when needed. If you are not adopting a Policy, place the same directives directly in `nginx.org/location-snippets` alongside the `auth_request` directive instead. NIC's `authSigninURI` is a relative URI (validated `^/.$`): a full `auth-signin` URL is reduced to its path, and a sign-in page on a different host cannot be expressed by this field. Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-url: "http://auth-svc.default.svc.cluster.local/auth" nginx.ingress.kubernetes.io/auth-method: "GET" nginx.ingress.kubernetes.io/auth-signin: "https://auth.example.com/login" nginx.ingress.kubernetes.io/auth-snippet: \| proxy_set_header X-Original-URI $request_uri;` F5 NGINX Ingress Controller # 1. Create the ExternalAuth Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: external-auth spec: externalAuth: authURI: "/auth" # auth-url (path) authServiceName: "default/auth-svc" # auth-url (service) authSigninURI: "/login" # auth-signin (path only — NIC authSigninURI is relative) authSnippets: \| # auth-snippet proxy_set_header X-Original-URI $request_uri; --- # 2. Reference from VirtualServer (or VirtualServerRoute) apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com policies: - name: external-auth upstreams: - name: backend service: backend-svc port: 80 routes: - path: / action: pass: backend Note:* Use this if you are already migrating to VirtualServer/VirtualServerRoute resources for other reasons (e.g., advanced routing, traffic splitting). Policies can also be scoped per-route via the route-level `policies[]` field.
`nginx.ingress.kubernetes.io/auth-keepalive` `nginx.ingress.kubernetes.io/auth-keepalive-requests` `nginx.ingress.kubernetes.io/auth-keepalive-share-vars` `nginx.ingress.kubernetes.io/auth-keepalive-timeout`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-keepalive: "10" nginx.ingress.kubernetes.io/auth-keepalive-requests: "100" nginx.ingress.kubernetes.io/auth-keepalive-share-vars: "true" nginx.ingress.kubernetes.io/auth-keepalive-timeout: "60" nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/verify"` F5 NGINX Ingress Controller `# No direct auth-keepalive annotations; use snippets # for auth_request subrequest customization. annotations: nginx.org/location-snippets: \| # auth-keepalive auth_request /auth; auth_request_set $auth_user $upstream_http_x_auth_user; proxy_set_header X-Auth-User $auth_user;` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-keepalive: "10" nginx.ingress.kubernetes.io/auth-keepalive-requests: "100" nginx.ingress.kubernetes.io/auth-keepalive-share-vars: "true" nginx.ingress.kubernetes.io/auth-keepalive-timeout: "60" nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/verify"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # auth-keepalive auth_request /auth; auth_request_set $auth_user $upstream_http_x_auth_user; proxy_set_header X-Auth-User $auth_user; action: pass: backend` Note: The community controller's `auth-keepalive`, `auth-keepalive-requests`, `auth-keepalive-share-vars`, and `auth-keepalive-timeout` annotations configure keepalive connections to the external auth service. The F5 NGINX Ingress Controller doesn't have dedicated `auth_request` annotations. For generic external auth, use `nginx.org/location-snippets` with the `auth_request` directive. If you adopt the `externalAuth` Policy (shown in the row above), keepalive concerns can be expressed via the Policy's `authSnippets` field.
`nginx.ingress.kubernetes.io/enable-global-auth`	Not applicable
Kubernetes Ingress NGINX (Ingress-NGINX) `# Opt out of global external auth for this Ingress annotations: nginx.ingress.kubernetes.io/enable-global-auth: "false"` F5 NGINX Ingress Controller `# The F5 NGINX Ingress Controller does not have a global external # auth feature. Authentication is configured per-resource # via Policy CRDs or annotations. # No migration action needed for this annotation.` Note: The community controller supports global external authentication via ConfigMap keys (`global-auth-url`, etc.). The `enable-global-auth: "false"` annotation opts an Ingress out of this global setting. The F5 NGINX Ingress Controller does not have global external auth — authentication is always configured per-resource (via the `externalAuth`/`oidc`/`jwt` Policy CRDs or `location-snippets`). This annotation can be safely removed during migration.

Authentication (API Key)

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

No direct equivalent Policy CRD apiKey

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
No direct equivalent	Policy CRD `apiKey`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No direct equivalent # Requires custom Lua or external service` F5 NGINX Ingress Controller `apiVersion: v1 kind: Secret metadata: name: api-keys type: nginx.org/apikey data: client1: YXBpa2V5MTIzNDU= --- apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: api-key-auth spec: apiKey: clientSecret: api-keys suppliedIn: header: [X-API-Key] query: [api_key]` Note: The `apiKey` Policy works with NGINX Open Source — unlike the `jwt`, `oidc`, and `waf` Policies, it is not gated on NGINX Plus. Attach it to a VirtualServer or VirtualServerRoute via `spec.policies` (the `apiKey` Policy is not attachable to an Ingress via `nginx.org/policies`).

Kubernetes Ingress NGINX (Ingress-NGINX)

# No direct equivalent
# Requires custom Lua or external service

F5 NGINX Ingress Controller

apiVersion: v1
kind: Secret
metadata:
  name: api-keys
type: nginx.org/apikey
data:
  client1: YXBpa2V5MTIzNDU=
---
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: api-key-auth
spec:
  apiKey:
    clientSecret: api-keys
    suppliedIn:
      header: [X-API-Key]
      query: [api_key]

Note: The apiKey Policy works with NGINX Open Source — unlike the jwt, oidc, and waf Policies, it is not gated on NGINX Plus. Attach it to a VirtualServer or VirtualServerRoute via spec.policies (the apiKey Policy is not attachable to an Ingress via nginx.org/policies).

Buffering

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/client-body-buffer-size`	VirtualServer CRD `upstreams[].client-body-buffer-size`— or —`nginx.org/client-body-buffer-size`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/client-body-buffer-size: "16k"` F5 NGINX Ingress Controller `annotations: nginx.org/client-body-buffer-size: "16k"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/client-body-buffer-size: "16k"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 client-body-buffer-size: "16k" # client-body-buffer-size`
`nginx.ingress.kubernetes.io/proxy-body-size`	VirtualServer CRD `upstreams[].client-max-body-size`— or —`nginx.org/client-max-body-size`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-body-size: "10m"` F5 NGINX Ingress Controller `annotations: nginx.org/client-max-body-size: "10m"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-body-size: "10m"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 client-max-body-size: "10m" # proxy-body-size`
`nginx.ingress.kubernetes.io/proxy-buffer-size`	VirtualServer CRD `upstreams[].buffer-size`— or —`nginx.org/proxy-buffer-size`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-buffer-size: "8k"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 buffer-size: "8k" # proxy-buffer-size`
`nginx.ingress.kubernetes.io/proxy-buffering`	VirtualServer CRD `upstreams[].buffering`— or —`nginx.org/proxy-buffering`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-buffering: "on"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-buffering: "on"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-buffering: "on"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 buffering: true # proxy-buffering`
`nginx.ingress.kubernetes.io/proxy-buffers-number`	VirtualServer CRD `upstreams[].buffers`— or —`nginx.org/proxy-buffers`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-buffers-number: "4"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-buffers: "4 8k"` Note: The F5 NGINX Ingress Controller annotation uses a combined format: `"number size"` (e.g., `"4 8k"`). Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-buffers-number: "4"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 buffers: # proxy-buffers-number number: 4 size: "8k"`
`nginx.ingress.kubernetes.io/proxy-busy-buffers-size`	VirtualServer CRD `upstreams[].busy-buffers-size`— or —`nginx.org/proxy-busy-buffers-size`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-busy-buffers-size: "16k"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-busy-buffers-size: "16k"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-busy-buffers-size: "16k"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 busy-buffers-size: "16k" # proxy-busy-buffers-size`
`nginx.ingress.kubernetes.io/proxy-max-temp-file-size`	`nginx.org/proxy-max-temp-file-size`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-max-temp-file-size: "1024m"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-max-temp-file-size: "1024m"`
`nginx.ingress.kubernetes.io/proxy-request-buffering`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-request-buffering: "off"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # proxy-request-buffering proxy_request_buffering off; # proxy-request-buffering` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-request-buffering: "off"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # proxy-request-buffering proxy_request_buffering off; action: pass: backend` Note: The F5 NGINX Ingress Controller does not have a dedicated `proxy-request-buffering` annotation or ConfigMap key. Use `location-snippets` to set the `proxy_request_buffering` directive.

Canary / Traffic Splitting

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/canary
nginx.ingress.kubernetes.io/canary-by-cookie
nginx.ingress.kubernetes.io/canary-by-header
nginx.ingress.kubernetes.io/canary-by-header-pattern
nginx.ingress.kubernetes.io/canary-by-header-value
nginx.ingress.kubernetes.io/canary-weight
nginx.ingress.kubernetes.io/canary-weight-total VirtualServer CRD splits[] + VirtualServer CRD matches[]

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/canary` `nginx.ingress.kubernetes.io/canary-by-cookie` `nginx.ingress.kubernetes.io/canary-by-header` `nginx.ingress.kubernetes.io/canary-by-header-pattern` `nginx.ingress.kubernetes.io/canary-by-header-value` `nginx.ingress.kubernetes.io/canary-weight` `nginx.ingress.kubernetes.io/canary-weight-total`	VirtualServer CRD `splits[]` + VirtualServer CRD `matches[]`
Kubernetes Ingress NGINX (Ingress-NGINX) `# Canary Ingress annotations: nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-cookie: "canary" nginx.ingress.kubernetes.io/canary-by-header: "X-Canary" nginx.ingress.kubernetes.io/canary-by-header-pattern: "^(test\|staging)$" nginx.ingress.kubernetes.io/canary-by-header-value: "always" nginx.ingress.kubernetes.io/canary-weight: "20" nginx.ingress.kubernetes.io/canary-weight-total: "100"` F5 NGINX Ingress Controller apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: main service: main-svc port: 80 - name: canary service: canary-svc port: 80 routes: - path: / matches: - conditions: - header: X-Canary # canary-by-header value: always # canary-by-header-value action: pass: canary - conditions: - header: X-Canary # canary-by-header value: "~^(test\|staging)$" # canary-by-header-pattern (regex) action: pass: canary - conditions: - cookie: canary # canary-by-cookie value: always # community routes to canary on "always" action: pass: canary splits: # canary-weight / canary-weight-total - weight: 80 action: { pass: main } - weight: 20 action: { pass: canary }

Kubernetes Ingress NGINX (Ingress-NGINX)

# Canary Ingress
annotations:
  nginx.ingress.kubernetes.io/canary: "true"
  nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
  nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
  nginx.ingress.kubernetes.io/canary-by-header-pattern: "^(test|staging)$"
  nginx.ingress.kubernetes.io/canary-by-header-value: "always"
  nginx.ingress.kubernetes.io/canary-weight: "20"
  nginx.ingress.kubernetes.io/canary-weight-total: "100"

F5 NGINX Ingress Controller

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
spec:
  upstreams:
    - name: main
      service: main-svc
      port: 80
    - name: canary
      service: canary-svc
      port: 80
  routes:
    - path: /
      matches:
        - conditions:
            - header: X-Canary  # canary-by-header
              value: always  # canary-by-header-value
          action:
            pass: canary
        - conditions:
            - header: X-Canary  # canary-by-header
              value: "~^(test|staging)$"  # canary-by-header-pattern (regex)
          action:
            pass: canary
        - conditions:
            - cookie: canary  # canary-by-cookie
              value: always  # community routes to canary on "always"
          action:
            pass: canary
      splits:  # canary-weight / canary-weight-total
        - weight: 80
          action: { pass: main }
        - weight: 20
          action: { pass: canary }

Configuration Snippets

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/configuration-snippet`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/configuration-snippet: \| add_header X-Custom "value";` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # configuration-snippet add_header X-Custom "value";` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/configuration-snippet: \| add_header X-Custom "value";` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # configuration-snippet add_header X-Custom "value"; action: pass: backend`
`nginx.ingress.kubernetes.io/server-snippet`	VirtualServer CRD `server-snippets`— or —`nginx.org/server-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/server-snippet: \| location /health { return 200; }` F5 NGINX Ingress Controller `annotations: nginx.org/server-snippets: \| # server-snippet location /health { return 200; }` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/server-snippet: \| location /health { return 200; }` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com server-snippets: \| # server-snippet location /health { return 200; } upstreams: - name: backend service: backend-svc port: 80 routes: - path: / action: pass: backend`
`nginx.ingress.kubernetes.io/stream-snippet`	GlobalConfiguration CRD +TransportServer CRD
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/stream-snippet: \| server { listen 3306; proxy_pass mysql; }` F5 NGINX Ingress Controller # stream-snippet → GlobalConfiguration + TransportServer CRD apiVersion: k8s.nginx.org/v1 kind: GlobalConfiguration metadata: name: nginx-configuration namespace: nginx-ingress spec: listeners: - name: mysql-tcp port: 3306 # from stream-snippet listen directive protocol: TCP --- apiVersion: k8s.nginx.org/v1 kind: TransportServer metadata: name: mysql-tcp spec: listener: name: mysql-tcp # references GlobalConfiguration listener protocol: TCP upstreams: - name: mysql service: mysql # from stream-snippet proxy_pass port: 3306 action: pass: mysql

CORS / Header Manipulation

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/cors-allow-credentials
nginx.ingress.kubernetes.io/cors-allow-headers
nginx.ingress.kubernetes.io/cors-allow-methods
nginx.ingress.kubernetes.io/cors-allow-origin
nginx.ingress.kubernetes.io/cors-expose-headers
nginx.ingress.kubernetes.io/cors-max-age
nginx.ingress.kubernetes.io/enable-cors Policy CRD cors + nginx.org/policies New v5.4.0— or —VirtualServer CRD responseHeaders— or —nginx.org/server-snippets

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/cors-allow-credentials` `nginx.ingress.kubernetes.io/cors-allow-headers` `nginx.ingress.kubernetes.io/cors-allow-methods` `nginx.ingress.kubernetes.io/cors-allow-origin` `nginx.ingress.kubernetes.io/cors-expose-headers` `nginx.ingress.kubernetes.io/cors-max-age` `nginx.ingress.kubernetes.io/enable-cors`	Policy CRD `cors` + `nginx.org/policies` New v5.4.0— or —VirtualServer CRD `responseHeaders`— or —`nginx.org/server-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/cors-allow-credentials: "true" nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization, Content-Type" nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, OPTIONS" nginx.ingress.kubernetes.io/cors-allow-origin: "https://frontend.example.com" nginx.ingress.kubernetes.io/cors-expose-headers: "X-Request-ID, X-Custom-Header" nginx.ingress.kubernetes.io/cors-max-age: "86400" nginx.ingress.kubernetes.io/enable-cors: "true"` F5 NGINX Ingress Controller annotations: nginx.org/server-snippets: \| # enable-cors + cors-* set $cors_origin ""; if ($http_origin ~* "^https://frontend\.example\.com$") { set $cors_origin $http_origin; } add_header Access-Control-Allow-Origin $cors_origin always; # cors-allow-origin add_header Access-Control-Allow-Credentials "true" always; # cors-allow-credentials add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always; # cors-allow-methods add_header Access-Control-Allow-Headers "Authorization, Content-Type" always; # cors-allow-headers add_header Access-Control-Expose-Headers "X-Request-ID, X-Custom-Header" always; # cors-expose-headers add_header Access-Control-Max-Age 86400 always; # cors-max-age if ($request_method = OPTIONS) { # enable-cors return 204; } Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/enable-cors: "true" nginx.ingress.kubernetes.io/cors-allow-origin: "https://frontend.example.com" nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, OPTIONS" nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization, Content-Type" nginx.ingress.kubernetes.io/cors-allow-credentials: "true" nginx.ingress.kubernetes.io/cors-expose-headers: "X-Request-ID" nginx.ingress.kubernetes.io/cors-max-age: "3600"` F5 NGINX Ingress Controller — Policy CRD # 1. Create the CORS Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: cors-policy spec: cors: allowOrigin: # cors-allow-origin - "https://frontend.example.com" allowMethods: # cors-allow-methods - "GET" - "POST" - "PUT" - "DELETE" - "OPTIONS" allowHeaders: # cors-allow-headers - "Authorization" - "Content-Type" allowCredentials: true # cors-allow-credentials exposeHeaders: # cors-expose-headers - "X-Request-ID" maxAge: 3600 # cors-max-age --- # 2. Reference from Ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.org/policies: "cors-policy" # ... rest of Ingress spec # Or reference from VirtualServer: # spec: # policies: # - name: cors-policy New in v5.4.0: The CORS Policy CRD is the recommended migration path. Create a reusable Policy and reference it via `nginx.org/policies` on Ingress or VirtualServer. Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/cors-allow-credentials: "true" nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization, Content-Type" nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, OPTIONS" nginx.ingress.kubernetes.io/cors-allow-origin: "https://frontend.example.com" nginx.ingress.kubernetes.io/cors-expose-headers: "X-Request-ID, X-Custom-Header" nginx.ingress.kubernetes.io/cors-max-age: "86400" nginx.ingress.kubernetes.io/enable-cors: "true"` F5 NGINX Ingress Controller apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: cors-app spec: host: api.example.com upstreams: - name: api-backend service: api-service port: 80 routes: - path: / action: proxy: upstream: api-backend responseHeaders: # declarative header manipulation add: - always: true name: Access-Control-Allow-Origin # cors-allow-origin value: "https://frontend.example.com" - always: true name: Access-Control-Allow-Credentials # cors-allow-credentials value: "true" - always: true name: Access-Control-Allow-Methods # cors-allow-methods value: "GET, POST, PUT, DELETE, OPTIONS" - always: true name: Access-Control-Allow-Headers # cors-allow-headers value: "Authorization, Content-Type" - always: true name: Access-Control-Expose-Headers # cors-expose-headers value: "X-Request-ID, X-Custom-Header" - always: true name: Access-Control-Max-Age # cors-max-age value: "86400" Recommended: The `responseHeaders` approach provides a fully declarative way to manage CORS and other response headers without raw NGINX snippets. Headers are set per-route via `action.proxy.responseHeaders`, and the `always` flag ensures headers are added regardless of response status code. See the VirtualServer CRD docs for additional options like `hide`, `ignore`, and `pass`.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
  nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization, Content-Type"
  nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, OPTIONS"
  nginx.ingress.kubernetes.io/cors-allow-origin: "https://frontend.example.com"
  nginx.ingress.kubernetes.io/cors-expose-headers: "X-Request-ID, X-Custom-Header"
  nginx.ingress.kubernetes.io/cors-max-age: "86400"
  nginx.ingress.kubernetes.io/enable-cors: "true"

F5 NGINX Ingress Controller

annotations:
  nginx.org/server-snippets: |  # enable-cors + cors-*
    set $cors_origin "";
    if ($http_origin ~* "^https://frontend\.example\.com$") {
        set $cors_origin $http_origin;
    }
    add_header Access-Control-Allow-Origin $cors_origin always;  # cors-allow-origin
    add_header Access-Control-Allow-Credentials "true" always;  # cors-allow-credentials
    add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;  # cors-allow-methods
    add_header Access-Control-Allow-Headers "Authorization, Content-Type" always;  # cors-allow-headers
    add_header Access-Control-Expose-Headers "X-Request-ID, X-Custom-Header" always;  # cors-expose-headers
    add_header Access-Control-Max-Age 86400 always;  # cors-max-age
    if ($request_method = OPTIONS) {  # enable-cors
        return 204;
    }

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/enable-cors: "true"
  nginx.ingress.kubernetes.io/cors-allow-origin: "https://frontend.example.com"
  nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, OPTIONS"
  nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization, Content-Type"
  nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
  nginx.ingress.kubernetes.io/cors-expose-headers: "X-Request-ID"
  nginx.ingress.kubernetes.io/cors-max-age: "3600"

F5 NGINX Ingress Controller — Policy CRD

# 1. Create the CORS Policy
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: cors-policy
spec:
  cors:
    allowOrigin:  # cors-allow-origin
      - "https://frontend.example.com"
    allowMethods:  # cors-allow-methods
      - "GET"
      - "POST"
      - "PUT"
      - "DELETE"
      - "OPTIONS"
    allowHeaders:  # cors-allow-headers
      - "Authorization"
      - "Content-Type"
    allowCredentials: true  # cors-allow-credentials
    exposeHeaders:  # cors-expose-headers
      - "X-Request-ID"
    maxAge: 3600  # cors-max-age
---
# 2. Reference from Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.org/policies: "cors-policy"
# ... rest of Ingress spec

# Or reference from VirtualServer:
# spec:
#   policies:
#     - name: cors-policy

New in v5.4.0: The CORS Policy CRD is the recommended migration path. Create a reusable Policy and reference it via nginx.org/policies on Ingress or VirtualServer.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
  nginx.ingress.kubernetes.io/cors-allow-headers: "Authorization, Content-Type"
  nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, OPTIONS"
  nginx.ingress.kubernetes.io/cors-allow-origin: "https://frontend.example.com"
  nginx.ingress.kubernetes.io/cors-expose-headers: "X-Request-ID, X-Custom-Header"
  nginx.ingress.kubernetes.io/cors-max-age: "86400"
  nginx.ingress.kubernetes.io/enable-cors: "true"

F5 NGINX Ingress Controller

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cors-app
spec:
  host: api.example.com
  upstreams:
    - name: api-backend
      service: api-service
      port: 80
  routes:
    - path: /
      action:
        proxy:
          upstream: api-backend
          responseHeaders:  # declarative header manipulation
            add:
              - always: true
                name: Access-Control-Allow-Origin  # cors-allow-origin
                value: "https://frontend.example.com"
              - always: true
                name: Access-Control-Allow-Credentials  # cors-allow-credentials
                value: "true"
              - always: true
                name: Access-Control-Allow-Methods  # cors-allow-methods
                value: "GET, POST, PUT, DELETE, OPTIONS"
              - always: true
                name: Access-Control-Allow-Headers  # cors-allow-headers
                value: "Authorization, Content-Type"
              - always: true
                name: Access-Control-Expose-Headers  # cors-expose-headers
                value: "X-Request-ID, X-Custom-Header"
              - always: true
                name: Access-Control-Max-Age  # cors-max-age
                value: "86400"

Recommended: The responseHeaders approach provides a fully declarative way to manage CORS and other response headers without raw NGINX snippets. Headers are set per-route via action.proxy.responseHeaders, and the always flag ensures headers are added regardless of response status code. See the VirtualServer CRD docs for additional options like hide, ignore, and pass.

Deprecated

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/http2-push-preload Not supported

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/http2-push-preload`	Not supported
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/http2-push-preload: "true"` F5 NGINX Ingress Controller `# Not supported — HTTP/2 Server Push was deprecated # by major browsers and removed from NGINX 1.25.1. # No migration action needed.` Note: HTTP/2 Server Push (`http2_push_preload`) was removed from NGINX in version 1.25.1 after major browsers deprecated the feature. This annotation can be safely removed during migration.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/http2-push-preload: "true"

F5 NGINX Ingress Controller

# Not supported — HTTP/2 Server Push was deprecated
# by major browsers and removed from NGINX 1.25.1.
# No migration action needed.

Note: HTTP/2 Server Push (http2_push_preload) was removed from NGINX in version 1.25.1 after major browsers deprecated the feature. This annotation can be safely removed during migration.

Error Handling

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/custom-http-errors
nginx.ingress.kubernetes.io/default-backend VirtualServer CRD errorPages[]

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/custom-http-errors` `nginx.ingress.kubernetes.io/default-backend`	VirtualServer CRD `errorPages[]`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/custom-http-errors: "404,500,502" nginx.ingress.kubernetes.io/default-backend: "error-svc"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: backend-svc port: 80 routes: - path: / action: pass: backend errorPages: # custom-http-errors - codes: [404, 500, 502] return: code: 503 body: "Service Unavailable"` No error-Service proxying: NIC `errorPages` can only `return` a canned response or `redirect` to a URL — they cannot pass the intercepted error to a `default-backend` Service the way the community controller does. To serve custom error pages from a Service, host them behind their own VirtualServer and `redirect` to it.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/custom-http-errors: "404,500,502"
  nginx.ingress.kubernetes.io/default-backend: "error-svc"

F5 NGINX Ingress Controller

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
spec:
  upstreams:
    - name: backend
      service: backend-svc
      port: 80
  routes:
    - path: /
      action:
        pass: backend
      errorPages:  # custom-http-errors
        - codes: [404, 500, 502]
          return:
            code: 503
            body: "Service Unavailable"

No error-Service proxying: NIC errorPages can only return a canned response or redirect to a URL — they cannot pass the intercepted error to a default-backend Service the way the community controller does. To serve custom error pages from a Service, host them behind their own VirtualServer and redirect to it.

Headers

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/connection-proxy-header`	VirtualServer CRD `requestHeaders.set`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/connection-proxy-header: "keep-alive"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # connection-proxy-header proxy_set_header Connection "keep-alive"; # connection-proxy-header` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/connection-proxy-header: "keep-alive"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: routes: - path: / action: proxy: upstream: my-backend requestHeaders: # connection-proxy-header set: - name: Connection value: "keep-alive"`
`nginx.ingress.kubernetes.io/custom-headers`	VirtualServer CRD `responseHeaders.add`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/custom-headers: "default/custom-headers-configmap"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: routes: - path: / action: proxy: upstream: my-backend responseHeaders: # custom-headers add: - name: X-Frame-Options value: "DENY" - name: X-Content-Type-Options value: "nosniff"`
ConfigMap `server-tokens`	`nginx.org/server-tokens`
Kubernetes Ingress NGINX (Ingress-NGINX) `# ConfigMap setting only apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: server-tokens: "false"` F5 NGINX Ingress Controller `annotations: nginx.org/server-tokens: "false"` Note: The Community controller configures server tokens via ConfigMap only. The F5 NGINX Ingress Controller provides a per-Ingress annotation.
`nginx.ingress.kubernetes.io/upstream-vhost` `nginx.ingress.kubernetes.io/x-forwarded-prefix`	VirtualServer CRD `requestHeaders.set`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/upstream-vhost: "backend.internal" nginx.ingress.kubernetes.io/x-forwarded-prefix: "/api"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: routes: - path: /api action: proxy: upstream: my-backend requestHeaders: set: - name: Host value: "backend.internal" # upstream-vhost - name: X-Forwarded-Prefix value: "/api" # x-forwarded-prefix`
No direct equivalent	`nginx.org/add-header` New v5.5.0 `nginx.org/add-header-inherit` New v5.5.0
Kubernetes Ingress NGINX (Ingress-NGINX) `# No equivalent per-Ingress annotation. # Community users typically inject add_header # directives via configuration-snippet: annotations: nginx.ingress.kubernetes.io/configuration-snippet: \| add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff";` F5 NGINX Ingress Controller `annotations: nginx.org/add-header: "X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff" nginx.org/add-header-inherit: "merge" # on \| off \| merge` New in v5.5.0: The `nginx.org/add-header` annotation adds response headers inline using a comma-separated `Name: Value` list — no snippet or external ConfigMap reference required. The `nginx.org/add-header-inherit` annotation controls how the directive is inherited from outer contexts: `on` (default — inherit), `off` (do not inherit), or `merge` (combine). Both are also available as ConfigMap keys (`add-header` and `add-header-inherit`) for global defaults.
No direct equivalent	`nginx.org/proxy-set-headers`
Kubernetes Ingress NGINX (Ingress-NGINX) `# Custom headers set via ConfigMap # proxy-set-headers in controller ConfigMap` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-set-headers: "my-custom-headers" --- # ConfigMap with custom headers apiVersion: v1 kind: ConfigMap metadata: name: my-custom-headers data: X-Custom-Header: "my-value" X-Forwarded-Proto: "$scheme"` Note: `nginx.org/proxy-set-headers` requires two resources: (1) the annotation on the Ingress, referencing a ConfigMap name, and (2) the ConfigMap itself containing header key-value pairs. Headers defined in the ConfigMap are added to all proxied requests for that Ingress. The ConfigMap must be in the same namespace as the Ingress resource.

HSTS

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
ConfigMap `hsts` ConfigMap `hsts-include-subdomains` ConfigMap `hsts-max-age` ConfigMap `hsts-preload`	`nginx.org/hsts` `nginx.org/hsts-include-subdomains` `nginx.org/hsts-max-age`
Kubernetes Ingress NGINX (Ingress-NGINX) `# ConfigMap settings only apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: hsts: "true" hsts-max-age: "31536000" hsts-include-subdomains: "true" hsts-preload: "true"` F5 NGINX Ingress Controller `annotations: nginx.org/hsts: "true" nginx.org/hsts-include-subdomains: "true" nginx.org/hsts-max-age: "31536000"` Note: HSTS annotations are F5 NGINX Ingress Controller-only and provide per-Ingress control. The community controller handles HSTS via ConfigMap only. The F5 NGINX Ingress Controller's `nginx.org/hsts` annotation includes the `preload` directive by default — there is no separate equivalent of the community `hsts-preload` ConfigMap key.
No direct equivalent	`nginx.org/hsts-behind-proxy`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No equivalent # HSTS headers are always added regardless # of proxy/load balancer presence` F5 NGINX Ingress Controller `annotations: nginx.org/hsts: "true" nginx.org/hsts-behind-proxy: "true"` Note: `nginx.org/hsts-behind-proxy` controls whether HSTS headers are added when NGINX sits behind a proxy or load balancer. When `true`, HSTS headers are added regardless of the connection protocol. This is an NIC-only feature with no community controller equivalent.

Ingress Configuration

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

No direct equivalent nginx.org/mergeable-ingress-type

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
No direct equivalent	`nginx.org/mergeable-ingress-type`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No direct equivalent # Canary/traffic-splitting uses separate # canary annotations` F5 NGINX Ingress Controller `# Master Ingress (server-level config) annotations: nginx.org/mergeable-ingress-type: "master" --- # Minion Ingress (route-level config) annotations: nginx.org/mergeable-ingress-type: "minion"` Note: Mergeable Ingress types allow splitting configuration across multiple Ingress resources for the same host. The `master` handles server-level settings while `minion` resources define individual routes.

Kubernetes Ingress NGINX (Ingress-NGINX)

# No direct equivalent
# Canary/traffic-splitting uses separate
# canary annotations

F5 NGINX Ingress Controller

# Master Ingress (server-level config)
annotations:
  nginx.org/mergeable-ingress-type: "master"
---
# Minion Ingress (route-level config)
annotations:
  nginx.org/mergeable-ingress-type: "minion"

Note: Mergeable Ingress types allow splitting configuration across multiple Ingress resources for the same host. The master handles server-level settings while minion resources define individual routes.

Load Balancing

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/load-balance`	VirtualServer CRD `upstreams[].lb-method`— or —`nginx.org/lb-method`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/load-balance: "ewma"` F5 NGINX Ingress Controller `annotations: nginx.org/lb-method: "least_conn"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/load-balance: "ewma"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 lb-method: "least_conn" # load-balance` Note: Supported methods differ. The F5 NGINX Ingress Controller supports: `round_robin`, `least_conn`, `ip_hash`, `hash`, `random`, `random two`, and `random two least_conn` (NGINX Plus adds `least_time` variants). The community controller's `ewma` method is not supported — the closest equivalent is `least_conn`. The F5 NGINX Ingress Controller's default is `random two least_conn` (not `round_robin`), so load balancing behavior may change even without explicit configuration.
`nginx.ingress.kubernetes.io/service-upstream`	VirtualServer CRD `upstreams[].use-cluster-ip`— or —`nginx.org/use-cluster-ip`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/service-upstream: "true"` F5 NGINX Ingress Controller `annotations: nginx.org/use-cluster-ip: "true"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/service-upstream: "true"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 use-cluster-ip: true # service-upstream`
`nginx.ingress.kubernetes.io/upstream-hash-by` `nginx.ingress.kubernetes.io/upstream-hash-by-subset` `nginx.ingress.kubernetes.io/upstream-hash-by-subset-size`	VirtualServer CRD `upstreams[].lb-method`— or —`nginx.org/lb-method`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$request_uri"` F5 NGINX Ingress Controller `annotations: nginx.org/lb-method: "hash $request_uri consistent"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/upstream-hash-by: "$request_uri" nginx.ingress.kubernetes.io/upstream-hash-by-subset: "true" nginx.ingress.kubernetes.io/upstream-hash-by-subset-size: "3"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 lb-method: "hash $request_uri consistent" # upstream-hash-by` Note: The F5 NGINX Ingress Controller has no dedicated `upstream-hash-by` equivalent. Instead, the hash key is specified as part of the `lb-method` value (e.g., `hash $request_uri consistent`). Subset hashing (`upstream-hash-by-subset`) is not supported; use `consistent` hashing for similar distribution.

Logging

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/enable-access-log`	ConfigMap `access-log-off`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/enable-access-log: "false"` F5 NGINX Ingress Controller `# Set via ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: access-log-off: "true"` Note: The community `enable-access-log` annotation is per-Ingress (disable access logging for a single Ingress), but NIC's `access-log-off` is a global ConfigMap key applied to the whole controller — there is no per-Ingress equivalent.
`nginx.ingress.kubernetes.io/enable-rewrite-log`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/enable-rewrite-log: "true"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # enable-rewrite-log rewrite_log on; # enable-rewrite-log` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/enable-rewrite-log: "true"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # enable-rewrite-log rewrite_log on; # enable-rewrite-log action: pass: backend` Note: The F5 NGINX Ingress Controller does not have a dedicated `rewrite-log` ConfigMap key. Use `location-snippets` to enable the `rewrite_log` directive. Rewrite logging outputs to the error log at `notice` level.

Request Mirroring

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/mirror-host
nginx.ingress.kubernetes.io/mirror-request-body
nginx.ingress.kubernetes.io/mirror-target VirtualServer CRD location-snippets / VirtualServer CRD server-snippets— or —nginx.org/location-snippets
nginx.org/server-snippets

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/mirror-host` `nginx.ingress.kubernetes.io/mirror-request-body` `nginx.ingress.kubernetes.io/mirror-target`	VirtualServer CRD `location-snippets` / VirtualServer CRD `server-snippets`— or —`nginx.org/location-snippets` `nginx.org/server-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/mirror-host: "mirror.example.com" nginx.ingress.kubernetes.io/mirror-request-body: "on" nginx.ingress.kubernetes.io/mirror-target: "https://mirror.example.com$request_uri"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # mirror-target + mirror-request-body mirror /mirror; # mirror-target mirror_request_body on; # mirror-request-body nginx.org/server-snippets: \| # mirror-host + mirror-target location /mirror { internal; proxy_set_header Host mirror.example.com; # mirror-host proxy_pass https://mirror.example.com$request_uri; # mirror-target }` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/mirror-host: "mirror.example.com" nginx.ingress.kubernetes.io/mirror-request-body: "on" nginx.ingress.kubernetes.io/mirror-target: "https://mirror.example.com$request_uri"` F5 NGINX Ingress Controller apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com server-snippets: \| # mirror-host + mirror-target location /mirror { internal; proxy_set_header Host mirror.example.com; # mirror-host proxy_pass https://mirror.example.com$request_uri; # mirror-target } upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # mirror-target + mirror-request-body mirror /mirror; # mirror-target mirror_request_body on; # mirror-request-body action: pass: backend

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/mirror-host: "mirror.example.com"
  nginx.ingress.kubernetes.io/mirror-request-body: "on"
  nginx.ingress.kubernetes.io/mirror-target: "https://mirror.example.com$request_uri"

F5 NGINX Ingress Controller

annotations:
  nginx.org/location-snippets: |  # mirror-target + mirror-request-body
    mirror /mirror;  # mirror-target
    mirror_request_body on;  # mirror-request-body
  nginx.org/server-snippets: |  # mirror-host + mirror-target
    location /mirror {
      internal;
      proxy_set_header Host mirror.example.com;  # mirror-host
      proxy_pass https://mirror.example.com$request_uri;  # mirror-target
    }

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/mirror-host: "mirror.example.com"
  nginx.ingress.kubernetes.io/mirror-request-body: "on"
  nginx.ingress.kubernetes.io/mirror-target: "https://mirror.example.com$request_uri"

F5 NGINX Ingress Controller

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: my-app
spec:
  host: app.example.com
  server-snippets: |  # mirror-host + mirror-target
    location /mirror {
      internal;
      proxy_set_header Host mirror.example.com;  # mirror-host
      proxy_pass https://mirror.example.com$request_uri;  # mirror-target
    }
  upstreams:
    - name: backend
      service: backend-svc
      port: 80
  routes:
    - path: /
      location-snippets: |  # mirror-target + mirror-request-body
        mirror /mirror;  # mirror-target
        mirror_request_body on;  # mirror-request-body
      action:
        pass: backend

mTLS (Client Certificate Verification)

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/auth-tls-error-page` `nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream` `nginx.ingress.kubernetes.io/auth-tls-secret` `nginx.ingress.kubernetes.io/auth-tls-verify-client` `nginx.ingress.kubernetes.io/auth-tls-verify-depth`	Policy CRD `ingressMTLS` + `nginx.org/policies` New v5.5.0— or —Policy CRD `ingressMTLS` + VirtualServer `policies[]`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-tls-error-page: "https://example.com/cert-error" nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true" nginx.ingress.kubernetes.io/auth-tls-secret: "ns/ca-secret" nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" nginx.ingress.kubernetes.io/auth-tls-verify-depth: "2"` F5 NGINX Ingress Controller # 1. Create the IngressMTLS Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: ingress-mtls spec: ingressMTLS: clientCertSecret: ca-secret # auth-tls-secret verifyClient: "on" # auth-tls-verify-client verifyDepth: 2 # auth-tls-verify-depth --- # 2. Reference from Ingress (new in v5.5.0) # auth-tls-pass-certificate-to-upstream → location-snippets # auth-tls-error-page → server-snippets apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.org/policies: "ingress-mtls" nginx.org/location-snippets: \| # auth-tls-pass-certificate-to-upstream proxy_set_header ssl-client-cert $ssl_client_escaped_cert; nginx.org/server-snippets: \| # auth-tls-error-page error_page 495 496 = https://example.com/cert-error; # ... rest of Ingress spec New in v5.5.0: The `ingressMTLS` Policy CRD can now be referenced directly from Ingress resources using the `nginx.org/policies` annotation. This is the simplest migration path — you stay on Ingress resources. Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-tls-error-page: "https://example.com/cert-error" nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true" nginx.ingress.kubernetes.io/auth-tls-secret: "ns/ca-secret" nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" nginx.ingress.kubernetes.io/auth-tls-verify-depth: "2"` F5 NGINX Ingress Controller # 1. Create the IngressMTLS Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: ingress-mtls spec: ingressMTLS: clientCertSecret: ca-secret # auth-tls-secret verifyClient: "on" # auth-tls-verify-client verifyDepth: 2 # auth-tls-verify-depth --- # 2. Reference from VirtualServer apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com policies: - name: ingress-mtls server-snippets: \| # auth-tls-error-page error_page 495 496 = https://example.com/cert-error; upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # auth-tls-pass-certificate-to-upstream proxy_set_header ssl-client-cert $ssl_client_escaped_cert; action: pass: backend Note: The VirtualServer approach has been available since before v5.5.0. Use this if you are already migrating to VirtualServer resources for other reasons (e.g., advanced routing, traffic splitting).
`nginx.ingress.kubernetes.io/auth-tls-match-cn`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-tls-match-cn: "CN=client-[0-9]+"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # auth-tls-match-cn if ($ssl_client_s_dn !~ "CN=client-[0-9]+") { # auth-tls-match-cn return 403; }` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/auth-tls-match-cn: "CN=client-[0-9]+"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # auth-tls-match-cn if ($ssl_client_s_dn !~ "CN=client-[0-9]+") { return 403; } action: pass: backend` Note: The F5 NGINX Ingress Controller's `ingressMTLS` Policy does not have a built-in CN matching feature. Use `location-snippets` to add custom CN validation logic.

mTLS (Backend/Egress)

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/proxy-ssl-ciphers
nginx.ingress.kubernetes.io/proxy-ssl-name
nginx.ingress.kubernetes.io/proxy-ssl-protocols
nginx.ingress.kubernetes.io/proxy-ssl-secret
nginx.ingress.kubernetes.io/proxy-ssl-server-name
nginx.ingress.kubernetes.io/proxy-ssl-verify
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth Policy CRD egressMTLS + nginx.org/policies New v5.5.0— or —Policy CRD egressMTLS + VirtualServer policies[]

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/proxy-ssl-ciphers` `nginx.ingress.kubernetes.io/proxy-ssl-name` `nginx.ingress.kubernetes.io/proxy-ssl-protocols` `nginx.ingress.kubernetes.io/proxy-ssl-secret` `nginx.ingress.kubernetes.io/proxy-ssl-server-name` `nginx.ingress.kubernetes.io/proxy-ssl-verify` `nginx.ingress.kubernetes.io/proxy-ssl-verify-depth`	Policy CRD `egressMTLS` + `nginx.org/policies` New v5.5.0— or —Policy CRD `egressMTLS` + VirtualServer `policies[]`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "HIGH:!aNULL:!MD5" nginx.ingress.kubernetes.io/proxy-ssl-name: "backend.example.com" nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2 TLSv1.3" nginx.ingress.kubernetes.io/proxy-ssl-secret: "ns/client-cert" nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on" nginx.ingress.kubernetes.io/proxy-ssl-verify: "on" nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "2"` F5 NGINX Ingress Controller # 1. Create the EgressMTLS Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: egress-mtls spec: egressMTLS: ciphers: "HIGH:!aNULL:!MD5" # proxy-ssl-ciphers sslName: "backend.example.com" # proxy-ssl-name protocols: "TLSv1.2 TLSv1.3" # proxy-ssl-protocols tlsSecret: client-cert # proxy-ssl-secret serverName: true # proxy-ssl-server-name verifyServer: true # proxy-ssl-verify verifyDepth: 2 # proxy-ssl-verify-depth trustedCertSecret: ca-cert --- # 2. Reference from Ingress (new in v5.5.0) apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.org/policies: "egress-mtls" nginx.org/ssl-services: "secure-app" # opt-in upstream(s) to TLS # ... rest of Ingress spec New in v5.5.0: The `egressMTLS` Policy CRD can now be referenced directly from Ingress resources using the `nginx.org/policies` annotation. This is the simplest migration path — you stay on Ingress resources. Combine with `nginx.org/ssl-services` to identify which backend services should use TLS. Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "HIGH:!aNULL:!MD5" nginx.ingress.kubernetes.io/proxy-ssl-name: "backend.example.com" nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2 TLSv1.3" nginx.ingress.kubernetes.io/proxy-ssl-secret: "ns/client-cert" nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on" nginx.ingress.kubernetes.io/proxy-ssl-verify: "on" nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "2"` F5 NGINX Ingress Controller # 1. Create the EgressMTLS Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: egress-mtls spec: egressMTLS: ciphers: "HIGH:!aNULL:!MD5" # proxy-ssl-ciphers sslName: "backend.example.com" # proxy-ssl-name protocols: "TLSv1.2 TLSv1.3" # proxy-ssl-protocols tlsSecret: client-cert # proxy-ssl-secret serverName: true # proxy-ssl-server-name verifyServer: true # proxy-ssl-verify verifyDepth: 2 # proxy-ssl-verify-depth trustedCertSecret: ca-cert --- # 2. Reference from VirtualServer apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com policies: - name: egress-mtls upstreams: - name: secure-app service: secure-app-svc port: 443 tls: enable: true routes: - path: / action: pass: secure-app Note: The VirtualServer approach has been available since before v5.5.0. TLS to upstream is enabled per-upstream via `tls.enable: true` (replacing the Ingress-level `nginx.org/ssl-services` annotation).

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "HIGH:!aNULL:!MD5"
  nginx.ingress.kubernetes.io/proxy-ssl-name: "backend.example.com"
  nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2 TLSv1.3"
  nginx.ingress.kubernetes.io/proxy-ssl-secret: "ns/client-cert"
  nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on"
  nginx.ingress.kubernetes.io/proxy-ssl-verify: "on"
  nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "2"

F5 NGINX Ingress Controller

# 1. Create the EgressMTLS Policy
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: egress-mtls
spec:
  egressMTLS:
    ciphers: "HIGH:!aNULL:!MD5"  # proxy-ssl-ciphers
    sslName: "backend.example.com"  # proxy-ssl-name
    protocols: "TLSv1.2 TLSv1.3"  # proxy-ssl-protocols
    tlsSecret: client-cert  # proxy-ssl-secret
    serverName: true  # proxy-ssl-server-name
    verifyServer: true  # proxy-ssl-verify
    verifyDepth: 2  # proxy-ssl-verify-depth
    trustedCertSecret: ca-cert
---
# 2. Reference from Ingress (new in v5.5.0)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.org/policies: "egress-mtls"
    nginx.org/ssl-services: "secure-app"  # opt-in upstream(s) to TLS
# ... rest of Ingress spec

New in v5.5.0: The egressMTLS Policy CRD can now be referenced directly from Ingress resources using the nginx.org/policies annotation. This is the simplest migration path — you stay on Ingress resources. Combine with nginx.org/ssl-services to identify which backend services should use TLS.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "HIGH:!aNULL:!MD5"
  nginx.ingress.kubernetes.io/proxy-ssl-name: "backend.example.com"
  nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2 TLSv1.3"
  nginx.ingress.kubernetes.io/proxy-ssl-secret: "ns/client-cert"
  nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on"
  nginx.ingress.kubernetes.io/proxy-ssl-verify: "on"
  nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "2"

F5 NGINX Ingress Controller

# 1. Create the EgressMTLS Policy
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: egress-mtls
spec:
  egressMTLS:
    ciphers: "HIGH:!aNULL:!MD5"  # proxy-ssl-ciphers
    sslName: "backend.example.com"  # proxy-ssl-name
    protocols: "TLSv1.2 TLSv1.3"  # proxy-ssl-protocols
    tlsSecret: client-cert  # proxy-ssl-secret
    serverName: true  # proxy-ssl-server-name
    verifyServer: true  # proxy-ssl-verify
    verifyDepth: 2  # proxy-ssl-verify-depth
    trustedCertSecret: ca-cert
---
# 2. Reference from VirtualServer
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: my-app
spec:
  host: app.example.com
  policies:
    - name: egress-mtls
  upstreams:
    - name: secure-app
      service: secure-app-svc
      port: 443
      tls:
        enable: true
  routes:
    - path: /
      action:
        pass: secure-app

Note: The VirtualServer approach has been available since before v5.5.0. TLS to upstream is enabled per-upstream via tls.enable: true (replacing the Ingress-level nginx.org/ssl-services annotation).

ModSecurity / WAF

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/enable-modsecurity
nginx.ingress.kubernetes.io/enable-owasp-core-rules
nginx.ingress.kubernetes.io/modsecurity-snippet
nginx.ingress.kubernetes.io/modsecurity-transaction-id No direct replacement (OSS) — see WAF (Plus)

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/enable-modsecurity` `nginx.ingress.kubernetes.io/enable-owasp-core-rules` `nginx.ingress.kubernetes.io/modsecurity-snippet` `nginx.ingress.kubernetes.io/modsecurity-transaction-id`	No direct replacement (OSS) — see WAF (Plus)
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/enable-modsecurity: "true" nginx.ingress.kubernetes.io/enable-owasp-core-rules: "true" nginx.ingress.kubernetes.io/modsecurity-snippet: \| SecRuleEngine On SecRule ARGS "@contains <script>" "id:1,deny,status:403" nginx.ingress.kubernetes.io/modsecurity-transaction-id: "$request_id"` F5 NGINX Ingress Controller `# No direct OSS replacement # For WAF capabilities, see the Plus WAF section # which uses the F5 WAF for NGINX (App Protect)` No OSS Equivalent: The F5 NGINX Ingress Controller does not include ModSecurity or any built-in WAF module. For WAF capabilities, F5 WAF for NGINX is available with NGINX Plus — see the WAF section in Plus Mappings for migration examples. Note: The community controller's ModSecurity support relies on a third-party module compiled into the controller image — it is not a native Kubernetes-integrated WAF solution. Neither controller provides an open-source WAF alternative.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/enable-modsecurity: "true"
  nginx.ingress.kubernetes.io/enable-owasp-core-rules: "true"
  nginx.ingress.kubernetes.io/modsecurity-snippet: |
    SecRuleEngine On
    SecRule ARGS "@contains <script>" "id:1,deny,status:403"
  nginx.ingress.kubernetes.io/modsecurity-transaction-id: "$request_id"

F5 NGINX Ingress Controller

# No direct OSS replacement
# For WAF capabilities, see the Plus WAF section
# which uses the F5 WAF for NGINX (App Protect)

No OSS Equivalent: The F5 NGINX Ingress Controller does not include ModSecurity or any built-in WAF module. For WAF capabilities, F5 WAF for NGINX is available with NGINX Plus — see the WAF section in Plus Mappings for migration examples.

Note: The community controller's ModSecurity support relies on a third-party module compiled into the controller image — it is not a native Kubernetes-integrated WAF solution. Neither controller provides an open-source WAF alternative.

OpenTelemetry

Key difference: The community controller supports per-Ingress OpenTelemetry control via annotations (enable-opentelemetry, opentelemetry-trust-incoming-span). The F5 NGINX Ingress Controller configures OpenTelemetry globally via ConfigMap — tracing applies to all routes when enabled. Per-Ingress toggling is not supported.

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/enable-opentelemetry`	ConfigMap `otel-trace-in-http`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/enable-opentelemetry: "true"` F5 NGINX Ingress Controller `# Global ConfigMap configuration (applies to all routes) apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: otel-trace-in-http: "true" # enable-opentelemetry otel-exporter-endpoint: "otel-collector:4317" # required: collector address otel-service-name: "nginx-ingress" # optional: service name for traces` Note: `otel-trace-in-http` is the direct replacement for `enable-opentelemetry`. Additional ConfigMap keys: `otel-exporter-endpoint` (required), `otel-service-name`, `otel-exporter-header-name`, `otel-exporter-header-value`. Unlike the community annotation, this enables tracing globally — not per-Ingress.
`nginx.ingress.kubernetes.io/opentelemetry-trust-incoming-span`	No direct equivalent (tracing is global-only)
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/opentelemetry-trust-incoming-span: "true"` F5 NGINX Ingress Controller `# No per-Ingress equivalent. NIC does not set otel_trace_context, # so the ngx_otel_module default applies and incoming trace # context is NOT propagated by default (community default: trust). # To enable tracing globally: apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: otel-trace-in-http: "true" otel-exporter-endpoint: "otel-collector:4317"` Note: The community controller's `opentelemetry-trust-incoming-span` (default `true`) enables per-Ingress control over whether to trust incoming trace context (W3C Trace Context propagation). The F5 NGINX Ingress Controller has no per-Ingress equivalent, and it does not set `otel_trace_context` — so the `ngx_otel_module` default applies and incoming trace context is not propagated by default (a behavior difference from the community default). The annotation can be removed during migration.
No direct equivalent	ConfigMap `otel-exporter-endpoint` ConfigMap `otel-exporter-header-name` ConfigMap `otel-exporter-header-value` ConfigMap `otel-service-name`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No equivalent ConfigMap keys # The community controller configures the # OTel collector via its own internal config` F5 NGINX Ingress Controller `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: otel-exporter-endpoint: "otel-collector:4317" # required: collector address otel-exporter-header-name: "Authorization" # optional: auth header name otel-exporter-header-value: "Bearer token" # optional: auth header value otel-service-name: "my-app" # optional: service name for traces` Note: These ConfigMap keys are NIC-only and configure the OpenTelemetry exporter. `otel-exporter-endpoint` is required when tracing is enabled. `otel-service-name` sets the service name in traces (defaults to `nginx-ingress`). `otel-exporter-header-name` and `otel-exporter-header-value` add custom headers to exporter requests (e.g., for authentication).

Passive Health Checks

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

No direct equivalent VirtualServer CRD upstreams[].fail-timeout
VirtualServer CRD upstreams[].max-fails— or —nginx.org/fail-timeout
nginx.org/max-fails

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
No direct equivalent	VirtualServer CRD `upstreams[].fail-timeout` VirtualServer CRD `upstreams[].max-fails`— or —`nginx.org/fail-timeout` `nginx.org/max-fails`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No passive health check settings — the community # controller's load balancer does not support # max_fails / fail_timeout; failed upstreams are # handled via proxy-next-upstream retries only.` F5 NGINX Ingress Controller `# Per-Ingress annotations: annotations: nginx.org/fail-timeout: "30s" nginx.org/max-fails: "3"` Note: The community controller has no passive health check tuning — its load balancer does not support `max_fails`/`fail_timeout`, and upstream failures are handled through `proxy-next-upstream` retries (see Proxy Settings). The F5 NGINX Ingress Controller adds per-upstream passive health checks via the `nginx.org/max-fails` and `nginx.org/fail-timeout` annotations. Kubernetes Ingress NGINX (Ingress-NGINX) `# No passive health check settings — the community # controller's load balancer does not support # max_fails / fail_timeout; failed upstreams are # handled via proxy-next-upstream retries only.` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 fail-timeout: 30s max-fails: 3` Note: The VirtualServer CRD allows passive health check settings per upstream. For active health checks that proactively probe endpoints, see Active Health Checks in Plus Mappings.

Kubernetes Ingress NGINX (Ingress-NGINX)

# No passive health check settings — the community
# controller's load balancer does not support
# max_fails / fail_timeout; failed upstreams are
# handled via proxy-next-upstream retries only.

F5 NGINX Ingress Controller

# Per-Ingress annotations:
annotations:
  nginx.org/fail-timeout: "30s"
  nginx.org/max-fails: "3"

Note: The community controller has no passive health check tuning — its load balancer does not support max_fails/fail_timeout, and upstream failures are handled through proxy-next-upstream retries (see Proxy Settings). The F5 NGINX Ingress Controller adds per-upstream passive health checks via the nginx.org/max-fails and nginx.org/fail-timeout annotations.

Kubernetes Ingress NGINX (Ingress-NGINX)

# No passive health check settings — the community
# controller's load balancer does not support
# max_fails / fail_timeout; failed upstreams are
# handled via proxy-next-upstream retries only.

F5 NGINX Ingress Controller

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
spec:
  upstreams:
    - name: backend
      service: my-service
      port: 80
      fail-timeout: 30s
      max-fails: 3

Note: The VirtualServer CRD allows passive health check settings per upstream. For active health checks that proactively probe endpoints, see Active Health Checks in Plus Mappings.

Proxy Settings

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/proxy-http-version`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-http-version: "1.1"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # proxy-http-version proxy_http_version 1.1; # proxy-http-version` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-http-version: "1.1"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # proxy-http-version proxy_http_version 1.1; # proxy-http-version action: pass: backend` Note: The F5 NGINX Ingress Controller does not have a dedicated annotation for HTTP version. Use `location-snippets` to set `proxy_http_version` directly.
`nginx.ingress.kubernetes.io/proxy-next-upstream` `nginx.ingress.kubernetes.io/proxy-next-upstream-timeout` `nginx.ingress.kubernetes.io/proxy-next-upstream-tries`	VirtualServer CRD `upstreams[].next-upstream` VirtualServer CRD `upstreams[].next-upstream-timeout` VirtualServer CRD `upstreams[].next-upstream-tries`— or —`nginx.org/proxy-next-upstream` New v5.4.0 `nginx.org/proxy-next-upstream-timeout` New v5.4.0 `nginx.org/proxy-next-upstream-tries` New v5.4.0
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-next-upstream: "error timeout" nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "30" nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "3"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-next-upstream: "error timeout" nginx.org/proxy-next-upstream-timeout: "30s" nginx.org/proxy-next-upstream-tries: "3"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-next-upstream: "error timeout" nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: "30" nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "3"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 next-upstream: "error timeout" # proxy-next-upstream next-upstream-timeout: 30s # proxy-next-upstream-timeout next-upstream-tries: 3 # proxy-next-upstream-tries` New in v5.4.0: The `nginx.org/proxy-next-upstream`, `nginx.org/proxy-next-upstream-timeout`, and `nginx.org/proxy-next-upstream-tries` annotations are new. They provide direct 1:1 mappings from the community annotations without requiring a VirtualServer CRD.

Rate Limiting

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/limit-burst-multiplier` `nginx.ingress.kubernetes.io/limit-connections` `nginx.ingress.kubernetes.io/limit-rate` `nginx.ingress.kubernetes.io/limit-rate-after` `nginx.ingress.kubernetes.io/limit-rpm` `nginx.ingress.kubernetes.io/limit-rps` `nginx.ingress.kubernetes.io/limit-whitelist`	Policy CRD `rateLimit`— or —`nginx.org/limit-req-burst` `nginx.org/limit-req-rate` `nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/limit-burst-multiplier: "5" nginx.ingress.kubernetes.io/limit-connections: "5" nginx.ingress.kubernetes.io/limit-rate: "100" nginx.ingress.kubernetes.io/limit-rate-after: "1024" nginx.ingress.kubernetes.io/limit-rpm: "300" nginx.ingress.kubernetes.io/limit-rps: "10" nginx.ingress.kubernetes.io/limit-whitelist: "10.0.0.0/8,172.16.0.0/12"` F5 NGINX Ingress Controller annotations: nginx.org/limit-req-burst: "50" # limit-burst-multiplier (limit-rps × multiplier) nginx.org/limit-req-rate: "10r/s" # limit-rps (also covers limit-rpm) # limit-connections, limit-rate, limit-rate-after, limit-whitelist # → use location-snippets: nginx.org/location-snippets: \| # limit-connections / limit-rate / limit-rate-after limit_conn addr 5; # limit-connections limit_rate 100k; # limit-rate limit_rate_after 1024k; # limit-rate-after (community value is kilobytes) # limit-whitelist → use geo module or map in server-snippets Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/limit-burst-multiplier: "5" nginx.ingress.kubernetes.io/limit-connections: "5" nginx.ingress.kubernetes.io/limit-rate: "100" nginx.ingress.kubernetes.io/limit-rate-after: "1024" nginx.ingress.kubernetes.io/limit-rpm: "300" nginx.ingress.kubernetes.io/limit-rps: "10" nginx.ingress.kubernetes.io/limit-whitelist: "10.0.0.0/8,172.16.0.0/12"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: rate-limit spec: rateLimit: burst: 50 # limit-rps × limit-burst-multiplier key: ${binary_remote_addr} rate: 10r/s # limit-rps rejectCode: 429 zoneSize: 10M` Note: The rateLimit Policy CRD covers `limit-rps`, `limit-rpm` (as `rate` in `r/m`), and `limit-burst-multiplier`. The community annotations `limit-connections`, `limit-rate`, `limit-rate-after`, and `limit-whitelist` have no Policy CRD equivalents — use `location-snippets` for those (see the Annotation Approach).
ConfigMap `limit-req-status-code`	`nginx.org/limit-req-reject-code`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: limit-req-status-code: "429"` F5 NGINX Ingress Controller `annotations: nginx.org/limit-req-reject-code: "429"` Note: The community controller sets the rate limit rejection status code globally via ConfigMap. The F5 NGINX Ingress Controller sets it per-Ingress via the `nginx.org/limit-req-reject-code` annotation (default: 429).
No direct equivalent	`nginx.org/limit-req-delay` `nginx.org/limit-req-dry-run` `nginx.org/limit-req-key` `nginx.org/limit-req-log-level` `nginx.org/limit-req-no-delay` `nginx.org/limit-req-reject-code` `nginx.org/limit-req-scale` `nginx.org/limit-req-zone-size`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No equivalents for these fine-grained # rate limiting controls` F5 NGINX Ingress Controller `annotations: nginx.org/limit-req-rate: "10r/s" nginx.org/limit-req-burst: "50" nginx.org/limit-req-key: "${binary_remote_addr}" nginx.org/limit-req-delay: "5" nginx.org/limit-req-no-delay: "true" nginx.org/limit-req-zone-size: "10M" nginx.org/limit-req-reject-code: "429" nginx.org/limit-req-log-level: "warn" nginx.org/limit-req-dry-run: "false" nginx.org/limit-req-scale: "true"` Note: These NIC-only annotations provide fine-grained rate limiting control. `limit-req-key` customizes the rate limiting key (default: `${binary_remote_addr}`). `limit-req-scale` divides the rate by pod count for consistency during autoscaling. `limit-req-reject-code` sets the response code for rejected requests (default: 429). `limit-req-dry-run` enables logging without enforcing limits.

Redirects

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/from-to-www-redirect
nginx.ingress.kubernetes.io/permanent-redirect
nginx.ingress.kubernetes.io/permanent-redirect-code
nginx.ingress.kubernetes.io/temporal-redirect
nginx.ingress.kubernetes.io/temporal-redirect-code VirtualServer CRD action.redirect

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/from-to-www-redirect` `nginx.ingress.kubernetes.io/permanent-redirect` `nginx.ingress.kubernetes.io/permanent-redirect-code` `nginx.ingress.kubernetes.io/temporal-redirect` `nginx.ingress.kubernetes.io/temporal-redirect-code`	VirtualServer CRD `action.redirect`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/permanent-redirect: "https://new.example.com" nginx.ingress.kubernetes.io/permanent-redirect-code: "308" # Or for temporary redirects: # nginx.ingress.kubernetes.io/temporal-redirect: "https://maintenance.example.com" # nginx.ingress.kubernetes.io/temporal-redirect-code: "307" # Or for www redirect: # nginx.ingress.kubernetes.io/from-to-www-redirect: "true"` F5 NGINX Ingress Controller apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: host: old.example.com routes: - path: / action: redirect: url: https://new.example.com # permanent-redirect (redirects to the exact URL; no path appended) code: 308 # permanent-redirect-code # temporal-redirect + temporal-redirect-code: # - path: /maintenance # action: # redirect: # url: https://maintenance.example.com # code: 307 # from-to-www-redirect → separate VirtualServer: # server-snippets: \| # return 301 https://www.example.com$request_uri;

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/permanent-redirect: "https://new.example.com"
  nginx.ingress.kubernetes.io/permanent-redirect-code: "308"
  # Or for temporary redirects:
  # nginx.ingress.kubernetes.io/temporal-redirect: "https://maintenance.example.com"
  # nginx.ingress.kubernetes.io/temporal-redirect-code: "307"
  # Or for www redirect:
  # nginx.ingress.kubernetes.io/from-to-www-redirect: "true"

F5 NGINX Ingress Controller

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
spec:
  host: old.example.com
  routes:
    - path: /
      action:
        redirect:
          url: https://new.example.com  # permanent-redirect (redirects to the exact URL; no path appended)
          code: 308  # permanent-redirect-code
  # temporal-redirect + temporal-redirect-code:
  # - path: /maintenance
  #   action:
  #     redirect:
  #       url: https://maintenance.example.com
  #       code: 307
  # from-to-www-redirect → separate VirtualServer:
  # server-snippets: |
  #   return 301 https://www.example.com$request_uri;

Rewrites

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/app-root` `nginx.ingress.kubernetes.io/rewrite-target` `nginx.ingress.kubernetes.io/use-regex`	VirtualServer CRD `rewritePath`— or —`nginx.org/app-root` New v5.4.0 `nginx.org/path-regex` `nginx.org/rewrite-target`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/app-root: "/dashboard" nginx.ingress.kubernetes.io/rewrite-target: /$2 nginx.ingress.kubernetes.io/use-regex: "true" # Used with Ingress path: /api(/\|$)(.)` F5 NGINX Ingress Controller `annotations: nginx.org/app-root: "/dashboard" nginx.org/path-regex: "case_sensitive" nginx.org/rewrite-target: /$2` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/app-root: "/dashboard" nginx.ingress.kubernetes.io/rewrite-target: /$2 nginx.ingress.kubernetes.io/use-regex: "true" # Used with Ingress path: /api(/\|$)(.)` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: routes: - path: / action: redirect: url: /dashboard # app-root code: 302 - path: ~ ^/api(/\|$)(.) # use-regex action: proxy: upstream: api rewritePath: /$2 # rewrite-target` New in v5.4.0:* The `nginx.org/app-root` annotation is new. It provides a direct 1:1 mapping from the community `app-root` annotation without requiring a VirtualServer CRD.
`nginx.ingress.kubernetes.io/proxy-cookie-domain` `nginx.ingress.kubernetes.io/proxy-cookie-path`	VirtualServer CRD `location-snippets`— or —`nginx.org/location-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-cookie-domain: "internal.example.com external.example.com" nginx.ingress.kubernetes.io/proxy-cookie-path: "/internal/ /external/"` F5 NGINX Ingress Controller `annotations: nginx.org/location-snippets: \| # proxy-cookie-domain / proxy-cookie-path proxy_cookie_domain internal.example.com external.example.com; # proxy-cookie-domain proxy_cookie_path /internal/ /external/; # proxy-cookie-path` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-cookie-domain: "internal.example.com external.example.com" nginx.ingress.kubernetes.io/proxy-cookie-path: "/internal/ /external/"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com upstreams: - name: backend service: backend-svc port: 80 routes: - path: / location-snippets: \| # proxy-cookie-domain / proxy-cookie-path proxy_cookie_domain internal.example.com external.example.com; proxy_cookie_path /internal/ /external/; action: pass: backend` Note: The F5 NGINX Ingress Controller does not have dedicated annotations for proxy cookie rewriting. Use `location-snippets` to configure `proxy_cookie_domain` and `proxy_cookie_path` directives.
`nginx.ingress.kubernetes.io/proxy-redirect-from` `nginx.ingress.kubernetes.io/proxy-redirect-to`	`nginx.org/proxy-redirect-from` New v5.5.0 `nginx.org/proxy-redirect-to` New v5.5.0
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-redirect-from: "http://internal/" nginx.ingress.kubernetes.io/proxy-redirect-to: "https://external/"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-redirect-from: "http://internal/" # proxy-redirect-from nginx.org/proxy-redirect-to: "https://external/" # proxy-redirect-to` New in v5.5.0: The `nginx.org/proxy-redirect-from` and `nginx.org/proxy-redirect-to` annotations are new and provide direct 1:1 mappings from the community annotations. The `from` value also accepts `off`, `default`, or a regex prefixed with `~`/`~*`.
No direct equivalent	`nginx.org/rewrites` (per-service URL rewriting)
Kubernetes Ingress NGINX (Ingress-NGINX) `# No per-service rewrite equivalent # rewrite-target applies globally to all # backends in the Ingress resource` F5 NGINX Ingress Controller `annotations: nginx.org/rewrites: "serviceName=tea-svc rewrite=/;serviceName=coffee-svc rewrite=/beans"` Note: `nginx.org/rewrites` enables per-service URL rewriting within a single Ingress resource. Each semicolon-separated entry specifies a service name and its rewrite path. This is an NIC-only feature with no community controller equivalent.

Route Delegation

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/server-alias`	VirtualServer CRD one resource per hostname— or —`nginx.org/server-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/server-alias: "alias.example.com"` F5 NGINX Ingress Controller `annotations: nginx.org/server-snippets: \| # server-alias server_name alias.example.com; # server-alias` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/server-alias: "alias.example.com"` F5 NGINX Ingress Controller `# server-alias → separate VirtualServer per host apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: alias-app spec: host: alias.example.com # server-alias upstreams: - name: backend service: backend-svc port: 80 routes: - path: / action: pass: backend` Note: The community `server-alias` annotation adds an additional hostname to the same NGINX server block. The F5 NGINX Ingress Controller does not have an equivalent annotation — instead, create a separate VirtualServer resource for each hostname, all pointing to the same backend service. Alternatively, use `nginx.org/server-snippets` to add additional `server_name` directives.
No direct equivalent	VirtualServerRoute CRD `routes[].route`
Tip: This feature requires CRDs. See Installing CRDs for Helm and manifest installation instructions. Note: The community controller has no equivalent for cross-namespace route delegation. VirtualServerRoute allows different teams to manage their own routing rules while a central VirtualServer controls the domain. Kubernetes Ingress NGINX (Ingress-NGINX) `# No equivalent — each team must have # their own Ingress resource per host, # or share a single Ingress manifest` F5 NGINX Ingress Controller # VirtualServer (platform team) apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: main-app namespace: platform spec: host: app.example.com routes: - path: /api route: api-team/api-routes - path: /web route: web-team/web-routes --- # VirtualServerRoute (API team) apiVersion: k8s.nginx.org/v1 kind: VirtualServerRoute metadata: name: api-routes namespace: api-team spec: host: app.example.com upstreams: - name: api-v1 service: api-v1-service port: 80 subroutes: - path: /api/v1 action: pass: api-v1

Session Affinity / Sticky Sessions

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/affinity: "cookie"` `nginx.ingress.kubernetes.io/affinity-mode` `nginx.ingress.kubernetes.io/session-cookie-change-on-failure` `nginx.ingress.kubernetes.io/session-cookie-conditional-samesite-none` `nginx.ingress.kubernetes.io/session-cookie-domain` `nginx.ingress.kubernetes.io/session-cookie-expires` `nginx.ingress.kubernetes.io/session-cookie-max-age` `nginx.ingress.kubernetes.io/session-cookie-name` `nginx.ingress.kubernetes.io/session-cookie-path` `nginx.ingress.kubernetes.io/session-cookie-samesite` `nginx.ingress.kubernetes.io/session-cookie-secure`	VirtualServer CRD `sessionCookie` New v5.4.0— or —`nginx.org/sticky-cookie-services`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-expires: "172800" nginx.ingress.kubernetes.io/session-cookie-max-age: "172800" nginx.ingress.kubernetes.io/session-cookie-name: "SERVERID" nginx.ingress.kubernetes.io/session-cookie-path: "/"` F5 NGINX Ingress Controller `annotations: nginx.org/sticky-cookie-services: "serviceName=my-service srv_id expires=48h path=/"` Note: The `nginx.org/sticky-cookie-services` annotation works with both NGINX OSS and NGINX Plus and provides a simpler way to configure session persistence via Ingress annotations (the legacy `nginx.com/sticky-cookie-services` form is Plus-only and kept for backward compatibility). For more granular control (domain, secure, samesite, httpOnly), use the VirtualServer CRD approach. Kubernetes Ingress NGINX (Ingress-NGINX) annotations: nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/affinity-mode: "balanced" nginx.ingress.kubernetes.io/session-cookie-change-on-failure: "true" nginx.ingress.kubernetes.io/session-cookie-conditional-samesite-none: "true" nginx.ingress.kubernetes.io/session-cookie-domain: ".example.com" nginx.ingress.kubernetes.io/session-cookie-expires: "172800" nginx.ingress.kubernetes.io/session-cookie-max-age: "172800" nginx.ingress.kubernetes.io/session-cookie-name: "SERVERID" nginx.ingress.kubernetes.io/session-cookie-path: "/" nginx.ingress.kubernetes.io/session-cookie-samesite: "Strict" nginx.ingress.kubernetes.io/session-cookie-secure: "true" F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 sessionCookie: domain: ".example.com" # session-cookie-domain enable: true # affinity: "cookie" expires: 48h # session-cookie-expires / session-cookie-max-age httpOnly: true name: SERVERID # session-cookie-name path: / # session-cookie-path samesite: strict # session-cookie-samesite secure: true # session-cookie-secure` New in v5.4.0: Session persistence via `sessionCookie` is now available in both NGINX OSS and NGINX Plus. Community-specific features `affinity-mode`, `session-cookie-change-on-failure`, and `session-cookie-conditional-samesite-none` have no direct equivalents.
`nginx.ingress.kubernetes.io/affinity-canary-behavior`	VirtualServer CRD `matches[]` + VirtualServer CRD `upstreams[].sessionCookie`
Kubernetes Ingress NGINX (Ingress-NGINX) `# Canary with session affinity behavior annotations: nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/affinity-canary-behavior: "sticky" nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"` F5 NGINX Ingress Controller apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: main service: main-svc port: 80 sessionCookie: # affinity: "cookie" + affinity-canary-behavior: "sticky" enable: true # affinity: "cookie" httpOnly: true name: SERVERID - name: canary service: canary-svc port: 80 sessionCookie: # affinity: "cookie" + affinity-canary-behavior: "sticky" enable: true # affinity: "cookie" httpOnly: true name: SERVERID routes: - path: / matches: - conditions: - header: X-Canary # canary-by-header value: always # community routes to canary on "always" action: pass: canary # canary: "true" action: pass: main Note: The community controller's `affinity-canary-behavior: "sticky"` ensures users routed to canary by session affinity continue to be served by the canary. The F5 NGINX Ingress Controller separates these concerns: canary routing uses VirtualServer `matches[]`, `splits[]`, while session persistence uses the VirtualServer `upstreams[].sessionCookie` field. The `sessionCookie` feature is available in both NGINX OSS and NGINX Plus.

SSL/TLS

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/backend-protocol`	VirtualServer CRD `upstreams[].tls.enable` VirtualServer CRD `upstreams[].type`— or —`nginx.org/grpc-services` `nginx.org/ssl-services`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"` F5 NGINX Ingress Controller `annotations: nginx.org/ssl-services: "my-service"` Note: For gRPC backends, use `nginx.org/grpc-services: "my-service"` instead. Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 443 tls: enable: true # backend-protocol` Note: For gRPC backends, use `type: grpc` on the upstream instead. For gRPC over TLS, combine both: `type: grpc` and `tls.enable: true`.
`nginx.ingress.kubernetes.io/force-ssl-redirect`	`nginx.org/redirect-to-https`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: "true"` F5 NGINX Ingress Controller `annotations: nginx.org/redirect-to-https: "true"` Note: `force-ssl-redirect` in the Community controller forces HTTPS redirect even without a TLS certificate. Use `nginx.org/redirect-to-https` for similar behavior.
`nginx.ingress.kubernetes.io/preserve-trailing-slash`	Not needed — trailing slash preserved by default
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/preserve-trailing-slash: "true"` F5 NGINX Ingress Controller `# No annotation needed — the F5 NGINX Ingress # Controller preserves trailing slashes by default.` Note: The community `preserve-trailing-slash` annotation has no F5 NGINX Ingress Controller equivalent because trailing slashes are preserved by default. You can safely drop it during migration.
`nginx.ingress.kubernetes.io/ssl-ciphers`	`nginx.org/ssl-ciphers`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/ssl-ciphers: "HIGH:!aNULL:!MD5"` F5 NGINX Ingress Controller `annotations: nginx.org/ssl-ciphers: "HIGH:!aNULL:!MD5"`
`nginx.ingress.kubernetes.io/ssl-passthrough`	TransportServer CRD `TLS_PASSTHROUGH` (built-in listener)
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/ssl-passthrough: "true"` F5 NGINX Ingress Controller `# ssl-passthrough → TransportServer with built-in tls-passthrough listener apiVersion: k8s.nginx.org/v1 kind: TransportServer metadata: name: ssl-passthrough-app spec: listener: name: tls-passthrough # ssl-passthrough protocol: TLS_PASSTHROUGH host: secure.example.com upstreams: - name: backend service: secure-svc port: 443 action: pass: backend`
`nginx.ingress.kubernetes.io/ssl-prefer-server-ciphers`	`nginx.org/ssl-prefer-server-ciphers`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/ssl-prefer-server-ciphers: "true"` F5 NGINX Ingress Controller `annotations: nginx.org/ssl-prefer-server-ciphers: "true"`
`nginx.ingress.kubernetes.io/ssl-redirect`	`nginx.org/redirect-to-https` / `nginx.org/ssl-redirect` New v5.4.0 + `nginx.org/http-redirect-code: "308"` New v5.4.0— or —VirtualServer CRD `tls.redirect.code: 308`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true"` F5 NGINX Ingress Controller `annotations: # Match the community controller's 308 default # (preserves request method and body) nginx.org/http-redirect-code: "308" # Option 1: For TLS terminated at load balancer nginx.org/redirect-to-https: "true" # OR Option 2: For unconditional redirect nginx.org/ssl-redirect: "true"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/ssl-redirect: "true"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: host: app.example.com tls: secret: app-tls redirect: enable: true code: 308 # ssl-redirect (matches community 308 default) upstreams: - name: backend service: my-service port: 80 routes: - path: / action: pass: backend` Important distinction: `nginx.org/redirect-to-https` checks the `X-Forwarded-Proto` header before redirecting. Use this when TLS terminates at a load balancer in front of NGINX. `nginx.org/ssl-redirect` performs an unconditional redirect for all incoming HTTP traffic. Use this when NGINX handles TLS termination directly. Default: `true`. Note: The community controller's `ssl-redirect` defaults to a 308 Permanent Redirect, which preserves the original request method and body. The F5 NGINX Ingress Controller defaults to 301, which clients may downgrade to `GET` and drop the request body. To match the community behavior exactly, set `nginx.org/http-redirect-code: "308"` on the Ingress, or `tls.redirect.code: 308` on the VirtualServer. New in v5.4.0: The `nginx.org/ssl-redirect` and `nginx.org/http-redirect-code` annotations are new. Previously, only `nginx.org/redirect-to-https` was available, with a fixed 301 response code. Use `ssl-redirect` as the direct 1:1 mapping from the community annotation.
No direct equivalent	`nginx.org/http-redirect-code` (used with `nginx.org/redirect-to-https`) New v5.4.0
Kubernetes Ingress NGINX (Ingress-NGINX) `# No direct equivalent # Redirect code is not configurable # per Ingress resource` F5 NGINX Ingress Controller `annotations: nginx.org/http-redirect-code: "308" nginx.org/redirect-to-https: "true"` New in v5.4.0: Customizes the HTTP redirect status code used when redirecting to HTTPS (default: 301). Available as both a per-Ingress annotation and a global ConfigMap key (`http-redirect-code`). Common values: 301 (permanent), 302 (temporary), 307 (temporary, preserves method), 308 (permanent, preserves method).
No direct equivalent	`nginx.org/listen-ports` / `nginx.org/listen-ports-ssl`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No direct equivalent # Port configuration is handled at the # controller/service level` F5 NGINX Ingress Controller `annotations: nginx.org/listen-ports: "8080,8443" nginx.org/listen-ports-ssl: "8443,9443"` Note: These annotations configure custom HTTP and HTTPS listen ports for the Ingress resource. Useful when the controller needs to listen on non-standard ports.

TCP/UDP Load Balancing

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/stream-snippet
ConfigMap tcp-services
ConfigMap udp-services GlobalConfiguration CRD +TransportServer CRD

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/stream-snippet` ConfigMap `tcp-services` ConfigMap `udp-services`	GlobalConfiguration CRD +TransportServer CRD
Kubernetes Ingress NGINX (Ingress-NGINX) `# ConfigMap for TCP services apiVersion: v1 kind: ConfigMap metadata: name: tcp-services data: 3306: "default/mysql:3306"` F5 NGINX Ingress Controller `# tcp-services ConfigMap → GlobalConfiguration + TransportServer apiVersion: k8s.nginx.org/v1 kind: GlobalConfiguration spec: listeners: - name: mysql-tcp port: 3306 # "3306" key from tcp-services ConfigMap protocol: TCP --- apiVersion: k8s.nginx.org/v1 kind: TransportServer spec: listener: name: mysql-tcp protocol: TCP upstreams: - name: mysql service: mysql # "default/mysql:3306" value from ConfigMap port: 3306 action: pass: mysql`

Kubernetes Ingress NGINX (Ingress-NGINX)

# ConfigMap for TCP services
apiVersion: v1
kind: ConfigMap
metadata:
  name: tcp-services
data:
  3306: "default/mysql:3306"

F5 NGINX Ingress Controller

# tcp-services ConfigMap → GlobalConfiguration + TransportServer
apiVersion: k8s.nginx.org/v1
kind: GlobalConfiguration
spec:
  listeners:
    - name: mysql-tcp
      port: 3306  # "3306" key from tcp-services ConfigMap
      protocol: TCP
---
apiVersion: k8s.nginx.org/v1
kind: TransportServer
spec:
  listener:
    name: mysql-tcp
    protocol: TCP
  upstreams:
    - name: mysql
      service: mysql  # "default/mysql:3306" value from ConfigMap
      port: 3306
  action:
    pass: mysql

Timeouts

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/proxy-connect-timeout`	VirtualServer CRD `upstreams[].connect-timeout`— or —`nginx.org/proxy-connect-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-connect-timeout: "10s"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 connect-timeout: "10s" # proxy-connect-timeout`
`nginx.ingress.kubernetes.io/proxy-read-timeout`	VirtualServer CRD `upstreams[].read-timeout`— or —`nginx.org/proxy-read-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-read-timeout: "60"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-read-timeout: "60s"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-read-timeout: "60"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 read-timeout: "60s" # proxy-read-timeout`
`nginx.ingress.kubernetes.io/proxy-send-timeout`	VirtualServer CRD `upstreams[].send-timeout`— or —`nginx.org/proxy-send-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-send-timeout: "60"` F5 NGINX Ingress Controller `annotations: nginx.org/proxy-send-timeout: "60s"` Kubernetes Ingress NGINX (Ingress-NGINX) `annotations: nginx.ingress.kubernetes.io/proxy-send-timeout: "60"` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 send-timeout: "60s" # proxy-send-timeout`

Upstream Configuration

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
No direct equivalent	VirtualServer CRD `upstreams[]` fields— or —`nginx.org/fail-timeout` `nginx.org/keepalive` `nginx.org/max-conns` `nginx.org/max-fails` `nginx.org/upstream-zone-size`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No per-Ingress upstream tuning # Community controller uses ConfigMap defaults` F5 NGINX Ingress Controller `annotations: nginx.org/fail-timeout: "10s" nginx.org/keepalive: "32" nginx.org/max-conns: "100" nginx.org/max-fails: "3" nginx.org/upstream-zone-size: "256k"` Kubernetes Ingress NGINX (Ingress-NGINX) `# No per-Ingress upstream tuning # Community controller uses ConfigMap defaults` F5 NGINX Ingress Controller `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 fail-timeout: "10s" keepalive: 32 max-conns: 100 max-fails: 3` Note: These are F5 NGINX Ingress Controller-only features for fine-tuning upstream behavior. The community controller does not provide per-Ingress control over these settings.
No direct equivalent (automatic with HTTP/1.1)	`nginx.org/websocket-services`
Kubernetes Ingress NGINX (Ingress-NGINX) `# WebSocket support is automatic # Just ensure proxy-http-version: "1.1" # and proper Upgrade/Connection headers` F5 NGINX Ingress Controller `annotations: nginx.org/websocket-services: "ws-service"` Note: The Community controller handles WebSocket upgrades automatically. The F5 NGINX Ingress Controller provides an explicit annotation to enable WebSocket support for specific services.

NGINX Plus Mappings

These features require an NGINX Plus subscription and provide enterprise-grade capabilities. Most Plus features use CRD-based configuration—click the expandable rows ▶ to see full examples. All items are annotations unless otherwise indicated with a badge. Community annotations use the nginx.ingress.kubernetes.io/ prefix; F5 NGINX Ingress Controller Plus annotations use the nginx.com/ prefix (or appprotect.f5.com/ for F5 WAF for NGINX).

How to Read the Mappings

Annotation-to-annotation rows ▶: Direct mappings where you change the annotation name/prefix. Click to expand and see before/after Ingress YAML examples.
CRD-based rows ▶: Annotations that map to a CRD (VirtualServer, Policy, or TransportServer). Click to expand for full CRD examples with installation instructions.
Grouped annotations: Related annotations that work together are grouped in a single expandable row, showing how they map to a unified configuration.
F5 NGINX Ingress Controller-only rows: Rows marked No direct equivalent on the left are features unique to the F5 NGINX Ingress Controller with no community equivalent.

Active Health Checks

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

No direct equivalent VirtualServer CRD Plus upstreams[].healthCheck— or —nginx.com/health-checks
nginx.com/health-checks-mandatory
nginx.com/health-checks-mandatory-queue
nginx.com/slow-start

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
No direct equivalent	VirtualServer CRD Plus `upstreams[].healthCheck`— or —`nginx.com/health-checks` `nginx.com/health-checks-mandatory` `nginx.com/health-checks-mandatory-queue` `nginx.com/slow-start`
`annotations: nginx.com/health-checks: "true" nginx.com/health-checks-mandatory: "true" nginx.com/health-checks-mandatory-queue: "5" nginx.com/slow-start: "30s"` Note: Active health checks proactively probe upstream endpoints at configurable intervals, rather than waiting for client requests to fail. These require NGINX Plus. For more granular control (custom paths, intervals, status matching), use the VirtualServer CRD approach. For passive health checks (OSS), see Passive Health Checks in OSS Mappings. `apiVersion: k8s.nginx.org/v1 kind: VirtualServer spec: upstreams: - name: backend service: my-service port: 80 healthCheck: # health-checks enable: true fails: 3 interval: 5s jitter: 2s mandatory: true # health-checks-mandatory passes: 2 path: /health persistent: true # health-checks-mandatory-queue port: 8080 statusMatch: "200-399" slowStart: 30s # slow-start` Note: The VirtualServer CRD provides the most granular control over active health checks. Active health checks and `slowStart` require NGINX Plus. For passive health checks (OSS), see Passive Health Checks in OSS Mappings.

annotations:
  nginx.com/health-checks: "true"
  nginx.com/health-checks-mandatory: "true"
  nginx.com/health-checks-mandatory-queue: "5"
  nginx.com/slow-start: "30s"

Note: Active health checks proactively probe upstream endpoints at configurable intervals, rather than waiting for client requests to fail. These require NGINX Plus. For more granular control (custom paths, intervals, status matching), use the VirtualServer CRD approach. For passive health checks (OSS), see Passive Health Checks in OSS Mappings.

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
spec:
  upstreams:
    - name: backend
      service: my-service
      port: 80
      healthCheck:  # health-checks
        enable: true
        fails: 3
        interval: 5s
        jitter: 2s
        mandatory: true  # health-checks-mandatory
        passes: 2
        path: /health
        persistent: true  # health-checks-mandatory-queue
        port: 8080
        statusMatch: "200-399"
      slowStart: 30s  # slow-start

Note: The VirtualServer CRD provides the most granular control over active health checks. Active health checks and slowStart require NGINX Plus. For passive health checks (OSS), see Passive Health Checks in OSS Mappings.

JWT Authentication

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

No direct equivalent Policy CRD Plus jwt— or —nginx.com/jwt-key
nginx.com/jwt-login-url
nginx.com/jwt-realm
nginx.com/jwt-token

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
No direct equivalent	Policy CRD Plus `jwt`— or —`nginx.com/jwt-key` `nginx.com/jwt-login-url` `nginx.com/jwt-realm` `nginx.com/jwt-token`
Kubernetes Ingress NGINX (Ingress-NGINX) `# No direct equivalent # Requires external auth service` F5 NGINX Ingress Controller (Plus) `annotations: nginx.com/jwt-key: "my-jwk-secret" nginx.com/jwt-login-url: "https://login.example.com" nginx.com/jwt-realm: "API" nginx.com/jwt-token: "$http_authorization"` Note: The annotation approach requires a Kubernetes Secret containing the JWK. The Policy CRD approach is recommended for new deployments as it provides more granular control including JWKS URI support and key caching. Kubernetes Ingress NGINX (Ingress-NGINX) `# No direct equivalent # Requires external auth service` F5 NGINX Ingress Controller (Plus) `apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: jwt-auth spec: jwt: jwksURI: "https://idp.example.com/.well-known/jwks.json" # jwt-key (enhanced) keyCache: 1h realm: "API" # jwt-realm token: "$http_authorization" # jwt-token` Note: The Policy CRD approach is recommended for new deployments. It supports JWKS URIs, key caching, and more granular configuration. The `jwt-login-url` annotation does not have a direct Policy CRD field — configure redirect logic separately via VirtualServer `errorPages` or `server-snippets` for 401 responses.

Kubernetes Ingress NGINX (Ingress-NGINX)

# No direct equivalent
# Requires external auth service

F5 NGINX Ingress Controller (Plus)

annotations:
  nginx.com/jwt-key: "my-jwk-secret"
  nginx.com/jwt-login-url: "https://login.example.com"
  nginx.com/jwt-realm: "API"
  nginx.com/jwt-token: "$http_authorization"

Note: The annotation approach requires a Kubernetes Secret containing the JWK. The Policy CRD approach is recommended for new deployments as it provides more granular control including JWKS URI support and key caching.

Kubernetes Ingress NGINX (Ingress-NGINX)

# No direct equivalent
# Requires external auth service

F5 NGINX Ingress Controller (Plus)

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: jwt-auth
spec:
  jwt:
    jwksURI: "https://idp.example.com/.well-known/jwks.json"  # jwt-key (enhanced)
    keyCache: 1h
    realm: "API"  # jwt-realm
    token: "$http_authorization"  # jwt-token

Note: The Policy CRD approach is recommended for new deployments. It supports JWKS URIs, key caching, and more granular configuration. The jwt-login-url annotation does not have a direct Policy CRD field — configure redirect logic separately via VirtualServer errorPages or server-snippets for 401 responses.

OIDC Authentication

Looking for generic auth_request (non-OIDC) migration? Use the new externalAuth Policy CRD documented in the Authentication (External) section — it works in NGINX OSS and Plus. The oidc Policy below is specifically for native OIDC flows (no oauth2-proxy required) and requires NGINX Plus.

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

nginx.ingress.kubernetes.io/auth-cache-duration
nginx.ingress.kubernetes.io/auth-cache-key
nginx.ingress.kubernetes.io/auth-method
nginx.ingress.kubernetes.io/auth-proxy-set-headers
nginx.ingress.kubernetes.io/auth-request-redirect
nginx.ingress.kubernetes.io/auth-response-headers
nginx.ingress.kubernetes.io/auth-signin
nginx.ingress.kubernetes.io/auth-signin-redirect-param
nginx.ingress.kubernetes.io/auth-url Policy CRD Plus oidc

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`nginx.ingress.kubernetes.io/auth-cache-duration` `nginx.ingress.kubernetes.io/auth-cache-key` `nginx.ingress.kubernetes.io/auth-method` `nginx.ingress.kubernetes.io/auth-proxy-set-headers` `nginx.ingress.kubernetes.io/auth-request-redirect` `nginx.ingress.kubernetes.io/auth-response-headers` `nginx.ingress.kubernetes.io/auth-signin` `nginx.ingress.kubernetes.io/auth-signin-redirect-param` `nginx.ingress.kubernetes.io/auth-url`	Policy CRD Plus `oidc`
Kubernetes Ingress NGINX (Ingress-NGINX) annotations: nginx.ingress.kubernetes.io/auth-cache-duration: "200 10m, 401 1m" nginx.ingress.kubernetes.io/auth-cache-key: "$remote_addr" nginx.ingress.kubernetes.io/auth-method: "GET" nginx.ingress.kubernetes.io/auth-proxy-set-headers: "default/auth-headers" nginx.ingress.kubernetes.io/auth-request-redirect: "https://app.example.com/callback" nginx.ingress.kubernetes.io/auth-response-headers: "X-Auth-User" nginx.ingress.kubernetes.io/auth-signin: "https://auth.example.com/oauth2/start" nginx.ingress.kubernetes.io/auth-signin-redirect-param: "rd" nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/oauth2/auth" F5 NGINX Ingress Controller (Plus) `apiVersion: v1 kind: Secret metadata: name: oidc-secret type: nginx.org/oidc data: client-secret: c2VjcmV0... --- apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: oidc-auth spec: oidc: authEndpoint: "https://idp.example.com/authorize" # auth-signin clientID: "my-client-id" clientSecret: oidc-secret jwksURI: "https://idp.example.com/.well-known/jwks.json" scope: "openid+profile+email" tokenEndpoint: "https://idp.example.com/token" # auth-url` Note: Native OIDC support eliminates the need for oauth2-proxy sidecar. The community `auth-url`/`auth-signin` pattern uses the `auth_request` module (typically with oauth2-proxy) and supports any external auth service, not just OIDC. The community annotations `auth-cache-duration`, `auth-cache-key`, `auth-method`, `auth-proxy-set-headers`, `auth-request-redirect`, `auth-response-headers`, and `auth-signin-redirect-param` have no direct OIDC Policy equivalents — the Policy manages these concerns internally. If you need generic external auth (non-OIDC), prefer the new `externalAuth` Policy CRD (v5.5.0+, OSS-capable) documented in the Authentication (External) section, or fall back to `nginx.org/location-snippets` with the `auth_request` directive.

Kubernetes Ingress NGINX (Ingress-NGINX)

annotations:
  nginx.ingress.kubernetes.io/auth-cache-duration: "200 10m, 401 1m"
  nginx.ingress.kubernetes.io/auth-cache-key: "$remote_addr"
  nginx.ingress.kubernetes.io/auth-method: "GET"
  nginx.ingress.kubernetes.io/auth-proxy-set-headers: "default/auth-headers"
  nginx.ingress.kubernetes.io/auth-request-redirect: "https://app.example.com/callback"
  nginx.ingress.kubernetes.io/auth-response-headers: "X-Auth-User"
  nginx.ingress.kubernetes.io/auth-signin: "https://auth.example.com/oauth2/start"
  nginx.ingress.kubernetes.io/auth-signin-redirect-param: "rd"
  nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/oauth2/auth"

F5 NGINX Ingress Controller (Plus)

apiVersion: v1
kind: Secret
metadata:
  name: oidc-secret
type: nginx.org/oidc
data:
  client-secret: c2VjcmV0...
---
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: oidc-auth
spec:
  oidc:
    authEndpoint: "https://idp.example.com/authorize"  # auth-signin
    clientID: "my-client-id"
    clientSecret: oidc-secret
    jwksURI: "https://idp.example.com/.well-known/jwks.json"
    scope: "openid+profile+email"
    tokenEndpoint: "https://idp.example.com/token"  # auth-url

Note: Native OIDC support eliminates the need for oauth2-proxy sidecar. The community auth-url/auth-signin pattern uses the auth_request module (typically with oauth2-proxy) and supports any external auth service, not just OIDC. The community annotations auth-cache-duration, auth-cache-key, auth-method, auth-proxy-set-headers, auth-request-redirect, auth-response-headers, and auth-signin-redirect-param have no direct OIDC Policy equivalents — the Policy manages these concerns internally. If you need generic external auth (non-OIDC), prefer the new externalAuth Policy CRD (v5.5.0+, OSS-capable) documented in the Authentication (External) section, or fall back to nginx.org/location-snippets with the auth_request directive.

WAF (Web Application Firewall)

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

No direct equivalent — see ModSecurity / WAF (OSS) Policy CRD Plus waf (F5 WAF for NGINX) + nginx.com/policies New v5.5.0— or —appprotect.f5.com/app-protect-enable
appprotect.f5.com/app-protect-policy
appprotect.f5.com/app-protect-security-log-enable
appprotect.f5.com/app-protect-security-log
appprotect.f5.com/app-protect-security-log-destination

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
No direct equivalent — see ModSecurity / WAF (OSS)	Policy CRD Plus `waf` (F5 WAF for NGINX) + `nginx.com/policies` New v5.5.0— or —`appprotect.f5.com/app-protect-enable` `appprotect.f5.com/app-protect-policy` `appprotect.f5.com/app-protect-security-log-enable` `appprotect.f5.com/app-protect-security-log` `appprotect.f5.com/app-protect-security-log-destination`
`# 1. Create the WAF Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: waf-policy spec: waf: apPolicy: "default/waf-policy" enable: true securityLogs: - enable: true apLogConf: "default/log-config" logDest: "syslog:server=syslog:514" --- # 2. Reference from Ingress (new in v5.5.0) apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app annotations: nginx.com/policies: "waf-policy" # ... rest of Ingress spec` New in v5.5.0: The `waf` Policy CRD can now be referenced directly from Ingress resources using the `nginx.com/policies` annotation. This is the simplest migration path — you stay on Ingress resources. Previously, WAF Policies were VirtualServer-only. # 1. Create the WAF Policy apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: waf-policy spec: waf: apPolicy: "default/waf-policy" enable: true securityLogs: - enable: true apLogConf: "default/log-config" logDest: "syslog:server=syslog:514" --- # 2. Reference from VirtualServer apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: my-app spec: host: app.example.com policies: - name: waf-policy upstreams: - name: backend service: backend-svc port: 80 routes: - path: / action: pass: backend Note: Use this if you are already migrating to VirtualServer resources for other reasons (e.g., advanced routing, traffic splitting). Policies can also be scoped per-route via the route-level `policies[]` field. `annotations: appprotect.f5.com/app-protect-enable: "True" appprotect.f5.com/app-protect-policy: "default/waf-policy" appprotect.f5.com/app-protect-security-log: "default/log-config" appprotect.f5.com/app-protect-security-log-destination: "syslog:server=syslog:514" appprotect.f5.com/app-protect-security-log-enable: "True"` Note: The `appprotect.f5.com/` annotations enable F5 WAF for NGINX directly on the Ingress without a Policy CRD. The Policy + Ingress approach (v5.5.0+) is recommended for new deployments as it provides reusability and a more consistent configuration model with other NIC Policies. Note: F5 WAF for NGINX provides enterprise WAF capabilities beyond ModSecurity. The Policy CRD approach allows WAF policies to be shared across multiple Ingress / VirtualServer resources. For community ModSecurity annotations, see the ModSecurity / WAF section in OSS Mappings. WAF IP Intelligence (threat-feed-based blocking) can also be enabled in v5.5.0 via the `-enable-app-protect-ip-intelligence` controller flag (or the `controller.appprotect.ipIntelligence.enable` Helm value) and configured inside the APPolicy resource.

# 1. Create the WAF Policy
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: waf-policy
spec:
  waf:
    apPolicy: "default/waf-policy"
    enable: true
    securityLogs:
      - enable: true
        apLogConf: "default/log-config"
        logDest: "syslog:server=syslog:514"
---
# 2. Reference from Ingress (new in v5.5.0)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.com/policies: "waf-policy"
# ... rest of Ingress spec

New in v5.5.0: The waf Policy CRD can now be referenced directly from Ingress resources using the nginx.com/policies annotation. This is the simplest migration path — you stay on Ingress resources. Previously, WAF Policies were VirtualServer-only.

# 1. Create the WAF Policy
apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: waf-policy
spec:
  waf:
    apPolicy: "default/waf-policy"
    enable: true
    securityLogs:
      - enable: true
        apLogConf: "default/log-config"
        logDest: "syslog:server=syslog:514"
---
# 2. Reference from VirtualServer
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: my-app
spec:
  host: app.example.com
  policies:
    - name: waf-policy
  upstreams:
    - name: backend
      service: backend-svc
      port: 80
  routes:
    - path: /
      action:
        pass: backend

Note: Use this if you are already migrating to VirtualServer resources for other reasons (e.g., advanced routing, traffic splitting). Policies can also be scoped per-route via the route-level policies[] field.

annotations:
  appprotect.f5.com/app-protect-enable: "True"
  appprotect.f5.com/app-protect-policy: "default/waf-policy"
  appprotect.f5.com/app-protect-security-log: "default/log-config"
  appprotect.f5.com/app-protect-security-log-destination: "syslog:server=syslog:514"
  appprotect.f5.com/app-protect-security-log-enable: "True"

Note: The appprotect.f5.com/ annotations enable F5 WAF for NGINX directly on the Ingress without a Policy CRD. The Policy + Ingress approach (v5.5.0+) is recommended for new deployments as it provides reusability and a more consistent configuration model with other NIC Policies.

Note: F5 WAF for NGINX provides enterprise WAF capabilities beyond ModSecurity. The Policy CRD approach allows WAF policies to be shared across multiple Ingress / VirtualServer resources. For community ModSecurity annotations, see the ModSecurity / WAF section in OSS Mappings. WAF IP Intelligence (threat-feed-based blocking) can also be enabled in v5.5.0 via the -enable-app-protect-ip-intelligence controller flag (or the controller.appprotect.ipIntelligence.enable Helm value) and configured inside the APPolicy resource.

ConfigMap Mappings

Both the community and F5 NGINX Ingress Controllers use a Kubernetes ConfigMap for global NGINX settings. Many keys share the same name, but some are renamed or have different semantics. The keys listed below are community ConfigMap keys that have an equivalent F5 NGINX Ingress Controller ConfigMap key.

Tip: A significant number of ConfigMap keys are identical between the two controllers — you can migrate those without any changes. The tables below highlight both the identical keys and the ones that need renaming or adjustment.

ConfigMap naming: The community controller typically uses a ConfigMap named ingress-nginx-controller. The F5 NGINX Ingress Controller uses nginx-config by default (configurable via --configmap flag). Remember to update the ConfigMap name in your deployment.

Identical Keys

These keys have the same name and semantics in both controllers. No changes are needed when migrating.

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`client-body-buffer-size`	`client-body-buffer-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: client-body-buffer-size: "16k"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: client-body-buffer-size: "16k"`
`error-log-level`	`error-log-level`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: error-log-level: "warn"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: error-log-level: "warn"`
`hsts`	`hsts`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: hsts: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: hsts: "true"`
`hsts-include-subdomains`	`hsts-include-subdomains`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: hsts-include-subdomains: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: hsts-include-subdomains: "true"`
`hsts-max-age`	`hsts-max-age`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: hsts-max-age: "31536000"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: hsts-max-age: "31536000"`
`map-hash-bucket-size`	`map-hash-bucket-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: map-hash-bucket-size: "128"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: map-hash-bucket-size: "128"`
`otel-service-name`	`otel-service-name`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: otel-service-name: "nginx-ingress"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: otel-service-name: "nginx-ingress"`
`proxy-buffer-size`	`proxy-buffer-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-buffer-size: "8k"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-buffer-size: "8k"`
`proxy-buffering`	`proxy-buffering`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-buffering: "on"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-buffering: "on"`
`proxy-busy-buffers-size`	`proxy-busy-buffers-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-busy-buffers-size: "16k"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-busy-buffers-size: "16k"`
`proxy-connect-timeout`	`proxy-connect-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-connect-timeout: "30"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-connect-timeout: "30"`
`proxy-read-timeout`	`proxy-read-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-read-timeout: "120"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-read-timeout: "120"`
`proxy-send-timeout`	`proxy-send-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-send-timeout: "60"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-send-timeout: "60"`
`server-tokens`	`server-tokens`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: server-tokens: "false"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: server-tokens: "false"`
`ssl-ciphers`	`ssl-ciphers`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5"`
`ssl-protocols`	`ssl-protocols`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: ssl-protocols: "TLSv1.2 TLSv1.3"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: ssl-protocols: "TLSv1.2 TLSv1.3"`
`ssl-redirect`	`ssl-redirect`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: ssl-redirect: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: ssl-redirect: "true"`
`variables-hash-bucket-size`	`variables-hash-bucket-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: variables-hash-bucket-size: "256"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: variables-hash-bucket-size: "256"`
`variables-hash-max-size`	`variables-hash-max-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: variables-hash-max-size: "2048"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: variables-hash-max-size: "2048"`
`worker-cpu-affinity`	`worker-cpu-affinity`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: worker-cpu-affinity: "auto"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: worker-cpu-affinity: "auto"`
`worker-processes`	`worker-processes`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: worker-processes: "auto"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: worker-processes: "auto"`
`worker-shutdown-timeout`	`worker-shutdown-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: worker-shutdown-timeout: "30s"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: worker-shutdown-timeout: "30s"`

Proxy & Buffering

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`proxy-body-size`	`client-max-body-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-body-size: "8m"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: client-max-body-size: "8m"` Note: Both keys map to the NGINX `client_max_body_size` directive. The F5 NGINX Ingress Controller uses the NGINX-native naming convention.
`proxy-buffers-number`	`proxy-buffers`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: proxy-buffers-number: "4"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-buffers: "4 8k"` Note: The community key takes just a number (buffer count). The F5 NGINX Ingress Controller key takes the full NGINX `proxy_buffers` format: `"number size"` (e.g., `"4 8k"`).

SSL/TLS

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`force-ssl-redirect`	`redirect-to-https`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: force-ssl-redirect: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: redirect-to-https: "true"` Note: The community controller uses an `X-Forwarded-Proto` header check to determine whether to redirect. The F5 NGINX Ingress Controller performs a direct HTTP-to-HTTPS redirect.
`hsts-preload`	(included automatically)
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: hsts: "true" hsts-preload: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: hsts: "true"` Note: The F5 NGINX Ingress Controller's `hsts: "true"` includes the `preload` directive by default. There is no separate `hsts-preload` key — just enable `hsts`.
`ssl-dh-param`	`ssl-dhparam-file`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: ssl-dh-param: "default/dh-param"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: ssl-dhparam-file: "/etc/nginx/secrets/dhparam.pem"` Note: The community key references a Kubernetes secret name, while the F5 NGINX Ingress Controller key expects a file path to the DH parameters file mounted into the pod.
No direct equivalent	`http-redirect-code` New v5.4.0
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `# No equivalent ConfigMap key # Redirect code is not globally configurable` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: redirect-to-https: "true" http-redirect-code: "308"` New in v5.4.0: The `http-redirect-code` ConfigMap key sets the global HTTP redirect status code used when redirecting to HTTPS (default: 301). Can also be set per-Ingress via the `nginx.org/http-redirect-code` annotation. Common values: 301 (permanent), 302 (temporary), 307 (temporary, preserves method), 308 (permanent, preserves method).

Logging

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`disable-access-log`	`access-log-off`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: disable-access-log: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: access-log-off: "true"`
`log-format-escape-json` `log-format-escape-none`	`log-format-escaping`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: log-format-escape-json: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: log-format-escaping: "json"` Note: The community controller uses separate boolean keys (`log-format-escape-json` and `log-format-escape-none`). The F5 NGINX Ingress Controller uses a single key with a string value: `"json"`, `"default"`, or `"none"`.
`log-format-stream`	`stream-log-format`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: log-format-stream: '$remote_addr [$time_local]'` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: stream-log-format: '$remote_addr [$time_local]'` Note: The word order is swapped: community uses `log-format-stream`, while the F5 NGINX Ingress Controller uses `stream-log-format`.
`log-format-upstream`	`log-format`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: log-format-upstream: '$remote_addr - $request_id'` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: log-format: '$remote_addr - $request_id'`

Network / Real IP

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`proxy-real-ip-cidr`	`set-real-ip-from`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: proxy-real-ip-cidr: "10.0.0.0/8" use-forwarded-headers: "true"` F5 NGINX Ingress Controller ConfigMap `data: set-real-ip-from: "10.0.0.0/8" real-ip-header: "X-Forwarded-For" real-ip-recursive: "true"` Note: The community controller uses `proxy-real-ip-cidr` and `use-forwarded-headers`. The F5 NGINX Ingress Controller uses the NGINX-native `set-real-ip-from`, `real-ip-header`, and `real-ip-recursive` ConfigMap keys.
`use-forwarded-headers`	`real-ip-header`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: use-forwarded-headers: "true"` F5 NGINX Ingress Controller ConfigMap `data: real-ip-header: "X-Forwarded-For"`
`use-proxy-protocol`	`proxy-protocol`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: use-proxy-protocol: "true"` F5 NGINX Ingress Controller ConfigMap `data: proxy-protocol: "true" set-real-ip-from: "0.0.0.0/0" real-ip-header: "proxy_protocol"` Note: When enabling PROXY protocol, also configure `set-real-ip-from` and `real-ip-header` to properly extract client IPs from the PROXY protocol header.

Worker & Performance

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`max-worker-connections`	`worker-connections`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: max-worker-connections: "16384"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: worker-connections: "16384"`
`max-worker-open-files`	`worker-rlimit-nofile`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: max-worker-open-files: "65536"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: worker-rlimit-nofile: "65536"`

Upstream & Load Balancing

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`load-balance`	`lb-method`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: load-balance: "ewma"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: lb-method: "random two least_conn"` Note: The community controller defaults to `round_robin` and supports methods like `ewma` and `least_conn`. The F5 NGINX Ingress Controller defaults to `random two least_conn` and uses standard NGINX load balancing method names.
`upstream-keepalive-connections`	`keepalive`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: upstream-keepalive-connections: "320"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: keepalive: "320"`

Keepalive & Timeouts

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`keep-alive`	`keepalive-timeout`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: keep-alive: "75"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: keepalive-timeout: "75s"` Note: Both map to the NGINX `keepalive_timeout` directive. The F5 NGINX Ingress Controller key uses the NGINX-native name and expects a time unit suffix (e.g., `"75s"`).
`keep-alive-requests`	`keepalive-requests`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: keep-alive-requests: "1000"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: keepalive-requests: "1000"`

Server & Hash Configuration

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`server-name-hash-bucket-size`	`server-names-hash-bucket-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: server-name-hash-bucket-size: "128"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: server-names-hash-bucket-size: "128"`
`server-name-hash-max-size`	`server-names-hash-max-size`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: server-name-hash-max-size: "1024"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: server-names-hash-max-size: "1024"` Note: Subtle difference: the community uses `server-name-hash-max-size` and `server-name-hash-bucket-size` (singular "name"), while the F5 NGINX Ingress Controller uses `server-names-hash-max-size` and `server-names-hash-bucket-size` (plural "names") matching the NGINX directives.

Headers

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`add-headers`	`add-header` New v5.5.0
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: add-headers: "default/custom-headers" # references another ConfigMap --- apiVersion: v1 kind: ConfigMap metadata: name: custom-headers namespace: default data: X-Frame-Options: "SAMEORIGIN" Strict-Transport-Security: "max-age=31536000"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: add-header: "X-Frame-Options: SAMEORIGIN, Strict-Transport-Security: max-age=31536000"` New in v5.5.0: The `add-header` ConfigMap key adds globally-applied response headers using a comma-separated `Name: Value` list. Unlike the community `add-headers` key (which references a separate ConfigMap of headers), values are specified inline.
`hide-headers`	`proxy-hide-headers`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: hide-headers: "X-Powered-By,Server"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: proxy-hide-headers: "X-Powered-By,Server"`
No direct equivalent	`add-header-inherit` New v5.5.0
Kubernetes Ingress NGINX (Ingress-NGINX) `# No equivalent ConfigMap key — the community # controller does not expose add_header_inherit.` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: add-header-inherit: "merge" # on \| off \| merge` New in v5.5.0: The `add-header-inherit` ConfigMap key sets the global default for `add_header_inherit`: `on` (inherit headers from outer contexts — the NGINX default), `off` (do not inherit), or `merge` (combine inner and outer headers). Per-Ingress override is available via the `nginx.org/add-header-inherit` annotation.

Protocol

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`use-http2`	`http2`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: use-http2: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: http2: "true"`

Snippets

Kubernetes Ingress NGINX (Ingress-NGINX) F5 NGINX Ingress Controller

http-snippet
location-snippet
main-snippet
server-snippet
stream-snippet http-snippets
location-snippets
main-snippets
server-snippets
stream-snippets

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`http-snippet` `location-snippet` `main-snippet` `server-snippet` `stream-snippet`	`http-snippets` `location-snippets` `main-snippets` `server-snippets` `stream-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: http-snippet: \| map $http_upgrade $connection_upgrade { default upgrade; '' close; } location-snippet: \| proxy_cache_valid 200 10m; main-snippet: \| worker_rlimit_nofile 65535; server-snippet: \| add_header X-Custom "value"; stream-snippet: \| log_format stream '$remote_addr [$time_local]';` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: http-snippets: \| map $http_upgrade $connection_upgrade { default upgrade; '' close; } location-snippets: \| proxy_cache_valid 200 10m; main-snippets: \| worker_rlimit_nofile 65535; server-snippets: \| add_header X-Custom "value"; stream-snippets: \| log_format stream '$remote_addr [$time_local]';` Note: All snippet keys change from singular to plural: `http-snippet` → `http-snippets`, `location-snippet` → `location-snippets`, `main-snippet` → `main-snippets`, `server-snippet` → `server-snippets`, `stream-snippet` → `stream-snippets`.

Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
data:
  http-snippet: |
    map $http_upgrade $connection_upgrade {
      default upgrade;
      '' close;
    }
  location-snippet: |
    proxy_cache_valid 200 10m;
  main-snippet: |
    worker_rlimit_nofile 65535;
  server-snippet: |
    add_header X-Custom "value";
  stream-snippet: |
    log_format stream '$remote_addr [$time_local]';

F5 NGINX Ingress Controller ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  http-snippets: |
    map $http_upgrade $connection_upgrade {
      default upgrade;
      '' close;
    }
  location-snippets: |
    proxy_cache_valid 200 10m;
  main-snippets: |
    worker_rlimit_nofile 65535;
  server-snippets: |
    add_header X-Custom "value";
  stream-snippets: |
    log_format stream '$remote_addr [$time_local]';

Note: All snippet keys change from singular to plural: http-snippet → http-snippets, location-snippet → location-snippets, main-snippet → main-snippets, server-snippet → server-snippets, stream-snippet → stream-snippets.

OpenTelemetry

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`enable-opentelemetry`	`otel-trace-in-http`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: enable-opentelemetry: "true"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: otel-trace-in-http: "true"`
`otlp-collector-host` `otlp-collector-port`	`otel-exporter-endpoint`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller data: otlp-collector-host: "otel-collector.observability" otlp-collector-port: "4317"` F5 NGINX Ingress Controller ConfigMap `apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: otel-exporter-endpoint: "otel-collector.observability:4317"` Note: The community controller uses separate keys for host and port. The F5 NGINX Ingress Controller combines them into a single endpoint URL.

Snippet-Based Keys

These community ConfigMap keys have no direct equivalent in the F5 NGINX Ingress Controller. Use main-snippets, http-snippets, or server-snippets in the NIC ConfigMap to inject the equivalent NGINX directives.

Kubernetes Ingress NGINX (Ingress-NGINX)	F5 NGINX Ingress Controller
`access-log-path`	`http-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: access-log-path: "/var/log/nginx/access.log"` F5 NGINX Ingress Controller ConfigMap `data: http-snippets: \| access_log /var/log/nginx/access.log;`
`custom-http-errors`	`server-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: custom-http-errors: "404,503"` F5 NGINX Ingress Controller ConfigMap `data: server-snippets: \| error_page 404 503 @custom_errors;` Note: The community controller integrates with a default backend for custom error pages. The NIC requires manual `error_page` directives via snippets, typically combined with a custom error backend.
`enable-brotli`	`http-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: enable-brotli: "true" brotli-level: "6"` F5 NGINX Ingress Controller ConfigMap `# Brotli is not included in the default NGINX build. # If using a custom build with the brotli module: data: http-snippets: \| brotli on; brotli_comp_level 6; brotli_types text/plain text/css application/json application/javascript;`
`error-log-path`	`main-snippets`
Kubernetes Ingress NGINX (Ingress-NGINX) ConfigMap `data: error-log-path: "/var/log/nginx/error.log"` F5 NGINX Ingress Controller ConfigMap `data: main-snippets: \| error_log /var/log/nginx/error.log warn;`