From e83f76ad31a35e0c00a29e1ee41ef32a2d54f436 Mon Sep 17 00:00:00 2001 From: Fabrizio Fiorucci Date: Mon, 29 Apr 2024 16:21:29 +0100 Subject: [PATCH 1/4] NGINX App Protect DoS references added --- .../installing-nic/installation-with-manifests.md | 4 ++++ .../nic-images/pulling-ingress-controller-image.md | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/content/installation/installing-nic/installation-with-manifests.md b/docs/content/installation/installing-nic/installation-with-manifests.md index 273cd355f2..9e0efa6a27 100644 --- a/docs/content/installation/installing-nic/installation-with-manifests.md +++ b/docs/content/installation/installing-nic/installation-with-manifests.md @@ -37,6 +37,10 @@ For example, if you want to use version 3.5.0, the command would be `git clone h This guide assumes you are using the latest release. +### App Protect DoS + +To use App Protect DoS, install the App Protect DoS Arbitrator using the provided manifests in the same namespace as the NGINX Ingress Controller. If you install multiple NGINX Ingress Controllers in the same namespace, they will need to share the same Arbitrator because there can only be one Arbitrator in a single namespace. + --- ## Set up role-based access control (RBAC) {#configure-rbac} diff --git a/docs/content/installation/nic-images/pulling-ingress-controller-image.md b/docs/content/installation/nic-images/pulling-ingress-controller-image.md index 3c472dfd78..6e4dc2eca2 100644 --- a/docs/content/installation/nic-images/pulling-ingress-controller-image.md +++ b/docs/content/installation/nic-images/pulling-ingress-controller-image.md @@ -60,7 +60,7 @@ To pull an image, follow these steps. Replace `` with the specific docker pull private-registry.nginx.com/nginx-ic-dos/nginx-plus-ingress: ``` -- For NGINX Plus Ingress Controller with NGINX App Protect WAF and DoS, run: +- For NGINX Plus Ingress Controller with NGINX App Protect WAF and NGINX App Protect DoS, run: ```shell docker pull private-registry.nginx.com/nginx-ic-nap-dos/nginx-plus-ingress: From f70bfe4c5f62da3ae013be7842dfe4b2c7bd7a68 Mon Sep 17 00:00:00 2001 From: Fabrizio Fiorucci Date: Fri, 24 May 2024 11:07:34 +0100 Subject: [PATCH 2/4] Added missing cd command --- .../installing-nic/installation-with-manifests.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/content/installation/installing-nic/installation-with-manifests.md b/docs/content/installation/installing-nic/installation-with-manifests.md index e83263806e..4f7c9525ac 100644 --- a/docs/content/installation/installing-nic/installation-with-manifests.md +++ b/docs/content/installation/installing-nic/installation-with-manifests.md @@ -37,6 +37,12 @@ For example, if you want to use version 3.5.1, the command would be `git clone h This guide assumes you are using the latest release. +Change the active directory. + +```shell +cd kubernetes-ingress +``` + ### App Protect DoS To use App Protect DoS, install the App Protect DoS Arbitrator using the provided manifests in the same namespace as the NGINX Ingress Controller. If you install multiple NGINX Ingress Controllers in the same namespace, they will need to share the same Arbitrator because there can only be one Arbitrator in a single namespace. From 1b867e3d8193efcf34f9c358398b8baa0fcf27e2 Mon Sep 17 00:00:00 2001 From: Fabrizio Fiorucci Date: Wed, 12 Mar 2025 13:35:20 +0000 Subject: [PATCH 3/4] Added SNI support for JWT secrets retrieved from HTTPS URL --- internal/configs/version2/nginx-plus.virtualserver.tmpl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/internal/configs/version2/nginx-plus.virtualserver.tmpl b/internal/configs/version2/nginx-plus.virtualserver.tmpl index b943e2d227..d9182616ae 100644 --- a/internal/configs/version2/nginx-plus.virtualserver.tmpl +++ b/internal/configs/version2/nginx-plus.virtualserver.tmpl @@ -216,6 +216,8 @@ server { {{- end }} {{- with .JwksURI }} proxy_set_header Host {{ .JwksHost }}; + proxy_ssl_name {{ .JwksHost }}; + proxy_ssl_server_name on; set $idp_backend {{ .JwksHost }}; proxy_pass {{ .JwksScheme}}://$idp_backend{{ if .JwksPort }}:{{ .JwksPort }}{{ end }}{{ .JwksPath }}; {{- end }} From 83ab9226311b3f00566353e3b12e884969443194 Mon Sep 17 00:00:00 2001 From: Fabrizio Fiorucci Date: Fri, 2 May 2025 13:41:11 +0100 Subject: [PATCH 4/4] Removed docs references --- docs/.hugo_build.lock | 0 docs/.markdownlint.json | 22 - docs/Makefile | 88 - docs/README.md | 159 -- docs/config/_default/config.toml | 65 - docs/config/development/config.toml | 7 - docs/config/production/config.toml | 24 - docs/config/staging/config.toml | 4 - docs/content/_index.md | 6 - docs/content/community.md | 22 - docs/content/configuration/_index.md | 8 - .../configuration/configuration-examples.md | 13 - .../global-configuration/_index.md | 8 - .../command-line-arguments.md | 562 ----- .../configmap-resource.md | 195 -- .../global-configuration/custom-templates.md | 10 - .../globalconfiguration-resource.md | 154 -- .../reporting-resources-status.md | 174 -- .../handling-host-and-listener-collisions.md | 143 -- .../configuration/ingress-resources/_index.md | 8 - ...advanced-configuration-with-annotations.md | 224 -- .../advanced-configuration-with-snippets.md | 127 -- .../ingress-resources/basic-configuration.md | 121 - .../cross-namespace-configuration.md | 14 - .../ingress-resources/custom-annotations.md | 144 -- docs/content/configuration/policy-resource.md | 733 ------ docs/content/configuration/security.md | 99 - .../configuration/transportserver-resource.md | 419 ---- ...server-and-virtualserverroute-resources.md | 1106 ---------- docs/content/glossary.md | 24 - docs/content/includes/index.md | 3 - .../installation/create-common-resources.md | 27 - .../installation/create-custom-resources.md | 52 - .../installation/deploy-controller.md | 10 - .../installation/manifests/daemonset.md | 21 - .../installation/manifests/deployment.md | 21 - .../manifests/verify-pods-are-running.md | 10 - docs/content/includes/rbac/set-up-rbac.md | 33 - docs/content/installation/_index.md | 8 - .../building-nginx-ingress-controller.md | 195 -- docs/content/installation/ingress-nginx.md | 546 ----- .../installation/installing-nic/_index.md | 5 - .../installing-nic/installation-with-helm.md | 471 ---- .../installation-with-manifests.md | 303 --- .../installation-with-operator.md | 72 - .../installation/integrations/_index.md | 5 - .../integrations/app-protect-dos/_index.md | 8 - .../app-protect-dos/configuration.md | 162 -- .../app-protect-dos/dos-protected.md | 125 -- .../app-protect-dos/installation.md | 228 -- .../troubleshooting-app-protect-dos.md | 111 - .../integrations/app-protect-waf/_index.md | 9 - .../app-protect-waf/configuration.md | 546 ----- .../app-protect-waf/installation.md | 228 -- .../troubleshooting-app-protect-waf.md | 134 -- .../integrations/f5-ingresslink.md | 95 - .../installation/integrations/opentracing.md | 112 - .../content/installation/nic-images/_index.md | 5 - .../pulling-ingress-controller-image.md | 168 -- .../nic-images/using-aws-marketplace-image.md | 91 - .../using-gcp-marketplace-package.md | 117 - .../using-the-jwt-token-docker-secret.md | 200 -- .../running-multiple-ingress-controllers.md | 53 - docs/content/logging-and-monitoring/_index.md | 8 - .../content/logging-and-monitoring/logging.md | 35 - .../logging-and-monitoring/prometheus.md | 85 - .../logging-and-monitoring/service-insight.md | 56 - .../logging-and-monitoring/status-page.md | 64 - docs/content/overview/_index.md | 8 - docs/content/overview/about.md | 16 - .../content/overview/controller-comparison.md | 65 - docs/content/overview/design.md | 312 --- docs/content/overview/nginx-plus.md | 31 - docs/content/overview/product-telemetry.md | 70 - docs/content/releases.md | 1966 ----------------- docs/content/technical-specifications.md | 116 - docs/content/troubleshooting/_index.md | 8 - .../troubleshooting/troubleshoot-common.md | 206 -- .../troubleshoot-configmap-policy.md | 48 - .../troubleshooting/troubleshoot-ingress.md | 29 - .../troubleshoot-transportserver.md | 9 - .../troubleshoot-virtualserver.md | 38 - docs/content/tutorials/_index.md | 8 - docs/content/tutorials/custom-listen-ports.md | 159 -- .../ingress-path-regex-annotation.md | 456 ---- .../content/tutorials/nginx-dynamic-module.md | 117 - docs/content/tutorials/nginx-ingress-istio.md | 262 --- .../tutorials/nginx-ingress-linkerd.md | 181 -- docs/content/tutorials/nginx-ingress-osm.md | 459 ---- .../tutorials/oidc-custom-configuration.md | 207 -- docs/content/tutorials/security-monitoring.md | 95 - ...rtual-server-with-custom-listener-ports.md | 185 -- docs/content/usage-reporting.md | 233 -- docs/developer/README.md | 3 - docs/developer/debugging.md | 183 -- docs/developer/telemetry-schema-generation.md | 37 - docs/go.mod | 5 - docs/go.sum | 4 - docs/layouts/shortcodes/call-out.html | 3 - docs/layouts/shortcodes/custom-styles.html | 41 - docs/md-linkcheck-config.json | 13 - docs/static/img/control-loop.png | Bin 5633 -> 0 bytes docs/static/img/controller-sync.png | Bin 34320 -> 0 bytes docs/static/img/ecr-pull-instructions.png | Bin 148462 -> 0 bytes docs/static/img/gke-create-cluster.png | Bin 101052 -> 0 bytes docs/static/img/gke-creating-cluster.png | Bin 66820 -> 0 bytes docs/static/img/gke-existing-cluster.png | Bin 169834 -> 0 bytes .../gke-ingress-controller-application.png | Bin 150715 -> 0 bytes .../static/img/gke-install-to-new-cluster.png | Bin 201085 -> 0 bytes docs/static/img/ic-high-level.png | Bin 99912 -> 0 bytes docs/static/img/ic-pod.png | Bin 54934 -> 0 bytes docs/static/img/ic-process-components.png | Bin 51942 -> 0 bytes docs/static/img/ic-process.png | Bin 24035 -> 0 bytes docs/static/img/nginx-envoy.png | Bin 152518 -> 0 bytes docs/static/img/nginx_istio_small.png | Bin 125996 -> 0 bytes docs/static/img/nginx_plain.png | Bin 119752 -> 0 bytes 116 files changed, 14678 deletions(-) delete mode 100644 docs/.hugo_build.lock delete mode 100644 docs/.markdownlint.json delete mode 100644 docs/Makefile delete mode 100644 docs/README.md delete mode 100644 docs/config/_default/config.toml delete mode 100644 docs/config/development/config.toml delete mode 100644 docs/config/production/config.toml delete mode 100644 docs/config/staging/config.toml delete mode 100644 docs/content/_index.md delete mode 100644 docs/content/community.md delete mode 100644 docs/content/configuration/_index.md delete mode 100644 docs/content/configuration/configuration-examples.md delete mode 100644 docs/content/configuration/global-configuration/_index.md delete mode 100644 docs/content/configuration/global-configuration/command-line-arguments.md delete mode 100644 docs/content/configuration/global-configuration/configmap-resource.md delete mode 100644 docs/content/configuration/global-configuration/custom-templates.md delete mode 100644 docs/content/configuration/global-configuration/globalconfiguration-resource.md delete mode 100644 docs/content/configuration/global-configuration/reporting-resources-status.md delete mode 100644 docs/content/configuration/handling-host-and-listener-collisions.md delete mode 100644 docs/content/configuration/ingress-resources/_index.md delete mode 100644 docs/content/configuration/ingress-resources/advanced-configuration-with-annotations.md delete mode 100644 docs/content/configuration/ingress-resources/advanced-configuration-with-snippets.md delete mode 100644 docs/content/configuration/ingress-resources/basic-configuration.md delete mode 100644 docs/content/configuration/ingress-resources/cross-namespace-configuration.md delete mode 100644 docs/content/configuration/ingress-resources/custom-annotations.md delete mode 100644 docs/content/configuration/policy-resource.md delete mode 100644 docs/content/configuration/security.md delete mode 100644 docs/content/configuration/transportserver-resource.md delete mode 100644 docs/content/configuration/virtualserver-and-virtualserverroute-resources.md delete mode 100644 docs/content/glossary.md delete mode 100644 docs/content/includes/index.md delete mode 100644 docs/content/includes/installation/create-common-resources.md delete mode 100644 docs/content/includes/installation/create-custom-resources.md delete mode 100644 docs/content/includes/installation/deploy-controller.md delete mode 100644 docs/content/includes/installation/manifests/daemonset.md delete mode 100644 docs/content/includes/installation/manifests/deployment.md delete mode 100644 docs/content/includes/installation/manifests/verify-pods-are-running.md delete mode 100644 docs/content/includes/rbac/set-up-rbac.md delete mode 100644 docs/content/installation/_index.md delete mode 100644 docs/content/installation/building-nginx-ingress-controller.md delete mode 100644 docs/content/installation/ingress-nginx.md delete mode 100644 docs/content/installation/installing-nic/_index.md delete mode 100644 docs/content/installation/installing-nic/installation-with-helm.md delete mode 100644 docs/content/installation/installing-nic/installation-with-manifests.md delete mode 100644 docs/content/installation/installing-nic/installation-with-operator.md delete mode 100644 docs/content/installation/integrations/_index.md delete mode 100644 docs/content/installation/integrations/app-protect-dos/_index.md delete mode 100644 docs/content/installation/integrations/app-protect-dos/configuration.md delete mode 100644 docs/content/installation/integrations/app-protect-dos/dos-protected.md delete mode 100644 docs/content/installation/integrations/app-protect-dos/installation.md delete mode 100644 docs/content/installation/integrations/app-protect-dos/troubleshooting-app-protect-dos.md delete mode 100644 docs/content/installation/integrations/app-protect-waf/_index.md delete mode 100644 docs/content/installation/integrations/app-protect-waf/configuration.md delete mode 100644 docs/content/installation/integrations/app-protect-waf/installation.md delete mode 100644 docs/content/installation/integrations/app-protect-waf/troubleshooting-app-protect-waf.md delete mode 100644 docs/content/installation/integrations/f5-ingresslink.md delete mode 100644 docs/content/installation/integrations/opentracing.md delete mode 100644 docs/content/installation/nic-images/_index.md delete mode 100644 docs/content/installation/nic-images/pulling-ingress-controller-image.md delete mode 100644 docs/content/installation/nic-images/using-aws-marketplace-image.md delete mode 100644 docs/content/installation/nic-images/using-gcp-marketplace-package.md delete mode 100644 docs/content/installation/nic-images/using-the-jwt-token-docker-secret.md delete mode 100644 docs/content/installation/running-multiple-ingress-controllers.md delete mode 100644 docs/content/logging-and-monitoring/_index.md delete mode 100644 docs/content/logging-and-monitoring/logging.md delete mode 100644 docs/content/logging-and-monitoring/prometheus.md delete mode 100644 docs/content/logging-and-monitoring/service-insight.md delete mode 100644 docs/content/logging-and-monitoring/status-page.md delete mode 100644 docs/content/overview/_index.md delete mode 100644 docs/content/overview/about.md delete mode 100644 docs/content/overview/controller-comparison.md delete mode 100644 docs/content/overview/design.md delete mode 100644 docs/content/overview/nginx-plus.md delete mode 100644 docs/content/overview/product-telemetry.md delete mode 100644 docs/content/releases.md delete mode 100644 docs/content/technical-specifications.md delete mode 100644 docs/content/troubleshooting/_index.md delete mode 100644 docs/content/troubleshooting/troubleshoot-common.md delete mode 100644 docs/content/troubleshooting/troubleshoot-configmap-policy.md delete mode 100644 docs/content/troubleshooting/troubleshoot-ingress.md delete mode 100644 docs/content/troubleshooting/troubleshoot-transportserver.md delete mode 100644 docs/content/troubleshooting/troubleshoot-virtualserver.md delete mode 100644 docs/content/tutorials/_index.md delete mode 100644 docs/content/tutorials/custom-listen-ports.md delete mode 100644 docs/content/tutorials/ingress-path-regex-annotation.md delete mode 100644 docs/content/tutorials/nginx-dynamic-module.md delete mode 100644 docs/content/tutorials/nginx-ingress-istio.md delete mode 100644 docs/content/tutorials/nginx-ingress-linkerd.md delete mode 100644 docs/content/tutorials/nginx-ingress-osm.md delete mode 100644 docs/content/tutorials/oidc-custom-configuration.md delete mode 100644 docs/content/tutorials/security-monitoring.md delete mode 100644 docs/content/tutorials/virtual-server-with-custom-listener-ports.md delete mode 100644 docs/content/usage-reporting.md delete mode 100644 docs/developer/README.md delete mode 100644 docs/developer/debugging.md delete mode 100644 docs/developer/telemetry-schema-generation.md delete mode 100644 docs/go.mod delete mode 100644 docs/go.sum delete mode 100644 docs/layouts/shortcodes/call-out.html delete mode 100644 docs/layouts/shortcodes/custom-styles.html delete mode 100644 docs/md-linkcheck-config.json delete mode 100644 docs/static/img/control-loop.png delete mode 100644 docs/static/img/controller-sync.png delete mode 100644 docs/static/img/ecr-pull-instructions.png delete mode 100644 docs/static/img/gke-create-cluster.png delete mode 100644 docs/static/img/gke-creating-cluster.png delete mode 100644 docs/static/img/gke-existing-cluster.png delete mode 100644 docs/static/img/gke-ingress-controller-application.png delete mode 100644 docs/static/img/gke-install-to-new-cluster.png delete mode 100644 docs/static/img/ic-high-level.png delete mode 100644 docs/static/img/ic-pod.png delete mode 100644 docs/static/img/ic-process-components.png delete mode 100644 docs/static/img/ic-process.png delete mode 100644 docs/static/img/nginx-envoy.png delete mode 100644 docs/static/img/nginx_istio_small.png delete mode 100644 docs/static/img/nginx_plain.png diff --git a/docs/.hugo_build.lock b/docs/.hugo_build.lock deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/docs/.markdownlint.json b/docs/.markdownlint.json deleted file mode 100644 index f25d51518a..0000000000 --- a/docs/.markdownlint.json +++ /dev/null @@ -1,22 +0,0 @@ -{ - "MD009": false, - "MD012": false, - "MD010": false, - "MD013": false, - "MD004": { - "style": "dash" - }, - "MD022": false, - "MD033": false, - "MD041": false, - "MD003": false, - "MD002": false, - "MD024": { - "siblings_only": true - }, - "MD046": false, - "MD001": false, - "MD049": false, - "MD055": false, - "MD056": false -} diff --git a/docs/Makefile b/docs/Makefile deleted file mode 100644 index 2eda42e6fb..0000000000 --- a/docs/Makefile +++ /dev/null @@ -1,88 +0,0 @@ -HUGO?=hugo -# the officially recommended unofficial docker image -HUGO_IMG?=hugomods/hugo:0.115.3 - -THEME_MODULE = github.com/nginxinc/nginx-hugo-theme -## Pulls the current theme version from the Netlify settings -THEME_VERSION = $(NGINX_THEME_VERSION) -NETLIFY_DEPLOY_URL = ${DEPLOY_PRIME_URL} - -# if there's no local hugo, fallback to docker -ifeq (, $(shell ${HUGO} version 2> /dev/null)) -ifeq (, $(shell docker version 2> /dev/null)) - $(error Docker and Hugo are not installed. Hugo (<0.91) or Docker are required to build the local preview.) -else - HUGO=docker run --rm -it -v ${CURDIR}:/src -p 1313:1313 ${HUGO_IMG} hugo -endif -endif - -MARKDOWNLINT?=markdownlint -MARKDOWNLINT_IMG?=ghcr.io/igorshubovych/markdownlint-cli:latest - -# if there's no local markdownlint, fallback to docker -ifeq (, $(shell ${MARKDOWNLINT} version 2> /dev/null)) -ifeq (, $(shell docker version 2> /dev/null)) -ifneq (, $(shell $(NETLIFY) "true")) - $(error Docker and markdownlint are not installed. markdownlint or Docker are required to lint.) -endif -else - MARKDOWNLINT=docker run --rm -i -v ${CURDIR}:/src --workdir /src ${MARKDOWNLINT_IMG} -endif -endif - -MARKDOWNLINKCHECK?=markdown-link-check -MARKDOWNLINKCHECK_IMG?=ghcr.io/tcort/markdown-link-check:stable -# if there's no local markdown-link-check, fallback to docker -ifeq (, $(shell ${MARKDOWNLINKCHECK} --version 2> /dev/null)) -ifeq (, $(shell docker version 2> /dev/null)) -ifneq (, $(shell $(NETLIFY) "true")) - $(error Docker and markdown-link-check are not installed. markdown-link-check or Docker are required to check links.) -endif -else - MARKDOWNLINKCHECK=docker run --rm -it -v ${CURDIR}:/site --workdir /site ${MARKDOWNLINKCHECK_IMG} -endif -endif - -.PHONY: all all-staging all-dev all-local clean hugo-mod build-production build-staging build-dev docs-drafts docs deploy-preview - -all: hugo-mod build-production - -all-staging: hugo-mod build-staging - -all-dev: hugo-mod build-dev - -all-local: clean hugo-mod build-production - -docs: - ${HUGO} - -clean: - if [[ -d ${PWD}/public ]] ; then rm -rf ${PWD}/public && echo "Removed public directory" ; else echo "Did not find a public directory to remove" ; fi - -watch: - ${HUGO} --bind 0.0.0.0 -p 1313 server --disableFastRender - -watch-drafts: - ${HUGO} --bind 0.0.0.0 -p 1313 server -D --disableFastRender - -link-check: - ${MARKDOWNLINKCHECK} $(shell find content -name '*.md') - -lint-markdown: - ${MARKDOWNLINT} -c .markdownlint.json -- content - -# Commands used by Netlify CI -hugo-mod: - hugo mod get $(THEME_MODULE)@v$(THEME_VERSION) - -build-production: - hugo --gc -e production - -build-staging: - hugo --gc -e staging - -build-dev: - hugo --gc -e development - -deploy-preview: hugo-mod - hugo --gc -b ${NETLIFY_DEPLOY_URL}/nginx-ingress-controller/ diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index 939630fdc9..0000000000 --- a/docs/README.md +++ /dev/null @@ -1,159 +0,0 @@ -# NGINX Ingress Controller Documentation - -This directory contains all of the user documentation for NGINX Ingress Controller, as well as the requirements for building and publishing the documentation. - -Documentation is written in Markdown, built using [Hugo](https://gohugo.io) with [nginx-hugo-theme](https://github.com/nginxinc/nginx-hugo-theme), then deployed with [Netlify](https://www.netlify.com/). - -## Setup - -Hugo is the only requirement for building documentation, but the repository's integration tooling uses markdownlint-cli. - -> **Note**: We currently use [Hugo v0.115.3](https://github.com/gohugoio/hugo/releases/tag/v0.115.3) in production. - -Although not a strict requirement, markdown-link-check is also used in documentation development. - -If you have [Docker](https://www.docker.com/get-started/) installed, there are fallbacks for all in the [Makefile](Makefile), meaning you do need to install them. - -- [Installing Hugo](https://gohugo.io/getting-started/installing/) -- [Installing markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli?tab=readme-ov-file#installation) -- [Installing markdown-link-check](https://github.com/tcort/markdown-link-check?tab=readme-ov-file#installation). - -The configuration files are as follows: - -- *Hugo*: `config/_default/config.toml` -- *markdownlint-cli*: `.markdownlint.json` -- *markdown-link-check* `md-linkcheck-config.json` - -## Repository guidelines - -To work on documentation, create a feature branch in a forked repository then target `main` with your pull requests, which is the default repository branch. - -The documentation is published from the latest public release branch. If your changes require immediate publication, create a pull request to cherry-pick changes from `main` to the public release branch. - -## Developing documentation locally - -To build the documentation locally, run the `make` command inside this `/site/` directory: - -```text -make docs - Builds the documentation set with the output as the '/public' directory -make clean - Removes the local '/public/' directory -make watch - Starts a local Hugo server for live previews -make watch-drafts - Starts a local Hugo server for live previews, including documentation marked with 'draft: true' -make link-check - Check for any broken links in the documentation -make lint-markdown - Runs markdownlint to identify possible markdown formatting issues -``` - -The `watch` options automatically reload the Hugo server, allowing you to view updates as you work. - -> **Note**: The documentation uses build environments to control the baseURL used for things like internal references and static resources. The configuration for each environment can be found in the `config` directory. When running Hugo you can specify the environment and baseURL, but it's unnecessary. - -## Adding new documentation - -### Using Hugo to generate a new documentation file - -To create a new documentation file with the pre-configured Hugo front-matter for the task template, run the following command inside this `/site` directory: - -`hugo new /.md` - -For example: - -```shell -hugo new getting-started/install.md -``` - -The default template (task) should be used for most pages. For other content templates, you can use the `--kind` flag: - -```shell -hugo new tutorials/deploy.md --kind tutorial -``` - -The available content templates (`kind`) are: - -- concept: Help a user learn about a specific feature or feature set. -- tutorial: Walk a user through an example use case scenario. -- reference: Describes an API, command line tool, configuration options, etc. -- troubleshooting: Guide a user towards solving a specific problem. -- openapi: A template with the requirements to render an openapi.yaml specification. - -## Documentation formatting - -### Basic markdown formatting - -There are multiple ways to format text: for consistency and clarity, these are our conventions: - -- Bold: Two asterisks on each side - `**Bolded text**`. -- Italic: One underscore on each side - `_Italicized text_`. -- Unordered lists: One dash - `- Unordered list item`. -- Ordered lists: The 1 character followed by a stop - `1. Ordered list item`. - -> **Note**: The ordered notation automatically enumerates lists when built by Hugo. - -Close every section with a horizontal line by using three dashes: `---`. - -### How to format internal links - -Internal links should use Hugo [ref and relref shortcodes](https://gohugo.io/content-management/cross-references/). - -- Although file extensions are optional for Hugo, we include them as best practice for page anchors. -- Relative paths are preferred, but just the filename is permissible. -- Paths without a leading forward slash (`/`) are first resolved relative to the current page, then the remainder of the website. - -Here are two examples: - -```md -To install , refer to the [installation instructions]({{< ref "install.md" >}}). -To install , refer to the [integration instructions]({{< relref "/integration/thing.md#section" >}}). -``` - -### How to add images - -Use the `img` [shortcode](#using-hugo-shortcodes) to add images into your documentation. - -1. Add the image to the `/static/img` directory. -1. Add the `img` shortcode: - `{{< img src="" >}}` - - **Do not include a forward slash at the beginning of the file path.** - - This will break the image when it's rendered: read about the [Hugo relURL Function](https://gohugo.io/functions/relurl/#input-begins-with-a-slash) to learn more. - -> **Note**: The `img` shortcode accepts all of the same parameters as the Hugo [figure shortcode](https://gohugo.io/content-management/shortcodes/#figure). - -### Using Hugo shortcodes - -[Hugo shortcodes](/docs/themes/f5-hugo/layouts/shortcodes/) are used to format callouts, add images, and reuse content across different pages. - -For example, to use the `note` callout: - -```md -{{< note >}}Provide the text of the note here.{{< /note >}} -``` - -The callout shortcodes support multi-line blocks: - -```md -{{< caution >}} -You should probably never do this specific thing in a production environment. - -If you do, and things break, don't say we didn't warn you. -{{< /caution >}} -``` - -Supported callouts: - -- `caution` -- `important` -- `note` -- `see-also` -- `tip` -- `warning` - -Here are some other shortcodes: - -- `fa`: Inserts a Font Awesome icon -- `collapse`: Make a section collapsible -- `tab`: Create mutually exclusive tabbed window panes, useful for parallel instructions -- `table`: Add scrollbars to wide tables for browsers with smaller viewports -- `link`: Link to a file, prepending its path with the Hugo baseUrl -- `openapi`: Loads an OpenAPI specifcation and render it as HTML using ReDoc -- `include`: Include the content of a file in another file; the included file must be present in the '/content/includes/' directory -- `raw-html`: Include a block of raw HTML -- `readfile`: Include the content of another file in the current file, which can be in an arbitrary location. diff --git a/docs/config/_default/config.toml b/docs/config/_default/config.toml deleted file mode 100644 index 85f031c73c..0000000000 --- a/docs/config/_default/config.toml +++ /dev/null @@ -1,65 +0,0 @@ -title = "NGINX Ingress Controller" -baseURL = "/" -enableGitInfo = false -staticDir = ["static"] -languageCode = "en-us" -description = "Enterprise-grade Ingress load balancing on Kubernetes platforms." -refLinksErrorLevel = "ERROR" -enableRobotsTXT = "true" -canonifyURLs = true -pygmentsCodeFences = true -pygmentsUseClasses = true - -[caches] - [caches.modules] - dir = "/tmp/hugo_cache/modules" - maxAge = -1 - -[[module.imports]] - path="github.com/nginxinc/nginx-hugo-theme" - -[markup] - [markup.highlight] - codeFences = true - guessSyntax = true - hl_Lines = "" - lineNoStart = 1 - lineNos = false - lineNumbersInTable = true - style = "monokai" - tabWidth = 4 - [markup.goldmark] - [markup.goldmark.extensions] - definitionList = true - footnote = true - linkify = true - strikethrough = true - table = true - taskList = true - typographer = true - [markup.goldmark.parser] - attribute = true - autoHeadingID = true - autoHeadingIDType = "gitlab" - [markup.goldmark.renderer] - hardWraps = false - unsafe = true - xhtml = false - -[params] - buildtype = "webdocs" - useSectionPageLists = "true" - RSSLink = "/index.xml" - author = "NGINX Inc." # add your company name - github = "nginxinc" # add your github profile name - twitter = "@nginx" # add your twitter profile - #email = "" - noindex_kinds = [ - "taxonomy", - "taxonomyTerm" - ] - logo = "NGINX-Ingress-Controller-product-icon.svg" - -sectionPagesMenu = "docs" - -ignoreFiles = [ "\\.sh$", "\\.DS_Store$", "\\.git.*$", "\\.txt$", "\\/config\\/.*"] diff --git a/docs/config/development/config.toml b/docs/config/development/config.toml deleted file mode 100644 index b616b14b18..0000000000 --- a/docs/config/development/config.toml +++ /dev/null @@ -1,7 +0,0 @@ -baseURL = "https://docs-dev.nginx.com/nginx-ingress-controller" -title = "DEV -- NGINX Ingress Controller Docs" -publishDir = "public/nginx-ingress-controller" -canonifyURLs = false - -[Params] - buildtype = "webdocs" diff --git a/docs/config/production/config.toml b/docs/config/production/config.toml deleted file mode 100644 index 4d674aec22..0000000000 --- a/docs/config/production/config.toml +++ /dev/null @@ -1,24 +0,0 @@ -baseURL = "https://docs.nginx.com/nginx-ingress-controller" -title = "NGINX Ingress Controller" -publishDir = "public/nginx-ingress-controller" -canonifyURLs = false - -[privacy] - [privacy.disqus] - disable = false - [privacy.googleAnalytics] - anonymizeIP = true - disable = false - respectDoNotTrack = true - useSessionStorage = false - [privacy.instagram] - disable = true - [privacy.twitter] - disable = false - enableDNT = true - simple = false - [privacy.vimeo] - disable = true - [privacy.youtube] - disable = false - privacyEnhanced = true diff --git a/docs/config/staging/config.toml b/docs/config/staging/config.toml deleted file mode 100644 index b0a3b95be5..0000000000 --- a/docs/config/staging/config.toml +++ /dev/null @@ -1,4 +0,0 @@ -baseURL = "https://docs-staging.nginx.com/nginx-ingress-controller" -title = "STAGING -- NGINX Ingress Controller Docs" -publishDir = "public/nginx-ingress-controller" -canonifyURLs = false diff --git a/docs/content/_index.md b/docs/content/_index.md deleted file mode 100644 index 2efd331f71..0000000000 --- a/docs/content/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: NGINX Ingress Controller -description: -linkTitle: "NGINX Ingress Controller" -menu: docs ---- diff --git a/docs/content/community.md b/docs/content/community.md deleted file mode 100644 index f4acbd2f8d..0000000000 --- a/docs/content/community.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -docs: DOCS-1447 -title: Community and Contribution -toc: true -weight: 2200 ---- - -There are a few ways to get involved with the NGINX Ingress Controller community and contribute to the project. - -# Community - -- Our [Slack channel #nginx-ingress-controller](https://nginxcommunity.slack.com/channels/nginx-ingress-controller), is the go-to place to start asking questions and sharing your thoughts. - -- Our [GitHub issues page](https://github.com/nginxinc/kubernetes-ingress/issues) or [GitHub discussions page](https://github.com/nginxinc/kubernetes-ingress/discussions) offers more space for an asynchronous technical discussion. - -# Contribute - -Please see our [contributing guide](https://github.com/nginxinc/kubernetes-ingress/blob/main/CONTRIBUTING.md) to get involved with code or documentation. - -# License - -[Apache License, Version 2.0](https://github.com/nginxinc/kubernetes-ingress/blob/main/LICENSE) diff --git a/docs/content/configuration/_index.md b/docs/content/configuration/_index.md deleted file mode 100644 index 7e15009732..0000000000 --- a/docs/content/configuration/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Configuration -description: -weight: 1400 -menu: - docs: - parent: NGINX Ingress Controller ---- diff --git a/docs/content/configuration/configuration-examples.md b/docs/content/configuration/configuration-examples.md deleted file mode 100644 index bc832d58f1..0000000000 --- a/docs/content/configuration/configuration-examples.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -docs: DOCS-584 -doctypes: -- '' -title: Configuration Examples -toc: true -weight: 2000 ---- - -Our [GitHub repo](https://github.com/nginxinc/kubernetes-ingress) includes a number of configuration examples: - -- [*Examples of Custom Resources*](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources) show how to advanced NGINX features by using VirtualServer, VirtualServerRoute, TransportServer and Policy Custom Resources. -- [*Examples of Ingress Resources*](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources) show how to use advanced NGINX features in Ingress resources with annotations. diff --git a/docs/content/configuration/global-configuration/_index.md b/docs/content/configuration/global-configuration/_index.md deleted file mode 100644 index f2b919eb4c..0000000000 --- a/docs/content/configuration/global-configuration/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Global Configuration -description: -weight: 1400 -menu: - docs: - parent: NGINX Ingress Controller ---- diff --git a/docs/content/configuration/global-configuration/command-line-arguments.md b/docs/content/configuration/global-configuration/command-line-arguments.md deleted file mode 100644 index 973a80e73c..0000000000 --- a/docs/content/configuration/global-configuration/command-line-arguments.md +++ /dev/null @@ -1,562 +0,0 @@ ---- -docs: DOCS-585 -doctypes: -- '' -title: Command-line Arguments -toc: true -weight: 1700 ---- - -NGINX Ingress Controller supports several command-line arguments, which are passed to it based on your installation method: - -- If you're using *Kubernetes Manifests* (Deployment or DaemonSet) to install NGINX Ingress Controller, modify the Manifests to set the command-line arguments. Read [Installation with Manifests]({{}}) for more information. -- If you're using *Helm* to install NGINX Ingress Controller, modify the parameters of the Helm chart to set the command-line arguments. Read [Installation with Helm]({{}}) documentation for more information. - - - -### -enable-snippets - -Enable custom NGINX configuration snippets in Ingress, VirtualServer, VirtualServerRoute and TransportServer resources. - -Default `false`. - - - -### -default-server-tls-secret `` - -Secret with a TLS certificate and key for TLS termination of the default server. - -- If not set, certificate and key in the file `/etc/nginx/secrets/default` are used. -- If `/etc/nginx/secrets/default` doesn't exist, NGINX Ingress Controller will configure NGINX to reject TLS connections to the default server. -- If a secret is set, but NGINX Ingress Controller is not able to fetch it from Kubernetes API, or it is not set and NGINX Ingress Controller fails to read the file "/etc/nginx/secrets/default", NGINX Ingress Controller will fail to start. - -Format: `/` - - - -### -wildcard-tls-secret `` - -A Secret with a TLS certificate and key for TLS termination of every Ingress/VirtualServer host for which TLS termination is enabled but the Secret is not specified. - -- If the argument is not set, for such Ingress/VirtualServer hosts NGINX will break any attempt to establish a TLS connection. - -- If the argument is set, but NGINX Ingress Controller is not able to fetch the Secret from Kubernetes API, NGINX Ingress Controller will fail to start. - -Format: `/` - - - -### -enable-custom-resources - -Enables custom resources. - -Default `true`. - - - -### -enable-preview-policies - -Enables preview policies. This flag is deprecated. To enable OIDC Policies please use [-enable-oidc](#cmdoption-enable-oidc) instead. - -Default `false`. - - - -### -enable-oidc - -Enables OIDC policies. - -Default `false`. - - - -### -inlcude-year - -Adds year to log headers. - -Default `false`. - -**NOTE**: This flag will be removed in release 2.7 and the year will be included by default. - -### -enable-leader-election - -Enables Leader election to avoid multiple replicas of the controller reporting the status of Ingress, VirtualServer and VirtualServerRoute resources -- only one replica will report status. -Default `true`. - -See [-report-ingress-status](#cmdoption-report-ingress-status) flag. - - - -### -enable-tls-passthrough - -Enable TLS Passthrough on port 443. - -Requires [-enable-custom-resources](#cmdoption-enable-custom-resources). - - - -### -tls-passthrough-port `` - -Set the port for TLS Passthrough. -Format: `[1024 - 65535]` (default `443`) - -Requires [-enable-custom-resources](#cmdoption-enable-custom-resources). - - - -### -enable-cert-manager - -Enable x509 automated certificate management for VirtualServer resources using cert-manager (cert-manager.io). - -Requires [-enable-custom-resources](#cmdoption-enable-custom-resources). - - - -### -enable-external-dns - -Enable integration with ExternalDNS for configuring public DNS entries for VirtualServer resources using [ExternalDNS](https://github.com/kubernetes-sigs/external-dns). - -Requires [-enable-custom-resources](#cmdoption-enable-custom-resources). - - -### -external-service `` - -Specifies the name of the service with the type LoadBalancer through which the NGINX Ingress Controller pods are exposed externally. The external address of the service is used when reporting the status of Ingress, VirtualServer and VirtualServerRoute resources. - -For Ingress resources only: Requires [-report-ingress-status](#cmdoption-report-ingress-status). - - - -### -ingresslink `` - -Specifies the name of the IngressLink resource, which exposes the NGINX Ingress Controller pods via a BIG-IP system. The IP of the BIG-IP system is used when reporting the status of Ingress, VirtualServer and VirtualServerRoute resources. - -For Ingress resources only: Requires [-report-ingress-status](#cmdoption-report-ingress-status). - - - -### -global-configuration `` - -A GlobalConfiguration resource for global configuration of NGINX Ingress Controller. - -Format: `/` - -Requires [-enable-custom-resources](#cmdoption-enable-custom-resources). - - - -### -health-status - -Adds a location "/nginx-health" to the default server. The location responds with the 200 status code for any request. - -Useful for external health-checking of NGINX Ingress Controller. - - - -### -health-status-uri `` - -Sets the URI of health status location in the default server. Requires [-health-status](#cmdoption-health-status). (default `/nginx-health`) - - - -### -ingress-class `` - -The `-ingress-class` argument refers to the name of the resource `kind: IngressClass`. An IngressClass resource with a name equal to the class must be deployed. Otherwise, NGINX Ingress Controller will fail to start. -NGINX Ingress Controller will only process Ingress resources that belong to its class (Whose `ingressClassName` value matches the value of `-ingress-class`), skipping the ones without it. It will also process all the VirtualServer/VirtualServerRoute/TransportServer resources that do not have the `ingressClassName` field. - -Default `nginx`. - - - -### -ingress-template-path `` - -Path to the ingress NGINX configuration template for an ingress resource. Default for NGINX is `nginx.ingress.tmpl`; default for NGINX Plus is `nginx-plus.ingress.tmpl`. - - - -### -leader-election-lock-name `` - -Specifies the name of the ConfigMap, within the same namespace as the controller, used as the lock for leader election. - -Requires [-enable-leader-election](#cmdoption-enable-leader-election). - - - -### -log_backtrace_at `` - -When logging hits line `file:N`, emit a stack trace. - - - -### -main-template-path `` - -Path to the main NGINX configuration template. - -- Default for NGINX is `nginx.tmpl`. -- Default for NGINX Plus is `nginx-plus.tmpl`. - - - -### -nginx-configmaps `` - -A ConfigMap resource for customizing NGINX configuration. If a ConfigMap is set, but NGINX Ingress Controller is not able to fetch it from Kubernetes API, NGINX Ingress Controller will fail to start. - -Format: `/` - - - -### -nginx-debug - -Enable debugging for NGINX. Uses the nginx-debug binary. Requires 'error-log-level: debug' in the ConfigMap. - - - -### -nginx-plus - -Enable support for NGINX Plus. - - - -### -nginx-reload-timeout `` - -Timeout in milliseconds which NGINX Ingress Controller will wait for a successful NGINX reload after a change or at the initial start. - -Default is 60000. - - - -### -nginx-status - -Enable the NGINX stub_status, or the NGINX Plus API. - -Default `true`. - - - -### -nginx-status-allow-cidrs `` - -Add IP/CIDR blocks to the allow list for NGINX stub_status or the NGINX Plus API. - -Separate multiple IP/CIDR by commas. (default `127.0.0.1,::1`) - - - -### -nginx-status-port `` - -Set the port where the NGINX stub_status or the NGINX Plus API is exposed. - -Format: `[1024 - 65535]` (default `8080`) - - - -### -proxy `` - -Use a proxy server to connect to Kubernetes API started by "kubectl proxy" command. **For testing purposes only**. - -NGINX Ingress Controller does not start NGINX and does not write any generated NGINX configuration files to disk. - - - -### -report-ingress-status - -Updates the address field in the status of Ingress resources. - -Requires the [-external-service](#cmdoption-external-service) or [-ingresslink](#cmdoption-ingresslink) flag, or the `external-status-address` key in the ConfigMap. - - - -### -transportserver-template-path `` - -Path to the TransportServer NGINX configuration template for a TransportServer resource. - -- Default for NGINX is `nginx.transportserver.tmpl`. -- Default for NGINX Plus is `nginx-plus.transportserver.tmpl`. - - - - -### -v `` - -Log level for V logs. - - - -### -version - -Print the version, git-commit hash and build date and exit. - - - -### -virtualserver-template-path `` - -Path to the VirtualServer NGINX configuration template for a VirtualServer resource. - -- Default for NGINX is `nginx.virtualserver.tmpl`. -- Default for NGINX Plus is `nginx-plus.virtualserver.tmpl`. - - - - -### -vmodule `` - -A comma-separated list of pattern=N settings for file-filtered logging. - - - -### -watch-namespace `` - -Comma separated list of namespaces NGINX Ingress Controller should watch for resources. By default NGINX Ingress Controller watches all namespaces. Mutually exclusive with "watch-namespace-label". - - - -### -watch-namespace-label `` - -Configures NGINX Ingress Controller to watch only those namespaces with label foo=bar. By default NGINX Ingress Controller watches all namespaces. Mutually exclusive with "watch-namespace". - - - -### -watch-secret-namespace `` - -Comma separated list of namespaces NGINX Ingress Controller should watch for secrets. If this arg is not configured, NGINX Ingress Controller watches the same namespaces for all resources. See "watch-namespace" and "watch-namespace-label". - - - -### -enable-prometheus-metrics - -Enables exposing NGINX or NGINX Plus metrics in the Prometheus format. - - - -### -prometheus-metrics-listen-port `` - -Sets the port where the Prometheus metrics are exposed. - -Format: `[1024 - 65535]` (default `9113`) - - - -### -prometheus-tls-secret `` - -A Secret with a TLS certificate and key for TLS termination of the Prometheus metrics endpoint. - -- If the argument is not set, the Prometheus endpoint will not use a TLS connection. -- If the argument is set, but NGINX Ingress Controller is not able to fetch the Secret from Kubernetes API, NGINX Ingress Controller will fail to start. - - - -### -enable-service-insight - -Exposes the Service Insight endpoint for Ingress Controller. - - - -### -service-insight-listen-port `` - -Sets the port where the Service Insight is exposed. - -Format: `[1024 - 65535]` (default `9114`) - - - -### -service-insight-tls-secret `` - -A Secret with a TLS certificate and key for TLS termination of the Service Insight endpoint. - -- If the argument is not set, the Service Insight endpoint will not use a TLS connection. -- If the argument is set, but NGINX Ingress Controller is not able to fetch the Secret from Kubernetes API, NGINX Ingress Controller will fail to start. - -Format: `/` - - - -### -spire-agent-address `` - -Specifies the address of a running Spire agent. **For use with NGINX Service Mesh only**. - -- If the argument is set, but NGINX Ingress Controller is unable to connect to the Spire Agent, NGINX Ingress Controller will fail to start. - - - - -### -enable-internal-routes - -Enable support for internal routes with NGINX Service Mesh. **For use with NGINX Service Mesh only**. - -Requires [-spire-agent-address](#cmdoption-spire-agent-address). - -- If the argument is set, but `spire-agent-address` is not provided, NGINX Ingress Controller will fail to start. - - - - -### -enable-latency-metrics - -Enable collection of latency metrics for upstreams. -Requires [-enable-prometheus-metrics](#cmdoption-enable-prometheus-metrics). - - - -### -enable-app-protect - -Enables support for App Protect. - -Requires [-nginx-plus](#cmdoption-nginx-plus). - -- If the argument is set, but `nginx-plus` is set to false, NGINX Ingress Controller will fail to start. - - - - -### -app-protect-log-level `` - -Sets log level for App Protect. Allowed values: fatal, error, warn, info, debug, trace. - -Requires [-nginx-plus](#cmdoption-nginx-plus) and [-enable-app-protect](#cmdoption-enable-app-protect). - -- If the argument is set, but `nginx-plus` and `enable-app-protect` are set to false, NGINX Ingress Controller will fail to start. - - - - -### -enable-app-protect-dos - -Enables support for App Protect DoS. - -Requires [-nginx-plus](#cmdoption-nginx-plus). - -- If the argument is set, but `nginx-plus` is set to false, NGINX Ingress Controller will fail to start. - - - - -### -app-protect-dos-debug - -Enable debugging for App Protect DoS. - -Requires [-nginx-plus](#cmdoption-nginx-plus) and [-enable-app-protect-dos](#cmdoption-enable-app-protect-dos). - -- If the argument is set, but `nginx-plus` and `enable-app-protect-dos` are set to false, NGINX Ingress Controller will fail to start. - - - - -### -app-protect-dos-max-daemons - -Max number of ADMD instances. - -Default `1`. - -Requires [-nginx-plus](#cmdoption-nginx-plus) and [-enable-app-protect-dos](#cmdoption-enable-app-protect-dos). - -- If the argument is set, but `nginx-plus` and `enable-app-protect-dos` are set to false, NGINX Ingress Controller will fail to start. - - - - -### -app-protect-dos-max-workers - -Max number of nginx processes to support. - -Default `Number of CPU cores in the machine`. - -Requires [-nginx-plus](#cmdoption-nginx-plus) and [-enable-app-protect-dos](#cmdoption-enable-app-protect-dos). - -- If the argument is set, but `nginx-plus` and `enable-app-protect-dos` are set to false, NGINX Ingress Controller will fail to start. - - - - -### -app-protect-dos-memory - -RAM memory size to consume in MB - -Default `50% of free RAM in the container or 80MB, the smaller`. - -Requires [-nginx-plus](#cmdoption-nginx-plus) and [-enable-app-protect-dos](#cmdoption-enable-app-protect-dos). - -- If the argument is set, but `nginx-plus` and `enable-app-protect-dos` are set to false, NGINX Ingress Controller will fail to start. - - - -### -ready-status - -Enables the readiness endpoint `/nginx-ready`. The endpoint returns a success code when NGINX has loaded all the config after the startup. - -Default `true`. - - - -### -ready-status-port - -The HTTP port for the readiness endpoint. - -Format: `[1024 - 65535]` (default `8081`) - - -### -disable-ipv6 - -Disable IPV6 listeners explicitly for nodes that do not support the IPV6 stack. - -Default `false`. - - - -### -default-http-listener-port - -Sets the port for the HTTP `default_server` listener. - -Default `80`. - - - -### -default-https-listener-port - -Sets the port for the HTTPS `default_server` listener. - -Default `443`. - - - -### -ssl-dynamic-reload - -Used to activate or deactivate lazy loading for SSL Certificates. - -The default value is `true`. - - - -### -weight-changes-dynamic-reload - -Enables the ability to change the weight distribution of two-way split clients without reloading NGINX. - -Requires [-nginx-plus](#cmdoption-nginx-plus). - -Using this feature may require increasing `map_hash_bucket_size`, `map_hash_max_size`, `variable_hash_bucket_size`, and `variable_hash_max_size` in the ConfigMap based on the number of two-way splits. - -The default value is `false`. - -- If the argument is set, but `nginx-plus` is set to false, NGINX Ingress Controller will ignore the flag. - - - -### -enable-telemetry-reporting - -Enable gathering and reporting of software telemetry. - -The default value is `true`. - - - -### -agent - -Enable NGINX Agent which can used with `-enable-app-protect` to send events to Security Monitoring. - -The default value is `false`. - - - -### -agent-instance-group - -Specify the instance group name to use for the NGINX Ingress Controller deployment when using `-agent`. - - diff --git a/docs/content/configuration/global-configuration/configmap-resource.md b/docs/content/configuration/global-configuration/configmap-resource.md deleted file mode 100644 index d6cdc5dcfc..0000000000 --- a/docs/content/configuration/global-configuration/configmap-resource.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -docs: DOCS-586 -doctypes: -- '' -title: ConfigMap Resources -toc: true -weight: 1600 ---- - -The ConfigMap Resources allows you to customize or fine tune NGINX behavior. Examples include setting the number of worker processes or customizing the access log format. - -## Using ConfigMap - -1. The [Installation with Manifests]({{< relref "/installation/installing-nic/installation-with-manifests.md" >}}) documentation deploy an empty ConfigMap while the default installation manifests specify it in the command-line arguments of the Ingress Controller. However, if you customized the manifests, to use ConfigMap, make sure to specify the ConfigMap resource to use the [command-line arguments]({{< relref "/configuration/global-configuration/command-line-arguments" >}}) of NGINX Ingress Controller. - -1. Create a ConfigMap file with the name *nginx-config.yaml* and set the values -that make sense for your setup: - - ```yaml - kind: ConfigMap - apiVersion: v1 - metadata: - name: nginx-config - namespace: nginx-ingress - data: - proxy-connect-timeout: "10s" - proxy-read-timeout: "10s" - client-max-body-size: "2m" - ``` - - See the section [Summary of ConfigMap Keys](#summary-of-configmap-keys) for the explanation of the available ConfigMap keys (such as `proxy-connect-timeout` in this example). - -1. Create a new (or update the existing) ConfigMap resource: - - ``` - kubectl apply -f nginx-config.yaml - ``` - - The NGINX configuration will be updated. - -## ConfigMap and Ingress Annotations - -Annotations allow you to configure advanced NGINX features and customize or fine tune NGINX behavior. - -The ConfigMap applies globally, meaning that it affects every Ingress resource. In contrast, annotations always apply to their Ingress resource. Annotations allow overriding some ConfigMap keys. For example, the `nginx.org/proxy-connect-timeout` annotations overrides the `proxy-connect-timeout` ConfigMap key. - -See the doc about [annotations](/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations). - -## ConfigMap and VirtualServer/VirtualServerRoute Resource - -The ConfigMap affects every VirtualServer and VirtualServerRoute resources. However, the fields of those resources allow overriding some ConfigMap keys. For example, the `connect-timeout` field of the `upstream` overrides the `proxy-connect-timeout` ConfigMap key. - -See the doc about [VirtualServer and VirtualServerRoute resources](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources). - -## Summary of ConfigMap Keys - -### Ingress Controller (Not Related to NGINX Configuration) - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``external-status-address`` | Sets the address to be reported in the status of Ingress resources. Requires the ``-report-status`` command-line argument. Overrides the ``-external-service`` argument. | N/A | [Report Ingress Status](/nginx-ingress-controller/configuration/global-configuration/reporting-resources-status). | -{{% /table %}} - -### General Customization - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``proxy-connect-timeout`` | Sets the value of the [proxy_connect_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout) and [grpc_connect_timeout](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_connect_timeout) directive. | ``60s`` | | -|``proxy-read-timeout`` | Sets the value of the [proxy_read_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) and [grpc_read_timeout](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_read_timeout) directive. | ``60s`` | | -|``proxy-send-timeout`` | Sets the value of the [proxy_send_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) and [grpc_send_timeout](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_send_timeout) directive. | ``60s`` | | -|``client-max-body-size`` | Sets the value of the [client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) directive. | ``1m`` | | -|``proxy-buffering`` | Enables or disables [buffering of responses](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering) from the proxied server. | ``True`` | | -|``proxy-buffers`` | Sets the value of the [proxy_buffers](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) directive. | Depends on the platform. | | -|``proxy-buffer-size`` | Sets the value of the [proxy_buffer_size](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) and [grpc_buffer_size](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_buffer_size) directives. | Depends on the platform. | | -|``proxy-max-temp-file-size`` | Sets the value of the [proxy_max_temp_file_size](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size) directive. | ``1024m`` | | -|``set-real-ip-from`` | Sets the value of the [set_real_ip_from](https://nginx.org/en/docs/http/ngx_http_realip_module.html#set_real_ip_from) directive. | N/A | | -|``real-ip-header`` | Sets the value of the [real_ip_header](https://nginx.org/en/docs/http/ngx_http_realip_module.html#real_ip_header) directive. | ``X-Real-IP`` | | -|``real-ip-recursive`` | Enables or disables the [real_ip_recursive](https://nginx.org/en/docs/http/ngx_http_realip_module.html#real_ip_recursive) directive. | ``False`` | | -|``default-server-return`` | Configures the [return](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return) directive in the default server, which handles a client request if none of the hosts of Ingress or VirtualServer resources match. The default value configures NGINX to return a 404 error page. You can configure a fixed response or a redirect. For example, ``default-server-return: 302 https://nginx.org`` will redirect a client to ``https://nginx.org``. | ``404`` | | -|``server-tokens`` | Enables or disables the [server_tokens](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens) directive. Additionally, with the NGINX Plus, you can specify a custom string value, including the empty string value, which disables the emission of the “Server” field. | ``True`` | | -|``worker-processes`` | Sets the value of the [worker_processes](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) directive. | ``auto`` | | -|``worker-rlimit-nofile`` | Sets the value of the [worker_rlimit_nofile](https://nginx.org/en/docs/ngx_core_module.html#worker_rlimit_nofile) directive. | N/A | | -|``worker-connections`` | Sets the value of the [worker_connections](https://nginx.org/en/docs/ngx_core_module.html#worker_connections) directive. | ``1024`` | | -|``worker-cpu-affinity`` | Sets the value of the [worker_cpu_affinity](https://nginx.org/en/docs/ngx_core_module.html#worker_cpu_affinity) directive. | N/A | | -|``worker-shutdown-timeout`` | Sets the value of the [worker_shutdown_timeout](https://nginx.org/en/docs/ngx_core_module.html#worker_shutdown_timeout) directive. | N/A | | -|``server-names-hash-bucket-size`` | Sets the value of the [server_names_hash_bucket_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_names_hash_bucket_size) directive. | ``256`` | | -|``server-names-hash-max-size`` | Sets the value of the [server_names_hash_max_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_names_hash_max_size) directive. | ``1024`` | | -|``map-hash-bucket-size`` | Sets the value of the [map_hash_bucket_size](http://nginx.org/en/docs/http/ngx_http_map_module.html#map_hash_bucket_size) directive.| ``256`` | | -|``map-hash-max-size`` | Sets the value of the [map_hash_max_size](http://nginx.org/en/docs/http/ngx_http_map_module.html#map_hash_max_size) directive. | ``2048`` | | -|``resolver-addresses`` | Sets the value of the [resolver](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) addresses. Note: If you use a DNS name (for example, ``kube-dns.kube-system.svc.cluster.local`` ) as a resolver address, NGINX Plus will resolve it using the system resolver during the start and on every configuration reload. If the name cannot be resolved or the DNS server doesn't respond, NGINX Plus will fail to start or reload. To avoid this, we recommend using IP addresses as resolver addresses instead of DNS names. Supported in NGINX Plus only. | N/A | [Support for Type ExternalName Services](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/externalname-services). | -|``resolver-ipv6`` | Enables IPv6 resolution in the resolver. Supported in NGINX Plus only. | ``True`` | [Support for Type ExternalName Services](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/externalname-services). | -|``resolver-valid`` | Sets the time NGINX caches the resolved DNS records. Supported in NGINX Plus only. | TTL value of a DNS record | [Support for Type ExternalName Services](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/externalname-services). | -|``resolver-timeout`` | Sets the [resolver_timeout](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver_timeout) for name resolution. Supported in NGINX Plus only. | ``30s`` | [Support for Type ExternalName Services](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/externalname-services). | -|``keepalive-timeout`` | Sets the value of the [keepalive_timeout](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout) directive. | ``75s`` | | -|``keepalive-requests`` | Sets the value of the [keepalive_requests](https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests) directive. | ``1000`` | | -|``variables-hash-bucket-size`` | Sets the value of the [variables_hash_bucket_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#variables_hash_bucket_size) directive. | ``256`` | | -|``variables-hash-max-size`` | Sets the value of the [variables-hash-max-size](https://nginx.org/en/docs/http/ngx_http_core_module.html#variables_hash_max_size) directive. | ``1024`` | | -{{% /table %}} - -### Logging - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``error-log-level`` | Sets the global [error log level](https://nginx.org/en/docs/ngx_core_module.html#error_log) for NGINX. | ``notice`` | | -|``access-log-off`` | Disables the [access log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log). | ``False`` | | -|``default-server-access-log-off`` | Disables the [access log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) for the default server. If access log is disabled globally (``access-log-off: "True"``), then the default server access log is always disabled. | ``False`` | | -|``log-format`` | Sets the custom [log format](https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) for HTTP and HTTPS traffic. For convenience, it is possible to define the log format across multiple lines (each line separated by ``\n``). In that case, the Ingress Controller will replace every ``\n`` character with a space character. All ``'`` characters must be escaped. | See the [template file](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/internal/configs/version1/nginx.tmpl) for the access log. | [Custom Log Format](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/shared-examples/custom-log-format). | -|``log-format-escaping`` | Sets the characters escaping for the variables of the log format. Supported values: ``json`` (JSON escaping), ``default`` (the default escaping) ``none`` (disables escaping). | ``default`` | | -|``stream-log-format`` | Sets the custom [log format](https://nginx.org/en/docs/stream/ngx_stream_log_module.html#log_format) for TCP, UDP, and TLS Passthrough traffic. For convenience, it is possible to define the log format across multiple lines (each line separated by ``\n``). In that case, the Ingress Controller will replace every ``\n`` character with a space character. All ``'`` characters must be escaped. | See the [template file](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/internal/configs/version1/nginx.tmpl). | | -|``stream-log-format-escaping`` | Sets the characters escaping for the variables of the stream log format. Supported values: ``json`` (JSON escaping), ``default`` (the default escaping) ``none`` (disables escaping). | ``default`` | | -{{% /table %}} - -### Request URI/Header Manipulation - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``proxy-hide-headers`` | Sets the value of one or more [proxy_hide_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header) directives. Example: ``"nginx.org/proxy-hide-headers": "header-a,header-b"`` | N/A | | -|``proxy-pass-headers`` | Sets the value of one or more [proxy_pass_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header) directives. Example: ``"nginx.org/proxy-pass-headers": "header-a,header-b"`` | N/A | | -{{% /table %}} - -### Auth and SSL/TLS - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``redirect-to-https`` | Sets the 301 redirect rule based on the value of the ``http_x_forwarded_proto`` header on the server block to force incoming traffic to be over HTTPS. Useful when terminating SSL in a load balancer in front of the Ingress Controller — see [115](https://github.com/nginxinc/kubernetes-ingress/issues/115) | ``False`` | | -|``ssl-redirect`` | Sets an unconditional 301 redirect rule for all incoming HTTP traffic to force incoming traffic over HTTPS. | ``True`` | | -|``hsts`` | Enables [HTTP Strict Transport Security (HSTS)](https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/) : the HSTS header is added to the responses from backends. The ``preload`` directive is included in the header. | ``False`` | | -|``hsts-max-age`` | Sets the value of the ``max-age`` directive of the HSTS header. | ``2592000`` (1 month) | | -|``hsts-include-subdomains`` | Adds the ``includeSubDomains`` directive to the HSTS header. | ``False`` | | -|``hsts-behind-proxy`` | Enables HSTS based on the value of the ``http_x_forwarded_proto`` request header. Should only be used when TLS termination is configured in a load balancer (proxy) in front of the Ingress Controller. Note: to control redirection from HTTP to HTTPS configure the ``nginx.org/redirect-to-https`` annotation. | ``False`` | | -|``ssl-protocols`` | Sets the value of the [ssl_protocols](https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols) directive. | ``TLSv1 TLSv1.1 TLSv1.2`` | | -|``ssl-prefer-server-ciphers`` | Enables or disables the [ssl_prefer_server_ciphers](https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_prefer_server_ciphers) directive. | ``False`` | | -|``ssl-ciphers`` | Sets the value of the [ssl_ciphers](https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers) directive. | ``HIGH:!aNULL:!MD5`` | | -|``ssl-dhparam-file`` | Sets the content of the dhparam file. The controller will create the file and set the value of the [ssl_dhparam](https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_dhparam) directive with the path of the file. | N/A | | -{{% /table %}} - -### Listeners - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``http2`` | Enables HTTP/2 in servers with SSL enabled. | ``False`` | | -|``proxy-protocol`` | Enables PROXY Protocol for incoming connections. | ``False`` | [Proxy Protocol](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/shared-examples/proxy-protocol). | -{{% /table %}} - -### Backend Services (Upstreams) - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``lb-method`` | Sets the [load balancing method](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#choosing-a-load-balancing-method). To use the round-robin method, specify ``"round_robin"``. | ``"random two least_conn"`` | | -|``max-fails`` | Sets the value of the [max_fails](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) parameter of the ``server`` directive. | ``1`` | | -|``upstream-zone-size`` | Sets the size of the shared memory [zone](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#zone) for upstreams. For NGINX, the special value 0 disables the shared memory zones. For NGINX Plus, shared memory zones are required and cannot be disabled. The special value 0 will be ignored. | ``256k`` for NGINX, ``512k`` for NGINX Plus | | -|``fail-timeout`` | Sets the value of the [fail_timeout](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#fail_timeout) parameter of the ``server`` directive. | ``10s`` | | -|``keepalive`` | Sets the value of the [keepalive](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive) directive. Note that ``proxy_set_header Connection "";`` is added to the generated configuration when the value > 0. | ``0`` | | -{{% /table %}} - -### Snippets and Custom Templates - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``main-snippets`` | Sets a custom snippet in main context. | N/A | | -|``http-snippets`` | Sets a custom snippet in http context. | N/A | | -|``location-snippets`` | Sets a custom snippet in location context. | N/A | | -|``server-snippets`` | Sets a custom snippet in server context. | N/A | | -|``stream-snippets`` | Sets a custom snippet in stream context. | N/A | [Support for TCP/UDP Load Balancing](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/tcp-udp). | -|``main-template`` | Sets the main NGINX configuration template. | By default the template is read from the file in the container. | [Custom Templates](/nginx-ingress-controller/configuration/global-configuration/custom-templates). | -|``ingress-template`` | Sets the NGINX configuration template for an Ingress resource. | By default the template is read from the file on the container. | [Custom Templates](/nginx-ingress-controller/configuration/global-configuration/custom-templates). | -|``virtualserver-template`` | Sets the NGINX configuration template for an VirtualServer resource. | By default the template is read from the file on the container. | [Custom Templates](/nginx-ingress-controller/configuration/global-configuration/custom-templates). | -{{% /table %}} - -### Modules {#modules} - -{{% table %}} -|ConfigMap Key | Description | Default | Example | -| ---| ---| ---| --- | -|``opentracing`` | Enables [OpenTracing](https://opentracing.io) globally (for all Ingress, VirtualServer and VirtualServerRoute resources). Note: requires the Ingress Controller image with OpenTracing module and a tracer. See the [docs](/nginx-ingress-controller/third-party-modules/opentracing) for more information. | ``False`` | | -|``opentracing-tracer`` | Sets the path to the vendor tracer binary plugin. | N/A | | -|``opentracing-tracer-config`` | Sets the tracer configuration in JSON format. | N/A | | -|``app-protect-compressed-requests-action`` | Sets the ``app_protect_compressed_requests_action`` [global directive](/nginx-app-protect/configuration/#global-directives). | ``drop`` | | -|``app-protect-cookie-seed`` | Sets the ``app_protect_cookie_seed`` [global directive](/nginx-app-protect/configuration/#global-directives). | Random automatically generated string | | -|``app-protect-failure-mode-action`` | Sets the ``app_protect_failure_mode_action`` [global directive](/nginx-app-protect/configuration/#global-directives). | ``pass`` | | -|``app-protect-cpu-thresholds`` | Sets the ``app_protect_cpu_thresholds`` [global directive](/nginx-app-protect/configuration/#global-directives). | ``high=100 low=100`` | | -|``app-protect-physical-memory-util-thresholds`` | Sets the ``app_protect_physical_memory_util_thresholds`` [global directive](/nginx-app-protect/configuration/#global-directives). | ``high=100 low=100`` | | -|`app-protect-reconnect-period-seconds` | Sets the `app_protect_reconnect_period_seconds` [global directive](/nginx-app-protect/configuration/#global-directives). | `5` | | -|``app-protect-dos-log-format`` | Sets the custom [log format](https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) for Dos Access log traffic. For convenience, it is possible to define the log format across multiple lines (each line separated by ``\n``). In that case, the Ingress Controller will replace every ``\n`` character with a space character. All ``'`` characters must be escaped. | `, vs_name_al=$app_protect_dos_vs_name, ip=$remote_addr, tls_fp=$app_protect_dos_tls_fp, outcome=$app_protect_dos_outcome, reason=$app_protect_dos_outcome_reason, policy_name=$app_protect_dos_policy_name, dos_version=$app_protect_dos_version, ip_tls=$remote_addr:$app_protect_dos_tls_fp,` | | -|``app-protect-dos-log-format-escaping`` | Sets the characters escaping for the variables of the stream log format. Supported values: ``json`` (JSON escaping), ``default`` (the default escaping) ``none`` (disables escaping). | ``default`` | | -|``app-protect-dos-arb-fqdn`` | Sets the ``app-protect-dos-arb-fqdn`` [directive](/nginx-app-protect-dos/directives-and-policy/learn-about-directives-and-policy/#arbitrator-fqdn-directive-app_protect_dos_arb_fqdn). | ``svc-appprotect-dos-arb`` | | -{{% /table %}} diff --git a/docs/content/configuration/global-configuration/custom-templates.md b/docs/content/configuration/global-configuration/custom-templates.md deleted file mode 100644 index 65f5a5c4b8..0000000000 --- a/docs/content/configuration/global-configuration/custom-templates.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -docs: DOCS-587 -doctypes: -- '' -title: Custom Templates -toc: true -weight: 1800 ---- - -NGINX Ingress Controller uses templates to generate NGINX configuration for Ingress resources, VirtualServer resources and the main NGINX configuration file. You can customize the templates and apply them via the ConfigMap. The GitHub repository has [examples of custom templates](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/shared-examples/custom-templates). diff --git a/docs/content/configuration/global-configuration/globalconfiguration-resource.md b/docs/content/configuration/global-configuration/globalconfiguration-resource.md deleted file mode 100644 index 33830af896..0000000000 --- a/docs/content/configuration/global-configuration/globalconfiguration-resource.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -docs: DOCS-588 -doctypes: -- '' -title: GlobalConfiguration Resource -toc: true -weight: 2000 ---- - -The GlobalConfiguration resource allows you to define the global configuration parameters of NGINX Ingress Controller. The resource is implemented as a [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - -The resource supports configuring listeners for TCP and UDP load balancing. Listeners are required by [TransportServer resources]({{< relref "/configuration/transportserver-resource.md" >}}) and -can be used to [configure custom listeners for VirtualServers]({{< relref "tutorials/virtual-server-with-custom-listener-ports" >}}). - -## Prerequisites - -When [installing NGINX Ingress Controller using Manifests]({{< relref "/installation/installing-nic/installation-with-manifests.md" >}}), you need to reference a GlobalConfiguration resource in the [`-global-configuration`](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments#cmdoption-global-configuration) command-line argument. NGINX Ingress Controller only needs one GlobalConfiguration resource. - -## GlobalConfiguration Specification - -The GlobalConfiguration resource defines the global configuration parameters of the Ingress Controller. Below is an example: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: GlobalConfiguration -metadata: - name: nginx-configuration - namespace: nginx-ingress -spec: - listeners: - - name: dns-udp - port: 5353 - protocol: UDP - - name: dns-tcp - port: 5353 - protocol: TCP - - name: http-8083 - port: 8083 - protocol: HTTP - - name: https-8443 - port: 8443 - protocol: HTTP - ssl: true -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``listeners`` | A list of listeners. | [[]listener](#listener) | No | -{{% /table %}} - -### Listener - -The `listeners:` key defines a listener (a combination of a protocol and a port) that NGINX will use to accept traffic for a [TransportServer](/nginx-ingress-controller/configuration/transportserver-resource) and a [VirtualServer](nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources): - -```yaml -- name: dns-tcp - port: 5353 - protocol: TCP -- name: http-8083 - port: 8083 - protocol: HTTP -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the listener. Must be a valid DNS label as defined in RFC 1035. For example, ``hello`` and ``listener-123`` are valid. The name must be unique among all listeners. The name ``tls-passthrough`` is reserved for the built-in TLS Passthrough listener and cannot be used. | ``string`` | Yes | -|``port`` | The port of the listener. The port must fall into the range ``1..65535`` with the following exceptions: ``80``, ``443``, the [status port](/nginx-ingress-controller/logging-and-monitoring/status-page), the [Prometheus metrics port](/nginx-ingress-controller/logging-and-monitoring/prometheus). Among all listeners, only a single combination of a port-protocol is allowed. | ``int`` | Yes | -|``protocol`` | The protocol of the listener. Supported values: ``TCP``, ``UDP`` and ``HTTP``. | ``string`` | Yes | -|``ssl`` | Configures the listener with SSL. This is currently only supported for ``HTTP`` listeners. Default value is ``false`` | ``bool`` | No | -{{% /table %}} - -## Using GlobalConfiguration - -You can use the usual `kubectl` commands to work with a GlobalConfiguration resource. - -For example, the following command creates a GlobalConfiguration resource defined in `global-configuration.yaml` with the name `nginx-configuration`: - -```shell -kubectl apply -f global-configuration.yaml -globalconfiguration.k8s.nginx.org/nginx-configuration created -``` - -Assuming the namespace of the resource is `nginx-ingress`, you can get the resource by running: - -```shell -kubectl get globalconfiguration nginx-configuration -n nginx-ingress -NAME AGE -nginx-configuration 13s -``` - -In the kubectl get and similar commands, you can also use the short name `gc` instead of `globalconfiguration`. - -### Validation - -Two types of validation are available for the GlobalConfiguration resource: - -- *Structural validation* by the `kubectl` and Kubernetes API server. -- *Comprehensive validation* by the Ingress Controller. - -#### Structural Validation - -The custom resource definition for the GlobalConfiguration includes structural OpenAPI schema which describes the type of every field of the resource. - -If you try to create (or update) a resource that violates the structural schema (for example, you use a string value for the port field of a listener), `kubectl` and Kubernetes API server will reject such a resource: - -- Example of `kubectl` validation: - - ``` - $ kubectl apply -f global-configuration.yaml - error: error validating "global-configuration.yaml": error validating data: ValidationError(GlobalConfiguration.spec.listeners[0].port): invalid type for org.nginx.k8s.v1.GlobalConfiguration.spec.listeners.port: got "string", expected "integer"; if you choose to ignore these errors, turn validation off with --validate=false - ``` - -- Example of Kubernetes API server validation: - - ``` - $ kubectl apply -f global-configuration.yaml --validate=false - The GlobalConfiguration "nginx-configuration" is invalid: []: Invalid value: map[string]interface {}{ ... }: validation failure list: - spec.listeners.port in body must be of type integer: "string" - ``` - -If a resource is not rejected (it doesn't violate the structural schema), the Ingress Controller will validate it further. - -#### Comprehensive Validation - -The Ingress Controller validates the fields of a GlobalConfiguration resource. If a GlobalConfiguration resource is partially invalid, the Ingress Controller use the valid listeners and emit events about invalid listeners. - -You can check if the Ingress Controller successfully applied the configuration for a GlobalConfiguration. For our `nginx-configuration` GlobalConfiguration, we can run: - -```shell -kubectl describe gc nginx-configuration -n nginx-ingress -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal Updated 11s nginx-ingress-controller GlobalConfiguration nginx-ingress/nginx-configuration was updated -``` - -Note how the events section includes a Normal event with the Updated reason that informs us that the configuration was successfully applied. - -If you create a GlobalConfiguration `nginx-configuration` with two or more listeners that have the same protocol UDP and port 53, you will get: - -```shell -kubectl describe gc nginx-configuration -n nginx-ingress -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal Updated 55s nginx-ingress-controller GlobalConfiguration nginx-ingress/nginx-configuration was updated - Warning AddedOrUpdatedWithError 6s nginx-ingress-controller GlobalConfiguration nginx-ingress/nginx-configuration is invalid and was rejected: spec.listeners: Duplicate value: "Duplicated port/protocol combination 53/UDP" -``` - -Note how the events section includes a Warning event with the AddedOrUpdatedWithError reason. diff --git a/docs/content/configuration/global-configuration/reporting-resources-status.md b/docs/content/configuration/global-configuration/reporting-resources-status.md deleted file mode 100644 index 4c75281d60..0000000000 --- a/docs/content/configuration/global-configuration/reporting-resources-status.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -docs: DOCS-589 -doctypes: -- '' -title: Reporting Resources Status -toc: true -weight: 1900 ---- - -## Ingress Resources - -An Ingress resource can have a status that includes the address (an IP address or a DNS name), through which the hosts of that Ingress resource are publicly accessible. -You can see the address in the output of the `kubectl get ingress` command, in the ADDRESS column, as shown below: - -```shell -$ kubectl get ingresses -NAME HOSTS ADDRESS PORTS AGE -cafe-ingress cafe.example.com 12.13.23.123 80, 443 2m -``` - -The Ingress Controller must be configured to report an Ingress status: - -1. Use the command-line flag `-report-ingress-status`. -2. Define a source for an external address. This can be either of: - 1. A user defined address, specified in the `external-status-address` ConfigMap key. - 2. A Service of the type LoadBalancer configured with an external IP or address and specified by the `-external-service` command-line flag. - -See the docs about [ConfigMap keys](/nginx-ingress-controller/configuration/global-configuration/configmap-resource) and [Command-line arguments](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments). - -Notes: NGINX Ingress Controller does not clear the status of Ingress resources when it is being shut down. - -## VirtualServer and VirtualServerRoute Resources - -A VirtualServer or VirtualServerRoute resource includes the status field with information about the state of the resource and the IP address, through which the hosts of that resource are publicly accessible. -You can see the status in the output of the `kubectl get virtualservers` or `kubectl get virtualserverroutes` commands as shown below: - -```shell -kubectl get virtualservers - NAME STATE HOST IP PORTS AGE - cafe Valid cafe.example.com 12.13.23.123 [80,443] 34s -``` - -To see an external hostname address associated with a VirtualServer resource, use the `-o wide` option: - -```shell -kubectl get virtualservers -o wide - NAME STATE HOST IP EXTERNALHOSTNAME PORTS AGE - cafe Valid cafe.example.com ae430f41a1a0042908655abcdefghijkl-12345678.eu-west-2.elb.amazonaws.com [80,443] 106s -``` - -> Note: If there are multiple addresses, only the first one is shown. - -In order to see additional addresses or extra information about the `Status` of the resource, use the following command: - -```shell -kubectl describe virtualserver -. . . -Status: - External Endpoints: - Ip: 12.13.23.123 - Ports: [80,443] - Message: Configuration for cafe/cafe was added or updated - Reason: AddedOrUpdated - State: Valid -``` - -### Status Specification - -The following fields are reported in both VirtualServer and VirtualServerRoute status: - -{{% table %}} -|Field | Description | Type | -| ---| ---| --- | -|``State`` | Current state of the resource. Can be ``Valid``, ``Warning`` an ``Invalid``. For more information, refer to the ``message`` field. | ``string`` | -|``Reason`` | The reason of the last update. | ``string`` | -|``Message`` | Additional information about the state. | ``string`` | -|``ExternalEndpoints`` | A list of external endpoints for which the hosts of the resource are publicly accessible. | [[]externalEndpoint](#externalendpoint) | -{{% /table %}} - -The following field is reported in the VirtualServerRoute status only: - -{{% table %}} -|Field | Description | Type | -| ---| ---| --- | -|``ReferencedBy`` | The VirtualServer that references this VirtualServerRoute. Format is ``namespace/name`` | ``string`` | -{{% /table %}} - -### ExternalEndpoint - -{{% table %}} -|Field | Description | Type | -| ---| ---| --- | -|``IP`` | The external IP address. | ``string`` | -|``Hostname`` | The external LoadBalancer Hostname address. | ``string`` | -|``Ports`` | A list of external ports. | ``string`` | -{{% /table %}} - -The Ingress Controller must be configured to report a VirtualServer or VirtualServerRoute status: - -1. If you want the Ingress Controller to report the `externalEndpoints`, define a source for an external address (Note: the rest of the fields will be reported without the external address configured). This can be either of: - 1. A user defined address, specified in the `external-status-address` ConfigMap key. - 2. A Service of the type LoadBalancer configured with an external IP or address and specified by the `-external-service` command-line flag. - -See the docs about [ConfigMap keys](/nginx-ingress-controller/configuration/global-configuration/configmap-resource) and [Command-line arguments](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments). - -Notes: The Ingress Controller does not clear the status of VirtualServer and VirtualServerRoute resources when it is being shut down. - -## Policy Resources - -A Policy resource includes the status field with information about the state of the resource. -You can see the status in the output of the `kubectl get policy` command as shown below: - -```shell -kubectl get policy - NAME STATE AGE - webapp-policy Valid 30s -``` - -In order to see additional addresses or extra information about the `Status` of the resource, use the following command: - -```shell -kubectl describe policy -. . . -Status: - Message: Configuration for default/webapp-policy was added or updated - Reason: AddedOrUpdated - State: Valid -``` - -### Status Specification - -The following fields are reported in Policy status: - -{{% table %}} -|Field | Description | Type | -| ---| ---| --- | -|``State`` | Current state of the resource. Can be ``Valid`` or ``Invalid``. For more information, refer to the ``message`` field. | ``string`` | -|``Reason`` | The reason of the last update. | ``string`` | -|``Message`` | Additional information about the state. | ``string`` | -{{% /table %}} - -## TransportServer Resources - -A TransportServer resource includes the status field with information about the state of the resource. -You can see the status in the output of the `kubectl get transportserver` command as shown below: - -```shell -kubectl get transportserver - NAME STATE REASON AGE - dns-tcp Valid AddedOrUpdated 47m -``` - -In order to see additional addresses or extra information about the `Status` of the resource, use the following command: - -```shell -kubectl describe transportserver -. . . -Status: - Message: Configuration for default/dns-tcp was added or updated - Reason: AddedOrUpdated - State: Valid -``` - -### Status Specification - -The following fields are reported in TransportServer status: - -{{% table %}} -|Field | Description | Type | -| ---| ---| --- | -|``State`` | Current state of the resource. Can be ``Valid``, ``Warning`` or ``Invalid``. For more information, refer to the ``message`` field. | ``string`` | -|``Reason`` | The reason of the last update. | ``string`` | -|``Message`` | Additional information about the state. | ``string`` | -{{% /table %}} diff --git a/docs/content/configuration/handling-host-and-listener-collisions.md b/docs/content/configuration/handling-host-and-listener-collisions.md deleted file mode 100644 index 45ef42afd8..0000000000 --- a/docs/content/configuration/handling-host-and-listener-collisions.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -docs: DOCS-590 -doctypes: -- '' -title: Handling Host and Listener Collisions -toc: true -weight: 1700 ---- - -This document explains how NGINX Ingress Controller handles host and listener collisions among resources. - -## Winner Selection Algorithm - -If multiple resources contend for the same host/listener, the Ingress Controller will pick the winner based on the `creationTimestamp` of the resources: the oldest resource will win. In case there are more than one oldest resource (their `creationTimestamp` is the same), the Ingress Controller will choose the resource with the lexicographically smallest `uid`. - -Note: the `creationTimestamp` and `uid` fields are part of the resource [ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#objectmeta-v1-meta). - -## Host Collisions - -A host collision occurs when multiple Ingress, VirtualServer, and TransportServer (configured for TLS Passthrough) resources configure the same `host`. The Ingress Controller supports two options for handling host collisions: - -- Choosing the winner so that only one resource handles the host. -- Merging configuration of the conflicting resources. - -### Choosing the Winner - -Consider the following two resources: - -- `cafe-ingress` Ingress: - - ```yaml - apiVersion: networking.k8s.io/v1 - kind: Ingress - metadata: - name: cafe-ingress - spec: - ingressClassName: nginx - rules: - - host: cafe.example.com - . . . - ``` - -- `cafe-virtual-server` VirtualServer: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: VirtualServer - metadata: - name: cafe-virtual-server - spec: - host: cafe.example.com - . . . - ``` - -If a user creates both resources in the cluster, a host collision will occur. As a result, the Ingress Controller will pick the winner using the [winner selection algorithm](#winner-selection-algorithm). - -In our example, if `cafe-virtual-server` was created first, it will win the host `cafe.example.com` and the Ingress Controller will reject `cafe-ingress`. This will be reflected in the events and in the resource's status field: - -```shell -kubectl describe vs cafe-virtual-server - -. . . -Status: - . . . - Message: Configuration for default/cafe-virtual-server was added or updated - Reason: AddedOrUpdated - State: Valid -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 9s nginx-ingress-controller Configuration for default/cafe-virtual-server was added or updated - -$ kubectl describe ingress cafe-ingress -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 66s nginx-ingress-controller All hosts are taken by other resources -``` - -> Note: You can configure multiple hosts for Ingress resources. As a result, it's possible that an Ingress resource can be the winner for some of its hosts and a loser for the others. For example, if `cafe-ingress` had an additional rule host rule -- `pub.example.com` -- the Ingress Controller would not reject the Ingress. Rather, it would allow `cafe-ingress` to handle `pub.example.com`. - -Similarly, if `cafe-ingress` was created first, it will win `cafe.example.com` and the Ingress Controller will reject `cafe-virtual-server`. - -### Merging Configuration for the Same Host - -It is possible to merge configuration for multiple Ingress resources for the same host. One common use case for this approach is distributing resources across multiple namespaces. See the [Cross-namespace Configuration](/nginx-ingress-controller/configuration/ingress-resources/cross-namespace-configuration/) doc for more information. - -It is *not* possible to merge the configurations for multiple VirtualServer resources for the same host. However, you can split the VirtualServers into multiple VirtualServerRoute resources, which a single VirtualServer can then reference. See the [corresponding example](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources/cross-namespace-configuration) on GitHub. - -It is *not* possible to merge configuration for multiple TransportServer resources. - -## Listener Collisions - -Listener collisions occur when multiple TransportServer resources (configured for TCP/UDP load balancing) configure the same `listener`. The Ingress Controller will choose the winner, which will own the listener. - -### Choosing the Winner - -Consider the following two resources: - -- `tcp-1` TransportServer: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: TransportServer - metadata: - name: tcp-1 - spec: - listener: - name: dns-tcp - protocol: TCP - . . . - ``` - -- `tcp-2` TransportServer: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: TransportServer - metadata: - name: tcp-2 - spec: - listener: - name: dns-tcp - protocol: TCP - . . . - ``` - -If a user creates both resources in the cluster, a listener collision will occur. As a result, the Ingress Controller will pick the winner using the [winner selection algorithm](#winner-selection-algorithm). - -In our example, if `tcp-1` was created first, it will win the listener `dns-tcp` and the Ingress Controller will reject `tcp-2`. This will be reflected in the events and in the resource's status field: - -```shell -kubectl describe ts tcp-2 - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 10s nginx-ingress-controller Listener dns-tcp is taken by another resource -``` - -Similarly, if `tcp-2` was created first, it will win `dns-tcp` and the Ingress Controller will reject `tcp-1`. diff --git a/docs/content/configuration/ingress-resources/_index.md b/docs/content/configuration/ingress-resources/_index.md deleted file mode 100644 index 32bdae29ad..0000000000 --- a/docs/content/configuration/ingress-resources/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Ingress Resources -description: -weight: 1500 -menu: - docs: - parent: NGINX Ingress Controller ---- diff --git a/docs/content/configuration/ingress-resources/advanced-configuration-with-annotations.md b/docs/content/configuration/ingress-resources/advanced-configuration-with-annotations.md deleted file mode 100644 index bd28023273..0000000000 --- a/docs/content/configuration/ingress-resources/advanced-configuration-with-annotations.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -docs: DOCS-591 -doctypes: -- '' -title: Advanced Configuration with Annotations -toc: true -weight: 1700 ---- - -This document explains how to enable advanced features with Annotations. - -The Ingress resource can only use basic NGINX features such as host or path-based routing and TLS termination. Advanced features like rewriting the request URI or inserting additional response headers can be enabled with Annotations. Outside of advanced features, Annotations are necessary for customizing NGINX behavior such as setting the value of connection timeouts. - -Customization is also available through the [ConfigMap]({{< relref "/configuration/global-configuration/configmap-resource.md" >}}): Annotations take priority over the ConfigMap. - -## Using Annotations - -This example uses Annotations to customize the configuration for an Ingress resource: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: cafe-ingress-with-annotations - annotations: - nginx.org/proxy-connect-timeout: "30s" - nginx.org/proxy-read-timeout: "20s" - nginx.org/client-max-body-size: "4m" - nginx.org/server-snippets: | - location / { - return 302 /coffee; - } -spec: - rules: - - host: cafe.example.com - http: - paths: - - path: /tea - pathType: Prefix - backend: - service: - name: tea-svc - port: - number: 80 - - path: /coffee - pathType: Prefix - backend: - service: - name: coffee-svc - port: - number: 80 -``` - -## Validation - -NGINX Ingress Controller validates the annotations of Ingress resources. If an Ingress is invalid, NGINX Ingress Controller will reject it: the Ingress will continue to exist in the cluster, but the Ingress Controller will ignore it. - -You can check if the Ingress Controller successfully applied the configuration for an Ingress. For our example `cafe-ingress-with-annotations` Ingress, we can run: - -```shell -kubectl describe ing cafe-ingress-with-annotations - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 3s nginx-ingress-controller Configuration for default/cafe-ingress-with-annotations was added or updated -``` - -Note how the events section includes a Normal event with the AddedOrUpdated reason that informs us that the configuration was successfully applied. - -If you create an invalid Ingress, the Ingress Controller will reject it and emit a Rejected event. For example, if you create an Ingress `cafe-ingress-with-annotations`, with an annotation `nginx.org/redirect-to-https` set to `yes please` instead of `true`, you will get: - -```shell -kubectl describe ing cafe-ingress-with-annotations - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 13s nginx-ingress-controller annotations.nginx.org/redirect-to-https: Invalid value: "yes please": must be a boolean -``` - -Note how the events section includes a Warning event with the Rejected reason. - -**Note**: If you make an existing Ingress invalid, the Ingress Controller will reject it and remove the corresponding configuration from NGINX. - -The following Ingress annotation currently has limited validation: - -- `nginx.com/jwt-token`. - -## Summary of Annotations - -The table below summarizes the available annotations. - -**Note**: The annotations that start with `nginx.com` are only supported with NGINX Plus. - -### General Customization - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``nginx.org/proxy-connect-timeout`` | ``proxy-connect-timeout`` | Sets the value of the [proxy_connect_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout) and [grpc_connect_timeout](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_connect_timeout) directive. | ``60s`` | | -|``nginx.org/proxy-read-timeout`` | ``proxy-read-timeout`` | Sets the value of the [proxy_read_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) and [grpc_read_timeout](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_read_timeout) directive. | ``60s`` | | -|``nginx.org/proxy-send-timeout`` | ``proxy-send-timeout`` | Sets the value of the [proxy_send_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) and [grpc_send_timeout](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_send_timeout) directive. | ``60s`` | | -|``nginx.org/client-max-body-size`` | ``client-max-body-size`` | Sets the value of the [client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) directive. | ``1m`` | | -|``nginx.org/proxy-buffering`` | ``proxy-buffering`` | Enables or disables [buffering of responses](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering) from the proxied server. | ``True`` | | -|``nginx.org/proxy-buffers`` | ``proxy-buffers`` | Sets the value of the [proxy_buffers](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) directive. | Depends on the platform. | | -|``nginx.org/proxy-buffer-size`` | ``proxy-buffer-size`` | Sets the value of the [proxy_buffer_size](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) and [grpc_buffer_size](https://nginx.org/en/docs/http/ngx_http_grpc_module.html#grpc_buffer_size) directives. | Depends on the platform. | | -|``nginx.org/proxy-max-temp-file-size`` | ``proxy-max-temp-file-size`` | Sets the value of the [proxy_max_temp_file_size](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size) directive. | ``1024m`` | | -|``nginx.org/server-tokens`` | ``server-tokens`` | Enables or disables the [server_tokens](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens) directive. Additionally, with the NGINX Plus, you can specify a custom string value, including the empty string value, which disables the emission of the “Server” field. | ``True`` | | -|``nginx.org/path-regex`` | N/A | Enables regular expression modifiers for Ingress path parameter. This translates to the NGINX [location](https://nginx.org/en/docs/http/ngx_http_core_module.html#location) directive. You can specify one of these values: "case_sensitive", "case_insensitive", or "exact". The annotation is applied to the entire Ingress resource and its paths. While using Master and Minion Ingresses i.e. Mergeable Ingresses, this annotation can be specified on Minion types. The `path-regex` annotation specified on Master is ignored, and has no effect on paths defined on Minions. | N/A | [Path Regex](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/path-regex). | -{{% /table %}} - -### Request URI/Header Manipulation - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``nginx.org/proxy-hide-headers`` | ``proxy-hide-headers`` | Sets the value of one or more [proxy_hide_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header) directives. Example: ``"nginx.org/proxy-hide-headers": "header-a,header-b"`` | N/A | | -|``nginx.org/proxy-pass-headers`` | ``proxy-pass-headers`` | Sets the value of one or more [proxy_pass_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header) directives. Example: ``"nginx.org/proxy-pass-headers": "header-a,header-b"`` | N/A | | -|``nginx.org/rewrites`` | N/A | Configures URI rewriting using [proxy_pass](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass) directive. | N/A | [Rewrites Support](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/rewrites). | -|``nginx.org/proxy-set-headers`` | N/A | Enables customization of proxy headers and values using the [proxy_set_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header) directive. Example: ``"nginx.org/proxy-set-headers": "header-a: valueA,header-b: valueB,header-c: valueC"`` | N/A | [Proxy Set Headers](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/proxy-set-headers). | -{{% /table %}} - -### Auth and SSL/TLS - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``nginx.org/redirect-to-https`` | ``redirect-to-https`` | Sets the 301 redirect rule based on the value of the ``http_x_forwarded_proto`` header on the server block to force incoming traffic to be over HTTPS. Useful when terminating SSL in a load balancer in front of the Ingress Controller — see [115](https://github.com/nginxinc/kubernetes-ingress/issues/115) | ``False`` | | -|``ingress.kubernetes.io/ssl-redirect`` | ``ssl-redirect`` | Sets an unconditional 301 redirect rule for all incoming HTTP traffic to force incoming traffic over HTTPS. | ``True`` | | -|``nginx.org/hsts`` | ``hsts`` | Enables [HTTP Strict Transport Security (HSTS)](https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/)\ : the HSTS header is added to the responses from backends. The ``preload`` directive is included in the header. | ``False`` | | -|``nginx.org/hsts-max-age`` | ``hsts-max-age`` | Sets the value of the ``max-age`` directive of the HSTS header. | ``2592000`` (1 month) | | -|``nginx.org/hsts-include-subdomains`` | ``hsts-include-subdomains`` | Adds the ``includeSubDomains`` directive to the HSTS header. | ``False`` | | -|``nginx.org/hsts-behind-proxy`` | ``hsts-behind-proxy`` | Enables HSTS based on the value of the ``http_x_forwarded_proto`` request header. Should only be used when TLS termination is configured in a load balancer (proxy) in front of the Ingress Controller. Note: to control redirection from HTTP to HTTPS configure the ``nginx.org/redirect-to-https`` annotation. | ``False`` | | -|``nginx.org/basic-auth-secret`` | N/A | Specifies a Secret resource with a user list for HTTP Basic authentication. | N/A | | -|``nginx.org/basic-auth-realm`` | N/A | Specifies a realm. | N/A | | -|``nginx.com/jwt-key`` | N/A | Specifies a Secret resource with keys for validating JSON Web Tokens (JWTs). | N/A | [Support for JSON Web Tokens (JWTs)](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/jwt). | -|``nginx.com/jwt-realm`` | N/A | Specifies a realm. | N/A | [Support for JSON Web Tokens (JWTs)](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/jwt). | -|``nginx.com/jwt-token`` | N/A | Specifies a variable that contains a JSON Web Token. | By default, a JWT is expected in the ``Authorization`` header as a Bearer Token. | [Support for JSON Web Tokens (JWTs)](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/jwt). | -|``nginx.com/jwt-login-url`` | N/A | Specifies a URL to which a client is redirected in case of an invalid or missing JWT. | N/A | [Support for JSON Web Tokens (JWTs)](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/jwt). | -{{% /table %}} - -### Listeners - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``nginx.org/listen-ports`` | N/A | Configures HTTP ports that NGINX will listen on. | ``[80]`` | | -|``nginx.org/listen-ports-ssl`` | N/A | Configures HTTPS ports that NGINX will listen on. | ``[443]`` | | -{{% /table %}} - -### Backend Services (Upstreams) - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``nginx.org/lb-method`` | ``lb-method`` | Sets the [load balancing method](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#choosing-a-load-balancing-method). To use the round-robin method, specify ``"round_robin"``. | ``"random two least_conn"`` | | -|``nginx.org/ssl-services`` | N/A | Enables HTTPS or gRPC over SSL when connecting to the endpoints of services. | N/A | [SSL Services Support](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/ssl-services). | -|``nginx.org/grpc-services`` | N/A | Enables gRPC for services. Note: requires HTTP/2 (see ``http2`` ConfigMap key); only works for Ingresses with TLS termination enabled. | N/A | [GRPC Services Support](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/grpc-services). | -|``nginx.org/websocket-services`` | N/A | Enables WebSocket for services. | N/A | [WebSocket support](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/websocket). | -|``nginx.org/max-fails`` | ``max-fails`` | Sets the value of the [max_fails](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) parameter of the ``server`` directive. | ``1`` | | -|``nginx.org/max-conns`` | N\A | Sets the value of the [max_conns](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_conns) parameter of the ``server`` directive. | ``0`` | | -|``nginx.org/upstream-zone-size`` | ``upstream-zone-size`` | Sets the size of the shared memory [zone](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#zone) for upstreams. For NGINX, the special value 0 disables the shared memory zones. For NGINX Plus, shared memory zones are required and cannot be disabled. The special value 0 will be ignored. | ``256K`` | | -|``nginx.org/fail-timeout`` | ``fail-timeout`` | Sets the value of the [fail_timeout](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#fail_timeout) parameter of the ``server`` directive. | ``10s`` | | -|``nginx.com/sticky-cookie-services`` | N/A | Configures session persistence. | N/A | [Session Persistence](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/session-persistence). | -|``nginx.org/keepalive`` | ``keepalive`` | Sets the value of the [keepalive](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive) directive. Note that ``proxy_set_header Connection "";`` is added to the generated configuration when the value > 0. | ``0`` | | -|``nginx.com/health-checks`` | N/A | Enables active health checks. | ``False`` | [Support for Active Health Checks](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/health-checks). | -|``nginx.com/health-checks-mandatory`` | N/A | Configures active health checks as mandatory. | ``False`` | [Support for Active Health Checks](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/health-checks). | -|``nginx.com/health-checks-mandatory-queue`` | N/A | When active health checks are mandatory, creates a queue where incoming requests are temporarily stored while NGINX Plus is checking the health of the endpoints after a configuration reload. | ``0`` | [Support for Active Health Checks](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/health-checks). | -|``nginx.com/slow-start`` | N/A | Sets the upstream server [slow-start period](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#server-slow-start). By default, slow-start is activated after a server becomes [available](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/#passive-health-checks) or [healthy](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/#active-health-checks). To enable slow-start for newly-added servers, configure [mandatory active health checks](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/health-checks). | ``"0s"`` | | -|``nginx.org/use-cluster-ip`` | N/A | Enables using the Cluster IP and port of the service instead of the default behavior of using the IP and port of the pods. When this field is enabled, the fields that configure NGINX behavior related to multiple upstream servers (like ``lb-method`` and ``next-upstream``) will have no effect, as NGINX Ingress Controller will configure NGINX with only one upstream server that will match the service Cluster IP. | ``False`` | | -{{% /table %}} - -### Rate limiting - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``nginx.org/limit-req-rate`` | N/A | Enables request-rate-limiting for this ingress by creating a [limit_req_zone](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone) and matching [limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req) for each location. All servers/locations of one ingress share the same zone. Must have unit r/s or r/m. | N/A | 200r/s | -|``nginx.org/limit-req-key`` | N/A | The key to which the rate limit is applied. Can contain text, variables, or a combination of them. Variables must be surrounded by ${}. | ${binary_remote_addr} | ${binary_remote_addr} | -|``nginx.org/limit-req-zone-size`` | N/A | Configures the size of the created [limit_req_zone](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone). | 10m | 20m | -|``nginx.org/limit-req-delay`` | N/A | Configures the delay-parameter of the [limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req) directive. | 0 | 100 | -|``nginx.org/limit-req-no-delay`` | N/A | Configures the nodelay-parameter of the [limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req) directive. | false | true | -|``nginx.org/limit-req-burst`` | N/A | Configures the burst-parameter of the [limit_req](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req) directive. | N/A | 100 | -|``nginx.org/limit-req-dry-run`` | N/A | Enables the dry run mode. In this mode, the rate limit is not actually applied, but the number of excessive requests is accounted as usual in the shared memory zone. | false | true | -|``nginx.org/limit-req-log-level`` | N/A | Sets the desired logging level for cases when the server refuses to process requests due to rate exceeding, or delays request processing. Allowed values are info, notice, warn or error. | error | info | -|``nginx.org/limit-req-reject-code`` | N/A | Sets the status code to return in response to rejected requests. Must fall into the range 400..599. | 429 | 503 | -|``nginx.org/limit-req-scale`` | N/A | Enables a constant rate-limit by dividing the configured rate by the number of nginx-ingress pods currently serving traffic. This adjustment ensures that the rate-limit remains consistent, even as the number of nginx-pods fluctuates due to autoscaling. Note: This will not work properly if requests from a client are not evenly distributed accross all ingress pods (sticky sessions, long lived TCP-Connections with many requests etc.). In such cases using NGINX+'s zone-sync feature instead would give better results. | false | true | -{{% /table %}} - -### Snippets and Custom Templates - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``nginx.org/location-snippets`` | ``location-snippets`` | Sets a custom snippet in location context. | N/A | | -|``nginx.org/server-snippets`` | ``server-snippets`` | Sets a custom snippet in server context. | N/A | | -{{% /table %}} - -### App Protect {#app-protect} - -**Note**: The App Protect annotations only work if App Protect WAF module is [installed](/nginx-ingress-controller/app-protect/installation/). - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``appprotect.f5.com/app-protect-policy`` | N/A | The name of the App Protect Policy for the Ingress Resource. Format is ``namespace/name``. If no namespace is specified, the same namespace of the Ingress Resource is used. If not specified but ``appprotect.f5.com/app-protect-enable`` is true, a default policy id applied. If the referenced policy resource does not exist, or policy is invalid, this annotation will be ignored, and the default policy will be applied. | N/A | [Example for App Protect](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-waf). | -|``appprotect.f5.com/app-protect-enable`` | N/A | Enable App Protect for the Ingress Resource. | ``False`` | [Example for App Protect](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-waf). | -|``appprotect.f5.com/app-protect-security-log-enable`` | N/A | Enable the [security log](/nginx-app-protect/troubleshooting/#app-protect-logging-overview) for App Protect. | ``False`` | [Example for App Protect](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-waf). | -|``appprotect.f5.com/app-protect-security-log`` | N/A | The App Protect log configuration for the Ingress Resource. Format is ``namespace/name``. If no namespace is specified, the same namespace as the Ingress Resource is used. If not specified the default is used which is: filter: ``illegal``, format: ``default``. Multiple configurations can be specified in a comma separated list. Both log configurations and destinations list (see below) must be of equal length. Configs and destinations are paired by the list indices. | N/A | [Example for App Protect](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-waf). | -|``appprotect.f5.com/app-protect-security-log-destination`` | N/A | The destination of the security log. For more information check the [DESTINATION argument](/nginx-app-protect/troubleshooting/#app-protect-logging-overview). Multiple destinations can be specified in a comma-separated list. Both log configurations and destinations list (see above) must be of equal length. Configs and destinations are paired by the list indices. | ``syslog:server=localhost:514`` | [Example for App Protect](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-waf). | -{{% /table %}} - -### App Protect DoS - -**Note**: The App Protect DoS annotations only work if App Protect DoS module is [installed](/nginx-ingress-controller/app-protect-dos/installation/). - -{{% table %}} -|Annotation | ConfigMap Key | Description | Default | Example | -| ---| ---| ---| ---| --- | -|``appprotectdos.f5.com/app-protect-dos-resource`` | N/A | Enable App Protect DoS for the Ingress Resource by specifying a [DosProtectedResource](/nginx-ingress-controller/app-protect-dos/dos-protected/). | N/A | [Example for App Protect DoS](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-dos). | -{{% /table %}} diff --git a/docs/content/configuration/ingress-resources/advanced-configuration-with-snippets.md b/docs/content/configuration/ingress-resources/advanced-configuration-with-snippets.md deleted file mode 100644 index 6001d18e4f..0000000000 --- a/docs/content/configuration/ingress-resources/advanced-configuration-with-snippets.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -docs: DOCS-592 -doctypes: -- '' -title: Advanced Configuration with Snippets -toc: true -weight: 1800 ---- - -Snippets allow you to insert raw NGINX config into different contexts of the NGINX configurations that NGINX Ingress Controller generates. Snippets are intended for advanced NGINX users who need more control over the generated NGINX configuration, and can be used in cases where Annotations and ConfigMap entries would not apply. - -Snippets are also available through the [ConfigMap]({{< relref "/configuration/global-configuration/configmap-resource.md" >}}) - -## Using Snippets - -The example below shows how to use snippets to customize the NGINX configuration template using annotations. - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: cafe-ingress-with-snippets - annotations: - nginx.org/server-snippets: | - location / { - return 302 /coffee; - } - nginx.org/location-snippets: | - add_header my-test-header test-value; -spec: - rules: - - host: cafe.example.com - http: - paths: - - path: /tea - pathType: Prefix - backend: - service: - name: tea-svc - port: - number: 80 - - path: /coffee - pathType: Prefix - backend: - service: - name: coffee-svc - port: - number: 80 -``` - -Generated NGINX configuration: - -```nginx -server { - listen 80; - - - location / { - return 302 /coffee; - } - - - location /coffee { - proxy_http_version 1.1; - - - add_header my-test-header test-value; - ... - proxy_pass http://default-cafe-ingress-with-snippets-cafe.example.com-coffee-svc-80; - } - - location /tea { - proxy_http_version 1.1; - - add_header my-test-header test-value; - ... - proxy_pass http://default-cafe-ingress-with-snippets-cafe.example.com-tea-svc-80; - } -} -``` - -**Note**: The generated configs are truncated for the clarity of the example. - -## Summary of Snippets - -See the [snippets annotations](/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#snippets-and-custom-templates) documentation for more information. -However, because of the disadvantages described below, snippets are disabled by default. To use snippets, set the [`enable-snippets`](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments#cmdoption-enable-snippets) command-line argument. - -## Disadvantages of Using Snippets - -Snippets have the following disadvantages: - -- *Complexity*. To use snippets, you will need to: - - Understand NGINX configuration primitives and implement a correct NGINX configuration. - - Understand how the IC generates NGINX configuration so that a snippet doesn't interfere with the other features in the configuration. -- *Decreased robustness*. An incorrect snippet makes the NGINX config invalid, which causes reload failures. This will prevent any new configuration updates, including updates for the other Ingress resources, until the snippet is fixed. -- *Security implications*. Snippets give access to NGINX configuration primitives and those primitives are not validated by the Ingress Controller. For example, a snippet can configure NGINX to serve the TLS certificates and keys used for TLS termination for Ingress resources. - -> **Note**: If the NGINX config includes an invalid snippet, NGINX will continue to operate with the latest valid configuration. - -## Troubleshooting - -If a snippet includes an invalid NGINX configuration, the Ingress Controller will fail to reload NGINX. The error will be reported in the Ingress Controller logs and an event with the error will be associated with the Ingress resource: - -An example of an error from the logs: - -```shell -[emerg] 31#31: unknown directive "badd_header" in /etc/nginx/conf.d/default-cafe-ingress-with-snippets.conf:54 -Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"cafe-ingress-with-snippets", UID:"f9656dc9-63a6-41dd-a499-525b0e0309bb", APIVersion:"extensions/v1beta1", ResourceVersion:"2322030", FieldPath:""}): type: 'Warning' reason: 'AddedOrUpdatedWithError' Configuration for default/cafe-ingress-with-snippets was added or updated, but not applied: Error reloading NGINX for default/cafe-ingress-with-snippets: nginx reload failed: Command /usr/sbin/nginx -s reload stdout: "" -stderr: "nginx: [emerg] unknown directive \"badd_header\" in /etc/nginx/conf.d/default-cafe-ingress-with-snippets.conf:54\n" -finished with error: exit status 1 -``` - -An example of an event with an error (you can view events associated with the Ingress by running `kubectl describe -n nginx-ingress ingress nginx-ingress`): - -```shell -Events: -Type Reason Age From Message ----- ------ ---- ---- ------- -Normal AddedOrUpdated 52m (x3 over 61m) nginx-ingress-controller Configuration for default/cafe-ingress-with-snippets was added or updated -finished with error: exit status 1 -Warning AddedOrUpdatedWithError 54s (x2 over 89s) nginx-ingress-controller Configuration for default/cafe-ingress-with-snippets was added or updated, but not applied: Error reloading NGINX for default/cafe-ingress-with-snippets: nginx reload failed: Command /usr/sbin/nginx -s reload stdout: "" -stderr: "nginx: [emerg] unknown directive \"badd_header\" in /etc/nginx/conf.d/default-cafe-ingress-with-snippets.conf:54\n" -finished with error: exit status 1 -``` - -Additionally, to help troubleshoot snippets, a number of Prometheus metrics show the stats about failed reloads – `controller_nginx_last_reload_status` and `controller_nginx_reload_errors_total`. diff --git a/docs/content/configuration/ingress-resources/basic-configuration.md b/docs/content/configuration/ingress-resources/basic-configuration.md deleted file mode 100644 index dd04c20a64..0000000000 --- a/docs/content/configuration/ingress-resources/basic-configuration.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -description: The example in this document shows a basic Ingress resource definition. -docs: DOCS-593 -doctypes: -- '' -title: Basic Configuration -toc: true -weight: 1600 ---- - -This document shows a basic Ingress resource definition which load balances requests for two services as part of a single application. - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: cafe-ingress -spec: - tls: - - hosts: - - cafe.example.com - secretName: cafe-secret - rules: - - host: cafe.example.com - http: - paths: - - path: /tea - pathType: Prefix - backend: - service: - name: tea-svc - port: - number: 80 - - path: /coffee - pathType: Prefix - backend: - service: - name: coffee-svc - port: - number: 80 -``` - -Here is a breakdown of what this Ingress resource definition means: - -- The `metadata.name` field defines the name of the resource `cafe‑ingress`. -- In the `spec.tls` field we set up SSL/TLS termination: - - In the `secretName`, we reference a secret resource by its name, `cafe‑secret`. The secret must belong to the same namespace as the Ingress, it must be of the type ``kubernetes.io/tls`` and contain keys named ``tls.crt`` and ``tls.key`` that hold the certificate and private key as described [here](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls>). If the secret doesn't exist or is invalid, NGINX will break any attempt to establish a TLS connection to the hosts to which the secret is applied. - - In the `hosts` field, we apply the certificate and key to our `cafe.example.com` host. -- In the `spec.rules` field, we define a host with domain name `cafe.example.com`. -- In the `paths` field, we define two path‑based rules: - - The rule with the path `/tea` instructs NGINX to distribute the requests with the `/tea` URI among the pods of the *tea* service, which is deployed with the name `tea‑svc` in the cluster. - - The rule with the path `/coffee` instructs NGINX to distribute the requests with the `/coffee` URI among the pods of the *coffee* service, which is deployed with the name `coffee‑svc` in the cluster. - - Both rules instruct NGINX to distribute the requests to `port 80` of the corresponding service (the `servicePort` field). - -> For complete instructions on deploying the Ingress and Secret resources in the cluster, see the [complete example](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/complete-example) in our GitHub repository. - -> To learn more about the Ingress resource, see the [Ingress resource documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) in the Kubernetes docs. - -## New Features Available in Kubernetes 1.18 and Above - -Starting from Kubernetes 1.18, you can use the following new features: - -- The host field supports wildcard domain names, such as `*.example.com`. -- The path supports different matching rules with the new field `pathType`, which takes the following values: `Prefix` for prefix-based matching, `Exact` for exact matching and `ImplementationSpecific`, which is the default type and is the same as `Prefix`. For example: - - ```yaml - - path: /tea - pathType: Prefix - backend: - serviceName: tea-svc - servicePort: 80 - - path: /tea/green - pathType: Exact - backend: - service: - name: tea-svc - port: - number: 80 - - path: /coffee - pathType: ImplementationSpecific - backend: - service: - name: coffee-svc - port: - number: 80 - ``` - -- The `ingressClassName` field is now supported: - - ```yaml - apiVersion: networking.k8s.io/v1 - kind: Ingress - metadata: - name: cafe-ingress - spec: - ingressClassName: nginx - tls: - - hosts: - - cafe.example.com - secretName: cafe-secret - rules: - - host: cafe.example.com - . . . - ``` - - When using this filed you need to create the `IngressClass` resource with the corresponding `name`. See Step 3 *Create an IngressClass resource* of the [Create Common Resources](/nginx-ingress-controller/installation/installation-with-manifests/#2-create-common-resources) section. - -## Restrictions - -NGINX Ingress Controller imposes the following restrictions on Ingress resources: - -- When defining an Ingress resource, the `host` field is required. -- The `host` value needs to be unique among all Ingress and VirtualServer resources unless the Ingress resource is a [mergeable minion](/nginx-ingress-controller/configuration/ingress-resources/cross-namespace-configuration/). See also [Handling Host and Listener Collisions](/nginx-ingress-controller/configuration/handling-host-and-listener-collisions). -- The `path` field in `spec.rules[].http.paths[]` is required for `Exact` and `Prefix` `pathTypes`. -- The ImplementationSpecific `pathType` is treated as equivalent to `Prefix` `pathType`, with the exception that when this `pathType` is configured, the `path` field in `spec.rules[].http.paths[]` is not mandatory. `path` defaults to `/` if not set but the `pathType` is set to ImplementationSpecific. - -## Advanced Configuration - -The Ingress resource only allows you to use basic NGINX features -- host and path-based routing and TLS termination. Advanced features like rewriting the request URI or inserting additional response headers are available through annotations. See the [Advanced Configuration with Annotations](/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations) doc. - -The Ingress Controller generates NGINX configuration by executing a template file that contains configuration options. These options are set via the Ingress resource and the Ingress Controller's ConfigMap. Advanced NGINX users who require more control over the generated NGINX configurations can use snippets to insert raw NGINX config. See [Advanced Configuration with Snippets](/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-snippets) for more information. Additionally, it is possible to customize the template. See [Custom Templates](/nginx-ingress-controller/configuration/global-configuration/custom-templates/) for instructions. diff --git a/docs/content/configuration/ingress-resources/cross-namespace-configuration.md b/docs/content/configuration/ingress-resources/cross-namespace-configuration.md deleted file mode 100644 index 2db8fe24eb..0000000000 --- a/docs/content/configuration/ingress-resources/cross-namespace-configuration.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -docs: DOCS-594 -doctypes: -- '' -title: Cross-namespace Configuration -toc: true -weight: 2000 ---- - -This document explains how to spread Ingress configuration across different namespaces. - -You can spread the Ingress configuration for a common host across multiple Ingress resources using Mergeable Ingress resources. Such resources can belong to the *same* or *different* namespaces. This enables easier management when using a large number of paths. See the [Mergeable Ingress Resources](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/mergeable-ingress-types) example in our GitHub repo. - -As an alternative to Mergeable Ingress resources, you can use [VirtualServer and VirtualServerRoute resources](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/) for cross-namespace configuration. See the [Cross-Namespace Configuration](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources/cross-namespace-configuration) example in our GitHub repo. diff --git a/docs/content/configuration/ingress-resources/custom-annotations.md b/docs/content/configuration/ingress-resources/custom-annotations.md deleted file mode 100644 index 67738816b3..0000000000 --- a/docs/content/configuration/ingress-resources/custom-annotations.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -docs: DOCS-595 -doctypes: -- '' -title: Custom Annotations -toc: true -weight: 1900 ---- - -Custom annotations enable you to quickly extend the Ingress resource to support many advanced features of NGINX, such as rate limiting, caching, etc. - -## What are Custom Annotations - -NGINX Ingress Controller supports a number of annotations for the Ingress resource that fine tune NGINX configuration (for example, connection timeouts) or enable additional features (for example, JWT validation). The complete list of annotations is available [here](/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations). - -The annotations are provided only for the most common features and use cases, meaning that not every NGINX feature or a customization option is available through the annotations. Additionally, even if an annotation is available, it might not give you the satisfactory level of control of a particular NGINX feature. - -Custom annotations allow you to add an annotation for an NGINX feature that is not available as a regular annotation. In contrast with regular annotations, to add a custom annotation, you don't need to modify the Ingress Controller source code -- just modify the template. Additionally, with a custom annotation, you get full control of how the feature is implemented in NGINX configuration. - -## Usage - -The Ingress Controller generates NGINX configuration for Ingress resources by executing a configuration template. See [NGINX template](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/internal/configs/version1/nginx.ingress.tmpl) or [NGINX Plus template](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/internal/configs/version1/nginx-plus.ingress.tmpl). - -To support custom annotations, the template has access to the information about the Ingress resource - its *name*, *namespace* and *annotations*. It is possible to check if a particular annotation present in the Ingress resource and conditionally insert NGINX configuration directives at multiple NGINX contexts - `http`, `server`, `location` or `upstream`. Additionally, you can get the value that is set to the annotation. - -Consider the following excerpt from the template, which was extended to support two custom annotations: - -```jinja2 -# This is the configuration for {{$.Ingress.Name}}/{{$.Ingress.Namespace}} - -{{if index $.Ingress.Annotations "custom.nginx.org/feature-a"}} -# Insert config for feature A if the annotation is set -{{end}} - -{{with $value := index $.Ingress.Annotations "custom.nginx.org/feature-b"}} -# Insert config for feature B if the annotation is set -# Print the value assigned to the annotation: {{$value}} -{{end}} -``` - -Consider the following Ingress resource and note how we set two annotations: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: example-ingress - namespace: production - annotations: - custom.nginx.org/feature-a: "on" - custom.nginx.org/feature-b: "512" -spec: - rules: - - host: example.com - . . . -``` - -Assuming that the Ingress Controller is using that customized template, it will generate a config for the Ingress resource that will include the following part, generated by our template excerpt: - -```yaml -# This is the configuration for cafe-ingress/default - -# Insert config for feature A if the annotation is set - - - -# Insert config for feature B if the annotation is set -# Print the value assigned to the annotation: 512 -``` - -**Notes**: - -- You can customize the template to insert you custom annotations via [custom templates](/nginx-ingress-controller/configuration/global-configuration/custom-templates). -- The Ingress Controller uses go templates to generate NGINX config. You can read more information about go templates [here](https://golang.org/pkg/text/template/). - -See the examples in the next section that use custom annotations to configure NGINX features. - -### Custom Annotations with Mergeable Ingress Resources - -A Mergeable Ingress resource consists of multiple Ingress resources - one master and one or several minions. Read more about Mergeable Ingress resources [here](/nginx-ingress-controller/configuration/ingress-resources/cross-namespace-configuration). - -If you'd like to use custom annotations with Mergeable Ingress resources, please keep the following in mind: - -- Custom annotations can be used in the Master and in Minions. For Minions, you can access them in the template only when processing locations. - - If you access `$.Ingress` anywhere in the Ingress template, you will get the master Ingress resource. To access a Minion Ingress resource, use `$location.MinionIngress`. However, it is only available when processing locations: - - ```jinja2 - {{range $location := $server.Locations}} - location {{$location.Path}} { - {{with $location.MinionIngress}} - # location for minion {{$location.MinionIngress.Namespace}}/{{$location.MinionIngress.Name}} - {{end}} - } {{end}} - ``` - - **Note**: `$location.MinionIngress` is a pointer. When a regular Ingress resource is processed in the template, the value of the pointer is `nil`. Thus, it is important that you check that `$location.MinionIngress` is not `nil` as in the example above using the `with` action. - -- Minions do not inherent custom annotations of the master. - -### Helper Functions - -Helper functions can be used in the Ingress template to parse the values of custom annotations. - -{{% table %}} -| Function | Input Arguments | Return Arguments | Description | -| ---| ---| ---| --- | -| ``split`` | ``s, sep string`` | ``[]string`` | Splits the string ``s`` into a slice of strings separated by the ``sep``. | -| ``trim`` | ``s string`` | ``string`` | Trims the trailing and leading whitespace from the string ``s``. | -| ``contains`` | ``s, substr string`` | ``bool`` | Tests whether the string ``substr`` is a substring of the string ``s``. | -| ``hasPrefix`` | ``s, prefix string`` | ``bool`` | Tests whether the string ``prefix`` is a prefix of the string ``s``. | -| ``hasSuffix`` | ``s, suffix string`` | ``bool`` | Tests whether the string ``suffix`` is a suffix of the string ``s``. | -| ``toLower`` | ``s string`` | ``bool`` | Converts all letters in the string ``s`` to their lower case. | -| ``toUpper`` | ``s string`` | ``bool`` | Converts all letters in the string ``s`` to their upper case. | -| ``replaceAll`` | ``s, old, new string`` | ``string`` | Replaces all occurrences of ``old`` with ``new`` in the string ``s``. | -{{% /table %}} - -Consider the following custom annotation `custom.nginx.org/allowed-ips`, which expects a comma-separated list of IP addresses: - -```yaml -annotations: - custom.nginx.org/allowed-ips: "192.168.1.3, 10.0.0.13" -``` - - The helper functions can parse the value of the `custom.nginx.org/allowed-ips` annotation, so that in the template you can use each IP address separately. Consider the following template excerpt: - -```jinja2 -{{range $ip := split (index $.Ingress.Annotations "custom.nginx.org/allowed-ips") ","}} - allow {{trim $ip}}; -{{end}} -deny all; -``` - -The template excerpt will generate the following configuration: - -``` -allow 192.168.1.3; -allow 10.0.0.13; -deny all; -``` - -## Example - -See the [custom annotations example](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/examples/ingress-resources/custom-annotations). diff --git a/docs/content/configuration/policy-resource.md b/docs/content/configuration/policy-resource.md deleted file mode 100644 index 5b96c58f27..0000000000 --- a/docs/content/configuration/policy-resource.md +++ /dev/null @@ -1,733 +0,0 @@ ---- -docs: DOCS-596 -doctypes: -- '' -title: Policy Resource -toc: true -weight: 1800 ---- - -The Policy resource allows you to configure features like access control and rate-limiting, which you can add to your [VirtualServer and VirtualServerRoute resources](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/). - -The resource is implemented as a [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - -This document is the reference documentation for the Policy resource. An example of a Policy for access control is available in our [GitHub repository](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/examples/custom-resources/access-control). - -## Prerequisites - -Policies work together with [VirtualServer and VirtualServerRoute resources](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/), which you need to create separately. - -## Policy Specification - -Below is an example of a policy that allows access for clients from the subnet `10.0.0.0/8` and denies access for any other clients: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: Policy -metadata: - name: allow-localhost -spec: - accessControl: - allow: - - 10.0.0.0/8 -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``accessControl`` | The access control policy based on the client IP address. | [accessControl](#accesscontrol) | No | -|``ingressClassName`` | Specifies which instance of NGINX Ingress Controller must handle the Policy resource. | ``string`` | No | -|``rateLimit`` | The rate limit policy controls the rate of processing requests per a defined key. | [rateLimit](#ratelimit) | No | -|``basicAuth`` | The basic auth policy configures NGINX to authenticate client requests using HTTP Basic authentication credentials. | [basicAuth](#basicauth) | No | -|``jwt`` | The JWT policy configures NGINX Plus to authenticate client requests using JSON Web Tokens. | [jwt](#jwt) | No | -|``ingressMTLS`` | The IngressMTLS policy configures client certificate verification. | [ingressMTLS](#ingressmtls) | No | -|``egressMTLS`` | The EgressMTLS policy configures upstreams authentication and certificate verification. | [egressMTLS](#egressmtls) | No | -|``waf`` | The WAF policy configures WAF and log configuration policies for [NGINX AppProtect](/nginx-ingress-controller/app-protect/installation/) | [WAF](#waf) | No | -{{% /table %}} - -\* A policy must include exactly one policy. - -### AccessControl - -The access control policy configures NGINX to deny or allow requests from clients with the specified IP addresses/subnets. - -For example, the following policy allows access for clients from the subnet `10.0.0.0/8` and denies access for any other clients: - -```yaml -accessControl: - allow: - - 10.0.0.0/8 -``` - -In contrast, the policy below does the opposite: denies access for clients from `10.0.0.0/8` and allows access for any other clients: - -```yaml -accessControl: - deny: - - 10.0.0.0/8 -``` - -> Note: The feature is implemented using the NGINX [ngx_http_access_module](http://nginx.org/en/docs/http/ngx_http_access_module.html). NGINX Ingress Controller access control policy supports either allow or deny rules, but not both (as the module does). - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``allow`` | Allows access for the specified networks or addresses. For example, ``192.168.1.1`` or ``10.1.1.0/16``. | ``[]string`` | No | -|``deny`` | Denies access for the specified networks or addresses. For example, ``192.168.1.1`` or ``10.1.1.0/16``. | ``[]string`` | No | \* an accessControl must include either `allow` or `deny`. | -{{% /table %}} - -#### AccessControl Merging Behavior - -A VirtualServer/VirtualServerRoute can reference multiple access control policies. For example, here we reference two policies, each with configured allow lists: - -```yaml -policies: -- name: allow-policy-one -- name: allow-policy-two -``` - -When you reference more than one access control policy, NGINX Ingress Controller will merge the contents into a single allow list or a single deny list. - -Referencing both allow and deny policies, as shown in the example below, is not supported. If both allow and deny lists are referenced, NGINX Ingress Controller uses just the allow list policies. - -```yaml -policies: -- name: deny-policy -- name: allow-policy-one -- name: allow-policy-two -``` - -### RateLimit - -The rate limit policy configures NGINX to limit the processing rate of requests. - -For example, the following policy will limit all subsequent requests coming from a single IP address once a rate of 10 requests per second is exceeded: - -```yaml -rateLimit: - rate: 10r/s - zoneSize: 10M - key: ${binary_remote_addr} -``` - -> Note: The feature is implemented using the NGINX [ngx_http_limit_req_module](https://nginx.org/en/docs/http/ngx_http_limit_req_module.html). - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``rate`` | The rate of requests permitted. The rate is specified in requests per second (r/s) or requests per minute (r/m). | ``string`` | Yes | -|``key`` | The key to which the rate limit is applied. Can contain text, variables, or a combination of them. Variables must be surrounded by ``${}``. For example: ``${binary_remote_addr}``. Accepted variables are ``$binary_remote_addr``, ``$request_uri``, ``$url``, ``$http_``, ``$args``, ``$arg_``, ``$cookie_``. | ``string`` | Yes | -|``zoneSize`` | Size of the shared memory zone. Only positive values are allowed. Allowed suffixes are ``k`` or ``m``, if none are present ``k`` is assumed. | ``string`` | Yes | -|``delay`` | The delay parameter specifies a limit at which excessive requests become delayed. If not set all excessive requests are delayed. | ``int`` | No | -|``noDelay`` | Disables the delaying of excessive requests while requests are being limited. Overrides ``delay`` if both are set. | ``bool`` | No | -|``burst`` | Excessive requests are delayed until their number exceeds the ``burst`` size, in which case the request is terminated with an error. | ``int`` | No | -|``dryRun`` | Enables the dry run mode. In this mode, the rate limit is not actually applied, but the number of excessive requests is accounted as usual in the shared memory zone. | ``bool`` | No | -|``logLevel`` | Sets the desired logging level for cases when the server refuses to process requests due to rate exceeding, or delays request processing. Allowed values are ``info``, ``notice``, ``warn`` or ``error``. Default is ``error``. | ``string`` | No | -|``rejectCode`` | Sets the status code to return in response to rejected requests. Must fall into the range ``400..599``. Default is ``503``. | ``int`` | No | -|``scale`` | Enables a constant rate-limit by dividing the configured rate by the number of nginx-ingress pods currently serving traffic. This adjustment ensures that the rate-limit remains consistent, even as the number of nginx-pods fluctuates due to autoscaling. Note: This will not work properly if requests from a client are not evenly distributed accross all ingress pods (sticky sessions, long lived TCP-Connections with many requests etc.). In such cases using NGINX+'s zone-sync feature instead would give better results. | ``bool`` | No | -{{% /table %}} - -> For each policy referenced in a VirtualServer and/or its VirtualServerRoutes, NGINX Ingress Controller will generate a single rate limiting zone defined by the [`limit_req_zone`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone) directive. If two VirtualServer resources reference the same policy, NGINX Ingress Controller will generate two different rate limiting zones, one zone per VirtualServer. - -#### RateLimit Merging Behavior - -A VirtualServer/VirtualServerRoute can reference multiple rate limit policies. For example, here we reference two policies: - -```yaml -policies: -- name: rate-limit-policy-one -- name: rate-limit-policy-two -``` - -When you reference more than one rate limit policy, NGINX Ingress Controller will configure NGINX to use all referenced rate limits. When you define multiple policies, each additional policy inherits the `dryRun`, `logLevel`, and `rejectCode` parameters from the first policy referenced (`rate-limit-policy-one`, in the example above). - -### BasicAuth - -The basic auth policy configures NGINX to authenticate client requests using the [HTTP Basic authentication scheme](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication). - -For example, the following policy will reject all requests that do not include a valid username/password combination in the HTTP header `Authentication` - -```yaml -basicAuth: - secret: htpasswd-secret - realm: "My API" -``` - -> Note: The feature is implemented using the NGINX [ngx_http_auth_basic_module](https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html). - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``secret`` | The name of the Kubernetes secret that stores the Htpasswd configuration. It must be in the same namespace as the Policy resource. The secret must be of the type ``nginx.org/htpasswd``, and the config must be stored in the secret under the key ``htpasswd``, otherwise the secret will be rejected as invalid. | ``string`` | Yes | -|``realm`` | The realm for the basic authentication. | ``string`` | No | -{{% /table %}} - -#### BasicAuth Merging Behavior - -A VirtualServer/VirtualServerRoute can reference multiple basic auth policies. However, only one can be applied. Every subsequent reference will be ignored. For example, here we reference two policies: - -```yaml -policies: -- name: basic-auth-policy-one -- name: basic-auth-policy-two -``` - -In this example NGINX Ingress Controller will use the configuration from the first policy reference `basic-auth-policy-one`, and ignores `basic-auth-policy-two`. - -### JWT Using Local Kubernetes Secret - -> Note: This feature is only available in NGINX Plus. - -The JWT policy configures NGINX Plus to authenticate client requests using JSON Web Tokens. - -The following example policy will reject all requests that do not include a valid JWT in the HTTP header `token`: - -```yaml -jwt: - secret: jwk-secret - realm: "My API" - token: $http_token -``` - -You can pass the JWT claims and JOSE headers to the upstream servers. For example: - -```yaml -action: - proxy: - upstream: webapp - requestHeaders: - set: - - name: user - value: ${jwt_claim_user} - - name: alg - value: ${jwt_header_alg} -``` - -We use the `requestHeaders` of the [Action.Proxy](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#actionproxy) to set the values of two headers that NGINX will pass to the upstream servers. - -The value of the `${jwt_claim_user}` variable is the `user` claim of a JWT. For other claims, use `${jwt_claim_name}`, where `name` is the name of the claim. Note that nested claims and claims that include a period (`.`) are not supported. Similarly, use `${jwt_header_name}` where `name` is the name of a header. In our example, we use the `alg` header. - -> Note: This feature is implemented using the NGINX Plus [ngx_http_auth_jwt_module](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html). - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``secret`` | The name of the Kubernetes secret that stores the JWK. It must be in the same namespace as the Policy resource. The secret must be of the type ``nginx.org/jwk``, and the JWK must be stored in the secret under the key ``jwk``, otherwise the secret will be rejected as invalid. | ``string`` | Yes | -|``realm`` | The realm of the JWT. | ``string`` | Yes | -|``token`` | The token specifies a variable that contains the JSON Web Token. By default the JWT is passed in the ``Authorization`` header as a Bearer Token. JWT may be also passed as a cookie or a part of a query string, for example: ``$cookie_auth_token``. Accepted variables are ``$http_``, ``$arg_``, ``$cookie_``. | ``string`` | No | -{{% /table %}} - -#### JWT Merging Behavior - -A VirtualServer/VirtualServerRoute can reference multiple JWT policies. However, only one can be applied: every subsequent reference will be ignored. For example, here we reference two policies: - -```yaml -policies: -- name: jwt-policy-one -- name: jwt-policy-two -``` - -In this example NGINX Ingress Controller will use the configuration from the first policy reference `jwt-policy-one`, and ignores `jwt-policy-two`. - -### JWT Using JWKS From Remote Location - -> Note: This feature is only available in NGINX Plus. - -The JWT policy configures NGINX Plus to authenticate client requests using JSON Web Tokens, allowing import of the keys (JWKS) for JWT policy by means of a URL (for a remote server or an identity provider) as a result they don't have to be copied and updated to the IC pod. - -The following example policy will reject all requests that do not include a valid JWT in the HTTP header fetched from the identity provider: - -```yaml -jwt: - realm: MyProductAPI - token: $http_token - jwksURI: - keyCache: 1h -``` - -> Note: This feature is implemented using the NGINX Plus directive [auth_jwt_key_request](http://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html#auth_jwt_key_request) under [ngx_http_auth_jwt_module](https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html). - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``jwksURI`` | The remote URI where the request will be sent to retrieve JSON Web Key set| ``string`` | Yes | -|``keyCache`` | Enables in-memory caching of JWKS (JSON Web Key Sets) that are obtained from the ``jwksURI`` and sets a valid time for expiration. | ``string`` | Yes | -|``realm`` | The realm of the JWT. | ``string`` | Yes | -|``token`` | The token specifies a variable that contains the JSON Web Token. By default the JWT is passed in the ``Authorization`` header as a Bearer Token. JWT may be also passed as a cookie or a part of a query string, for example: ``$cookie_auth_token``. Accepted variables are ``$http_``, ``$arg_``, ``$cookie_``. | ``string`` | No | -{{% /table %}} - -> Note: Content caching is enabled by default for each JWT policy with a default time of 12 hours. -> This is done to ensure to improve resiliency by allowing the JWKS (JSON Web Key Set) to be retrieved from the cache even when it has expired. - -#### JWT Merging Behavior - -This behavior is similar to using a local Kubernetes secret where a VirtualServer/VirtualServerRoute can reference multiple JWT policies. However, only one can be applied: every subsequent reference will be ignored. For example, here we reference two policies: - -```yaml -policies: -- name: jwt-policy-one -- name: jwt-policy-two -``` - -In this example NGINX Ingress Controller will use the configuration from the first policy reference `jwt-policy-one`, and ignores `jwt-policy-two`. - -### IngressMTLS - -The IngressMTLS policy configures client certificate verification. - -For example, the following policy will verify a client certificate using the CA certificate specified in the `ingress-mtls-secret`: - -```yaml -ingressMTLS: - clientCertSecret: ingress-mtls-secret - verifyClient: "on" - verifyDepth: 1 -``` - -Below is an example of the `ingress-mtls-secret` using the secret type `nginx.org/ca` - -```yaml -kind: Secret -metadata: - name: ingress-mtls-secret -apiVersion: v1 -type: nginx.org/ca -data: - ca.crt: -``` - -A VirtualServer that references an IngressMTLS policy must: - -- Enable [TLS termination](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#virtualservertls). -- Reference the policy in the VirtualServer [`spec`](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#virtualserver-specification). It is not allowed to reference an IngressMTLS policy in a [`route`](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#virtualserverroute) or in a VirtualServerRoute [`subroute`](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#virtualserverroutesubroute). - -If the conditions above are not met, NGINX will send the `500` status code to clients. - -You can pass the client certificate details, including the certificate, to the upstream servers. For example: - -```yaml -action: - proxy: - upstream: webapp - requestHeaders: - set: - - name: client-cert-subj-dn - value: ${ssl_client_s_dn} # subject DN - - name: client-cert - value: ${ssl_client_escaped_cert} # client certificate in the PEM format (urlencoded) -``` - -We use the `requestHeaders` of the [Action.Proxy](/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#actionproxy) to set the values of the two headers that NGINX will pass to the upstream servers. See the [list of embedded variables](https://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables) that are supported by the `ngx_http_ssl_module`, which you can use to pass the client certificate details. - -> Note: The feature is implemented using the NGINX [ngx_http_ssl_module](https://nginx.org/en/docs/http/ngx_http_ssl_module.html). - -#### Using a Certificate Revocation List - -The IngressMTLS policy supports configuring at CRL for your policy. -This can be done in one of two ways. - -> Note: Only one of these configurations options can be used at a time. - -1. Adding the `ca.crl` field to the `nginx.org/ca` secret type, which accepts a base64 encoded certificate revocation list (crl). - Example YAML: - -```yaml -kind: Secret -metadata: - name: ingress-mtls-secret -apiVersion: v1 -type: nginx.org/ca -data: - ca.crt: - ca.crl: -``` - -2. Adding the `crlFileName` field to your IngressMTLS policy spec with the name of the CRL file. - -> Note: This configuration option should only be used when using a CRL that is larger than 1MiB -> Otherwise we recommend using the `nginx.org/ca` secret type for managing your CRL. - -Example YAML: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: Policy -metadata: - name: ingress-mtls-policy -spec: -ingressMTLS: - clientCertSecret: ingress-mtls-secret - crlFileName: webapp.crl - verifyClient: "on" - verifyDepth: 1 -``` - -**IMPORTANT NOTE** -When configuring a CRL with the `ingressMTLS.crlFileName` field, there is additional context to keep in mind: - -1. NGINX Ingress Controller will expect the CRL, in this case `webapp.crl`, will be in `/etc/nginx/secrets`. A volume mount will need to be added to NGINX Ingress Controller deployment add your CRL to `/etc/nginx/secrets` -2. When updating the content of your CRL (e.g a new certificate has been revoked), NGINX will need to be reloaded to pick up the latest changes. Depending on your environment this may require updating the name of your CRL and applying this update to your `ingress-mtls.yaml` policy to ensure NGINX picks up the latest CRL. - -Please refer to the Kubernetes documentation on [volumes](https://kubernetes.io/docs/concepts/storage/volumes/) to find the best implementation for your environment. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``clientCertSecret`` | The name of the Kubernetes secret that stores the CA certificate. It must be in the same namespace as the Policy resource. The secret must be of the type ``nginx.org/ca``, and the certificate must be stored in the secret under the key ``ca.crt``, otherwise the secret will be rejected as invalid. | ``string`` | Yes | -|``verifyClient`` | Verification for the client. Possible values are ``"on"``, ``"off"``, ``"optional"``, ``"optional_no_ca"``. The default is ``"on"``. | ``string`` | No | -|``verifyDepth`` | Sets the verification depth in the client certificates chain. The default is ``1``. | ``int`` | No | -|``crlFileName`` | The file name of the Certificate Revocation List. NGINX Ingress Controller will look for this file in `/etc/nginx/secrets` | ``string`` | No | -{{% /table %}} - -#### IngressMTLS Merging Behavior - -A VirtualServer can reference only a single IngressMTLS policy. Every subsequent reference will be ignored. For example, here we reference two policies: - -```yaml -policies: -- name: ingress-mtls-policy-one -- name: ingress-mtls-policy-two -``` - -In this example NGINX Ingress Controller will use the configuration from the first policy reference `ingress-mtls-policy-one`, and ignores `ingress-mtls-policy-two`. - -### EgressMTLS - -The EgressMTLS policy configures upstreams authentication and certificate verification. - -For example, the following policy will use `egress-mtls-secret` to authenticate with the upstream application and `egress-trusted-ca-secret` to verify the certificate of the application: - -```yaml -egressMTLS: - tlsSecret: egress-mtls-secret - trustedCertSecret: egress-trusted-ca-secret - verifyServer: on - verifyDepth: 2 -``` - -> Note: The feature is implemented using the NGINX [ngx_http_proxy_module](https://nginx.org/en/docs/http/ngx_http_proxy_module.html). - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``tlsSecret`` | The name of the Kubernetes secret that stores the TLS certificate and key. It must be in the same namespace as the Policy resource. The secret must be of the type ``kubernetes.io/tls``, the certificate must be stored in the secret under the key ``tls.crt``, and the key must be stored under the key ``tls.key``, otherwise the secret will be rejected as invalid. | ``string`` | No | -|``trustedCertSecret`` | The name of the Kubernetes secret that stores the CA certificate. It must be in the same namespace as the Policy resource. The secret must be of the type ``nginx.org/ca``, and the certificate must be stored in the secret under the key ``ca.crt``, otherwise the secret will be rejected as invalid. | ``string`` | No | -|``verifyServer`` | Enables verification of the upstream HTTPS server certificate. | ``bool`` | No | -|``verifyDepth`` | Sets the verification depth in the proxied HTTPS server certificates chain. The default is ``1``. | ``int`` | No | -|``sessionReuse`` | Enables reuse of SSL sessions to the upstreams. The default is ``true``. | ``bool`` | No | -|``serverName`` | Enables passing of the server name through ``Server Name Indication`` extension. | ``bool`` | No | -|``sslName`` | Allows overriding the server name used to verify the certificate of the upstream HTTPS server. | ``string`` | No | -|``ciphers`` | Specifies the enabled ciphers for requests to an upstream HTTPS server. The default is ``DEFAULT``. | ``string`` | No | -|``protocols`` | Specifies the protocols for requests to an upstream HTTPS server. The default is ``TLSv1 TLSv1.1 TLSv1.2``. | ``string`` | No | > Note: the value of ``ciphers`` and ``protocols`` is not validated by NGINX Ingress Controller. As a result, NGINX can fail to reload the configuration. To ensure that the configuration for a VirtualServer/VirtualServerRoute that references the policy was successfully applied, check its [status](/nginx-ingress-controller/configuration/global-configuration/reporting-resources-status/#virtualserver-and-virtualserverroute-resources). The validation will be added in the future releases. | -{{% /table %}} - -#### EgressMTLS Merging Behavior - -A VirtualServer/VirtualServerRoute can reference multiple EgressMTLS policies. However, only one can be applied. Every subsequent reference will be ignored. For example, here we reference two policies: - -```yaml -policies: -- name: egress-mtls-policy-one -- name: egress-mtls-policy-two -``` - -In this example NGINX Ingress Controller will use the configuration from the first policy reference `egress-mtls-policy-one`, and ignores `egress-mtls-policy-two`. - -### OIDC - -> **Feature Status**: This feature is disabled by default. To enable it, set the [enable-oidc](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments/#cmdoption-enable-oidc) command-line argument of NGINX Ingress Controller. - -The OIDC policy configures NGINX Plus as a relying party for OpenID Connect authentication. - -For example, the following policy will use the client ID `nginx-plus` and the client secret `oidc-secret` to authenticate with the OpenID Connect provider `https://idp.example.com`: - -```yaml -spec: - oidc: - clientID: nginx-plus - clientSecret: oidc-secret - authEndpoint: https://idp.example.com/openid-connect/auth - tokenEndpoint: https://idp.example.com/openid-connect/token - jwksURI: https://idp.example.com/openid-connect/certs - accessTokenEnable: true -``` - -NGINX Plus will pass the ID of an authenticated user to the backend in the HTTP header `username`. - -> Note: The feature is implemented using the [reference implementation](https://github.com/nginxinc/nginx-openid-connect/) of NGINX Plus as a relying party for OpenID Connect authentication. - -#### Prerequisites - -In order to use OIDC, you need to enable [zone synchronization](https://docs.nginx.com/nginx/admin-guide/high-availability/zone_sync/). If you don't set up zone synchronization, NGINX Plus will fail to reload. -You also need to configure a resolver, which NGINX Plus will use to resolve the IDP authorization endpoint. You can find an example configuration [in our GitHub repository](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/examples/custom-resources/oidc#step-7---configure-nginx-plus-zone-synchronization-and-resolver). - -> **Note**: The configuration in the example doesn't enable TLS and the synchronization between the replica happens in clear text. This could lead to the exposure of tokens. - -#### Limitations - -The OIDC policy defines a few internal locations that can't be customized: `/_jwks_uri`, `/_token`, `/_refresh`, `/_id_token_validation`, `/logout`, `/_logout`. In addition, as explained below `/_codexch` is the default value for redirect URI, but can be customized. Specifying one of these locations as a route in the VirtualServer or VirtualServerRoute will result in a collision and NGINX Plus will fail to reload. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``clientID`` | The client ID provided by your OpenID Connect provider. | ``string`` | Yes | -|``clientSecret`` | The name of the Kubernetes secret that stores the client secret provided by your OpenID Connect provider. It must be in the same namespace as the Policy resource. The secret must be of the type ``nginx.org/oidc``, and the secret under the key ``client-secret``, otherwise the secret will be rejected as invalid. | ``string`` | Yes | -|``authEndpoint`` | URL for the authorization endpoint provided by your OpenID Connect provider. | ``string`` | Yes | -|``authExtraArgs`` | A list of extra URL arguments to pass to the authorization endpoint provided by your OpenID Connect provider. Arguments must be URL encoded, multiple arguments may be included in the list, for example ``[ arg1=value1, arg2=value2 ]`` | ``string[]`` | No | -|``tokenEndpoint`` | URL for the token endpoint provided by your OpenID Connect provider. | ``string`` | Yes | -|``jwksURI`` | URL for the JSON Web Key Set (JWK) document provided by your OpenID Connect provider. | ``string`` | Yes | -|``scope`` | List of OpenID Connect scopes. The scope ``openid`` always needs to be present and others can be added concatenating them with a ``+`` sign, for example ``openid+profile+email``, ``openid+email+userDefinedScope``. The default is ``openid``. | ``string`` | No | -|``redirectURI`` | Allows overriding the default redirect URI. The default is ``/_codexch``. | ``string`` | No | -|``zoneSyncLeeway`` | Specifies the maximum timeout in milliseconds for synchronizing ID/access tokens and shared values between Ingress Controller pods. The default is ``200``. | ``int`` | No | -|``accessTokenEnable`` | Option of whether Bearer token is used to authorize NGINX to access protected backend. | ``boolean`` | No | -{{% /table %}} - -> **Note**: Only one OIDC policy can be referenced in a VirtualServer and its VirtualServerRoutes. However, the same policy can still be applied to different routes in the VirtualServer and VirtualServerRoutes. - -#### OIDC Merging Behavior - -A VirtualServer/VirtualServerRoute can reference only a single OIDC policy. Every subsequent reference will be ignored. For example, here we reference two policies: - -```yaml -policies: -- name: oidc-policy-one -- name: oidc-policy-two -``` - -In this example NGINX Ingress Controller will use the configuration from the first policy reference `oidc-policy-one`, and ignores `oidc-policy-two`. - -## Using Policy - -You can use the usual `kubectl` commands to work with Policy resources, just as with built-in Kubernetes resources. - -For example, the following command creates a Policy resource defined in `access-control-policy-allow.yaml` with the name `webapp-policy`: - -```shell -kubectl apply -f access-control-policy-allow.yaml - -policy.k8s.nginx.org/webapp-policy configured -``` - -You can get the resource by running: - -```shell -kubectl get policy webapp-policy - -NAME AGE -webapp-policy 27m -``` - -For `kubectl get` and similar commands, you can also use the short name `pol` instead of `policy`. - -### WAF {#waf} - -> Note: This feature is only available in NGINX Plus with AppProtect. - -The WAF policy configures NGINX Plus to secure client requests using App Protect WAF policies. - -For example, the following policy will enable the referenced APPolicy. You can configure multiple APLogConfs with log destinations: - -```yaml -waf: - enable: true - apPolicy: "default/dataguard-alarm" - securityLogs: - - enable: true - apLogConf: "default/logconf" - logDest: "syslog:server=syslog-svc.default:514" - - enable: true - apLogConf: "default/logconf" - logDest: "syslog:server=syslog-svc-secondary.default:514" -``` - -> Note: The field `waf.securityLog` is deprecated and will be removed in future releases.It will be ignored if `waf.securityLogs` is populated. -> Note: The feature is implemented using the NGINX Plus [NGINX App Protect WAF Module](https://docs.nginx.com/nginx-app-protect/configuration/). - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables NGINX App Protect WAF. | ``bool`` | Yes | -|``apPolicy`` | The [App Protect WAF policy]({{< relref "installation/integrations/app-protect-waf/configuration.md#waf-policies" >}}) of the WAF. Accepts an optional namespace. Mutually exclusive with ``apBundle``. | ``string`` | No | -|``apBundle`` | The [App Protect WAF policy bundle]({{< relref "installation/integrations/app-protect-waf/configuration.md#waf-bundles" >}}). Mutually exclusive with ``apPolicy``. | ``string`` | No | -|``securityLog.enable`` | Enables security log. | ``bool`` | No | -|``securityLog.apLogConf`` | The [App Protect WAF log conf]({{< relref "installation/integrations/app-protect-waf/configuration.md#waf-logs" >}}) resource. Accepts an optional namespace. Only works with ``apPolicy``. | ``string`` | No | -|``securityLog.apLogBundle`` | The [App Protect WAF log bundle]({{< relref "installation/integrations/app-protect-waf/configuration.md#waf-bundles" >}}) resource. Only works with ``apBundle``. | ``string`` | No | -|``securityLog.logDest`` | The log destination for the security log. Accepted variables are ``syslog:server=:``, ``stderr``, ````. Default is ``"syslog:server=127.0.0.1:514"``. | ``string`` | No | -{{% /table %}} - -#### WAF Merging Behavior - -A VirtualServer/VirtualServerRoute can reference multiple WAF policies. However, only one can be applied. Every subsequent reference will be ignored. For example, here we reference two policies: - -```yaml -policies: -- name: waf-policy-one -- name: waf-policy-two -``` - -In this example NGINX Ingress Controller will use the configuration from the first policy reference `waf-policy-one`, and ignores `waf-policy-two`. - -### Applying Policies - -You can apply policies to both VirtualServer and VirtualServerRoute resources. For example: - -- VirtualServer: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: VirtualServer - metadata: - name: cafe - namespace: cafe - spec: - host: cafe.example.com - tls: - secret: cafe-secret - policies: # spec policies - - name: policy1 - upstreams: - - name: coffee - service: coffee-svc - port: 80 - routes: - - path: /tea - policies: # route policies - - name: policy2 - namespace: cafe - route: tea/tea - - path: /coffee - policies: # route policies - - name: policy3 - namespace: cafe - action: - pass: coffee - ``` - - For VirtualServer, you can apply a policy: - * to all routes (spec policies) - * to a specific route (route policies) - - Route policies of the *same type* override spec policies. In the example above, if the type of the policies `policy-1` and `policy-3` is `accessControl`, then for requests to `cafe.example.com/coffee`, NGINX will apply `policy-3`. - - The overriding is enforced by NGINX: the spec policies are implemented in the `server` context of the config, and the route policies are implemented in the `location` context. As a result, the route policies of the same type win. - -- VirtualServerRoute, which is referenced by the VirtualServer above: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: VirtualServerRoute - metadata: - name: tea - namespace: tea - spec: - host: cafe.example.com - upstreams: - - name: tea - service: tea-svc - port: 80 - subroutes: # subroute policies - - path: /tea - policies: - - name: policy4 - namespace: tea - action: - pass: tea - ``` - - For VirtualServerRoute, you can apply a policy to a subroute (subroute policies). - - Subroute policies of the same type override spec policies. In the example above, if the type of the policies `policy-1` (in the VirtualServer) and `policy-4` is `accessControl`, then for requests to `cafe.example.com/tea`, NGINX will apply `policy-4`. As with the VirtualServer, the overriding is enforced by NGINX. - - Subroute policies always override route policies no matter the types. For example, the policy `policy-2` in the VirtualServer route will be ignored for the subroute `/tea`, because the subroute has its own policies (in our case, only one policy `policy4`). If the subroute didn't have any policies, then the `policy-2` would be applied. This overriding is enforced by NGINX Ingress Controller -- the `location` context for the subroute will either have route policies or subroute policies, but not both. - -### Invalid Policies - -NGINX will treat a policy as invalid if one of the following conditions is met: - -- The policy doesn't pass the [comprehensive validation](#comprehensive-validation). -- The policy isn't present in the cluster. -- The policy doesn't meet its type-specific requirements. For example, an `ingressMTLS` policy requires TLS termination enabled in the VirtualServer. - -For an invalid policy, NGINX returns the 500 status code for client requests with the following rules: - -- If a policy is referenced in a VirtualServer `route` or a VirtualServerRoute `subroute`, then NGINX will return the 500 status code for requests for the URIs of that route/subroute. -- If a policy is referenced in the VirtualServer `spec`, then NGINX will return the 500 status code for requests for all URIs of that VirtualServer. - -If a policy is invalid, the VirtualServer or VirtualServerRoute will have the [status](/nginx-ingress-controller/configuration/global-configuration/reporting-resources-status#virtualserver-and-virtualserverroute-resources) with the state `Warning` and the message explaining why the policy wasn't considered invalid. - -### Validation - -Two types of validation are available for the Policy resource: - -- *Structural validation*, done by `kubectl` and the Kubernetes API server. -- *Comprehensive validation*, done by NGINX Ingress Controller. - -#### Structural Validation - -The custom resource definition for the Policy includes a structural OpenAPI schema, which describes the type of every field of the resource. - -If you try to create (or update) a resource that violates the structural schema -- for example, the resource uses a string value instead of an array of strings in the `allow` field -- `kubectl` and the Kubernetes API server will reject the resource. - -- Example of `kubectl` validation: - - ```shell - kubectl apply -f access-control-policy-allow.yaml - - error: error validating "access-control-policy-allow.yaml": error validating data: ValidationError(Policy.spec.accessControl.allow): invalid type for org.nginx.k8s.v1.Policy.spec.accessControl.allow: got "string", expected "array"; if you choose to ignore these errors, turn validation off with --validate=false - ``` - -- Example of Kubernetes API server validation: - - ```shell - kubectl apply -f access-control-policy-allow.yaml --validate=false - - The Policy "webapp-policy" is invalid: spec.accessControl.allow: Invalid value: "string": spec.accessControl.allow in body must be of type array: "string" - ``` - -If a resource passes structural validation, then NGINX Ingress Controller's comprehensive validation runs. - -#### Comprehensive Validation - -NGINX Ingress Controller validates the fields of a Policy resource. If a resource is invalid, NGINX Ingress Controller will reject it. The resource will continue to exist in the cluster, but NGINX Ingress Controller will ignore it. - -You can use `kubectl` to check whether or not NGINX Ingress Controller successfully applied a Policy configuration. For our example `webapp-policy` Policy, we can run: - -```shell -kubectl describe pol webapp-policy - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 11s nginx-ingress-controller Policy default/webapp-policy was added or updated -``` - -Note how the events section includes a Normal event with the AddedOrUpdated reason that informs us that the configuration was successfully applied. - -If you create an invalid resource, NGINX Ingress Controller will reject it and emit a Rejected event. For example, if you create a Policy `webapp-policy` with an invalid IP `10.0.0.` in the `allow` field, you will get: - -```shell -kubectl describe policy webapp-policy - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 7s nginx-ingress-controller Policy default/webapp-policy is invalid and was rejected: spec.accessControl.allow[0]: Invalid value: "10.0.0.": must be a CIDR or IP -``` - -Note how the events section includes a Warning event with the Rejected reason. - -Additionally, this information is also available in the `status` field of the Policy resource. Note the Status section of the Policy: - -```shell -kubectl describe pol webapp-policy - -. . . -Status: - Message: Policy default/webapp-policy is invalid and was rejected: spec.accessControl.allow[0]: Invalid value: "10.0.0.": must be a CIDR or IP - Reason: Rejected - State: Invalid -``` - -**Note**: If you make an existing resource invalid, NGINX Ingress Controller will reject it. diff --git a/docs/content/configuration/security.md b/docs/content/configuration/security.md deleted file mode 100644 index 112e37cfea..0000000000 --- a/docs/content/configuration/security.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -docs: DOCS-597 -doctypes: -- '' -title: Security recommendations -toc: true -weight: 1500 ---- - -NGINX Ingress Controller follows Kubernetes best practices: this page outlines configuration specific to NGINX Ingress Controller you may require, including links to examples in the [GitHub repository](https://github.com/nginxinc/kubernetes-ingress/tree/release-3.5). - -For general guidance, we recommend the official Kubernetes documentation for [Securing a Cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/). - -## Kubernetes recommendations - -### RBAC and Service Accounts - -Kubernetes uses [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) to control the resources and operations available to different types of users. - -NGINX Ingress Controller requires RBAC to configure a [ServiceUser](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts), and provides least privilege access in its standard deployment configurations: - -- [Helm](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/deployments/rbac/rbac.yaml) -- [Manifests](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/deployments/rbac/rbac.yaml) - -By default, the ServiceAccount has access to all Secret resources in the cluster. - -### Secrets - -[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) are required by NGINX Ingress Controller for certificates and privacy keys, which Kubernetes stores unencrypted by default. We recommend following the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) to store these Secrets using at-rest encryption. - - -## NGINX Ingress Controller recommendations - -### Configure root filesystem as read-only - -{{< caution >}} - This feature is not compatible with [NGINX App Protect WAF](https://docs.nginx.com/nginx-app-protect-waf/) or [NGINX App Protect DoS](https://docs.nginx.com/nginx-app-protect-dos/). -{{< /caution >}} - -NGINX Ingress Controller is designed to be resilient against attacks in various ways, such as running the service as non-root to avoid changes to files. We recommend setting filesystems to read-only so that the attack surface is further reduced by limiting changes to binaries and libraries. - -This is not enabled by default, but can be enabled with **Helm** using the [**controller.readOnlyRootFilesystem**]({{< relref "installation/installing-nic/installation-with-helm.md#configuration" >}}) argument. - -For **Manifests**, uncomment the following sections of the deployment: - -- `readOnlyRootFilesystem: true` -- The entire **volumeMounts** section -- The entire **initContainers** section - -The block below shows the code you will look for: - -```yaml -# volumes: -# - name: nginx-etc -# emptyDir: {} -# - name: nginx-cache -# emptyDir: {} -# - name: nginx-lib -# emptyDir: {} -# - name: nginx-log -# emptyDir: {} -. -. -. -# readOnlyRootFilesystem: true -. -. -. -# volumeMounts: -# - mountPath: /etc/nginx -# name: nginx-etc -# - mountPath: /var/cache/nginx -# name: nginx-cache -# - mountPath: /var/lib/nginx -# name: nginx-lib -# - mountPath: /var/log/nginx -# name: nginx-log -``` - -### Prometheus - -If Prometheus metrics are [enabled]({{< relref "/logging-and-monitoring/prometheus.md" >}}), we recommend [using HTTPS]({{< relref "configuration/global-configuration/command-line-arguments.md#cmdoption-prometheus-tls-secret" >}}). - -### Snippets - -Snippets allow raw NGINX configuration to be inserted into resources. They are intended for advanced NGINX users and could create vulnerabilities in a cluster if misused. - -Snippets are disabled by default. To use snippets, set the [**enable-snippets**]({{< relref"configuration/global-configuration/command-line-arguments.md#cmdoption-enable-snippets" >}}) command-line argument. - -{{< caution >}} - Snippets are **always** enabled for ConfigMap. -{{< /caution >}} - -For more information, read the following: - -- [Advanced Configuration using Snippets]({{< relref "/configuration/ingress-resources/advanced-configuration-with-snippets.md" >}}) -- [Using Snippets with VirtualServer/VirtualServerRoute]({{< relref "configuration/virtualserver-and-virtualserverroute-resources.md#using-snippets" >}}) -- [Using Snippets with TransportServer]({{< relref "/configuration/transportserver-resource.md#using-snippets" >}}) -- [ConfigMap Snippets and Custom Templates]({{< relref "configuration/global-configuration/configmap-resource.md#snippets-and-custom-templates" >}}) diff --git a/docs/content/configuration/transportserver-resource.md b/docs/content/configuration/transportserver-resource.md deleted file mode 100644 index 2ef19d51f3..0000000000 --- a/docs/content/configuration/transportserver-resource.md +++ /dev/null @@ -1,419 +0,0 @@ ---- -docs: DOCS-598 -doctypes: -- '' -title: TransportServer Resource -toc: true -weight: 1900 ---- - -The TransportServer resource allows you to configure TCP, UDP, and TLS Passthrough load balancing. The resource is implemented as a [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - -This document is the reference documentation for the TransportServer resource. To see additional examples of using the resource for specific use cases, go to the [examples/custom-resources](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources) folder in our GitHub repo. - -## Prerequisites - -- For TCP and UDP, the TransportServer resource must be used in conjunction with the [GlobalConfiguration resource](/nginx-ingress-controller/configuration/global-configuration/globalconfiguration-resource), which must be created separately. -- For TLS Passthrough, make sure to enable the [`-enable-tls-passthrough`](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments#cmdoption-enable-tls-passthrough) command-line argument of the Ingress Controller. - -## TransportServer Specification - -The TransportServer resource defines load balancing configuration for TCP, UDP, or TLS Passthrough traffic. Below are a few examples: - -- TCP load balancing: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: TransportServer - metadata: - name: dns-tcp - spec: - listener: - name: dns-tcp - protocol: TCP - tls: - secret: cafe-secret - upstreams: - - name: dns-app - service: dns-service - port: 5353 - action: - pass: dns-app - ``` - -- UDP load balancing: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: TransportServer - metadata: - name: dns-udp - spec: - listener: - name: dns-udp - protocol: UDP - upstreams: - - name: dns-app - service: dns-service - port: 5353 - upstreamParameters: - udpRequests: 1 - udpResponses: 1 - action: - pass: dns-app - ``` - -- TLS passthrough load balancing: - - ```yaml - apiVersion: k8s.nginx.org/v1 - kind: TransportServer - metadata: - name: secure-app - spec: - listener: - name: tls-passthrough - protocol: TLS_PASSTHROUGH - host: app.example.com - upstreams: - - name: secure-app - service: secure-app - port: 8443 - action: - pass: secure-app - ``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``listener`` | The listener on NGINX that will accept incoming connections/datagrams. | [listener](#listener) | Yes | -|``host`` | The host (domain name) of the server. Must be a valid subdomain as defined in RFC 1123, such as ``my-app`` or ``hello.example.com``. Wildcard domains like ``*.example.com`` are not allowed. Required for TLS Passthrough load balancing. | ``string`` | No | -|``tls`` | The TLS termination configuration. Not supported for TLS Passthrough load balancing. | [tls](#tls) | No | -|``upstreams`` | A list of upstreams. | [[]upstream](#upstream) | Yes | -|``upstreamParameters`` | The upstream parameters. | [upstreamParameters](#upstreamparameters) | No | -|``action`` | The action to perform for a client connection/datagram. | [action](#action) | Yes | -|``ingressClassName`` | Specifies which Ingress Controller must handle the TransportServer resource. | ``string`` | No | -|``streamSnippets`` | Sets a custom snippet in the ``stream`` context. | ``string`` | No | -|``serverSnippets`` | Sets a custom snippet in the ``server`` context. | ``string`` | No | -{{% /table %}} - -\* -- Required for TLS Passthrough load balancing. - -### Listener - -The listener field references a listener that NGINX will use to accept incoming traffic for the TransportServer. For TCP and UDP, the listener must be defined in the [GlobalConfiguration resource](/nginx-ingress-controller/configuration/global-configuration/globalconfiguration-resource). When referencing a listener, both the name and the protocol must match. For TLS Passthrough, use the built-in listener with the name `tls-passthrough` and the protocol `TLS_PASSTHROUGH`. - -An example: - -```yaml -listener: - name: dns-udp - protocol: UDP -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the listener. | ``string`` | Yes | -|``protocol`` | The protocol of the listener. | ``string`` | Yes | -{{% /table %}} - -### TLS - -The tls field defines TLS configuration for a TransportServer. Please note the current implementation supports TLS termination on multiple ports, where each application owns a dedicated port - the Ingress Controller terminates TLS connections on each port, where each application uses its own cert/key, and routes connections to appropriate application (service) based on that incoming port (any TLS connection regardless of the SNI on a port will be routed to the application that corresponds to that port). An example configuration is shown below: - -```yaml -secret: cafe-secret -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``secret`` | The name of a secret with a TLS certificate and key. The secret must belong to the same namespace as the TransportServer. The secret must be of the type ``kubernetes.io/tls`` and contain keys named ``tls.crt`` and ``tls.key`` that contain the certificate and private key as described [here](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls). | ``string`` | No | -{{% /table %}} - -### Upstream - -The upstream defines a destination for the TransportServer. For example: - -```yaml -name: secure-app -service: secure-app -port: 8443 -maxFails: 3 -maxConns: 100 -failTimeout: 30s -loadBalancingMethod: least_conn -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the upstream. Must be a valid DNS label as defined in RFC 1035. For example, ``hello`` and ``upstream-123`` are valid. The name must be unique among all upstreams of the resource. | ``string`` | Yes | -|``service`` | The name of a [service](https://kubernetes.io/docs/concepts/services-networking/service/). The service must belong to the same namespace as the resource. If the service doesn't exist, NGINX will assume the service has zero endpoints and close client connections/ignore datagrams. | ``string`` | Yes | -|``port`` | The port of the service. If the service doesn't define that port, NGINX will assume the service has zero endpoints and close client connections/ignore datagrams. The port must fall into the range ``1..65535``. | ``int`` | Yes | -|``maxFails`` | Sets the [number](https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#max_fails) of unsuccessful attempts to communicate with the server that should happen in the duration set by the failTimeout parameter to consider the server unavailable. The default ``1``. | ``int`` | No | -|``maxConns`` | Sets the [number](https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#max_conns) of maximum connections to the proxied server. Default value is zero, meaning there is no limit. The default is ``0``. | ``int`` | No | -|``failTimeout`` | Sets the [time](https://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#fail_timeout) during which the specified number of unsuccessful attempts to communicate with the server should happen to consider the server unavailable and the period of time the server will be considered unavailable. The default is ``10s``. | ``string`` | No | -|``healthCheck`` | The health check configuration for the Upstream. See the [health_check](https://nginx.org/en/docs/stream/ngx_stream_upstream_hc_module.html#health_check) directive. Note: this feature is supported only in NGINX Plus. | [healthcheck](#upstreamhealthcheck) | No | -|``loadBalancingMethod`` | The method used to load balance the upstream servers. By default, connections are distributed between the servers using a weighted round-robin balancing method. See the [upstream](http://nginx.org/en/docs/stream/ngx_stream_upstream_module.html#upstream) section for available methods and their details. | ``string`` | No | -|``backup`` | The name of the backup service of type [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname). This will be used when the primary servers are unavailable. Note: The parameter cannot be used along with the ``random`` , ``hash`` or ``ip_hash`` load balancing methods. | ``string`` | No | -|``backupPort`` | The port of the backup service. The backup port is required if the backup service name is provided. The port must fall into the range ``1..65535``. | ``uint16`` | No | -{{% /table %}} - -### Upstream.Healthcheck - -The Healthcheck defines an [active health check](https://nginx.org/en/docs/stream/ngx_stream_upstream_hc_module.html?#health_check). In the example below we enable a health check for an upstream and configure all the available parameters: - -```yaml -name: secure-app -service: secure-app -port: 8443 -healthCheck: - enable: true - interval: 20s - timeout: 30s - jitter: 3s - fails: 5 - passes: 5 - port: 8080 -``` - -Note: This feature is supported only in NGINX Plus. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables a health check for an upstream server. The default is ``false``. | ``boolean`` | No | -|``interval`` | The interval between two consecutive health checks. The default is ``5s``. | ``string`` | No | -|``timeout`` | This overrides the timeout set by [proxy_timeout](http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_timeout) which is set in `SessionParameters` for health checks. The default value is ``5s``. | ``string`` | No | -|``jitter`` | The time within which each health check will be randomly delayed. By default, there is no delay. | ``string`` | No | -|``fails`` | The number of consecutive failed health checks of a particular upstream server after which this server will be considered unhealthy. The default is ``1``. | ``integer`` | No | -|``passes`` | The number of consecutive passed health checks of a particular upstream server after which the server will be considered healthy. The default is ``1``. | ``integer`` | No | -|``port`` | The port used for health check requests. By default, the [server port is used](https://nginx.org/en/docs/stream/ngx_stream_upstream_hc_module.html#health_check_port). Note: in contrast with the port of the upstream, this port is not a service port, but a port of a pod. | ``integer`` | No | -|``match`` | Controls the data to send and the response to expect for the healthcheck. | [match](#upstreamhealthcheckmatch) | No | -{{% /table %}} - -### Upstream.Healthcheck.Match - -The match controls the data to send and the response to expect for the healthcheck: - -```yaml -match: - send: 'GET / HTTP/1.0\r\nHost: localhost\r\n\r\n' - expect: "~200 OK" -``` - -Both `send` and `expect` fields can contain hexadecimal literals with the prefix `\x` followed by two hex digits, for example, `\x80`. - -See the [match](https://nginx.org/en/docs/stream/ngx_stream_upstream_hc_module.html#match) directive for details. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``send`` | A string to send to an upstream server. | ``string`` | No | -|``expect`` | A literal string or a regular expression that the data obtained from the server should match. The regular expression is specified with the preceding ``~*`` modifier (for case-insensitive matching), or the ``~`` modifier (for case-sensitive matching). The Ingress Controller validates a regular expression using the RE2 syntax. | ``string`` | No | -{{% /table %}} - -### UpstreamParameters - -The upstream parameters define various parameters for the upstreams: - -```yaml -upstreamParameters: - udpRequests: 1 - udpResponses: 1 - connectTimeout: 60s - nextUpstream: true - nextUpstreamTimeout: 50s - nextUpstreamTries: 1 -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``udpRequests`` | The number of datagrams, after receiving which, the next datagram from the same client starts a new session. See the [proxy_requests](https://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_requests) directive. The default is ``0``. | ``int`` | No | -|``udpResponses`` | The number of datagrams expected from the proxied server in response to a client datagram. See the [proxy_responses](https://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_responses) directive. By default, the number of datagrams is not limited. | ``int`` | No | -|``connectTimeout`` | The timeout for establishing a connection with a proxied server. See the [proxy_connect_timeout](http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_connect_timeout) directive. The default is ``60s``. | ``string`` | No | -|``nextUpstream`` | If a connection to the proxied server cannot be established, determines whether a client connection will be passed to the next server. See the [proxy_next_upstream](http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_next_upstream) directive. The default is ``true``. | bool | No | -|``nextUpstreamTries`` | The number of tries for passing a connection to the next server. See the [proxy_next_upstream_tries](http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_next_upstream_tries) directive. The default is ``0``. | ``int`` | No | -|``nextUpstreamTimeout`` | The time allowed to pass a connection to the next server. See the [proxy_next_upstream_timeout](http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_next_upstream_timeout) directive. The default us ``0``. | ``string`` | No | -{{% /table %}} - -### SessionParameters - -The session parameters define various parameters for TCP connections and UDP sessions. - -```yaml -sessionParameters: - timeout: 50s -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``timeout`` | The timeout between two successive read or write operations on client or proxied server connections. See [proxy_timeout](http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_timeout) directive. The default is ``10m``. | ``string`` | No | -{{% /table %}} - -### Action - -The action defines an action to perform for a client connection/datagram. - -In the example below, client connections/datagrams are passed to an upstream `dns-app`: - -```yaml -action: - pass: dns-app -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``pass`` | Passes connections/datagrams to an upstream. The upstream with that name must be defined in the resource. | ``string`` | Yes | -{{% /table %}} - -## Using TransportServer - -You can use the usual `kubectl` commands to work with TransportServer resources, similar to Ingress resources. - -For example, the following command creates a TransportServer resource defined in `transport-server-passthrough.yaml` with the name `secure-app`: - -```shell -kubectl apply -f transport-server-passthrough.yaml - -transportserver.k8s.nginx.org/secure-app created -``` - -You can get the resource by running: - -```shell -kubectl get transportserver secure-app - -NAME AGE -secure-app 46sm -``` - -In the kubectl get and similar commands, you can also use the short name `ts` instead of `transportserver`. - -### Using Snippets - -Snippets allow you to insert raw NGINX config into different contexts of NGINX configuration. In the example below, we use snippets to configure [access control](http://nginx.org/en/docs/stream/ngx_stream_access_module.html) in a TransportServer: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: TransportServer -metadata: - name: cafe -spec: - host: cafe.example.com - serverSnippets: | - deny 192.168.1.1; - allow 192.168.1.0/24; - upstreams: - - name: tea - service: tea-svc - port: 80 -``` - -Snippets can also be specified for a stream. In the example below, we use snippets to [limit the number of connections](https://nginx.org/en/docs/stream/ngx_stream_limit_conn_module.html): - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: TransportServer -metadata: - name: cafe -spec: - host: cafe.example.com - streamSnippets: limit_conn_zone $binary_remote_addr zone=addr:10m; - serverSnippets: limit_conn addr 1; - upstreams: - - name: tea - service: tea-svc - port: 80 -``` - -Snippets are intended to be used by advanced NGINX users who need more control over the generated NGINX configuration. - -However, because of the disadvantages described below, snippets are disabled by default. To use snippets, set the [`enable-snippets`](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments#cmdoption-enable-snippets) command-line argument. - -Disadvantages of using snippets: - -- *Complexity*. To use snippets, you will need to: - - Understand NGINX configuration primitives and implement a correct NGINX configuration. - - Understand how the IC generates NGINX configuration so that a snippet doesn't interfere with the other features in the configuration. -- *Decreased robustness*. An incorrect snippet makes the NGINX config invalid which will lead to a failed reload. This will prevent any new configuration updates, including updates for the other TransportServer resource until the snippet is fixed. -- *Security implications*. Snippets give access to NGINX configuration primitives and those primitives are not validated by the Ingress Controller. - -> Note: during a period when the NGINX config includes an invalid snippet, NGINX will continue to operate with the latest valid configuration. - -> Note: to configure snippets in the `stream` context, use `stream-snippets` ConfigMap key. - -### Validation - -Two types of validation are available for the TransportServer resource: - -- *Structural validation* by the `kubectl` and Kubernetes API server. -- *Comprehensive validation* by the Ingress Controller. - -#### Structural Validation - -The custom resource definition for the TransportServer includes structural OpenAPI schema which describes the type of every field of the resource. - -If you try to create (or update) a resource that violates the structural schema (for example, you use a string value for the port field of an upstream), `kubectl` and Kubernetes API server will reject such a resource: - -- Example of `kubectl` validation: - - ```shell - kubectl apply -f transport-server-passthrough.yaml - - error: error validating "transport-server-passthrough.yaml": error validating data: ValidationError(TransportServer.spec.upstreams[0].port): invalid type for org.nginx.k8s.v1.TransportServer.spec.upstreams.port: got "string", expected "integer"; if you choose to ignore these errors, turn validation off with --validate=false - ``` - -- Example of Kubernetes API server validation: - - ```shell - kubectl apply -f transport-server-passthrough.yaml --validate=false - - The TransportServer "secure-app" is invalid: []: Invalid value: map[string]interface {}{ ... }: validation failure list: - spec.upstreams.port in body must be of type integer: "string" - ``` - -If a resource is not rejected (it doesn't violate the structural schema), the Ingress Controller will validate it further. - -#### Comprehensive Validation - -The Ingress Controller validates the fields of a TransportServer resource. If a resource is invalid, the Ingress Controller will reject it: the resource will continue to exist in the cluster, but the Ingress Controller will ignore it. - -You can check if the Ingress Controller successfully applied the configuration for a TransportServer. For our example `secure-app` TransportServer, we can run: - -```shell -kubectl describe ts secure-app - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 3s nginx-ingress-controller Configuration for default/secure-app was added or updated -``` - -Note how the events section includes a Normal event with the AddedOrUpdated reason that informs us that the configuration was successfully applied. - -If you create an invalid resource, the Ingress Controller will reject it and emit a Rejected event. For example, if you create a TransportServer `secure-app` with a pass action that references a non-existing upstream, you will get : - -```shell -kubectl describe ts secure-app - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 2s nginx-ingress-controller TransportServer default/secure-app is invalid and was rejected: spec.action.pass: Not found: "some-app" -``` - -Note how the events section includes a Warning event with the Rejected reason. - -**Note**: If you make an existing resource invalid, the Ingress Controller will reject it and remove the corresponding configuration from NGINX. - -## Customization via ConfigMap - -The [ConfigMap](/nginx-ingress-controller/configuration/global-configuration/configmap-resource) keys (except for `stream-snippets`, `stream-log-format`, `resolver-addresses`, `resolver-ipv6`, `resolver-valid` and `resolver-timeout`) do not affect TransportServer resources. diff --git a/docs/content/configuration/virtualserver-and-virtualserverroute-resources.md b/docs/content/configuration/virtualserver-and-virtualserverroute-resources.md deleted file mode 100644 index 2cc77b556d..0000000000 --- a/docs/content/configuration/virtualserver-and-virtualserverroute-resources.md +++ /dev/null @@ -1,1106 +0,0 @@ ---- -docs: DOCS-599 -doctypes: -- '' -title: VirtualServer and VirtualServerRoute Resources -toc: true -weight: 1600 ---- - -VirtualServer and VirtualServerRoute resources are load balancing configurations recommended as an alternative to the Ingress resource. - -They enable use cases not supported with the Ingress resource, such as traffic splitting and advanced content-based routing. The resources are implemented as [Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - -This document is the reference documentation for the resources. To see additional examples of using the resources for specific use cases, go to the [examples/custom-resources](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources) folder in our GitHub repo. - -## VirtualServer Specification - -The VirtualServer resource defines load balancing configuration for a domain name, such as `example.com`. Below is an example of such configuration: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: VirtualServer -metadata: - name: cafe -spec: - host: cafe.example.com - listener: - http: http-8083 - https: https-8443 - tls: - secret: cafe-secret - gunzip: on - upstreams: - - name: tea - service: tea-svc - port: 80 - - name: coffee - service: coffee-svc - port: 80 - routes: - - path: /tea - action: - pass: tea - - path: /coffee - action: - pass: coffee - - path: ~ ^/decaf/.*\\.jpg$ - action: - pass: coffee - - path: = /green/tea - action: - pass: tea -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``host`` | The host (domain name) of the server. Must be a valid subdomain as defined in RFC 1123, such as ``my-app`` or ``hello.example.com``. When using a wildcard domain like ``*.example.com`` the domain must be contained in double quotes. The ``host`` value needs to be unique among all Ingress and VirtualServer resources. See also [Handling Host and Listener Collisions](/nginx-ingress-controller/configuration/handling-host-and-listener-collisions). | ``string`` | Yes | -|``listener`` | Sets a custom HTTP and/or HTTPS listener. Valid fields are `listener.http` and `listener.https`. Each field must reference the name of a valid listener defined in a GlobalConfiguration resource | [listener](#virtualserverlistener) | No | -|``tls`` | The TLS termination configuration. | [tls](#virtualservertls) | No | -|``gunzip`` | Enables or disables [decompression](https://docs.nginx.com/nginx/admin-guide/web-server/compression/) of gzipped responses for clients. Allowed values “on”/“off”, “true”/“false” or “yes”/“no”. If the ``gunzip`` value is not set, it defaults to ``off``. | ``boolean`` | No | -|``externalDNS`` | The externalDNS configuration for a VirtualServer. | [externalDNS](#virtualserverexternaldns) | No | -|``dos`` | A reference to a DosProtectedResource, setting this enables DOS protection of the VirtualServer. | ``string`` | No | -|``policies`` | A list of policies. | [[]policy](#virtualserverpolicy) | No | -|``upstreams`` | A list of upstreams. | [[]upstream](#upstream) | No | -|``routes`` | A list of routes. | [[]route](#virtualserverroute) | No | -|``ingressClassName`` | Specifies which Ingress Controller must handle the VirtualServer resource. | ``string`` | No | -|``internalRoute`` | Specifies if the VirtualServer resource is an internal route or not. | ``boolean`` | No | -|``http-snippets`` | Sets a custom snippet in the http context. | ``string`` | No | -|``server-snippets`` | Sets a custom snippet in server context. Overrides the ``server-snippets`` ConfigMap key. | ``string`` | No | -{{% /table %}} - -### VirtualServer.TLS - -The tls field defines TLS configuration for a VirtualServer. For example: - -```yaml -secret: cafe-secret -redirect: - enable: true -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``secret`` | The name of a secret with a TLS certificate and key. The secret must belong to the same namespace as the VirtualServer. The secret must be of the type ``kubernetes.io/tls`` and contain keys named ``tls.crt`` and ``tls.key`` that contain the certificate and private key as described [here](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls). If the secret doesn't exist or is invalid, NGINX will break any attempt to establish a TLS connection to the host of the VirtualServer. If the secret is not specified but [wildcard TLS secret](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments#cmdoption-wildcard-tls-secret) is configured, NGINX will use the wildcard secret for TLS termination. | ``string`` | No | -|``redirect`` | The redirect configuration of the TLS for a VirtualServer. | [tls.redirect](#virtualservertlsredirect) | No | ### VirtualServer.TLS.Redirect | -|``cert-manager`` | The cert-manager configuration of the TLS for a VirtualServer. | [tls.cert-manager](#virtualservertlscertmanager) | No | ### VirtualServer.TLS.CertManager | -{{% /table %}} - -### VirtualServer.TLS.Redirect - -The redirect field configures a TLS redirect for a VirtualServer: - -```yaml -enable: true -code: 301 -basedOn: scheme -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables a TLS redirect for a VirtualServer. The default is ``False``. | ``boolean`` | No | -|``code`` | The status code of a redirect. The allowed values are: ``301`` , ``302`` , ``307`` , ``308``. The default is ``301``. | ``int`` | No | -|``basedOn`` | The attribute of a request that NGINX will evaluate to send a redirect. The allowed values are ``scheme`` (the scheme of the request) or ``x-forwarded-proto`` (the ``X-Forwarded-Proto`` header of the request). The default is ``scheme``. | ``string`` | No | ### VirtualServer.Policy | -{{% /table %}} - -### VirtualServer.TLS.CertManager - -The cert-manager field configures x509 automated Certificate management for VirtualServer resources using cert-manager (cert-manager.io). Please see the [cert-manager configuration documentation](https://cert-manager.io/docs/configuration/) for more information on deploying and configuring Issuers. Example: - -```yaml -cert-manager: - cluster-issuer: "my-issuer-name" -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``issuer`` | the name of an Issuer. An Issuer is a cert-manager resource which describes the certificate authority capable of signing certificates. The Issuer must be in the same namespace as the VirtualServer resource. Please note that one of `issuer` and `cluster-issuer` are required, but they are mutually exclusive - one and only one must be defined. | ``string`` | No | -|``cluster-issuer`` | the name of a ClusterIssuer. A ClusterIssuer is a cert-manager resource which describes the certificate authority capable of signing certificates. It does not matter which namespace your VirtualServer resides, as ClusterIssuers are non-namespaced resources. Please note that one of `issuer` and `cluster-issuer` are required, but they are mutually exclusive - one and only one must be defined. | ``string`` | No | -|``issuer-kind`` | The kind of the external issuer resource, for example AWSPCAIssuer. This is only necessary for out-of-tree issuers. This cannot be defined if `cluster-issuer` is also defined. | ``string`` | No | -|``issuer-group`` | The API group of the external issuer controller, for example awspca.cert-manager.io. This is only necessary for out-of-tree issuers. This cannot be defined if `cluster-issuer` is also defined. | ``string`` | No | -|``common-name`` | This field allows you to configure spec.commonName for the Certificate to be generated. This configuration adds a CN to the x509 certificate. | ``string`` | No | -|``duration`` | This field allows you to configure spec.duration field for the Certificate to be generated. Must be specified using a [Go time.Duration](https://pkg.go.dev/time#ParseDuration) string format, which does not allow the d (days) suffix. You must specify these values using s, m, and h suffixes instead. | ``string`` | No | -|``renew-before`` | this annotation allows you to configure spec.renewBefore field for the Certificate to be generated. Must be specified using a [Go time.Duration](https://pkg.go.dev/time#ParseDuration) string format, which does not allow the d (days) suffix. You must specify these values using s, m, and h suffixes instead. | ``string`` | No | -|``usages`` | This field allows you to configure spec.usages field for the Certificate to be generated. Pass a string with comma-separated values i.e. ``key agreement,digital signature, server auth``. An exhaustive list of supported key usages can be found in the [the cert-manager api documentation](https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.KeyUsage). | ``string`` | No | -|``issue-temp-cert`` | When ``true``, ask cert-manager for a [temporary self-signed certificate](https://cert-manager.io/docs/usage/certificate/#temporary-certificates-while-issuing) pending the issuance of the Certificate. This allows HTTPS-only servers to use ACME HTTP01 challenges when the TLS secret does not exist yet. | ``boolean`` | No | -{{% /table %}} - -### VirtualServer.Listener -The listener field defines a custom HTTP and/or HTTPS listener. -The respective listeners used must reference the name of a listener defined using a [GlobalConfiguration](/nginx-ingress-controller/configuration/global-configuration/globalconfiguration-resource/) resource. -For example: -```yaml -http: http-8083 -https: https-8443 -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``http`` | The name of am HTTP listener defined in a [GlobalConfiguration](/nginx-ingress-controller/configuration/global-configuration/globalconfiguration-resource/) resource. | ``string`` | No | -|``https`` | The name of an HTTPS listener defined in a [GlobalConfiguration](/nginx-ingress-controller/configuration/global-configuration/globalconfiguration-resource/) resource. | ``string`` | No | -{{% /table %}} - -### VirtualServer.ExternalDNS - -The externalDNS field configures controlling DNS records dynamically for VirtualServer resources using [ExternalDNS](https://github.com/kubernetes-sigs/external-dns). Please see the [ExternalDNS configuration documentation](https://kubernetes-sigs.github.io/external-dns/v0.12.0/) for more information on deploying and configuring ExternalDNS and Providers. Example: - -```yaml -enable: true -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables ExternalDNS integration for a VirtualServer resource. The default is ``false``. | ``string`` | No | -|``labels`` | Configure labels to be applied to the Endpoint resources that will be consumed by ExternalDNS. | ``map[string]string`` | No | -|``providerSpecific`` | Configure provider specific properties which holds the name and value of a configuration which is specific to individual DNS providers. | [[]ProviderSpecific](#virtualserverexternaldnsproviderspecific) | No | -|``recordTTL`` | TTL for the DNS record. This defaults to 0 if not defined. See [the ExternalDNS TTL documentation for provider-specific defaults](https://kubernetes-sigs.github.io/external-dns/v0.12.0/ttl/#providers) | ``int64`` | No | -|``recordType`` | The record Type that should be created, e.g. "A", "AAAA", "CNAME". This is automatically computed based on the external endpoints if not defined. | ``string`` | No | -{{% /table %}} - -### VirtualServer.ExternalDNS.ProviderSpecific - -The providerSpecific field of the externalDNS block allows the specification of provider specific properties which is a list of key value pairs of configurations which are specific to individual DNS providers. Example: - -```yaml -- name: my-name - value: my-value -- name: my-name2 - value: my-value2 -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the key value pair. | ``string`` | Yes | -|``value`` | The value of the key value pair. | ``string`` | Yes | -{{% /table %}} - -### VirtualServer.Policy - -The policy field references a [Policy resource](/nginx-ingress-controller/configuration/policy-resource/) by its name and optional namespace. For example: - -```yaml -name: access-control -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of a policy. If the policy doesn't exist or invalid, NGINX will respond with an error response with the `500` status code. | ``string`` | Yes | -|``namespace`` | The namespace of a policy. If not specified, the namespace of the VirtualServer resource is used. | ``string`` | No | -{{% /table %}} - -### VirtualServer.Route - -The route defines rules for matching client requests to actions like passing a request to an upstream. For example: - -```yaml - path: /tea - action: - pass: tea -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``path`` | The path of the route. NGINX will match it against the URI of a request. Possible values are: a prefix ( ``/`` , ``/path`` ), an exact match ( ``=/exact/match`` ), a case insensitive regular expression ( ``~*^/Bar.*\.jpg`` ) or a case sensitive regular expression ( ``~^/foo.*\.jpg`` ). In the case of a prefix (must start with ``/`` ) or an exact match (must start with ``=`` ), the path must not include any whitespace characters, ``{`` , ``}`` or ``;``. In the case of the regex matches, all double quotes ``"`` must be escaped and the match can't end in an unescaped backslash ``\``. The path must be unique among the paths of all routes of the VirtualServer. Check the [location](https://nginx.org/en/docs/http/ngx_http_core_module.html#location) directive for more information. | ``string`` | Yes | -|``policies`` | A list of policies. The policies override the policies of the same type defined in the ``spec`` of the VirtualServer. See [Applying Policies](/nginx-ingress-controller/configuration/policy-resource/#applying-policies) for more details. | [[]policy](#virtualserverpolicy) | No | -|``action`` | The default action to perform for a request. | [action](#action) | No | -|``dos`` | A reference to a DosProtectedResource, setting this enables DOS protection of the VirtualServer route. | ``string`` | No | -|``splits`` | The default splits configuration for traffic splitting. Must include at least 2 splits. | [[]split](#split) | No | -|``matches`` | The matching rules for advanced content-based routing. Requires the default ``action`` or ``splits``. Unmatched requests will be handled by the default ``action`` or ``splits``. | [matches](#match) | No | -|``route`` | The name of a VirtualServerRoute resource that defines this route. If the VirtualServerRoute belongs to a different namespace than the VirtualServer, you need to include the namespace. For example, ``tea-namespace/tea``. | ``string`` | No | -|``errorPages`` | The custom responses for error codes. NGINX will use those responses instead of returning the error responses from the upstream servers or the default responses generated by NGINX. A custom response can be a redirect or a canned response. For example, a redirect to another URL if an upstream server responded with a 404 status code. | [[]errorPage](#errorpage) | No | -|``location-snippets`` | Sets a custom snippet in the location context. Overrides the ``location-snippets`` ConfigMap key. | ``string`` | No | -{{% /table %}} - -\* -- a route must include exactly one of the following: `action`, `splits`, or `route`. - -## VirtualServerRoute Specification - -The VirtualServerRoute resource defines a route for a VirtualServer. It can consist of one or multiple subroutes. The VirtualServerRoute is an alternative to [Mergeable Ingress types](/nginx-ingress-controller/configuration/ingress-resources/cross-namespace-configuration). - -In the example below, the VirtualServer `cafe` from the namespace `cafe-ns` defines a route with the path `/coffee`, which is further defined in the VirtualServerRoute `coffee` from the namespace `coffee-ns`. - -VirtualServer: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: VirtualServer -metadata: - name: cafe - namespace: cafe-ns -spec: - host: cafe.example.com - upstreams: - - name: tea - service: tea-svc - port: 80 - routes: - - path: /tea - action: - pass: tea - - path: /coffee - route: coffee-ns/coffee -``` - -VirtualServerRoute: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: VirtualServerRoute -metadata: - name: coffee - namespace: coffee-ns -spec: - host: cafe.example.com - upstreams: - - name: latte - service: latte-svc - port: 80 - - name: espresso - service: espresso-svc - port: 80 - subroutes: - - path: /coffee/latte - action: - pass: latte - - path: /coffee/espresso - action: - pass: espresso -``` - -Note that each subroute must have a `path` that starts with the same prefix (here `/coffee`), which is defined in the route of the VirtualServer. Additionally, the `host` in the VirtualServerRoute must be the same as the `host` of the VirtualServer. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``host`` | The host (domain name) of the server. Must be a valid subdomain as defined in RFC 1123, such as ``my-app`` or ``hello.example.com``. When using a wildcard domain like ``*.example.com`` the domain must be contained in double quotes. Must be the same as the ``host`` of the VirtualServer that references this resource. | ``string`` | Yes | -|``upstreams`` | A list of upstreams. | [[]upstream](#upstream) | No | -|``subroutes`` | A list of subroutes. | [[]subroute](#virtualserverroutesubroute) | No | -|``ingressClassName`` | Specifies which Ingress Controller must handle the VirtualServerRoute resource. Must be the same as the ``ingressClassName`` of the VirtualServer that references this resource. | ``string``_ | No | -{{% /table %}} - -### VirtualServerRoute.Subroute - -The subroute defines rules for matching client requests to actions like passing a request to an upstream. For example: - -```yaml -path: /coffee -action: - pass: coffee -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``path`` | The path of the subroute. NGINX will match it against the URI of a request. Possible values are: a prefix ( ``/`` , ``/path`` ), an exact match ( ``=/exact/match`` ), a case insensitive regular expression ( ``~*^/Bar.*\.jpg`` ) or a case sensitive regular expression ( ``~^/foo.*\.jpg`` ). In the case of a prefix, the path must start with the same path as the path of the route of the VirtualServer that references this resource. In the case of an exact or regex match, the path must be the same as the path of the route of the VirtualServer that references this resource. A matching path of the route of the VirtualServer but in different type is not accepted, e.g. a regex path (`~/match`) cannot be used with a prefix path in VirtualServer (`/match`) In the case of a prefix or an exact match, the path must not include any whitespace characters, ``{`` , ``}`` or ``;``. In the case of the regex matches, all double quotes ``"`` must be escaped and the match can't end in an unescaped backslash ``\``. The path must be unique among the paths of all subroutes of the VirtualServerRoute. | ``string`` | Yes | -|``policies`` | A list of policies. The policies override *all* policies defined in the route of the VirtualServer that references this resource. The policies also override the policies of the same type defined in the ``spec`` of the VirtualServer. See [Applying Policies](/nginx-ingress-controller/configuration/policy-resource/#applying-policies) for more details. | [[]policy](#virtualserverpolicy) | No | -|``action`` | The default action to perform for a request. | [action](#action) | No | -|``dos`` | A reference to a DosProtectedResource, setting this enables DOS protection of the VirtualServerRoute subroute. | ``string`` | No | -|``splits`` | The default splits configuration for traffic splitting. Must include at least 2 splits. | [[]split](#split) | No | -|``matches`` | The matching rules for advanced content-based routing. Requires the default ``action`` or ``splits``. Unmatched requests will be handled by the default ``action`` or ``splits``. | [matches](#match) | No | -|``errorPages`` | The custom responses for error codes. NGINX will use those responses instead of returning the error responses from the upstream servers or the default responses generated by NGINX. A custom response can be a redirect or a canned response. For example, a redirect to another URL if an upstream server responded with a 404 status code. | [[]errorPage](#errorpage) | No | -|``location-snippets`` | Sets a custom snippet in the location context. Overrides the ``location-snippets`` of the VirtualServer (if set) or the ``location-snippets`` ConfigMap key. | ``string`` | No | -{{% /table %}} - -\* -- a subroute must include exactly one of the following: `action` or `splits`. - -## Common Parts of the VirtualServer and VirtualServerRoute - -### Upstream - -The upstream defines a destination for the routing configuration. For example: - -```yaml -name: tea -service: tea-svc -subselector: - version: canary -port: 80 -lb-method: round_robin -fail-timeout: 10s -max-fails: 1 -max-conns: 32 -keepalive: 32 -connect-timeout: 30s -read-timeout: 30s -send-timeout: 30s -next-upstream: "error timeout non_idempotent" -next-upstream-timeout: 5s -next-upstream-tries: 10 -client-max-body-size: 2m -tls: - enable: true -``` - -**Note**: The WebSocket protocol is supported without any additional configuration. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the upstream. Must be a valid DNS label as defined in RFC 1035. For example, ``hello`` and ``upstream-123`` are valid. The name must be unique among all upstreams of the resource. | ``string`` | Yes | -|``service`` | The name of a [service](https://kubernetes.io/docs/concepts/services-networking/service/). The service must belong to the same namespace as the resource. If the service doesn't exist, NGINX will assume the service has zero endpoints and return a ``502`` response for requests for this upstream. For NGINX Plus only, services of type [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) are also supported (check the [prerequisites](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/externalname-services#prerequisites) ). | ``string`` | Yes | -|``subselector`` | Selects the pods within the service using label keys and values. By default, all pods of the service are selected. Note: the specified labels are expected to be present in the pods when they are created. If the pod labels are updated, the Ingress Controller will not see that change until the number of the pods is changed. | ``map[string]string`` | No | -|``use-cluster-ip`` | Enables using the Cluster IP and port of the service instead of the default behavior of using the IP and port of the pods. When this field is enabled, the fields that configure NGINX behavior related to multiple upstream servers (like ``lb-method`` and ``next-upstream``) will have no effect, as NGINX Ingress Controller will configure NGINX with only one upstream server that will match the service Cluster IP. | ``boolean`` | No | -|``port`` | The port of the service. If the service doesn't define that port, NGINX will assume the service has zero endpoints and return a ``502`` response for requests for this upstream. The port must fall into the range ``1..65535``. | ``uint16`` | Yes | -|``lb-method`` | The load [balancing method](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#choosing-a-load-balancing-method). To use the round-robin method, specify ``round_robin``. The default is specified in the ``lb-method`` ConfigMap key. | ``string`` | No | -|``fail-timeout`` | The time during which the specified number of unsuccessful attempts to communicate with an upstream server should happen to consider the server unavailable. See the [fail_timeout](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#fail_timeout) parameter of the server directive. The default is set in the ``fail-timeout`` ConfigMap key. | ``string`` | No | -|``max-fails`` | The number of unsuccessful attempts to communicate with an upstream server that should happen in the duration set by the ``fail-timeout`` to consider the server unavailable. See the [max_fails](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_fails) parameter of the server directive. The default is set in the ``max-fails`` ConfigMap key. | ``int`` | No | -|``max-conns`` | The maximum number of simultaneous active connections to an upstream server. See the [max_conns](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#max_conns) parameter of the server directive. By default there is no limit. Note: if keepalive connections are enabled, the total number of active and idle keepalive connections to an upstream server may exceed the ``max_conns`` value. | ``int`` | No | -|``keepalive`` | Configures the cache for connections to upstream servers. The value ``0`` disables the cache. See the [keepalive](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive) directive. The default is set in the ``keepalive`` ConfigMap key. | ``int`` | No | -|``connect-timeout`` | The timeout for establishing a connection with an upstream server. See the [proxy_connect_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout) directive. The default is specified in the ``proxy-connect-timeout`` ConfigMap key. | ``string`` | No | -|``read-timeout`` | The timeout for reading a response from an upstream server. See the [proxy_read_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) directive. The default is specified in the ``proxy-read-timeout`` ConfigMap key. | ``string`` | No | -|``send-timeout`` | The timeout for transmitting a request to an upstream server. See the [proxy_send_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) directive. The default is specified in the ``proxy-send-timeout`` ConfigMap key. | ``string`` | No | -|``next-upstream`` | Specifies in which cases a request should be passed to the next upstream server. See the [proxy_next_upstream](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream) directive. The default is ``error timeout``. | ``string`` | No | -|``next-upstream-timeout`` | The time during which a request can be passed to the next upstream server. See the [proxy_next_upstream_timeout](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_timeout) directive. The ``0`` value turns off the time limit. The default is ``0``. | ``string`` | No | -|``next-upstream-tries`` | The number of possible tries for passing a request to the next upstream server. See the [proxy_next_upstream_tries](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_tries) directive. The ``0`` value turns off this limit. The default is ``0``. | ``int`` | No | -|``client-max-body-size`` | Sets the maximum allowed size of the client request body. See the [client_max_body_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) directive. The default is set in the ``client-max-body-size`` ConfigMap key. | ``string`` | No | -|``tls`` | The TLS configuration for the Upstream. | [tls](#upstreamtls) | No | -|``healthCheck`` | The health check configuration for the Upstream. See the [health_check](https://nginx.org/en/docs/http/ngx_http_upstream_hc_module.html#health_check) directive. Note: this feature is supported only in NGINX Plus. | [healthcheck](#upstreamhealthcheck) | No | -|``slow-start`` | The slow start allows an upstream server to gradually recover its weight from 0 to its nominal value after it has been recovered or became available or when the server becomes available after a period of time it was considered unavailable. By default, the slow start is disabled. See the [slow_start](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#slow_start) parameter of the server directive. Note: The parameter cannot be used along with the ``random`` , ``hash`` or ``ip_hash`` load balancing methods and will be ignored. | ``string`` | No | -|``queue`` | Configures a queue for an upstream. A client request will be placed into the queue if an upstream server cannot be selected immediately while processing the request. By default, no queue is configured. Note: this feature is supported only in NGINX Plus. | [queue](#upstreamqueue) | No | -|``buffering`` | Enables buffering of responses from the upstream server. See the [proxy_buffering](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering) directive. The default is set in the ``proxy-buffering`` ConfigMap key. | ``boolean`` | No | -|``buffers`` | Configures the buffers used for reading a response from the upstream server for a single connection. | [buffers](#upstreambuffers) | No | -|``buffer-size`` | Sets the size of the buffer used for reading the first part of a response received from the upstream server. See the [proxy_buffer_size](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) directive. The default is set in the ``proxy-buffer-size`` ConfigMap key. | ``string`` | No | -|``ntlm`` | Allows proxying requests with NTLM Authentication. See the [ntlm](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ntlm) directive. In order for NTLM authentication to work, it is necessary to enable keepalive connections to upstream servers using the ``keepalive`` field. Note: this feature is supported only in NGINX Plus.| ``boolean`` | No | -|``type`` |The type of the upstream. Supported values are ``http`` and ``grpc``. The default is ``http``. For gRPC, it is necessary to enable HTTP/2 in the [ConfigMap](/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#listeners) and configure TLS termination in the VirtualServer. | ``string`` | No | -|``backup`` | The name of the backup service of type [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname). This will be used when the primary servers are unavailable. Note: The parameter cannot be used along with the ``random`` , ``hash`` or ``ip_hash`` load balancing methods. | ``string`` | No | -|``backupPort`` | The port of the backup service. The backup port is required if the backup service name is provided. The port must fall into the range ``1..65535``. | ``uint16`` | No | -{{% /table %}} - -### Upstream.Buffers - -The buffers field configures the buffers used for reading a response from the upstream server for a single connection: - -```yaml -number: 4 -size: 8K -``` - -See the [proxy_buffers](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) directive for additional information. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``number`` | Configures the number of buffers. The default is set in the ``proxy-buffers`` ConfigMap key. | ``int`` | Yes | -|``size`` | Configures the size of a buffer. The default is set in the ``proxy-buffers`` ConfigMap key. | ``string`` | Yes | -{{% /table %}} - -### Upstream.TLS - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables HTTPS for requests to upstream servers. The default is ``False`` , meaning that HTTP will be used. Note: by default, NGINX will not verify the upstream server certificate. To enable the verification, configure an [EgressMTLS Policy](/nginx-ingress-controller/configuration/policy-resource/#egressmtls). | ``boolean`` | No | -{{% /table %}} - -### Upstream.Queue - -The queue field configures a queue. A client request will be placed into the queue if an upstream server cannot be selected immediately while processing the request: - -```yaml -size: 10 -timeout: 60s -``` - -See [`queue`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#queue) directive for additional information. - -Note: This feature is supported only in NGINX Plus. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``size`` | The size of the queue. | ``int`` | Yes | -|``timeout`` | The timeout of the queue. A request cannot be queued for a period longer than the timeout. The default is ``60s``. | ``string`` | No | -{{% /table %}} - -### Upstream.Healthcheck - -The Healthcheck defines an [active health check](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/). In the example below we enable a health check for an upstream and configure all the available parameters, including the `slow-start` parameter combined with [`mandatory` and `persistent`](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/#mandatory-health-checks): - -```yaml -name: tea -service: tea-svc -port: 80 -slow-start: 30s -healthCheck: - enable: true - path: /healthz - interval: 20s - jitter: 3s - fails: 5 - passes: 5 - port: 8080 - tls: - enable: true - connect-timeout: 10s - read-timeout: 10s - send-timeout: 10s - headers: - - name: Host - value: my.service - statusMatch: "! 500" - mandatory: true - persistent: true - keepalive-time: 60s -``` - -Note: This feature is supported only in NGINX Plus. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables a health check for an upstream server. The default is ``false``. | ``boolean`` | No | -|``path`` | The path used for health check requests. The default is ``/``. This not configurable for gRPC type upstreams. | ``string`` | No | -|``interval`` | The interval between two consecutive health checks. The default is ``5s``. | ``string`` | No | -|``jitter`` | The time within which each health check will be randomly delayed. By default, there is no delay. | ``string`` | No | -|``fails`` | The number of consecutive failed health checks of a particular upstream server after which this server will be considered unhealthy. The default is ``1``. | ``integer`` | No | -|``passes`` | The number of consecutive passed health checks of a particular upstream server after which the server will be considered healthy. The default is ``1``. | ``integer`` | No | -|``port`` | The port used for health check requests. By default, the [server port is used](https://nginx.org/en/docs/http/ngx_http_upstream_hc_module.html#health_check_port). Note: in contrast with the port of the upstream, this port is not a service port, but a port of a pod. | ``integer`` | No | -|``tls`` | The TLS configuration used for health check requests. By default, the ``tls`` field of the upstream is used. | [upstream.tls](#upstreamtls) | No | -|``connect-timeout`` | The timeout for establishing a connection with an upstream server. By default, the ``connect-timeout`` of the upstream is used. | ``string`` | No | -|``read-timeout`` | The timeout for reading a response from an upstream server. By default, the ``read-timeout`` of the upstream is used. | ``string`` | No | -|``send-timeout`` | The timeout for transmitting a request to an upstream server. By default, the ``send-timeout`` of the upstream is used. | ``string`` | No | -|``headers`` | The request headers used for health check requests. NGINX Plus always sets the ``Host`` , ``User-Agent`` and ``Connection`` headers for health check requests. | [[]header](#header) | No | -|``statusMatch`` | The expected response status codes of a health check. By default, the response should have status code 2xx or 3xx. Examples: ``"200"`` , ``"! 500"`` , ``"301-303 307"``. See the documentation of the [match](https://nginx.org/en/docs/http/ngx_http_upstream_hc_module.html?#match) directive. This not supported for gRPC type upstreams. | ``string`` | No | -|``grpcStatus`` | The expected [gRPC status code](https://github.com/grpc/grpc/blob/master/doc/statuscodes.md#status-codes-and-their-use-in-grpc) of the upstream server response to the [Check method](https://github.com/grpc/grpc/blob/master/doc/health-checking.md). Configure this field only if your gRPC services do not implement the gRPC health checking protocol. For example, configure ``12`` if the upstream server responds with `12 (UNIMPLEMENTED)` status code. Only valid on gRPC type upstreams. | ``int`` | No | -|``grpcService`` | The gRPC service to be monitored on the upstream server. Only valid on gRPC type upstreams. | ``string`` | No | -|``mandatory`` | Require every newly added server to pass all configured health checks before NGINX Plus sends traffic to it. If this is not specified, or is set to false, the server will be initially considered healthy. When combined with [slow-start](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#slow_start), it gives a new server more time to connect to databases and “warm up” before being asked to handle their full share of traffic. | ``bool`` | No | -|``persistent`` | Set the initial “up” state for a server after reload if the server was considered healthy before reload. Enabling persistent requires that the mandatory parameter is also set to `true`. | ``bool`` | No | -|``keepalive-time`` | Enables [keepalive](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive) connections for health checks and specifies the time during which requests can be processed through one keepalive connection. The default is ``60s``. | ``string`` | No | -{{% /table %}} - -### Upstream.SessionCookie - -The SessionCookie field configures session persistence which allows requests from the same client to be passed to the same upstream server. The information about the designated upstream server is passed in a session cookie generated by NGINX Plus. - -In the example below, we configure session persistence with a session cookie for an upstream and configure all the available parameters: - -```yaml -name: tea -service: tea-svc -port: 80 -sessionCookie: - enable: true - name: srv_id - path: / - expires: 1h - domain: .example.com - httpOnly: false - secure: true - samesite: strict -``` - -See the [`sticky`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html?#sticky) directive for additional information. The session cookie corresponds to the `sticky cookie` method. - -Note: This feature is supported only in NGINX Plus. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables session persistence with a session cookie for an upstream server. The default is ``false``. | ``boolean`` | No | -|``name`` | The name of the cookie. | ``string`` | Yes | -|``path`` | The path for which the cookie is set. | ``string`` | No | -|``expires`` | The time for which a browser should keep the cookie. Can be set to the special value ``max`` , which will cause the cookie to expire on ``31 Dec 2037 23:55:55 GMT``. | ``string`` | No | -|``domain`` | The domain for which the cookie is set. | ``string`` | No | -|``httpOnly`` | Adds the ``HttpOnly`` attribute to the cookie. | ``boolean`` | No | -|``secure`` | Adds the ``Secure`` attribute to the cookie. | ``boolean`` | No | -|``samesite`` | Adds the ``SameSite`` attribute to the cookie. The allowed values are: ``strict``, ``lax``, ``none`` | ``string`` | No | -{{% /table %}} - -### Header - -The header defines an HTTP Header: - -```yaml -name: Host -value: example.com -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the header. | ``string`` | Yes | -|``value`` | The value of the header. | ``string`` | No | -{{% /table %}} - -### Action - -The action defines an action to perform for a request. - -In the example below, client requests are passed to an upstream `coffee`: - -```yaml - path: /coffee - action: - pass: coffee -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``pass`` | Passes requests to an upstream. The upstream with that name must be defined in the resource. | ``string`` | No | -|``redirect`` | Redirects requests to a provided URL. | [action.redirect](#actionredirect) | No | -|``return`` | Returns a preconfigured response. | [action.return](#actionreturn) | No | -|``proxy`` | Passes requests to an upstream with the ability to modify the request/response (for example, rewrite the URI or modify the headers). | [action.proxy](#actionproxy) | No | -{{% /table %}} - -\* -- an action must include exactly one of the following: `pass`, `redirect`, `return` or `proxy`. - -### Action.Redirect - -The redirect action defines a redirect to return for a request. - -In the example below, client requests are passed to a url `http://www.nginx.com`: - -```yaml -redirect: - url: http://www.nginx.com - code: 301 -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``url`` | The URL to redirect the request to. Supported NGINX variables: ``$scheme`` , ``$http_x_forwarded_proto`` , ``$request_uri`` , ``$host``. Variables must be enclosed in curly braces. For example: ``${host}${request_uri}``. | ``string`` | Yes | -|``code`` | The status code of a redirect. The allowed values are: ``301`` , ``302`` , ``307`` , ``308``. The default is ``301``. | ``int`` | No | -{{% /table %}} - -### Action.Return - -The return action defines a preconfigured response for a request. - -In the example below, NGINX will respond with the preconfigured response for every request: - -```yaml -return: - code: 200 - type: text/plain - body: "Hello World\n" - headers: - - name: x-coffee - value: espresso -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``code`` | The status code of the response. The allowed values are: ``2XX``, ``4XX`` or ``5XX``. The default is ``200``. | ``int`` | No | -|``type`` | The MIME type of the response. The default is ``text/plain``. | ``string`` | No | -|``body`` | The body of the response. Supports NGINX variables*. Variables must be enclosed in curly brackets. For example: ``Request is ${request_uri}\n``. | ``string`` | Yes | -|``headers`` | The custom headers of the response. | [[]Action.Return.Header](#actionreturnheader) | No | -{{% /table %}} - -\* -- Supported NGINX variables: `$request_uri`, `$request_method`, `$request_body`, `$scheme`, `$http_`, `$args`, `$arg_`, `$cookie_`, `$host`, `$request_time`, `$request_length`, `$nginx_version`, `$pid`, `$connection`, `$remote_addr`, `$remote_port`, `$time_iso8601`, `$time_local`, `$server_addr`, `$server_port`, `$server_name`, `$server_protocol`, `$connections_active`, `$connections_reading`, `$connections_writing` and `$connections_waiting`. - -### Action.Return.Header - -The header defines an HTTP Header for a canned response in an actionReturn: - -```yaml -name: x-coffee -value: espresso -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the header. | ``string`` | Yes | -|``value`` | The value of the header. | ``string`` | Yes | -{{% /table %}} - -### Action.Proxy - -The proxy action passes requests to an upstream with the ability to modify the request/response (for example, rewrite the URI or modify the headers). - -In the example below, the request URI is rewritten to `/`, and the request and the response headers are modified: - -```yaml -proxy: - upstream: coffee - requestHeaders: - pass: true - set: - - name: My-Header - value: Value - - name: Client-Cert - value: ${ssl_client_escaped_cert} - responseHeaders: - add: - - name: My-Header - value: Value - - name: IC-Nginx-Version - value: ${nginx_version} - always: true - hide: - - x-internal-version - ignore: - - Expires - - Set-Cookie - pass: - - Server - rewritePath: / -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``upstream`` | The name of the upstream which the requests will be proxied to. The upstream with that name must be defined in the resource. | ``string`` | Yes | -|``requestHeaders`` | The request headers modifications. | [action.Proxy.RequestHeaders](#actionproxyrequestheaders) | No | -|``responseHeaders`` | The response headers modifications. | [action.Proxy.ResponseHeaders](#actionproxyresponseheaders) | No | -|``rewritePath`` | The rewritten URI. If the route path is a regular expression -- starts with `~` -- the `rewritePath` can include capture groups with ``$1-9``. For example `$1` for the first group, and so on. For more information, check the [rewrite](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources/rewrites) example. | ``string`` | No | -{{% /table %}} - -### Action.Proxy.RequestHeaders - -The RequestHeaders field modifies the headers of the request to the proxied upstream server. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``pass`` | Passes the original request headers to the proxied upstream server. See the [proxy_pass_request_header](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_request_headers) directive for more information. Default is true. | ``bool`` | No | -|``set`` | Allows redefining or appending fields to present request headers passed to the proxied upstream servers. See the [proxy_set_header](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header) directive for more information. | [[]header](#actionproxyrequestheaderssetheader) | No | -{{% /table %}} - -### Action.Proxy.RequestHeaders.Set.Header - -The header defines an HTTP Header: - -```yaml -name: My-Header -value: My-Value -``` - -It is possible to override the default value of the `Host` header, which the Ingress Controller sets to [`$host`](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_host): - -```yaml -name: Host -value: example.com -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the header. | ``string`` | Yes | -|``value`` | The value of the header. Supports NGINX variables*. Variables must be enclosed in curly brackets. For example: ``${scheme}``. | ``string`` | No | -{{% /table %}} - -\* -- Supported NGINX variables: `$request_uri`, `$request_method`, `$request_body`, `$scheme`, `$http_`, `$args`, `$arg_`, `$cookie_`, `$host`, `$request_time`, `$request_length`, `$nginx_version`, `$pid`, `$connection`, `$remote_addr`, `$remote_port`, `$time_iso8601`, `$time_local`, `$server_addr`, `$server_port`, `$server_name`, `$server_protocol`, `$connections_active`, `$connections_reading`, `$connections_writing`, `$connections_waiting`, `$ssl_cipher`, `$ssl_ciphers`, `$ssl_client_cert`, `$ssl_client_escaped_cert`, `$ssl_client_fingerprint`, `$ssl_client_i_dn`, `$ssl_client_i_dn_legacy`, `$ssl_client_raw_cert`, `$ssl_client_s_dn`, `$ssl_client_s_dn_legacy`, `$ssl_client_serial`, `$ssl_client_v_end`, `$ssl_client_v_remain`, `$ssl_client_v_start`, `$ssl_client_verify`, `$ssl_curves`, `$ssl_early_data`, `$ssl_protocol`, `$ssl_server_name`, `$ssl_session_id`, `$ssl_session_reused`, `$jwt_claim_` (NGINX Plus only) and `$jwt_header_` (NGINX Plus only). - -### Action.Proxy.ResponseHeaders - -The ResponseHeaders field modifies the headers of the response to the client. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``hide`` | The headers that will not be passed* in the response to the client from a proxied upstream server. See the [proxy_hide_header](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header) directive for more information. | ``[]string`` | No | -|``pass`` | Allows passing the hidden header fields* to the client from a proxied upstream server. See the [proxy_pass_header](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass_header) directive for more information. | ``[]string`` | No | -|``ignore`` | Disables processing of certain headers** to the client from a proxied upstream server. See the [proxy_ignore_headers](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers) directive for more information. | ``[]string`` | No | -|``add`` | Adds headers to the response to the client. | [[]addHeader](#addheader) | No | -{{% /table %}} - -\* -- Default hidden headers are: `Date`, `Server`, `X-Pad` and `X-Accel-...`. - -\** -- The following fields can be ignored: `X-Accel-Redirect`, `X-Accel-Expires`, `X-Accel-Limit-Rate`, `X-Accel-Buffering`, `X-Accel-Charset`, `Expires`, `Cache-Control`, `Set-Cookie` and `Vary`. - -### AddHeader - -The addHeader defines an HTTP Header with an optional `always` field: - -```yaml -name: My-Header -value: My-Value -always: true -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the header. | ``string`` | Yes | -|``value`` | The value of the header. Supports NGINX variables*. Variables must be enclosed in curly brackets. For example: ``${scheme}``. | ``string`` | No | -|``always`` | If set to true, add the header regardless of the response status code**. Default is false. See the [add_header](http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header) directive for more information. | ``bool`` | No | -{{% /table %}} - -\* -- Supported NGINX variables: `$request_uri`, `$request_method`, `$request_body`, `$scheme`, `$http_`, `$args`, `$arg_`, `$cookie_`, `$host`, `$request_time`, `$request_length`, `$nginx_version`, `$pid`, `$connection`, `$remote_addr`, `$remote_port`, `$time_iso8601`, `$time_local`, `$server_addr`, `$server_port`, `$server_name`, `$server_protocol`, `$connections_active`, `$connections_reading`, `$connections_writing`, `$connections_waiting`, `$ssl_cipher`, `$ssl_ciphers`, `$ssl_client_cert`, `$ssl_client_escaped_cert`, `$ssl_client_fingerprint`, `$ssl_client_i_dn`, `$ssl_client_i_dn_legacy`, `$ssl_client_raw_cert`, `$ssl_client_s_dn`, `$ssl_client_s_dn_legacy`, `$ssl_client_serial`, `$ssl_client_v_end`, `$ssl_client_v_remain`, `$ssl_client_v_start`, `$ssl_client_verify`, `$ssl_curves`, `$ssl_early_data`, `$ssl_protocol`, `$ssl_server_name`, `$ssl_session_id`, `$ssl_session_reused`, `$jwt_claim_` (NGINX Plus only) and `$jwt_header_` (NGINX Plus only). - -\*\* -- If `always` is false, the response header is added only if the response status code is any of `200`, `201`, `204`, `206`, `301`, `302`, `303`, `304`, `307` or `308`. - -### Split - -The split defines a weight for an action as part of the splits configuration. - -In the example below NGINX passes 80% of requests to the upstream `coffee-v1` and the remaining 20% to `coffee-v2`: - -```yaml -splits: -- weight: 80 - action: - pass: coffee-v1 -- weight: 20 - action: - pass: coffee-v2 -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``weight`` | The weight of an action. Must fall into the range ``0..100``. The sum of the weights of all splits must be equal to ``100``. | ``int`` | Yes | -|``action`` | The action to perform for a request. | [action](#action) | Yes | -{{% /table %}} - -### Match - -The match defines a match between conditions and an action or splits. - -In the example below, NGINX routes requests with the path `/coffee` to different upstreams based on the value of the cookie `user`: - -- `user=john` -> `coffee-future` -- `user=bob` -> `coffee-deprecated` -- If the cookie is not set or not equal to either `john` or `bob`, NGINX routes to `coffee-stable` - -```yaml -path: /coffee -matches: -- conditions: - - cookie: user - value: john - action: - pass: coffee-future -- conditions: - - cookie: user - value: bob - action: - pass: coffee-deprecated -action: - pass: coffee-stable -``` - -In the next example, NGINX routes requests based on the value of the built-in [`$request_method` variable](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_method), which represents the HTTP method of a request: - -- all POST requests -> `coffee-post` -- all non-POST requests -> `coffee` - -```yaml -path: /coffee -matches: -- conditions: - - variable: $request_method - value: POST - action: - pass: coffee-post -action: - pass: coffee -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``conditions`` | A list of conditions. Must include at least 1 condition. | [[]condition](#condition) | Yes | -|``action`` | The action to perform for a request. | [action](#action) | No | -|``splits`` | The splits configuration for traffic splitting. Must include at least 2 splits. | [[]split](#split) | No | -{{% /table %}} - -\* -- a match must include exactly one of the following: `action` or `splits`. - -### Condition - -The condition defines a condition in a match. - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``header`` | The name of a header. Must consist of alphanumeric characters or ``-``. | ``string`` | No | -|``cookie`` | The name of a cookie. Must consist of alphanumeric characters or ``_``. | ``string`` | No | -|``argument`` | The name of an argument. Must consist of alphanumeric characters or ``_``. | ``string`` | No | -|``variable`` | The name of an NGINX variable. Must start with ``$``. See the list of the supported variables below the table. | ``string`` | No | -|``value`` | The value to match the condition against. How to define a value is shown below the table. | ``string`` | Yes | -{{% /table %}} - -\* -- a condition must include exactly one of the following: `header`, `cookie`, `argument` or `variable`. - -Supported NGINX variables: `$args`, `$http2`, `$https`, `$remote_addr`, `$remote_port`, `$query_string`, `$request`, `$request_body`, `$request_uri`, `$request_method`, `$scheme`. Find the documentation for each variable [here](https://nginx.org/en/docs/varindex.html). - -The value supports two kinds of matching: - -- *Case-insensitive string comparison*. For example: - - `john` -- case-insensitive matching that succeeds for strings, such as `john`, `John`, `JOHN`. - - `!john` -- negation of the case-insensitive matching for john that succeeds for strings, such as `bob`, `anything`, `''` (empty string). -- *Matching with a regular expression*. Note that NGINX supports regular expressions compatible with those used by the Perl programming language (PCRE). For example: - - `~^yes` -- a case-sensitive regular expression that matches any string that starts with `yes`. For example: `yes`, `yes123`. - - `!~^yes` -- negation of the previous regular expression that succeeds for strings like `YES`, `Yes123`, `noyes`. (The negation mechanism is not part of the PCRE syntax). - - `~*no$` -- a case-insensitive regular expression that matches any string that ends with `no`. For example: `no`, `123no`, `123NO`. - -**Note**: a value must not include any unescaped double quotes (`"`) and must not end with an unescaped backslash (`\`). For example, the following are invalid values: `some"value`, `somevalue\`. - -### ErrorPage - -The errorPage defines a custom response for a route for the case when either an upstream server responds with (or NGINX generates) an error status code. The custom response can be a redirect or a canned response. See the [error_page](https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page) directive for more information. - -```yaml -path: /coffee -errorPages: -- codes: [502, 503] - redirect: - code: 301 - url: https://nginx.org -- codes: [404] - return: - code: 200 - body: "Original resource not found, but success!" -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``codes`` | A list of error status codes. | ``[]int`` | Yes | -|``redirect`` | The redirect action for the given status codes. | [errorPage.Redirect](#errorpageredirect) | No | -|``return`` | The canned response action for the given status codes. | [errorPage.Return](#errorpagereturn) | No | -{{% /table %}} - -\* -- an errorPage must include exactly one of the following: `return` or `redirect`. - -### ErrorPage.Redirect - -The redirect defines a redirect for an errorPage. - -In the example below, NGINX responds with a redirect when a response from an upstream server has a 404 status code. - -```yaml -codes: [404] -redirect: - code: 301 - url: ${scheme}://cafe.example.com/error.html -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``code`` | The status code of a redirect. The allowed values are: ``301`` , ``302`` , ``307`` , ``308``. The default is ``301``. | ``int`` | No | -|``url`` | The URL to redirect the request to. Supported NGINX variables: ``$scheme`` and ``$http_x_forwarded_proto``. Variables must be enclosed in curly braces. For example: ``${scheme}``. | ``string`` | Yes | -{{% /table %}} - -### ErrorPage.Return - -The return defines a canned response for an errorPage. - -In the example below, NGINX responds with a canned response when a response from an upstream server has either 401 or 403 status code. - -```yaml -codes: [401, 403] -return: - code: 200 - type: application/json - body: | - {\"msg\": \"You don't have permission to do this\"} - headers: - - name: x-debug-original-statuses - value: ${upstream_status} -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``code`` | The status code of the response. The default is the status code of the original response. | ``int`` | No | -|``type`` | The MIME type of the response. The default is ``text/html``. | ``string`` | No | -|``body`` | The body of the response. Supported NGINX variable: ``$upstream_status`` . Variables must be enclosed in curly braces. For example: ``${upstream_status}``. | ``string`` | Yes | -|``headers`` | The custom headers of the response. | [[]errorPage.Return.Header](#errorpagereturnheader) | No | -{{% /table %}} - -### ErrorPage.Return.Header - -The header defines an HTTP Header for a canned response in an errorPage: - -```yaml -name: x-debug-original-statuses -value: ${upstream_status} -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``name`` | The name of the header. | ``string`` | Yes | -|``value`` | The value of the header. Supported NGINX variable: ``$upstream_status`` . Variables must be enclosed in curly braces. For example: ``${upstream_status}``. | ``string`` | No | -{{% /table %}} - -## Using VirtualServer and VirtualServerRoute - -You can use the usual `kubectl` commands to work with VirtualServer and VirtualServerRoute resources, similar to Ingress resources. - -For example, the following command creates a VirtualServer resource defined in `cafe-virtual-server.yaml` with the name `cafe`: - -```shell -kubectl apply -f cafe-virtual-server.yaml - -virtualserver.k8s.nginx.org "cafe" created -``` - -You can get the resource by running: - -```shell -kubectl get virtualserver cafe - -NAME STATE HOST IP PORTS AGE -cafe Valid cafe.example.com 12.13.23.123 [80,443] 3m -``` - -In the kubectl get and similar commands, you can also use the short name `vs` instead of `virtualserver`. - -Working with VirtualServerRoute resources is analogous. In the kubectl commands, use `virtualserverroute` or the short name `vsr`. - -### Using Snippets - -Snippets allow you to insert raw NGINX config into different contexts of NGINX configuration. In the example below, we use snippets to configure several NGINX features in a VirtualServer: - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: VirtualServer -metadata: - name: cafe - namespace: cafe -spec: - http-snippets: | - limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s; - proxy_cache_path /tmp keys_zone=one:10m; - host: cafe.example.com - tls: - secret: cafe-secret - server-snippets: | - limit_req zone=mylimit burst=20; - upstreams: - - name: tea - service: tea-svc - port: 80 - - name: coffee - service: coffee-svc - port: 80 - routes: - - path: /tea - location-snippets: | - proxy_cache one; - proxy_cache_valid 200 10m; - action: - pass: tea - - path: /coffee - action: - pass: coffee -``` - -Snippets are intended to be used by advanced NGINX users who need more control over the generated NGINX configuration. - -However, because of the disadvantages described below, snippets are disabled by default. To use snippets, set the [`enable-snippets`](/nginx-ingress-controller/configuration/global-configuration/command-line-arguments#cmdoption-enable-snippets) command-line argument. - -Disadvantages of using snippets: - -- *Complexity*. To use snippets, you will need to: - - Understand NGINX configuration primitives and implement a correct NGINX configuration. - - Understand how the IC generates NGINX configuration so that a snippet doesn't interfere with the other features in the configuration. -- *Decreased robustness*. An incorrect snippet makes the NGINX config invalid which will lead to a failed reload. This will prevent any new configuration updates, including updates for the other VirtualServer and VirtualServerRoute resources until the snippet is fixed. -- *Security implications*. Snippets give access to NGINX configuration primitives and those primitives are not validated by the Ingress Controller. For example, a snippet can configure NGINX to serve the TLS certificates and keys used for TLS termination for Ingress and VirtualServer resources. - -To help catch errors when using snippets, the Ingress Controller reports config reload errors in the logs as well as in the events and status field of VirtualServer and VirtualServerRoute resources. Additionally, a number of Prometheus metrics show the stats about failed reloads – `controller_nginx_last_reload_status` and `controller_nginx_reload_errors_total`. - -> Note that during a period when the NGINX config includes an invalid snippet, NGINX will continue to operate with the latest valid configuration. - -### Validation - -Two types of validation are available for VirtualServer and VirtualServerRoute resources: - -- *Structural validation* by the `kubectl` and Kubernetes API server. -- *Comprehensive validation* by the Ingress Controller. - -#### Structural Validation - -The custom resource definitions for VirtualServer and VirtualServerRoute include structural OpenAPI schema which describes the type of every field of those resources. - -If you try to create (or update) a resource that violates the structural schema (for example, you use a string value for the port field of an upstream), `kubectl` and Kubernetes API server will reject such a resource: - -- Example of `kubectl` validation: - - ```shell - kubectl apply -f cafe-virtual-server.yaml - - error: error validating "cafe-virtual-server.yaml": error validating data: ValidationError(VirtualServer.spec.upstreams[0].port): invalid type for org.nginx.k8s.v1.VirtualServer.spec.upstreams.port: got "string", expected "integer"; if you choose to ignore these errors, turn validation off with --validate=false - ``` - -- Example of Kubernetes API server validation: - - ```shell - kubectl apply -f cafe-virtual-server.yaml --validate=false - - The VirtualServer "cafe" is invalid: []: Invalid value: map[string]interface {}{ ... }: validation failure list: - spec.upstreams.port in body must be of type integer: "string" - ``` - -If a resource is not rejected (it doesn't violate the structural schema), the Ingress Controller will validate it further. - -#### Comprehensive Validation - -The Ingress Controller validates the fields of the VirtualServer and VirtualServerRoute resources. If a resource is invalid, the Ingress Controller will reject it: the resource will continue to exist in the cluster, but the Ingress Controller will ignore it. - -You can check if the Ingress Controller successfully applied the configuration for a VirtualServer. For our example `cafe` VirtualServer, we can run: - -```shell -kubectl describe vs cafe - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 16s nginx-ingress-controller Configuration for default/cafe was added or updated -``` - -Note how the events section includes a Normal event with the AddedOrUpdated reason that informs us that the configuration was successfully applied. - -If you create an invalid resource, the Ingress Controller will reject it and emit a Rejected event. For example, if you create a VirtualServer `cafe` with two upstream with the same name `tea`, you will get: - -```shell -kubectl describe vs cafe - -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 12s nginx-ingress-controller VirtualServer default/cafe is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea" -``` - -Note how the events section includes a Warning event with the Rejected reason. - -Additionally, this information is also available in the `status` field of the VirtualServer resource. Note the Status section of the VirtualServer: - -```shell -kubectl describe vs cafe - -. . . -Status: - External Endpoints: - Ip: 12.13.23.123 - Ports: [80,443] - Message: VirtualServer default/cafe is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea" - Reason: Rejected - State: Invalid -``` - -The Ingress Controller validates VirtualServerRoute resources in a similar way. - -**Note**: If you make an existing resource invalid, the Ingress Controller will reject it and remove the corresponding configuration from NGINX. - -## Customization via ConfigMap - -You can customize the NGINX configuration for VirtualServer and VirtualServerRoutes resources using the [ConfigMap](/nginx-ingress-controller/configuration/global-configuration/configmap-resource). Most of the ConfigMap keys are supported, with the following exceptions: - -- `proxy-hide-headers` -- `proxy-pass-headers` -- `hsts` -- `hsts-max-age` -- `hsts-include-subdomains` -- `hsts-behind-proxy` -- `redirect-to-https` -- `ssl-redirect` diff --git a/docs/content/glossary.md b/docs/content/glossary.md deleted file mode 100644 index 0a7bacdfd0..0000000000 --- a/docs/content/glossary.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -description: null -docs: DOCS-1446 -title: Glossary -weight: 10000 ---- - -## Ingress {#ingress} - -_Ingress_ refers to an _Ingress Resource_, a Kubernetes API object which allows access to [Services](https://kubernetes.io/docs/concepts/services-networking/service/) within a cluster. They are managed by an [Ingress Controller]({{< relref "glossary.md#ingress-controller">}}). - -_Ingress_ resources enable the following functionality: - -- **Load balancing**, extended through the use of Services -- **Content-based routing**, using hosts and paths -- **TLS/SSL termination**, based on hostnames - -For additional information, please read the official [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/). - -## Ingress Controller {#ingress-controller} - -*Ingress Controllers* are applications within a Kubernetes cluster that enable [Ingress]({{< relref "glossary.md#ingress">}}) resources to function. They are not automatically deployed with a Kubernetes cluster, and can vary in implementation based on intended use, such as load balancing algorithms for Ingress resources. - -[How NGINX Ingress Controller is Designed]({{< relref "overview/design">}}) explains the technical details of the F5 NGINX Ingress Controller. diff --git a/docs/content/includes/index.md b/docs/content/includes/index.md deleted file mode 100644 index ca03031f1e..0000000000 --- a/docs/content/includes/index.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -headless: true ---- diff --git a/docs/content/includes/installation/create-common-resources.md b/docs/content/includes/installation/create-common-resources.md deleted file mode 100644 index d30f555255..0000000000 --- a/docs/content/includes/installation/create-common-resources.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -docs: DOCS-1464 ---- - -In this section, you'll create resources that most NGINX Ingress Controller installations require: - -1. (Optional) Create a secret for the default NGINX server's TLS certificate and key. Complete this step only if you're using the [default server TLS secret]({{< relref "configuration/global-configuration/command-line-arguments#cmdoption-default-server-tls-secret.md" >}}) command-line argument. If you're not, feel free to skip this step. - - By default, the server returns a _404 Not Found_ page for all requests when no ingress rules are set up. Although we provide a self-signed certificate and key for testing purposes, we recommend using your own certificate. - - ```shell - kubectl apply -f examples/shared-examples/default-server-secret/default-server-secret.yaml - ``` - -2. Create a ConfigMap to customize your NGINX settings: - - ```shell - kubectl apply -f deployments/common/nginx-config.yaml - ``` - -3. Create an `IngressClass` resource. NGINX Ingress Controller won't start without an `IngressClass` resource. - - ```shell - kubectl apply -f deployments/common/ingress-class.yaml - ``` - - If you want to make this NGINX Ingress Controller instance your cluster's default, uncomment the `ingressclass.kubernetes.io/is-default-class` annotation. This action will auto-assign `IngressClass` to new ingresses that don't specify an `ingressClassName`. diff --git a/docs/content/includes/installation/create-custom-resources.md b/docs/content/includes/installation/create-custom-resources.md deleted file mode 100644 index 6126a6b1c2..0000000000 --- a/docs/content/includes/installation/create-custom-resources.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -docs: DOCS-1463 ---- - -To make sure your NGINX Ingress Controller pods reach the `Ready` state, you'll need to create custom resource definitions (CRDs) for various components. - -Alternatively, you can disable this requirement by setting the `-enable-custom-resources` command-line argument to `false`. - -There are two ways you can install the custom resource definitions: - -1. Using a URL to apply a single CRD yaml file, which we recommend. -1. Applying your local copy of the CRD yaml files, which requires you to clone the repository. - -{{}} - -{{%tab name="Install CRDs from single YAML"%}} - -This single YAML file creates CRDs for the following resources: - -- [VirtualServer and VirtualServerRoute]({{< relref "configuration/virtualserver-and-virtualserverroute-resources.md" >}}) -- [TransportServer]({{< relref "configuration/transportserver-resource.md" >}}) -- [Policy]({{< relref "configuration/policy-resource.md" >}}) -- [GlobalConfiguration]({{< relref "configuration/global-configuration/globalconfiguration-resource.md" >}}) - -```shell -kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds.yaml -``` - -{{%/tab%}} - -{{%tab name="Install CRDs after cloning the repo"%}} - -{{< note >}} If you are installing the CRDs this way, ensure you have first cloned the repository. {{< /note >}} - -These YAML files create CRDs for the following resources: - -- [VirtualServer and VirtualServerRoute]({{< relref "configuration/virtualserver-and-virtualserverroute-resources.md" >}}) -- [TransportServer]({{< relref "configuration/transportserver-resource.md" >}}) -- [Policy]({{< relref "configuration/policy-resource.md" >}}) -- [GlobalConfiguration]({{< relref "configuration/global-configuration/globalconfiguration-resource.md" >}}) - -```shell -kubectl apply -f config/crd/bases/k8s.nginx.org_virtualservers.yaml -kubectl apply -f config/crd/bases/k8s.nginx.org_virtualserverroutes.yaml -kubectl apply -f config/crd/bases/k8s.nginx.org_transportservers.yaml -kubectl apply -f config/crd/bases/k8s.nginx.org_policies.yaml -kubectl apply -f config/crd/bases/k8s.nginx.org_globalconfigurations.yaml -``` - -{{%/tab%}} - -{{}} diff --git a/docs/content/includes/installation/deploy-controller.md b/docs/content/includes/installation/deploy-controller.md deleted file mode 100644 index 9e6c334408..0000000000 --- a/docs/content/includes/installation/deploy-controller.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -docs: DOCS-1462 ---- - -You have two options for deploying NGINX Ingress Controller: - -- **Deployment**. Choose this method for the flexibility to dynamically change the number of NGINX Ingress Controller replicas. -- **DaemonSet**. Choose this method if you want NGINX Ingress Controller to run on all nodes or a subset of nodes. - -Before you start, update the [command-line arguments]({{< relref "configuration/global-configuration/command-line-arguments.md" >}}) for the NGINX Ingress Controller container in the relevant manifest file to meet your specific requirements. diff --git a/docs/content/includes/installation/manifests/daemonset.md b/docs/content/includes/installation/manifests/daemonset.md deleted file mode 100644 index c19376eb2e..0000000000 --- a/docs/content/includes/installation/manifests/daemonset.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -docs: DOCS-1465 ---- - -For additional context on managing containers using Kubernetes DaemonSets, refer to the official Kubernetes [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) documentation. - -When you deploy NGINX Ingress Controller as a DaemonSet, Kubernetes creates an Ingress Controller pod on every node in the cluster. - -- For NGINX, run: - - ```shell - kubectl apply -f deployments/daemon-set/nginx-ingress.yaml - ``` - -- For NGINX Plus, run: - - ```shell - kubectl apply -f deployments/daemon-set/nginx-plus-ingress.yaml - ``` - - Update the `nginx-plus-ingress.yaml` file to include your chosen image from the F5 Container registry or your custom container image. diff --git a/docs/content/includes/installation/manifests/deployment.md b/docs/content/includes/installation/manifests/deployment.md deleted file mode 100644 index 3786a2256b..0000000000 --- a/docs/content/includes/installation/manifests/deployment.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -docs: DOCS-1467 ---- - -For additional context on managing containers using Kubernetes Deployments, refer to the official Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) documentation. - -When you deploy NGINX Ingress Controller as a Deployment, Kubernetes automatically sets up a single NGINX Ingress Controller pod. - -- For NGINX, run: - - ```shell - kubectl apply -f deployments/deployment/nginx-ingress.yaml - ``` - -- For NGINX Plus, run: - - ```shell - kubectl apply -f deployments/deployment/nginx-plus-ingress.yaml - ``` - - Update the `nginx-plus-ingress.yaml` file to include your chosen image from the F5 Container registry or your custom container image. diff --git a/docs/content/includes/installation/manifests/verify-pods-are-running.md b/docs/content/includes/installation/manifests/verify-pods-are-running.md deleted file mode 100644 index 9f11fa7b04..0000000000 --- a/docs/content/includes/installation/manifests/verify-pods-are-running.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -docs: DOCS-1466 ---- - - -To confirm the NGINX Ingress Controller pods are operational, run: - -```shell -kubectl get pods --namespace=nginx-ingress -``` diff --git a/docs/content/includes/rbac/set-up-rbac.md b/docs/content/includes/rbac/set-up-rbac.md deleted file mode 100644 index a8bd5a1763..0000000000 --- a/docs/content/includes/rbac/set-up-rbac.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -docs: DOCS-1468 ---- - -{{}}To complete these steps you need admin access to your cluster. Refer to to your Kubernetes platform's documentation to set up admin access. For Google Kubernetes Engine (GKE), you can refer to their [Role-Based Access Control guide](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).{{}} - -1. Create a namespace and a service account: - - ```shell - kubectl apply -f deployments/common/ns-and-sa.yaml - ``` - -2. Create a cluster role and binding for the service account: - - ```shell - kubectl apply -f deployments/rbac/rbac.yaml - ``` - -
- -If you're planning to use NGINX App Protect or NGINX App Protect DoS, additional roles and bindings are needed. - -1. (NGINX App Protect only) Create the *App Protect* role and binding: - - ```shell - kubectl apply -f deployments/rbac/ap-rbac.yaml - ``` - -2. (NGINX App Protect DoS only) Create the *App Protect DoS* role and binding: - - ```shell - kubectl apply -f deployments/rbac/apdos-rbac.yaml - ``` diff --git a/docs/content/installation/_index.md b/docs/content/installation/_index.md deleted file mode 100644 index 4ed49bfcbb..0000000000 --- a/docs/content/installation/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Installation -description: -weight: 400 -menu: - docs: - parent: NGINX Ingress Controller ---- diff --git a/docs/content/installation/building-nginx-ingress-controller.md b/docs/content/installation/building-nginx-ingress-controller.md deleted file mode 100644 index b968a198af..0000000000 --- a/docs/content/installation/building-nginx-ingress-controller.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -description: -docs: DOCS-1453 -doctypes: -- installation -title: Building NGINX Ingress Controller -toc: true -weight: 200 ---- - -Learn how to build an NGINX Ingress Controller image from source code and upload it to a private Docker registry. You'll also find information on the Makefile targets and variables. - -{{}}If you'd rather not build your own NGINX Ingress Controller image, see the [pre-built image options](#pre-built-images) at the end of this guide.{{}} - -## Before you start - -To get started, you need the following software installed on your machine: - -- [Docker v19.03 or higher](https://docs.docker.com/engine/release-notes/19.03/) -- [GNU Make](https://www.gnu.org/software/make/) -- [git](https://git-scm.com/) -- [OpenSSL](https://www.openssl.org/), optionally, if you would like to generate a self-signed certificate and a key for the default server. -- For NGINX Plus users, download the certificate (_nginx-repo.crt_) and key (_nginx-repo.key_) from [MyF5](https://my.f5.com). - -Although NGINX Ingress Controller is written in Golang, you don't need to have Golang installed. You can either download the precompiled binary file or build NGINX Ingress Controller in a Docker container. - ---- - -## Prepare the environment {#prepare-environment} - -Get your system ready for building and pushing the NGINX Ingress Controller image. - -1. Sign in to your private registry. Replace `` with the path to your own private registry. - - ```shell - docker login - ``` - -2. Clone the NGINX Ingress Controller GitHub repository. Replace `` with the version of NGINX Ingress Controller you want. - - ```shell - git clone https://github.com/nginxinc/kubernetes-ingress.git --branch - cd kubernetes-ingress - ``` - - For instance if you want to clone version v3.5.1, the commands to run would be: - - ```shell - git clone https://github.com/nginxinc/kubernetes-ingress.git --branch v3.5.1 - cd kubernetes-ingress - ``` - ---- - -## Build the NGINX Ingress Controller image {#build-image} - -After setting up your environment, follow these steps to build the NGINX Ingress Controller image. - -{{}}If you have a local Golang environment and want to build the binary yourself, remove `TARGET=download` from the make commands. If you don't have Golang but still want to build the binary, use `TARGET=container`.{{}} - -### For NGINX - -1. Build the image. Replace `` with your private registry's path. - - - For a Debian-based image: - - ```shell - make debian-image PREFIX=/nginx-ingress TARGET=download - ``` - - - For an Alpine-based image: - - ```shell - make alpine-image PREFIX=/nginx-ingress TARGET=download - ``` - - **What to expect**: The image is built and tagged with a version number, which is derived from the `VERSION` variable in the [_Makefile_](#makefile-details). This version number is used for tracking and deployment purposes. - -### For NGINX Plus - -1. Place your NGINX Plus license files (_nginx-repo.crt_ and _nginx-repo.key_) in the project's root folder. To verify they're in place, run: - - ```shell - ls nginx-repo.* - ``` - - You should see: - - ```shell - nginx-repo.crt nginx-repo.key - ``` - -2. Build the image. Replace `` with your private registry's path. - - ```shell - make debian-image-plus PREFIX=/nginx-plus-ingress TARGET=download - ``` - -
- - **What to expect**: The image is built and tagged with a version number, which is derived from the `VERSION` variable in the [_Makefile_](#makefile-details). This version number is used for tracking and deployment purposes. - -{{}}In the event a patch version of NGINX Plus is released, make sure to rebuild your image to get the latest version. If your system is caching the Docker layers and not updating the packages, add `DOCKER_BUILD_OPTIONS="--pull --no-cache"` to the make command.{{}} - ---- - -## Push the image to your private registry {#push-image} - -Once you've successfully built the NGINX or NGINX Plus Ingress Controller image, the next step is to upload it to your private Docker registry. This makes the image available for deployment to your Kubernetes cluster. - -### For NGINX - -1. Upload the NGINX image. If you're using a custom tag, append `TAG=your-tag` to the command. Replace `` with your private registry's path. - - ```shell - make push PREFIX=/nginx-ingress - ``` - -### For NGINX Plus - -1. Upload the NGINX Plus image. Like with the NGINX image, if you're using a custom tag, add `TAG=your-tag` to the end of the command. Replace `` with your private registry's path. - - ```shell - make push PREFIX=/nginx-plus-ingress - ``` - ---- - -## Makefile details {#makefile-details} - -This section provides comprehensive information on the targets and variables available in the _Makefile_. These targets and variables allow you to customize how you build, tag, and push your NGINX or NGINX Plus images. - -### Key Makefile targets {#key-makefile-targets} - -{{}}To view available _Makefile_ targets, run `make` with no target or type `make help`.{{}} - -Key targets include: - -{{}} -|
Target | Description | -|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| _build_ | Creates the NGINX Ingress Controller binary with your local Go environment. | -| _alpine-image_ | Builds an Alpine-based image with NGINX. | -| _alpine-image-plus_ | Builds an Alpine-based image with NGINX Plus. | -| _alpine-image-plus-fips_ | Builds an Alpine-based image with NGINX Plus and FIPS. | -| _debian-image_ | Builds a Debian-based image with NGINX. | -| _debian-image-plus_ | Builds a Debian-based image with NGINX Plus. | -| _debian-image-nap-plus_ | Builds a Debian-based image with NGINX Plus and the [NGINX App Protect WAF](/nginx-app-protect/) module. | -| _debian-image-dos-plus_ | Builds a Debian-based image with NGINX Plus and the [NGINX App Protect DoS](/nginx-app-protect-dos/) module. | -| _debian-image-nap-dos-plus_ | Builds a Debian-based image with NGINX Plus, [NGINX App Protect WAF](/nginx-app-protect/) and [NGINX App Protect DoS](/nginx-app-protect-dos/) modules. | -| _ubi-image_ | Builds a UBI-based image with NGINX for [OpenShift](https://www.openshift.com/) clusters. | -| _ubi-image-plus_ | Builds a UBI-based image with NGINX Plus for [OpenShift](https://www.openshift.com/) clusters. | -| _ubi-image-nap-plus_ | Builds a UBI-based image with NGINX Plus and the [NGINX App Protect WAF](/nginx-app-protect/) module for [OpenShift](https://www.openshift.com/) clusters. | -| _ubi-image-dos-plus_ | Builds a UBI-based image with NGINX Plus and the [NGINX App Protect DoS](/nginx-app-protect-dos/) module for [OpenShift](https://www.openshift.com/) clusters. | -| _ubi-image-nap-dos-plus_ |

Builds a UBI-based image with NGINX Plus, [NGINX App Protect WAF](/nginx-app-protect/) and the [NGINX App Protect DoS](/nginx-app-protect-dos/) module for [OpenShift](https://www.openshift.com/) clusters.

**Important**: Save your RHEL organization and activation keys in a file named _rhel_license_ at the project root.

For instance:

RHEL_ORGANIZATION=1111111
RHEL_ACTIVATION_KEY=your-key
| -{{}} - -### Additional useful targets {#other-makefile-targets} - -A few other useful targets: - -{{}} -|
Target
| Description | -|---------------------------------------|---------------| -| _push_ | Pushes the built image to the Docker registry. Configures with `PREFIX` and `TAG`. | -| _all_ | Runs `test`, `lint`, `verify-codegen`, `update-crds`, and `debian-image`. Stops and reports an error if any of these targets fail. | -| _test_ | Runs unit tests. | -{{}} - -### Makefile variables you can customize {#makefile-variables} - -The _Makefile_ includes several key variables. You have the option to either modify these variables directly in the _Makefile_ or override them when you run the `make` command. - -{{}} -|
Variable
| Description | -|-----------------------------------------|---------------| -| _ARCH_ | Defines the architecture for the image and binary. The default is `amd64`, but you can also choose from `arm64`, `arm`, `ppc64le`, and `s390x`. | -| _PREFIX_ | Gives the image its name. The default is `nginx/nginx-ingress`. | -| _TAG_ | Adds a tag to the image. This is often the version of NGINX Ingress Controller. | -| _DOCKER\_BUILD\_OPTIONS_ | Allows for additional [options](https://docs.docker.com/engine/reference/commandline/build/#options) during the `docker build` process, like `--pull`. | -| _TARGET_ |

Determines the build environment. NGINX Ingress Controller compiles locally in a Golang environment by default. Ensure the NGINX Ingress Controller repo resides in your `$GOPATH` if you select this option.

Alternatively, you can set `TARGET=container` to build using a Docker [Golang](https://hub.docker.com/_/golang/) container. To skip compiling the binary if you're on a specific tag or the latest `main` branch commit, set `TARGET=download`.

| -{{}} - ---- - -## Alternatives to building your own image {#pre-built-images} - -If you prefer not to build your own NGINX Ingress Controller image, you can use pre-built images. Here are your options: - -**NGINX Ingress Controller**: Download the image `nginx/nginx-ingress` from [DockerHub](https://hub.docker.com/r/nginx/nginx-ingress) or [GitHub](https://github.com/nginxinc/kubernetes-ingress/pkgs/container/kubernetes-ingress). - -**NGINX Plus Ingress Controller**: You have two options for this, both requiring an NGINX Ingress Controller subscription. - -- Download the image using your NGINX Ingress Controller subscription certificate and key. See the [Getting the F5 Registry NGINX Ingress Controller Image]({{< relref "installation/nic-images/pulling-ingress-controller-image.md" >}}) guide. -- Use your NGINX Ingress Controller subscription JWT token to get the image: Instructions are in [Getting the NGINX Ingress Controller Image with JWT]({{< relref "installation/nic-images/using-the-jwt-token-docker-secret.md" >}}). diff --git a/docs/content/installation/ingress-nginx.md b/docs/content/installation/ingress-nginx.md deleted file mode 100644 index adfce0953c..0000000000 --- a/docs/content/installation/ingress-nginx.md +++ /dev/null @@ -1,546 +0,0 @@ ---- -docs: DOCS-1469 -doctypes: -- tutorial -tags: -- docs -title: Migrating from Ingress-NGINX Controller to NGINX Ingress Controller -toc: true -weight: 500 ---- - -This document describes how to migrate from the community-maintained Ingress-NGINX Controller to the F5 NGINX Ingress Controller. - -## Overview - -This page explains two different ways to migrate from the community-maintained [Ingress-NGINX Controller](https://github.com/kubernetes/ingress-nginx) project to NGINX Ingress Controller: using NGINX's Ingress Resources or with Kubernetes's built-in Ingress Resources. This is typically because of implementation differences, and to take advantage of features such as [NGINX Plus integration]({{}}). - -The information in this guide is extracted from a free eBook called "_Kubernetes Ingress Controller Deployment and Security with NGINX_", which can be downloaded from the [NGINX Library](https://www.nginx.com/resources/library/kubernetes-ingress-controller-deployment-security-nginx/). - -## Before you begin - -To complete the instructions in this guide, you need the following: - -- A working knowledge of [Ingress Controllers]({{}}). -- An [NGINX Ingress Controller installation]({{}}) on the same host as an existing Ingress-NGINX Controller. - -There are two primary paths for migrating between the community Ingress-NGINX Controller to NGINX Ingress Controller: - -- Using NGINX Ingress Resources -- Using Kubernetes Ingress Resources. - -## Migration with NGINX Ingress resources -This path uses Kubernetes Ingress Resources to set root permissions, then NGINX Ingress Resources for configuration using custom resource definitions (CRDs): - -* [VirtualServer and VirtualServerRoute]({{}}) -* [TransportServer]({{}}) -* [GlobalConfiguration]({{}}) -* [Policy]({{}}) - -### Configuring SSL termination and HTTP path-based routing -The following two code examples correspond to a Kubernetes Ingress Resource and an [NGINX VirtualServer Resource]({{}}). Although the syntax and indentation is different, they accomplish the same basic Ingress functions, used for SSL termination and Layer 7 path-based routing. - -**Kubernetes Ingress Resource** -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: nginx-test -spec: - tls: - - hosts: - - foo.bar.com - secretName: tls-secret - rules: - - host: foo.bar.com - http: - paths: - - path: /login - backend: - serviceName: login-svc - servicePort: 80 - - path: /billing - serviceName: billing-svc - servicePort: 80 -``` - -**NGINX VirtualServer Resource** -```yaml -apiVersion: networking.k8s.io/v1 -kind: VirtualServer -metadata: - name: nginx-test -spec: - host: foo.bar.com - tls: - secret: tls-secret - upstreams: - - name: login - service: login-svc - port: 80 - - name: billing - service: billing-svc - port: 80 - routes: - - path: /login - action: - pass: login - - path: /billing - action: - pass: billing -``` - -### Configuring TCP/UDP load balancing and TLS passthrough -NGINX Ingress Controller exposes TCP and UDP services using [TransportServer]({{}}) and [GlobalConfiguration]({{}}) resources. These resources provide a broad range of options for TCP/UDP and TLS Passthrough load balancing. By contrast, the community Ingress-NGINX Controller exposes TCP/UDP services by using a Kubernetes ConfigMap object. - ---- - -### Convert Ingress-NGINX Controller annotations to NGINX Ingress resources -Kubernetes deployments often need to extend basic Ingress rules for advanced use cases such as canary and blue-green deployments, traffic throttling, and ingress-egress traffic manipulation. The community Ingress-NGINX Controller implements many of these using Kubernetes annotations with custom Lua extensions. - -These custom Lua extensions are intended for specific NGINX Ingress resource definitions and may not be as granular as required for advanced use cases. The following examples show how to convert these annotations into NGINX Ingress Controller Resources. - ---- - -#### Canary deployments -Canary and blue-green deployments allow you to push code changes to production environments without disrupting existing users. NGINX Ingress Controller runs them on the data plane: to migrate from the community Ingress-NGINX Controller, you must map the latter's annotations to [VirtualServer and VirtualServerRoute resources]({{}}). - -The Ingress-NGINX Controller evaluates canary annotations in the following order: - -1. _nginx.ingress.kubernetes.io/canary-by-header_ -1. _nginx.ingress.kubernetes.io/canary-by-cookie_ -1. _nginx.ingress.kubernetes.io/canary-by-weight_ - -For NGINX Ingress Controller to evalute them the same way, they must appear in the same order in the VirtualServer or VirtualServerRoute Manifest. - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/canary: "true" -nginx.ingress.kubernetes.io/canary-by-header: "httpHeader" -``` - -**NGINX Ingress Controller** -```yaml -matches: -- conditions: - - header: httpHeader - value: never - action: - pass: echo - - header: httpHeader - value: always - action: - pass: echo-canary -action: - pass: echo -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/canary: "true" -nginx.ingress.kubernetes.io/canary-by-header: "httpHeader" -nginx.ingress.kubernetes.io/canary-by-header-value: "my-value" -``` - -**NGINX Ingress Controller** -```yaml -matches: -- conditions: - - header: httpHeader - value: my-value - action: - pass: echo-canary -action: - pass: echo -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/canary: "true" -nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName" -``` - -**NGINX Ingress Controller** -```yaml -matches: -- conditions: - - cookie: cookieName - value: never - action: - pass: echo - - cookie: cookieName - value: always - action: - pass: echo-canary -action: - pass: echo -``` - ---- - -#### Traffic control -Environments using microservices tend to use extensive traffic-control policies to manage ephemeral applications using circuit breaking and rate and connection limiting to prevent error conditions due to unhealthy states or abnormal behavior. - -The following examples map Ingress-NGINX Controller annotations to NGINX [VirtualServer and VirtualServerRoute resources]({{}}) for rate limiting, custom HTTP errors, custom default backend and URI rewriting. - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/custom-http-errors: "code" - -nginx.ingress.kubernetes.io/default-backend: "default-svc" -``` - -**NGINX Ingress Controller** -```yaml -errorPages: -- codes: [code] - redirect: - code: 301 - url: default-svc -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/limit-connections: "number" -``` - -**NGINX Ingress Controller** -```yaml -http-snippets: | - limit_conn_zone $binary_remote_addr zone=zone_name:size; -routes: -- path: /path - location-snippets: | - limit_conn zone_name number; -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/limit-rate: "number" -nginx.ingress.kubernetes.io/limit-rate-after: "number" -``` - -**NGINX Ingress Controller** -```yaml -location-snippets: | - limit_rate number; - - limit_rate_after number; -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/limit-rpm: "number" -nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier" -``` - -**NGINX Ingress Controller** -```yaml -rateLimit: - rate: numberr/m - - burst: number * multiplier - key: ${binary_remote_addr} - zoneSize: size -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/limit-rps: "number" -nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier" -``` - -**NGINX Ingress Controller** -```yaml -rateLimit: - rate: numberr/s - - burst: number * multiplier - key: ${binary_remote_addr} - zoneSize: size -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/limit-whitelist: "CIDR" -``` - -**NGINX Ingress Controller** -```yaml -http-snippets: | -server-snippets: | -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/rewrite-target: "URI" -``` - -**NGINX Ingress Controller** -```yaml -rewritePath: "URI" -``` - -There are four Ingress-NGINX Controller annotations without NGINX Ingress resource fields yet: they must be handled using snippets. - -- _nginx.ingress.kubernetes.io/limit-connections_ -- _nginx.ingress.kubernetes.io/limit-rate_ -- _nginx.ingress.kubernetes.io/limit-rate-after_ -- _nginx.ingress.kubernetes.io/limit-whitelist_ - ---- - -#### Header manipulation -Manipulating HTTP headers is useful in many cases, as they contain information that is important and relevant to systems involved in HTTP transactions. The community Ingress-NGINX Controller supports enabling and configuring cross-origin resource sharing (CORS) headings used by AJAX applications, where front-end Javascript code interacts with backend applications or web servers. - -These code blocks show how the Ingress-NGINX annotations correspond to NGINX Ingress Controller [VirtualServer and VirtualServerRoute resources]({{}}). - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/enable-cors: "true" -nginx.ingress.kubernetes.io/cors-allow-credentials: "true" - -nginx.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For" - -nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS" - -nginx.ingress.kubernetes.io/cors-allow-origin: "*" - -nginx.ingress.kubernetes.io/cors-max-age: "seconds" -``` - -**NGINX Ingress Controller** -```yaml -responseHeaders: - add: - - name: Access-Control-Allow-Credentials - value: "true" - - name: Access-Control-Allow-Headers - value: "X-Forwarded-For" - - name: Access-Control-Allow-Methods - value: "PUT, GET, POST, OPTIONS" - - name: Access-Control-Allow-Origin - value: "*" - - name: Access-Control-Max-Age - value: "seconds" -``` - ---- - -#### Proxying and load balancing -NGINX Ingress Controller has multiple proxy and load balancing functionalities you may want to configure based on the use case, such as configuring the load balancing algorithm and the timeout and buffering settings for proxied connections. - -This table shows how Ingress-NGINX Controller annotations map to statements in the upstream field for [VirtualServer and VirtualServerRoute resources]({{}}), covering load balancing, proxy timeout, proxy buffering and connection routing for a services' ClusterIP address and port. - -{{< bootstrap-table "table table-bordered table-striped table-responsive" >}} -| Ingress-NGINX Controller | NGINX Ingress Controller | -| ------------------------ | ------------------------ | -| _nginx.ingress.kubernetes.io/load-balance_ | _lb-method_ | -| _nginx.ingress.kubernetes.io/proxy-buffering_ | _buffering_ | -| _nginx.ingress.kubernetes.io/proxy-buffers-number_ | _buffers_ | -| _nginx.ingress.kubernetes.io/proxy-buffer-size_ | _buffers_ | -| _nginx.ingress.kubernetes.io/proxy-connect-timeout_ | _connect-timeout_ | -| _nginx.ingress.kubernetes.io/proxy-next-upstream_ | _next-upstream_ | -| _nginx.ingress.kubernetes.io/proxy-next-upstream-timeout_ | _next-upstream-timeout_ | -| _nginx.ingress.kubernetes.io/proxy-read-timeout_ | _read-timeout_ | -| _nginx.ingress.kubernetes.io/proxy-send-timeout_ | _send-timeout_ | -| _nginx.ingress.kubernetes.io/service-upstream_ | _use-cluster-ip_ | -{{% /bootstrap-table %}} - -#### mTLS authentication - -mTLS authentication is a way of enforcing mutual authentication on traffic entering and exiting a cluster (north-sourth traffic). This secure form of communication is common within a service mesh, commonly used in strict zero-trust environments. - -NGINX Ingress Controller layer can handle mTLS authentication for end systems through the presentation of valid certificates for external connections. It accomplishes this through [Policy]({{}}) resources, which correspond to Ingress-NGINX Controller annotations for [client certificate authentication](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#client-certificate-authentication) and [backend certificate authentication](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#backend-certificate-authentication). - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/auth-tls-secret: secretName -nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" -nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1" -``` - -**NGINX Ingress Controller** -```yaml -ingressMTLS: - clientCertSecret: secretName - verifyClient: "on" - - verifyDepth: 1 -``` - ---- - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/proxy-ssl-secret: "secretName" -nginx.ingress.kubernetes.io/proxy-ssl-verify: "on|off" -nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "1" -nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2" -nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "DEFAULT" -nginx.ingress.kubernetes.io/proxy-ssl-name: "server-name" -nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on|off" -``` - -**NGINX Ingress Controller** -```yaml -egressMTLS: - tlsSecret: secretName - - verifyServer: true|false - - verifyDepth: 1 - - protocols: TLSv1.2 - - ciphers: DEFAULT - - sslName: server-name - - serverName: true|false -``` - ---- - -#### Session persistence with NGINX Plus -With [NGINX Plus]({{}}), you can use [Policy]({{}}) resources for session persistence, which have corresponding annotations for the community Ingress-NGINX Controller. - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/affinity: "cookie" -nginx.ingress.kubernetes.io/session-cookie-name: "cookieName" -nginx.ingress.kubernetes.io/session-cookie-expires: "x" -nginx.ingress.kubernetes.io/session-cookie-path: "/route" -nginx.ingress.kubernetes.io/session-cookie-secure: "true" -``` - -**NGINX Ingress Controller** -```yaml -sessionCookie: - enable: true - - name: cookieName - - expires: xh - - path: /route - - secure: true -``` - -## Migration with Kubernetes Ingress resources -The other option for migrating from the community Ingress-NGINX Controller to NGINX Ingress Controller is using only [annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) and [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/) from standard Kubernetes resources, potentially relying on [mergeable Ingress types](https://github.com/nginxinc/kubernetes-ingress/tree/main/examples/ingress-resources/mergeable-ingress-types). - -This ensures that all configuration is kept in the Ingress object. - -{{< warning >}} -You should avoid altering the `spec` field of the Ingress resource when taking this option. Ingress-NGINX Controller and NGINX Ingress Controller differ slightly in their implementations: changing the Kubernetes Ingress can create incompatibility issues. -{{< /warning >}} - -### Advanced configuration with annotations -This table maps the Ingress-NGINX Controller annotations to NGINX Ingress Controller's equivalent annotations, and the respective NGINX Directive. - -{{< bootstrap-table "table table-bordered table-striped table-responsive" >}} -| Ingress-NGINX Controller | NGINX Ingress Controller | NGINX Directive | -| ------------------------ | ------------------------ | --------------- | -| [_nginx.ingress.kubernetes.io/configuration-snippet_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#configuration-snippet) | [_nginx.org/location-snippets_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#snippets-and-custom-templates) | N/A | -| [_nginx.ingress.kubernetes.io/load-balance_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-nginx-load-balancing) (1) | [_nginx.org/lb-method_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#backend-services-upstreams) | [_random two least_conn_](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#random) | -| [_nginx.ingress.kubernetes.io/proxy-buffering_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#proxy-buffering) | [_nginx.org/proxy-buffering_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#general-customization) | [_proxy_buffering_](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering) | -| [_nginx.ingress.kubernetes.io/proxy-buffers-number_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#proxy-buffers-number) | [_nginx.org/proxy-buffers_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#general-customization) | [_proxy_buffers_](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) | -| [_nginx.ingress.kubernetes.io/proxy-buffer-size_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#proxy-buffer-size) | [_nginx.org/proxy-buffer-size_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#general-customization) | [_proxy_buffer_size_](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) | -| [_nginx.ingress.kubernetes.io/proxy-connect-timeout_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-timeouts) | [_nginx.org/proxy-connect-timeout_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#general-customization) | [_proxy_connect_timeout_](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout) | -| [_nginx.ingress.kubernetes.io/proxy-read-timeout_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-timeouts) | [_nginx.org/proxy-read-timeout_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#general-customization) | [_proxy_read_timeout_](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) | -| [_nginx.ingress.kubernetes.io/proxy-send-timeout_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-timeouts) | [_nginx.org/proxy-send-timeout_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#general-customization) | [_proxy_send_timeout_](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) | -| [_nginx.ingress.kubernetes.io/rewrite-target_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#rewrite) | [_nginx.org/rewrites_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#request-uriheader-manipulation) | [_rewrite_](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite) | -| [_nginx.ingress.kubernetes.io/server-snippet_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-snippet)| [_nginx.org/server-snippets_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#snippets-and-custom-templates) | N/A | -| [_nginx.ingress.kubernetes.io/ssl-redirect_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-side-https-enforcement-through-redirect) | [_ingress.kubernetes.io/ssl-redirect_](https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/#auth-and-ssltls) | N/A (2) | -{{% /bootstrap-table %}} - -1. Ingress-NGINX Controller implements some of its load balancing algorithms with Lua, which may not have an equivalent in NGINX Ingress Controller. -1. To redirect HTTP (80) traffic to HTTPS (443), NGINX Ingress Controller uses built-in NGINX `if` conditions while Ingress-NGINX Controller uses Lua. - -The following two snippets outline Ingress-NGINX Controller annotations that correspond to annotations for NGINX Ingress Controller with NGINX Plus. - -**Ingress-NGINX Controller** -```yaml -nginx.ingress.kubernetes.io/affinity: "cookie" -nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name" -nginx.ingress.kubernetes.io/session-cookie-expires: "seconds" -nginx.ingress.kubernetes.io/session-cookie-path: "/route" -``` - -**NGINX Ingress Controller (with NGINX Plus)** -```yaml -nginx.com/sticky-cookie-services: "serviceName=example-svc cookie_name expires=time path=/route" -``` - -{{< note >}} -NGINX Ingress Controller has additional annotations for features using NGINX Plus that have no Ingress-NGINX Controller equivalent, such as active health checks and authentication using JSON Web Tokens (JWTs). -{{< /note >}} - -### Global configuration with ConfigMaps - -This table maps the Ingress-NGINX Controller ConfigMap keys to NGINX Ingress Controller's equivalent ConfigMap keys. - - - -{{< bootstrap-table "table table-bordered table-striped table-responsive" >}} -| Ingress-NGINX Controller | NGINX Ingress Controller | -| ------------------------ | ------------------------ | -| [_disable-access-log_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#disable-access-log) | [_access-log-off_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#logging) | -| [_error-log-level_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#error-log-level) | [_error-log-level_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#logging) | -| [_hsts_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#hsts) | [_hsts_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#auth-and-ssltls) | -| [_hsts-include-subdomains_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#hsts-include-subdomains) | [_hsts-include-subdomains_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#auth-and-ssltls) | -| [_hsts-max-age_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#hsts-max-age) | [_hsts-max-age_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#auth-and-ssltls) | -| [_http-snippet_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#http-snippet) | [_http-snippets_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#snippets-and-custom-templates) | -| [_keep-alive_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#keep-alive) | [_keepalive-timeout_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_keep-alive-requests_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#keep-alive-requests) | [_keepalive-requests_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_load-balance_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#load-balance) | [_lb-method_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#backend-services-upstreams) | -| [_location-snippet_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#location-snippet) | [_location-snippets_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#snippets-and-custom-templates) | -| [_log-format-escape-json_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#log-format-escape-json) | [_log-format-escaping: "json"_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#logging) | -| [_log-format-stream_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#log-format-stream) | [_stream-log-format_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#logging) | -| [_log-format-upstream_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#log-format-upstream) | [_log-format_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#logging) | -| [_main-snippet_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#main-snippet) | [_main-snippets_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#snippets-and-custom-templates) | -| [_max-worker-connections_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#max-worker-connections) | [_worker-connections_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_max-worker-open-files_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#max-worker-open-files) | [_worker-rlimit-nofile_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-body-size_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-body-size) | [_client-max-body-size_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-buffering_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-buffering) | [_proxy-buffering_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-buffers-number_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-buffers-number) | [_proxy-buffers: number size_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-buffer-size_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-buffer-size) | [_proxy-buffers: number size_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-connect-timeout_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-connect-timeout) | [_proxy-connect-timeout_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-read-timeout_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-read-timeout) | [_proxy-read-timeout_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-send-timeout_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-send-timeout) | [_proxy-send-timeout_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_server-name-hash-bucket-size_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#server-name-hash-bucket-size) | [_server-names-hash-bucket-size_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_proxy-headers-hash-max-size_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#proxy-headers-hash-max-size) | [_server-names-hash-max-size_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_server-snippet_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#server-snippet) | [_server-snippets_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#snippets-and-custom-templates) | -| [_server-tokens _](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#server-tokens) | [_server-tokens_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_ssl-ciphers_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#ssl-ciphers) | [_ssl-ciphers_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#auth-and-ssltls) | -| [_ssl-dh-param_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#ssl-dh-param) | [_ssl-dhparam-file_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#auth-and-ssltls) | -| [_ssl-protocols_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#ssl-protocols) | [_ssl-protocols_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#auth-and-ssltls) | -| [_ssl-redirect_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#ssl-redirect) | [_ssl-redirect_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#auth-and-ssltls) | -| [_upstream-keepalive-connections_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#upstream-keepalive-connections) | [_keepalive_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#backend-services-upstreams) | -| [_use-http2_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-http2) | [_http2_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#listeners) | -| [_use-proxy-protocol_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-proxy-protocol) | [_proxy-protocol_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#listeners) | -| [_variables-hash-bucket-size_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#variables-hash-bucket-size) | [_variables-hash-bucket-size_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_worker-cpu-affinity_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#worker-cpu-affinity) | [_worker-cpu-affinity_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_worker-processes_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#worker-processes) | [_worker-processes_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -| [_worker-shutdown-timeout_](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#worker-shutdown-timeout) | [_worker-shutdown-timeole_](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/#general-customization) | -{{% /bootstrap-table %}} diff --git a/docs/content/installation/installing-nic/_index.md b/docs/content/installation/installing-nic/_index.md deleted file mode 100644 index ad70f8f425..0000000000 --- a/docs/content/installation/installing-nic/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Install NGINX Ingress Controller -description: -weight: 100 ---- diff --git a/docs/content/installation/installing-nic/installation-with-helm.md b/docs/content/installation/installing-nic/installation-with-helm.md deleted file mode 100644 index 7a8ddbce7a..0000000000 --- a/docs/content/installation/installing-nic/installation-with-helm.md +++ /dev/null @@ -1,471 +0,0 @@ ---- -docs: DOCS-602 -doctypes: -- '' -title: Installation with Helm -toc: true -weight: 100 ---- - -This document explains how to install NGINX Ingress Controller using [Helm](https://helm.sh/). - -## Before you start - -{{}} All documentation should only be used with the latest stable release, indicated on [the releases page]({{< relref "releases.md" >}}) of the GitHub repository. {{}} - -- A [Kubernetes Version Supported by the Ingress Controller](https://docs.nginx.com/nginx-ingress-controller/technical-specifications/#supported-kubernetes-versions) -- Helm 3.0+. -- If you’d like to use NGINX Plus: - - To pull from the F5 Container registry, configure a docker registry secret using your JWT token from the MyF5 portal by following the instructions from [here](https://docs.nginx.com/nginx-ingress-controller/installation/nic-images/using-the-jwt-token-docker-secret). Make sure to specify the secret using `controller.serviceAccount.imagePullSecretName` or `controller.serviceAccount.imagePullSecretsNames` parameter. - - Alternatively, pull an NGINX Ingress Controller image with NGINX Plus and push it to your private registry by following the instructions from [here]({{< relref "installation/nic-images/pulling-ingress-controller-image" >}}). - - Alternatively, you can NGINX build an Ingress Controller image with NGINX Plus and push it to your private registry by following the instructions from [here]({{< relref "installation/building-nginx-ingress-controller.md" >}}). - - Update the `controller.image.repository` field of the `values-plus.yaml` accordingly. -- To use App Protect DoS, install the App Protect DoS Arbitrator [Helm Chart](https://github.com/nginxinc/nap-dos-arbitrator-helm-chart) in the same namespace as NGINX Ingress Controller. If you install multiple NGINX Ingress Controllers in the same namespace, they will need to share the same Arbitrator because there can only be one Arbitrator in a single namespace. - -## CRDs - -By default, the Ingress Controller requires a number of custom resource definitions (CRDs) installed in the cluster. The Helm client will install those CRDs. If the CRDs are not installed, the Ingress Controller pods will not become `Ready`. - -If you do not use the custom resources that require those CRDs (which corresponds to `controller.enableCustomResources` set to `false` and `controller.appprotect.enable` set to `false` and `controller.appprotectdos.enable` set to `false`), the installation of the CRDs can be skipped by specifying `--skip-crds` for the helm install command. - -### Upgrading the CRDs - -To upgrade the CRDs, pull the chart sources as described in [Pulling the Chart](#pulling-the-chart) and then run: - -```shell -kubectl apply -f crds/ -``` - -Alternatively, CRDs can be upgraded without pulling the chart by running: - -```shell -kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds.yaml -``` - -In the above command, `v3.5.1` represents the version of NGINX Ingress Controller release rather than the Helm chart version. - -{{}}The following warning is expected and can be ignored: `Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply`. - -Make sure to check the [release notes](https://www.github.com/nginxinc/kubernetes-ingress/releases) for a new release for any special upgrade procedures. -{{}} - -### Uninstalling the CRDs - -To remove the CRDs, pull the chart sources as described in [Pulling the Chart](#pulling-the-chart) and then run: - -```shell -kubectl delete -f crds/ -``` - -{{}}This command will delete all the corresponding custom resources in your cluster across all namespaces. Please ensure there are no custom resources that you want to keep and there are no other Ingress Controller releases running in the cluster.{{}} - -## Managing the Chart via OCI Registry - -### Installing the Chart - -To install the chart with the release name my-release (my-release is the name that you choose): - -- For NGINX: - - ```shell - helm install my-release oci://ghcr.io/nginxinc/charts/nginx-ingress --version 1.2.1 - ``` - -- For NGINX Plus: (assuming you have pushed the Ingress Controller image `nginx-plus-ingress` to your private registry `myregistry.example.com`) - - ```shell - helm install my-release oci://ghcr.io/nginxinc/charts/nginx-ingress --version 1.2.1 --set controller.image.repository=myregistry.example.com/nginx-plus-ingress --set controller.nginxplus=true - ``` - -This will install the latest `edge` version of the Ingress Controller from GitHub Container Registry. If you prefer to use Docker Hub, you can replace `ghcr.io/nginxinc/charts/nginx-ingress` with `registry-1.docker.io/nginxcharts/nginx-ingress`. - -### Upgrading the Chart - -Helm does not upgrade the CRDs during a release upgrade. Before you upgrade a release, see [Upgrading the CRDs](#upgrading-the-crds). - -To upgrade the release `my-release`: - -```shell -helm upgrade my-release oci://ghcr.io/nginxinc/charts/nginx-ingress --version 1.2.1 -``` - -### Uninstalling the Chart - -To uninstall/delete the release `my-release`: - -```shell -helm uninstall my-release -``` - -The command removes all the Kubernetes components associated with the release and deletes the release. - -Uninstalling the release does not remove the CRDs. To remove the CRDs, see [Uninstalling the CRDs](#uninstalling-the-crds). - -### Edge Version - -To test the latest changes in NGINX Ingress Controller before a new release, you can install the `edge` version. This version is built from the `main` branch of the NGINX Ingress Controller repository. -You can install the `edge` version by specifying the `--version` flag with the value `0.0.0-edge`: - -```shell -helm install my-release oci://ghcr.io/nginxinc/charts/nginx-ingress --version 0.0.0-edge -``` - -> **Warning** -> -> The `edge` version is not intended for production use. It is intended for testing and development purposes only. - -## Managing the Chart via Sources - -### Pulling the Chart - -This step is required if you're installing the chart using its sources. Additionally, the step is also required for managing the custom resource definitions (CRDs), which the Ingress Controller requires by default, or for upgrading/deleting the CRDs. - -1. Pull the chart sources: - - ```shell - helm pull oci://ghcr.io/nginxinc/charts/nginx-ingress --untar --version 1.2.1 - ``` - -2. Change your working directory to nginx-ingress: - - ```shell - cd nginx-ingress - ``` - -### Installing the Chart - -To install the chart with the release name my-release (my-release is the name that you choose): - -- For NGINX: - - ```shell - helm install my-release . - ``` - -- For NGINX Plus: - - ```shell - helm install my-release -f values-plus.yaml . - ``` - -The command deploys the Ingress Controller in your Kubernetes cluster in the default configuration. The configuration section lists the parameters that can be configured during installation. - -### Upgrading the Chart - -Helm does not upgrade the CRDs during a release upgrade. Before you upgrade a release, see [Upgrading the CRDs](#upgrading-the-crds). - -To upgrade the release `my-release`: - -```shell -helm upgrade my-release . -``` - -### Uninstalling the Chart - -To uninstall/delete the release `my-release`: - -```shell -helm uninstall my-release -``` - -The command removes all the Kubernetes components associated with the release and deletes the release. - -Uninstalling the release does not remove the CRDs. To remove the CRDs, see [Uninstalling the CRDs](#uninstalling-the-crds). - - -## Upgrading without downtime - -### Background - -In NGINX Ingress Controller version 3.1.0, [changes were introduced](https://github.com/nginxinc/kubernetes-ingress/pull/3606) to Helm resource names, labels and annotations to fit with Helm best practices. -When using Helm to upgrade from a version prior to 3.1.0, certain resources like Deployment, DaemonSet and Service will be recreated due to the aforementioned changes, which will result in downtime. - -Although the advisory is to update all resources in accordance with new naming convention, to avoid the downtime please follow the steps listed in this page. - -### Upgrade Steps - -{{}} The following steps apply to both 2.x and 3.0.x releases.{{}} - -The steps you should follow depend on the Helm release name: - -{{}} - -{{%tab name="Helm release name is `nginx-ingress`"%}} - -1. Use `kubectl describe` on deployment/daemonset to get the `Selector` value: - - ```shell - kubectl describe deployments -n - ``` - - Copy the key=value under `Selector`, such as: - - ```shell - Selector: app=nginx-ingress-nginx-ingress - ``` - -2. Checkout the latest available tag using `git checkout v3.5.1` - -3. Navigate to `/kubernates-ingress/charts/nginx-ingress` - -4. Update the `selectorLabels: {}` field in the `values.yaml` file located at `/kubernates-ingress/charts/nginx-ingress` with the copied `Selector` value. - ```shell - selectorLabels: {app: nginx-ingress-nginx-ingress} - ``` - -5. Run `helm upgrade` with following arguments set: - ```shell - --set serviceNameOverride="nginx-ingress-nginx-ingress" - --set controller.name="" - --set fullnameOverride="nginx-ingress-nginx-ingress" - ``` - It could look as follows: - - ```shell - helm upgrade nginx-ingress oci://ghcr.io/nginxinc/charts/nginx-ingress --version 0.19.0 --set controller.kind=deployment/daemonset --set controller.nginxplus=false/true --set controller.image.pullPolicy=Always --set serviceNameOverride="nginx-ingress-nginx-ingress" --set controller.name="" --set fullnameOverride="nginx-ingress-nginx-ingress" -f values.yaml - ``` - -6. Once the upgrade process has finished, use `kubectl describe` on the deployment to verify the change by reviewing its events: - ```shell - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal ScalingReplicaSet 9m11s deployment-controller Scaled up replica set nginx-ingress-nginx-ingress- to 1 - Normal ScalingReplicaSet 101s deployment-controller Scaled up replica set nginx-ingress-nginx-ingress- to 1 - Normal ScalingReplicaSet 98s deployment-controller Scaled down replica set nginx-ingress-nginx-ingress- to 0 from 1 - ``` -{{%/tab%}} - -{{%tab name="Helm release name is not `nginx-ingress`"%}} - -1. Use `kubectl describe` on deployment/daemonset to get the `Selector` value: - - ```shell - kubectl describe deployment/daemonset -n - ``` - - Copy the key=value under ```Selector```, such as: - - ```shell - Selector: app=-nginx-ingress - ``` - -2. Checkout the latest available tag using `git checkout v3.5.1` - -3. Navigate to `/kubernates-ingress/charts/nginx-ingress` - -4. Update the `selectorLabels: {}` field in the `values.yaml` file located at `/kubernates-ingress/charts/nginx-ingress` with the copied `Selector` value. - - ```shell - selectorLabels: {app: -nginx-ingress} - ``` - -5. Run `helm upgrade` with following arguments set: - - ```shell - --set serviceNameOverride="-nginx-ingress" - --set controller.name="" - ``` - - It could look as follows: - - ```shell - helm upgrade test-release oci://ghcr.io/nginxinc/charts/nginx-ingress --version 0.19.0 --set controller.kind=deployment/daemonset --set controller.nginxplus=false/true --set controller.image.pullPolicy=Always --set serviceNameOverride="test-release-nginx-ingress" --set controller.name="" -f values.yaml - ``` - -6. Once the upgrade process has finished, use `kubectl describe` on the deployment to verify the change by reviewing its events: - - ```shell - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal ScalingReplicaSet 9m11s deployment-controller Scaled up replica set test-release-nginx-ingress- to 1 - Normal ScalingReplicaSet 101s deployment-controller Scaled up replica set test-release-nginx-ingress- to 1 - Normal ScalingReplicaSet 98s deployment-controller Scaled down replica set test-release-nginx-ingress- to 0 from 1 - ``` - -{{%/tab%}} - -{{}} - - -## Running Multiple Ingress Controllers - -If you are running multiple Ingress Controller releases in your cluster with enabled custom resources, the releases will share a single version of the CRDs. As a result, make sure that the Ingress Controller versions match the version of the CRDs. Additionally, when uninstalling a release, ensure that you don’t remove the CRDs until there are no other Ingress Controller releases running in the cluster. - -See [running multiple Ingress Controllers]({{< relref "installation/running-multiple-ingress-controllers.md" >}}) for more details. - -## Configuration - -The following tables lists the configurable parameters of the NGINX Ingress Controller chart and their default values. - -{{< table >}} -{{}} -|Parameter | Description | Default | -| --- | --- | --- | -| **controller.name** | The name of the Ingress Controller daemonset or deployment. | Autogenerated | -| **controller.kind** | The kind of the Ingress Controller installation - deployment or daemonset. | deployment | -| **controller.annotations** | Allows for setting of `annotations` for deployment or daemonset. | {} | -| **controller.nginxplus** | Deploys the Ingress Controller for NGINX Plus. | false | -| **controller.nginxReloadTimeout** | The timeout in milliseconds which the Ingress Controller will wait for a successful NGINX reload after a change or at the initial start. | 60000 | -| **controller.hostNetwork** | Enables the Ingress Controller pods to use the host's network namespace. | false | -| **controller.dnsPolicy** | DNS policy for the Ingress Controller pods. | ClusterFirst | -| **controller.nginxDebug** | Enables debugging for NGINX. Uses the `nginx-debug` binary. Requires `error-log-level: debug` in the ConfigMap via `controller.config.entries`. | false | -| **controller.logLevel** | The log level of the Ingress Controller. | 1 | -| **controller.image.digest** | The image digest of the Ingress Controller. | None | -| **controller.image.repository** | The image repository of the Ingress Controller. | nginx/nginx-ingress | -| **controller.image.tag** | The tag of the Ingress Controller image. | 3.5.1 | -| **controller.image.pullPolicy** | The pull policy for the Ingress Controller image. | IfNotPresent | -| **controller.lifecycle** | The lifecycle of the Ingress Controller pods. | {} | -| **controller.customConfigMap** | The name of the custom ConfigMap used by the Ingress Controller. If set, then the default config is ignored. | "" | -| **controller.config.name** | The name of the ConfigMap used by the Ingress Controller. | Autogenerated | -| **controller.config.annotations** | The annotations of the Ingress Controller configmap. | {} | -| **controller.config.entries** | The entries of the ConfigMap for customizing NGINX configuration. See [ConfigMap resource docs](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/) for the list of supported ConfigMap keys. | {} | -| **controller.customPorts** | A list of custom ports to expose on the NGINX Ingress Controller pod. Follows the conventional Kubernetes yaml syntax for container ports. | [] | -| **controller.defaultTLS.cert** | The base64-encoded TLS certificate for the default HTTPS server. **Note:** It is recommended that you specify your own certificate. Alternatively, omitting the default server secret completely will configure NGINX to reject TLS connections to the default server. | -| **controller.defaultTLS.key** | The base64-encoded TLS key for the default HTTPS server. **Note:** It is recommended that you specify your own key. Alternatively, omitting the default server secret completely will configure NGINX to reject TLS connections to the default server. | -| **controller.defaultTLS.secret** | The secret with a TLS certificate and key for the default HTTPS server. The value must follow the following format: `/`. Used as an alternative to specifying a certificate and key using `controller.defaultTLS.cert` and `controller.defaultTLS.key` parameters. **Note:** Alternatively, omitting the default server secret completely will configure NGINX to reject TLS connections to the default server. | None | -| **controller.wildcardTLS.cert** | The base64-encoded TLS certificate for every Ingress/VirtualServer host that has TLS enabled but no secret specified. If the parameter is not set, for such Ingress/VirtualServer hosts NGINX will break any attempt to establish a TLS connection. | None | -| **controller.wildcardTLS.key** | The base64-encoded TLS key for every Ingress/VirtualServer host that has TLS enabled but no secret specified. If the parameter is not set, for such Ingress/VirtualServer hosts NGINX will break any attempt to establish a TLS connection. | None | -| **controller.wildcardTLS.secret** | The secret with a TLS certificate and key for every Ingress/VirtualServer host that has TLS enabled but no secret specified. The value must follow the following format: `/`. Used as an alternative to specifying a certificate and key using `controller.wildcardTLS.cert` and `controller.wildcardTLS.key` parameters. | None | -| **controller.nodeSelector** | The node selector for pod assignment for the Ingress Controller pods. | {} | -| **controller.terminationGracePeriodSeconds** | The termination grace period of the Ingress Controller pod. | 30 | -| **controller.tolerations** | The tolerations of the Ingress Controller pods. | [] | -| **controller.affinity** | The affinity of the Ingress Controller pods. | {} | -| **controller.topologySpreadConstraints** | The topology spread constraints of the Ingress controller pods. | {} | -| **controller.env** | The additional environment variables to be set on the Ingress Controller pods. | [] | -| **controller.volumes** | The volumes of the Ingress Controller pods. | [] | -| **controller.volumeMounts** | The volumeMounts of the Ingress Controller pods. | [] | -| **controller.initContainers** | InitContainers for the Ingress Controller pods. | [] | -| **controller.extraContainers** | Extra (eg. sidecar) containers for the Ingress Controller pods. | [] | -| **controller.podSecurityContext**| The SecurityContext for Ingress Controller pods. | "seccompProfile": {"type": "RuntimeDefault"} | -| **controller.securityContext** | The SecurityContext for Ingress Controller container. | {} | -| **controller.initContainerSecurityContext** | The SecurityContext for Ingress Controller init container when `readOnlyRootFilesystem` is enabled by either setting `controller.securityContext.readOnlyRootFilesystem` or `controller.readOnlyRootFilesystem`to `true`. | {} | -| **controller.resources** | The resources of the Ingress Controller pods. | requests: cpu=100m,memory=128Mi | -| **controller.initContainerResources** | The resources of the init container which is used when `readOnlyRootFilesystem` is enabled by either setting `controller.securityContext.readOnlyRootFilesystem` or `controller.readOnlyRootFilesystem`to `true`. | requests: cpu=100m,memory=128Mi | -| **controller.replicaCount** | The number of replicas of the Ingress Controller deployment. | 1 | -| **controller.ingressClass.name** | A class of the Ingress Controller. An IngressClass resource with the name equal to the class must be deployed. Otherwise, the Ingress Controller will fail to start. The Ingress Controller only processes resources that belong to its class - i.e. have the "ingressClassName" field resource equal to the class. The Ingress Controller processes all the VirtualServer/VirtualServerRoute/TransportServer resources that do not have the "ingressClassName" field for all versions of Kubernetes. | nginx | -| **controller.ingressClass.create** | Creates a new IngressClass object with the name `controller.ingressClass.name`. Set to `false` to use an existing ingressClass created using `kubectl` with the same name. If you use `helm upgrade`, do not change the values from the previous release as helm will delete IngressClass objects managed by helm. If you are upgrading from a release earlier than 3.5.1, do not set the value to false. | true | -| **controller.ingressClass.setAsDefaultIngress** | New Ingresses without an `"ingressClassName"` field specified will be assigned the class specified in `controller.ingressClass.name`. Requires `controller.ingressClass.create`. | false | -| **controller.watchNamespace** | Comma separated list of namespaces the Ingress Controller should watch for resources. By default the Ingress Controller watches all namespaces. Mutually exclusive with `controller.watchNamespaceLabel`. Please note that if configuring multiple namespaces using the Helm cli `--set` option, the string needs to wrapped in double quotes and the commas escaped using a backslash - e.g. `--set controller.watchNamespace="default\,nginx-ingress"`. | "" | -| **controller.watchNamespaceLabel** | Configures the Ingress Controller to watch only those namespaces with label foo=bar. By default the Ingress Controller watches all namespaces. Mutually exclusive with `controller.watchNamespace`. | "" | -| **controller.watchSecretNamespace** | Comma separated list of namespaces the Ingress Controller should watch for resources of type Secret. If this arg is not configured, the Ingress Controller watches the same namespaces for all resources. See `controller.watchNamespace` and `controller.watchNamespaceLabel`. Please note that if configuring multiple namespaces using the Helm cli `--set` option, the string needs to wrapped in double quotes and the commas escaped using a backslash - e.g. `--set controller.watchSecretNamespace="default\,nginx-ingress"`. | "" | -| **controller.enableCustomResources** | Enable the custom resources. | true | -| **controller.enableOIDC** | Enable OIDC policies. | false | -| **controller.enableTLSPassthrough** | Enable TLS Passthrough on default port 443. Requires `controller.enableCustomResources`. | false | -| **controller.tlsPassThroughPort** | Set the port for the TLS Passthrough. Requires `controller.enableCustomResources` and `controller.enableTLSPassthrough`. | 443 | -| **controller.enableCertManager** | Enable x509 automated certificate management for VirtualServer resources using cert-manager (cert-manager.io). Requires `controller.enableCustomResources`. | false | -| **controller.enableExternalDNS** | Enable integration with ExternalDNS for configuring public DNS entries for VirtualServer resources using [ExternalDNS](https://github.com/kubernetes-sigs/external-dns). Requires `controller.enableCustomResources`. | false | -| **controller.globalConfiguration.create** | Creates the GlobalConfiguration custom resource. Requires `controller.enableCustomResources`. | false | -| **controller.globalConfiguration.spec** | The spec of the GlobalConfiguration for defining the global configuration parameters of the Ingress Controller. | {} | -| **controller.enableSnippets** | Enable custom NGINX configuration snippets in Ingress, VirtualServer, VirtualServerRoute and TransportServer resources. | false | -| **controller.healthStatus** | Add a location "/nginx-health" to the default server. The location responds with the 200 status code for any request. Useful for external health-checking of the Ingress Controller. | false | -| **controller.healthStatusURI** | Sets the URI of health status location in the default server. Requires `controller.healthStatus`. | "/nginx-health" | -| **controller.nginxStatus.enable** | Enable the NGINX stub_status, or the NGINX Plus API. | true | -| **controller.nginxStatus.port** | Set the port where the NGINX stub_status or the NGINX Plus API is exposed. | 8080 | -| **controller.nginxStatus.allowCidrs** | Add IP/CIDR blocks to the allow list for NGINX stub_status or the NGINX Plus API. Separate multiple IP/CIDR by commas. | 127.0.0.1,::1 | -| **controller.priorityClassName** | The PriorityClass of the Ingress Controller pods. | None | -| **controller.service.create** | Creates a service to expose the Ingress Controller pods. | true | -| **controller.service.type** | The type of service to create for the Ingress Controller. | LoadBalancer | -| **controller.service.externalTrafficPolicy** | The externalTrafficPolicy of the service. The value Local preserves the client source IP. | Local | -| **controller.service.annotations** | The annotations of the Ingress Controller service. | {} | -| **controller.service.extraLabels** | The extra labels of the service. | {} | -| **controller.service.loadBalancerIP** | The static IP address for the load balancer. Requires `controller.service.type` set to `LoadBalancer`. The cloud provider must support this feature. | "" | -| **controller.service.externalIPs** | The list of external IPs for the Ingress Controller service. | [] | -| **controller.service.clusterIP** | The clusterIP for the Ingress Controller service, autoassigned if not specified. | "" | -| **controller.service.loadBalancerSourceRanges** | The IP ranges (CIDR) that are allowed to access the load balancer. Requires `controller.service.type` set to `LoadBalancer`. The cloud provider must support this feature. | [] | -| **controller.service.name** | The name of the service. | Autogenerated | -| **controller.service.customPorts** | A list of custom ports to expose through the Ingress Controller service. Follows the conventional Kubernetes yaml syntax for service ports. | [] | -| **controller.service.httpPort.enable** | Enables the HTTP port for the Ingress Controller service. | true | -| **controller.service.httpPort.port** | The HTTP port of the Ingress Controller service. | 80 | -| **controller.service.httpPort.nodePort** | The custom NodePort for the HTTP port. Requires `controller.service.type` set to `NodePort`. | "" | -| **controller.service.httpPort.targetPort** | The target port of the HTTP port of the Ingress Controller service. | 80 | -| **controller.service.httpsPort.enable** | Enables the HTTPS port for the Ingress Controller service. | true | -| **controller.service.httpsPort.port** | The HTTPS port of the Ingress Controller service. | 443 | -| **controller.service.httpsPort.nodePort** | The custom NodePort for the HTTPS port. Requires `controller.service.type` set to `NodePort`. | "" | -| **controller.service.httpsPort.targetPort** | The target port of the HTTPS port of the Ingress Controller service. | 443 | -| **controller.serviceAccount.annotations** | The annotations of the Ingress Controller service account. | {} | -| **controller.serviceAccount.name** | The name of the service account of the Ingress Controller pods. Used for RBAC. | Autogenerated | -| **controller.serviceAccount.imagePullSecretName** | The name of the secret containing docker registry credentials. Secret must exist in the same namespace as the helm release. | "" | -| **controller.serviceAccount.imagePullSecretsNames** | The list of secret names containing docker registry credentials. Secret must exist in the same namespace as the helm release. | [] | -| **controller.serviceMonitor.name** | The name of the serviceMonitor. | Autogenerated | -| **controller.serviceMonitor.create** | Create a ServiceMonitor custom resource. | false | -| **controller.serviceMonitor.labels** | Kubernetes object labels to attach to the serviceMonitor object. | "" | -| **controller.serviceMonitor.selectorMatchLabels** | A set of labels to allow the selection of endpoints for the ServiceMonitor. | "" | -| **controller.serviceMonitor.endpoints** | A list of endpoints allowed as part of this ServiceMonitor. | "" | -| **controller.reportIngressStatus.enable** | Updates the address field in the status of Ingress resources with an external address of the Ingress Controller. You must also specify the source of the external address either through an external service via `controller.reportIngressStatus.externalService`, `controller.reportIngressStatus.ingressLink` or the `external-status-address` entry in the ConfigMap via `controller.config.entries`. **Note:** `controller.config.entries.external-status-address` takes precedence over the others. | true | -| **controller.reportIngressStatus.externalService** | Specifies the name of the service with the type LoadBalancer through which the Ingress Controller is exposed externally. The external address of the service is used when reporting the status of Ingress, VirtualServer and VirtualServerRoute resources. `controller.reportIngressStatus.enable` must be set to `true`. The default is autogenerated and enabled when `controller.service.create` is set to `true` and `controller.service.type` is set to `LoadBalancer`. | Autogenerated | -| **controller.reportIngressStatus.ingressLink** | Specifies the name of the IngressLink resource, which exposes the Ingress Controller pods via a BIG-IP system. The IP of the BIG-IP system is used when reporting the status of Ingress, VirtualServer and VirtualServerRoute resources. `controller.reportIngressStatus.enable` must be set to `true`. | "" | -| **controller.reportIngressStatus.enableLeaderElection** | Enable Leader election to avoid multiple replicas of the controller reporting the status of Ingress resources. `controller.reportIngressStatus.enable` must be set to `true`. | true | -| **controller.reportIngressStatus.leaderElectionLockName** | Specifies the name of the ConfigMap, within the same namespace as the controller, used as the lock for leader election. controller.reportIngressStatus.enableLeaderElection must be set to true. | Autogenerated | -| **controller.reportIngressStatus.annotations** | The annotations of the leader election configmap. | {} | -| **controller.pod.annotations** | The annotations of the Ingress Controller pod. | {} | -| **controller.pod.extraLabels** | The additional extra labels of the Ingress Controller pod. | {} | -| **controller.appprotect.enable** | Enables the App Protect WAF module in the Ingress Controller. | false | -| **controller.appprotectdos.enable** | Enables the App Protect DoS module in the Ingress Controller. | false | -| **controller.appprotectdos.debug** | Enable debugging for App Protect DoS. | false | -| **controller.appprotectdos.maxDaemons** | Max number of ADMD instances. | 1 | -| **controller.appprotectdos.maxWorkers** | Max number of nginx processes to support. | Number of CPU cores in the machine | -| **controller.appprotectdos.memory** | RAM memory size to consume in MB. | 50% of free RAM in the container or 80MB, the smaller | -| **controller.readyStatus.enable** | Enables the readiness endpoint `"/nginx-ready"`. The endpoint returns a success code when NGINX has loaded all the config after the startup. This also configures a readiness probe for the Ingress Controller pods that uses the readiness endpoint. | true | -| **controller.readyStatus.port** | The HTTP port for the readiness endpoint. | 8081 | -| **controller.readyStatus.initialDelaySeconds** | The number of seconds after the Ingress Controller pod has started before readiness probes are initiated. | 0 | -| **controller.enableLatencyMetrics** | Enable collection of latency metrics for upstreams. Requires `prometheus.create`. | false | -| **controller.minReadySeconds** | Specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. [docs](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) | 0 | -| **controller.autoscaling.enabled** | Enables HorizontalPodAutoscaling. | false | -| **controller.autoscaling.annotations** | The annotations of the Ingress Controller HorizontalPodAutoscaler. | {} | -| **controller.autoscaling.behavior** | Behavior configuration for the HPA. | {} | -| **controller.autoscaling.minReplicas** | Minimum number of replicas for the HPA. | 1 | -| **controller.autoscaling.maxReplicas** | Maximum number of replicas for the HPA. | 3 | -| **controller.autoscaling.targetCPUUtilizationPercentage** | The target CPU utilization percentage. | 50 | -| **controller.autoscaling.targetMemoryUtilizationPercentage** | The target memory utilization percentage. | 50 | -| **controller.podDisruptionBudget.enabled** | Enables PodDisruptionBudget. | false | -| **controller.podDisruptionBudget.annotations** | The annotations of the Ingress Controller pod disruption budget | {} | -| **controller.podDisruptionBudget.minAvailable** | The number of Ingress Controller pods that should be available. This is a mutually exclusive setting with "maxUnavailable". | 0 | -| **controller.podDisruptionBudget.maxUnavailable** | The number of Ingress Controller pods that can be unavailable. This is a mutually exclusive setting with "minAvailable". | 0 | -| **controller.strategy** | Specifies the strategy used to replace old Pods with new ones. Docs for [Deployment update strategy](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy) and [Daemonset update strategy](https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/#daemonset-update-strategy) | {} | -| **controller.disableIPV6** | Disable IPV6 listeners explicitly for nodes that do not support the IPV6 stack. | false | -| **controller.defaultHTTPListenerPort** | Sets the port for the HTTP `default_server` listener. | 80 | -| **controller.defaultHTTPSListenerPort** | Sets the port for the HTTPS `default_server` listener. | 443 | -| **controller.readOnlyRootFilesystem** | Configure root filesystem as read-only and add volumes for temporary data. Three major releases after 3.5.x this argument will be moved permanently to the `controller.securityContext` section. | false | -| **controller.enableSSLDynamicReload** | Enable lazy loading for SSL Certificates. | true | -| **controller.telemetryReporting.enable** | Enable telemetry reporting. | true | -| **controller.enableWeightChangesDynamicReload** | Enable weight changes without reloading the NGINX configuration. May require increasing `map_hash_bucket_size`, `map_hash_max_size`, `variable_hash_bucket_size`, and `variable_hash_max_size` in the [ConfigMap](https://docs.nginx.com/nginx-ingress-controller/configuration/global-configuration/configmap-resource/) if there are many two-way splits. Requires `controller.nginxplus` | false | -| **rbac.create** | Configures RBAC. | true | -| **prometheus.create** | Expose NGINX or NGINX Plus metrics in the Prometheus format. | true | -| **prometheus.port** | Configures the port to scrape the metrics. | 9113 | -| **prometheus.scheme** | Configures the HTTP scheme to use for connections to the Prometheus endpoint. | http | -| **prometheus.secret** | The namespace / name of a Kubernetes TLS Secret. If specified, this secret is used to secure the Prometheus endpoint with TLS connections. | "" | -| **prometheus.service.create** | Create a Headless service to expose prometheus metrics. Requires `prometheus.create`. | false | -| **prometheus.service.labels** | Kubernetes object labels to attach to the service object. | {service: "nginx-ingress-prometheus-service"} | -| **prometheus.serviceMonitor.create** | Create a ServiceMonitor custom resource. Requires ServiceMonitor CRD to be installed. For the latest CRD, check the latest release on the [prometheus-operator](https://github.com/prometheus-operator/prometheus-operator) GitHub repo under `example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml` | false | -| **prometheus.serviceMonitor.labels** | Kubernetes object labels to attach to the serviceMonitor object. | {} | -| **prometheus.serviceMonitor.selectorMatchLabels** | A set of labels to allow the selection of endpoints for the ServiceMonitor. | {service: "nginx-ingress-prometheus-service"} | -| **prometheus.serviceMonitor.endpoints** | A list of endpoints allowed as part of this ServiceMonitor. | [port: prometheus] | -| **serviceInsight.create** | Expose NGINX Plus Service Insight endpoint. | false | -| **serviceInsight.port** | Configures the port to expose endpoints. | 9114 | -| **serviceInsight.scheme** | Configures the HTTP scheme to use for connections to the Service Insight endpoint. | http | -| **serviceInsight.secret** | The namespace / name of a Kubernetes TLS Secret. If specified, this secret is used to secure the Service Insight endpoint with TLS connections. | "" | -| **serviceNameOverride** | Used to prevent cloud load balancers from being replaced due to service name change during helm upgrades. | "" | -| **nginxServiceMesh.enable** | Enable integration with NGINX Service Mesh. See the NGINX Service Mesh [docs](https://docs.nginx.com/nginx-service-mesh/tutorials/kic/deploy-with-kic/) for more details. Requires `controller.nginxplus`. | false | -| **nginxServiceMesh.enableEgress** | Enable NGINX Service Mesh workloads to route egress traffic through the Ingress Controller. See the NGINX Service Mesh [docs](https://docs.nginx.com/nginx-service-mesh/tutorials/kic/deploy-with-kic/#enabling-egress) for more details. Requires `nginxServiceMesh.enable`. | false | -|**nginxAgent.enable** | Enable NGINX Agent to integrate the Security Monitoring and App Protect WAF modules. Requires `controller.appprotect.enable`. | false | -|**nginxAgent.instanceGroup** | Set a custom Instance Group name for the deployment, shown when connected to NGINX Instance Manager. `nginx-ingress.controller.fullname` will be used if not set. | "" | -|**nginxAgent.logLevel** | Log level for NGINX Agent. | "error | -|**nginxAgent.instanceManager.host** | FQDN or IP for connecting to NGINX Ingress Controller. Required when `nginxAgent.enable` is set to `true` | "" | -|**nginxAgent.instanceManager.grpcPort** | Port for connecting to NGINX Ingress Controller. | 443 | -|**nginxAgent.instanceManager.sni** | Server Name Indication for Instance Manager. See the NGINX Agent [docs](https://docs.nginx.com/nginx-agent/configuration/encrypt-communication/) for more details. | "" | -|**nginxAgent.instanceManager.tls.enable** | Enable TLS for Instance Manager connection. | true | -|**nginxAgent.instanceManager.tls.skipVerify** | Skip certification verification for Instance Manager connection. | false | -|**nginxAgent.instanceManager.tls.caSecret** | Name of `nginx.org/ca` secret used for verification of Instance Manager TLS. | "" | -|**nginxAgent.instanceManager.tls.secret** | Name of `kubernetes.io/tls` secret with a TLS certificate and key for using mTLS between NGINX Agent and Instance Manager. See the NGINX Instance Manager [docs](https://docs.nginx.com/nginx-management-suite/admin-guides/configuration/secure-traffic/#mutual-client-certificate-auth-setup-mtls) and the NGINX Agent [docs](https://docs.nginx.com/nginx-agent/configuration/encrypt-communication/) for more details. | "" | -|**nginxAgent.syslog.host** | Address for NGINX Agent to run syslog listener. | 127.0.0.1 | -|**nginxAgent.syslog.port** | Port for NGINX Agent to run syslog listener. | 1514 | -|**nginxAgent.napMonitoring.collectorBufferSize** | Buffer size for collector. Will contain log lines and parsed log lines. | 50000 | -|**nginxAgent.napMonitoring.processorBufferSize** | Buffer size for processor. Will contain log lines and parsed log lines. | 50000 | -|**nginxAgent.customConfigMap** | The name of a custom ConfigMap to use instead of the one provided by default. | "" | -{{}} -{{< /table >}} - -## Notes - -- The values-icp.yaml file is used for deploying the Ingress Controller on IBM Cloud Private. See the [blog post](https://www.nginx.com/blog/nginx-ingress-controller-ibm-cloud-private/) for more details. -- The values-nsm.yaml file is used for deploying the Ingress Controller with NGINX Service Mesh. See the NGINX Service Mesh [docs](https://docs.nginx.com/nginx-service-mesh/tutorials/kic/deploy-with-kic/) for more details. diff --git a/docs/content/installation/installing-nic/installation-with-manifests.md b/docs/content/installation/installing-nic/installation-with-manifests.md deleted file mode 100644 index 4f7c9525ac..0000000000 --- a/docs/content/installation/installing-nic/installation-with-manifests.md +++ /dev/null @@ -1,303 +0,0 @@ ---- -docs: DOCS-603 -doctypes: -- '' -title: Installation with Manifests -toc: true -weight: 200 ---- - -This guide explains how to use Manifests to install NGINX Ingress Controller, then create both common and custom resources and set up role-based access control. - -## Before you start - -### Get the NGINX Controller Image - -{{}} Always use the latest stable release listed on the [releases page]({{< relref "releases.md" >}}). {{}} - -Choose one of the following methods to get the NGINX Ingress Controller image: - -- **NGINX Ingress Controller**: Download the image `nginx/nginx-ingress` from [DockerHub](https://hub.docker.com/r/nginx/nginx-ingress). -- **NGINX Plus Ingress Controller**: You have two options for this, both requiring an NGINX Ingress Controller subscription. - - - Download the image using your NGINX Ingress Controller subscription certificate and key. Read the [Getting the F5 Registry NGINX Ingress Controller Image]({{< relref "installation/nic-images/pulling-ingress-controller-image.md" >}}) guide. - - Use your NGINX Ingress Controller subscription JWT token to get the image: Read the [Getting the NGINX Ingress Controller Image with JWT]({{< relref "installation/nic-images/using-the-jwt-token-docker-secret.md" >}}). - -- **Build your own image**: To build your own image, follow the [Building NGINX Ingress Controller]({{< relref "installation/building-nginx-ingress-controller.md" >}}) guide. - -### Clone the repository - -Clone the NGINX Ingress Controller repository using the command shown below, and replace `` with the specific release you want to use. - -```shell -git clone https://github.com/nginxinc/kubernetes-ingress.git --branch -``` - -For example, if you want to use version 3.5.1, the command would be `git clone https://github.com/nginxinc/kubernetes-ingress.git --branch v3.5.1`. - -This guide assumes you are using the latest release. - -Change the active directory. - -```shell -cd kubernetes-ingress -``` - -### App Protect DoS - -To use App Protect DoS, install the App Protect DoS Arbitrator using the provided manifests in the same namespace as the NGINX Ingress Controller. If you install multiple NGINX Ingress Controllers in the same namespace, they will need to share the same Arbitrator because there can only be one Arbitrator in a single namespace. - ---- - -## Set up role-based access control (RBAC) {#configure-rbac} - -{{< include "rbac/set-up-rbac.md" >}} - ---- - -## Create common resources {#create-common-resources} - -{{< include "installation/create-common-resources.md" >}} - ---- - -## Create custom resources {#create-custom-resources} - -{{< include "installation/create-custom-resources.md" >}} - -{{}} - -{{%tab name="Install CRDs from single YAML"%}} - -### Core custom resource definitions - -1. Create CRDs for [VirtualServer and VirtualServerRoute]({{< relref "configuration/virtualserver-and-virtualserverroute-resources.md" >}}), [TransportServer]({{< relref "configuration/transportserver-resource.md" >}}), [Policy]({{< relref "configuration/policy-resource.md" >}}) and [GlobalConfiguration]({{< relref "configuration/global-configuration/globalconfiguration-resource.md" >}}): - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds.yaml - ``` - -### Optional custom resource definitions - -1. For the NGINX App Protect WAF module, create CRDs for `APPolicy`, `APLogConf` and `APUserSig`: - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds-nap-waf.yaml - ``` - -2. For the NGINX App Protect DoS module, create CRDs for `APDosPolicy`, `APDosLogConf` and `DosProtectedResource`: - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds-nap-dos.yaml - ``` - -{{%/tab%}} - -{{%tab name="Install CRDs after cloning the repo"%}} - -If you are installing the CRDs this way, ensure that you have first [cloned the repository](#clone-the-repository) - -### Core custom resource definitions - -1. Create CRDs for [VirtualServer and VirtualServerRoute]({{< relref "configuration/virtualserver-and-virtualserverroute-resources.md" >}}), [TransportServer]({{< relref "configuration/transportserver-resource.md" >}}), [Policy]({{< relref "configuration/policy-resource.md" >}}) and [GlobalConfiguration]({{< relref "configuration/global-configuration/globalconfiguration-resource.md" >}}): - - ```shell - kubectl apply -f config/crd/bases/k8s.nginx.org_virtualservers.yaml - kubectl apply -f config/crd/bases/k8s.nginx.org_virtualserverroutes.yaml - kubectl apply -f config/crd/bases/k8s.nginx.org_transportservers.yaml - kubectl apply -f config/crd/bases/k8s.nginx.org_policies.yaml - kubectl apply -f config/crd/bases/k8s.nginx.org_globalconfigurations.yaml - ``` -### Optional custom resource definitions - -{{< note >}} This step can be skipped if you are using App Protect WAF module with policy bundles. {{< /note >}} - -1. For the NGINX App Protect WAF module, create CRDs for `APPolicy`, `APLogConf` and `APUserSig`: - - ```shell - kubectl apply -f config/crd/bases/appprotect.f5.com_aplogconfs.yaml - kubectl apply -f config/crd/bases/appprotect.f5.com_appolicies.yaml - kubectl apply -f config/crd/bases/appprotect.f5.com_apusersigs.yaml - ``` - -2. For the NGINX App Protect DoS module, create CRDs for `APDosPolicy`, `APDosLogConf` and `DosProtectedResource`: - - ```shell - kubectl apply -f config/crd/bases/appprotectdos.f5.com_apdoslogconfs.yaml - kubectl apply -f config/crd/bases/appprotectdos.f5.com_apdospolicy.yaml - kubectl apply -f config/crd/bases/appprotectdos.f5.com_dosprotectedresources.yaml - ``` -{{%/tab%}} - -{{}} - ---- - -## Deploy NGINX Ingress Controller {#deploy-ingress-controller} - -You have two options for deploying NGINX Ingress Controller: - -- **Deployment**. Choose this method for the flexibility to dynamically change the number of NGINX Ingress Controller replicas. -- **DaemonSet**. Choose this method if you want NGINX Ingress Controller to run on all nodes or a subset of nodes. - -Before you start, update the [command-line arguments]({{< relref "configuration/global-configuration/command-line-arguments.md" >}}) for the NGINX Ingress Controller container in the relevant manifest file to meet your specific requirements. - -### Using a Deployment - -{{< include "installation/manifests/deployment.md" >}} - -### Using a DaemonSet - -{{< include "installation/manifests/daemonset.md" >}} - ---- - -## Confirm NGINX Ingress Controller is running - -{{< include "installation/manifests/verify-pods-are-running.md" >}} - ---- - -## How to access NGINX Ingress Controller - -### Using a Deployment - -For Deployments, you have two options for accessing NGINX Ingress Controller pods. - -#### Option 1: Create a NodePort service - -For more information about the _NodePort_ service, refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport). - -1. To create a service of type *NodePort*, run: - - ```shell - kubectl create -f deployments/service/nodeport.yaml - ``` - - Kubernetes automatically allocates two ports on every node in the cluster. You can access NGINX Ingress Controller by combining any node's IP address with these ports. - -#### Option 2: Create a LoadBalancer service - -For more information about the _LoadBalancer_ service, refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer). - -1. To set up a _LoadBalancer_ service, run one of the following commands based on your cloud provider: - - - GCP or Azure: - - ```shell - kubectl apply -f deployments/service/loadbalancer.yaml - ``` - - - AWS: - - ```shell - kubectl apply -f deployments/service/loadbalancer-aws-elb.yaml - ``` - - If you're using AWS, Kubernetes will set up a Classic Load Balancer (ELB) in TCP mode. This load balancer will have the PROXY protocol enabled to pass along the client's IP address and port. - -2. AWS users: Follow these additional steps to work with ELB in TCP mode. - - - Add the following keys to the `nginx-config.yaml` ConfigMap file, which you created in the [Create common resources](#create-common-resources) section. - - ```yaml - proxy-protocol: "True" - real-ip-header: "proxy_protocol" - set-real-ip-from: "0.0.0.0/0" - ``` - - - Update the ConfigMap: - - ```shell - kubectl apply -f deployments/common/nginx-config.yaml - ``` - - {{}}AWS users have more customization options for their load balancers. These include choosing the load balancer type and configuring SSL termination. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) to learn more. {{}} - -3. To access NGINX Ingress Controller, get the public IP of your load balancer. - - - For GCP or Azure, run: - - ```shell - kubectl get svc nginx-ingress --namespace=nginx-ingress - ``` - - - For AWS find the DNS name: - - ```shell - kubectl describe svc nginx-ingress --namespace=nginx-ingress - ``` - - Resolve the DNS name into an IP address using `nslookup`: - - ```shell - nslookup - ``` - - You can also find more details about the public IP in the status section of an ingress resource. For more details, refer to the [Reporting Resources Status doc]({{< relref "configuration/global-configuration/reporting-resources-status.md" >}}). - -### Using a DaemonSet - -Connect to ports 80 and 443 using the IP address of any node in the cluster where NGINX Ingress Controller is running. - ---- - -## Uninstall NGINX Ingress Controller - -{{}}Proceed with caution when performing these steps, as they will remove NGINX Ingress Controller and all related resources, potentially affecting your running services.{{}} - -1. **Delete the nginx-ingress namespace**: To remove NGINX Ingress Controller and all auxiliary resources, run: - - ```shell - kubectl delete namespace nginx-ingress - ``` - -2. **Remove the cluster role and cluster role binding**: - - ```shell - kubectl delete clusterrole nginx-ingress - kubectl delete clusterrolebinding nginx-ingress - ``` - -3. **Delete the Custom Resource Definitions**: - - {{}} - - {{%tab name="Deleting CRDs from single YAML"%}} - - 1. Delete core custom resource definitions: - ```shell - kubectl delete -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds.yaml - ``` - 2. Delete custom resource definitions for the NGINX App Protect WAF module: - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds-nap-waf.yaml - ``` - - 3. Delete custom resource definitions for the NGINX App Protect DoS module: - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds-nap-dos.yaml - ``` - {{%/tab%}} - - {{%tab name="Deleting CRDs after cloning the repo"%}} - - 1. Delete core custom resource definitions: - ```shell - kubectl delete -f config/crd/bases/crds.yaml - ``` - 2. Delete custom resource definitions for the NGINX App Protect WAF module: - - ```shell - kubectl apply -f config/crd/bases/crds-nap-waf.yaml - ``` - - 3. Delete custom resource definitions for the NGINX App Protect DoS module: - ```shell - kubectl apply -f config/crd/bases/crds-nap-dos.yaml - ``` - - {{%/tab%}} - - {{}} diff --git a/docs/content/installation/installing-nic/installation-with-operator.md b/docs/content/installation/installing-nic/installation-with-operator.md deleted file mode 100644 index 72d65f89b0..0000000000 --- a/docs/content/installation/installing-nic/installation-with-operator.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -docs: DOCS-604 -doctypes: -- '' -title: Installation with the NGINX Ingress Operator -toc: true -weight: 300 ---- - -This document explains how to use NGINX Ingress Operator to install NGINX Ingress Controller. - -## Before you start - -{{}} We recommend the most recent stable version of NGINX Ingress Controller, available on the GitHub repository's [releases page]({{< relref "releases.md" >}}). {{}} - -1. Make sure you have access to the NGINX Ingress Controller image: - - - For NGINX Ingress Controller, use the image `nginx/nginx-ingress` from [DockerHub](https://hub.docker.com/r/nginx/nginx-ingress). - - For NGINX Plus Ingress Controller, see [here]({{< relref "installation/nic-images/pulling-ingress-controller-image" >}}) for details on how to pull the image from the F5 Docker registry. - - To pull from the F5 Container registry, configure a docker registry secret using your JWT token from the MyF5 portal by following the instructions from [here]({{< relref "installation/nic-images/using-the-jwt-token-docker-secret" >}}). - - It is also possible to build your own image and push it to your private Docker registry by following the instructions from [here]({{< relref "installation/building-nginx-ingress-controller.md" >}})). - -2. Install the NGINX Ingress Operator following the [instructions](https://github.com/nginxinc/nginx-ingress-helm-operator/blob/main/docs/installation.md). -3. Create the SecurityContextConstraint as outlined in the ["Getting Started" instructions](https://github.com/nginxinc/nginx-ingress-helm-operator/blob/main/README.md#getting-started). - -{{}} If you're upgrading your operator installation to a later release, navigate [here](https://github.com/nginxinc/nginx-ingress-helm-operator/blob/main/helm-charts/nginx-ingress) and run `kubectl apply -f crds/` or `oc apply -f crds/` as a prerequisite{{}} - -## Create the NGINX Ingress Controller manifest - -Create a manifest `nginx-ingress-controller.yaml` with the following content: - -```yaml -apiVersion: charts.nginx.org/v1alpha1 -kind: NginxIngress -metadata: - name: nginxingress-sample - namespace: nginx-ingress -spec: - controller: - image: - pullPolicy: IfNotPresent - repository: nginx/nginx-ingress - tag: 3.5.1-ubi - ingressClass: - name: nginx - kind: deployment - nginxplus: false - replicaCount: 1 - serviceAccount: - imagePullSecretName: "" -``` - -{{}}For NGINX Plus, change the `image.repository` and `image.tag` values and change `nginxPlus` to `True`. If required, set the `serviceAccount.imagePullSecretName` or `serviceAccount.imagePullSecretsNames` to the name of the pre-created docker config secret that should be associated with the ServiceAccount.{{}} - -## Deploy NGINX Ingress Controller - -```shell -kubectl apply -f nginx-ingress-controller.yaml -``` - -A new instance of NGINX Ingress Controller will be deployed by the NGINX Ingress Operator in the `default` namespace with default parameters. - -To configure other parameters of the NginxIngressController resource, check the [documentation](https://github.com/nginxinc/nginx-ingress-helm-operator/blob/main/docs/nginx-ingress-controller.md). - -## Troubleshooting - -If you experience an `OOMkilled` error when deploying the NGINX Ingress Operator in a large cluster, it's likely because the Helm operator is caching all Kubernetes objects and using up too much memory. If you encounter this issue, try the following solutions: - -- Set the operator to only watch one namespace. -- If monitoring multiple namespaces is required, consider manually increasing the memory limit for the operator. Keep in mind that this value might be overwritten after a release update. - -We are working with the OpenShift team to resolve this issue. diff --git a/docs/content/installation/integrations/_index.md b/docs/content/installation/integrations/_index.md deleted file mode 100644 index e1c0b2f103..0000000000 --- a/docs/content/installation/integrations/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Integrations -description: -weight: 600 ---- diff --git a/docs/content/installation/integrations/app-protect-dos/_index.md b/docs/content/installation/integrations/app-protect-dos/_index.md deleted file mode 100644 index 2cd1a1fd30..0000000000 --- a/docs/content/installation/integrations/app-protect-dos/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: NGINX App Protect DoS -description: Learn how to use NGINX Ingress Controller for Kubernetes with NGINX App Protect DoS. -weight: 200 -menu: - docs: - parent: Integrations ---- diff --git a/docs/content/installation/integrations/app-protect-dos/configuration.md b/docs/content/installation/integrations/app-protect-dos/configuration.md deleted file mode 100644 index f7d96fadb6..0000000000 --- a/docs/content/installation/integrations/app-protect-dos/configuration.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -docs: DOCS-580 -doctypes: -- '' -title: Configuration -toc: true -weight: 200 ---- - -This document describes how to configure the NGINX App Protect DoS module. - -> Check out the complete [NGINX Ingress Controller with App Protect DoS example for VirtualServer](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources/app-protect-dos) and the [NGINX Ingress Controller with App Protect DoS example for Ingress](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-dos). - -## App Protect DoS Configuration - -A `DosProtectedResource` is a [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) that holds the configuration of a collection of protected resources. -An [Ingress]({{< relref "configuration/ingress-resources/basic-configuration" >}}), [VirtualServer and VirtualServerRoute]({{< relref "configuration/virtualserver-and-virtualserverroute-resources.md" >}}) can be protected by specifying a reference to the DosProtectedResource. - -1. Create an `DosProtectedResource` Custom resource manifest. As an example: - - ```yaml -apiVersion: appprotectdos.f5.com/v1beta1 -kind: DosProtectedResource -metadata: - name: dos-protected -spec: - enable: true - name: "webapp.example.com" - apDosMonitor: - uri: "webapp.example.com" - protocol: "http1" - timeout: 5 - ``` - -2. Enable App Protect DoS for an Ingress resource by adding an annotation to the Ingress. Set the value of the annotation to the qualified identifier(`namespace/name`) of a DosProtectedResource: - - ```yaml - apiVersion: networking.k8s.io/v1 - kind: Ingress - metadata: - name: webapp-ingress - annotations: - appprotectdos.f5.com/app-protect-dos-resource: "default/dos-protected" - ``` - -3. Enable App Protect DoS on a VirtualServer resource by setting the `dos` field value to the qualified identifier(`namespace/name`) of a DosProtectedResource: - - ```yaml -apiVersion: k8s.nginx.org/v1 -kind: VirtualServer -metadata: - name: webapp -spec: - host: webapp.example.com - upstreams: - - name: webapp - service: webapp-svc - port: 80 - routes: - - path: / - dos: dos-protected - action: - pass: webapp - ``` - -## DoS Policy Configuration - -You can configure the policy for DoS by creating an `APDosPolicy` [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) and specifying the qualified identifier(`namespace/name`) of the `ApDosPolicy` in the `DosProtectedResource`. - -For example, say you want to use DoS Policy as shown below: - - ```json - { - mitigation_mode: "standard", - signatures: "on", - bad_actors: "on", - automation_tools_detection: "on", - tls_fingerprint: "on", - } - ``` - -Create an `APDosPolicy` resource with the policy defined in the `spec`, as shown below: - - ```yaml - apiVersion: appprotectdos.f5.com/v1beta1 - kind: APDosPolicy - metadata: - name: dospolicy - spec: - mitigation_mode: "standard" - signatures: "on" - bad_actors: "on" - automation_tools_detection: "on" - tls_fingerprint: "on" - ``` - -Then add a reference in the `DosProtectedResource` to the `ApDosPolicy`: - - ```yaml - apiVersion: appprotectdos.f5.com/v1beta1 - kind: DosProtectedResource - metadata: - name: dos-protected - spec: - enable: true - name: "my-dos" - apDosMonitor: - uri: "webapp.example.com" - apDosPolicy: "default/dospolicy" - ``` - -## App Protect DoS Logs {#app-protect-dos-logs} - -You can set the [App Protect DoS Log configuration](/nginx-app-protect-dos/monitoring/types-of-logs/) by creating an `APDosLogConf` [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) and specifying the qualified identifier(`namespace/name`) of the `ApDosLogConf` in the `DosProtectedResource`. - -For example, say you want to log state changing requests for your Ingress resources using App Protect DoS. The App Protect DoS log configuration looks like this: - -```json -{ - "filter": { - "traffic-mitigation-stats": "all", - "bad-actors": "top 10", - "attack-signatures": "top 10" - } -} -``` - -You would add that config in the `spec` of your `APDosLogConf` resource as follows: - -```yaml -apiVersion: appprotectdos.f5.com/v1beta1 -kind: APDosLogConf -metadata: - name: doslogconf -spec: - filter: - traffic-mitigation-stats: all - bad-actors: top 10 - attack-signatures: top 10 -``` - -Then add a reference in the `DosProtectedResource` to the `APDosLogConf`: - - ```yaml - apiVersion: appprotectdos.f5.com/v1beta1 - kind: DosProtectedResource - metadata: - name: dos-protected - spec: - enable: true - name: "my-dos" - apDosMonitor: - uri: "webapp.example.com" - dosSecurityLog: - enable: true - apDosLogConf: "doslogconf" - dosLogDest: "syslog-svc.default.svc.cluster.local:514" - ``` - -## Global Configuration - -NGINX Ingress Controller has a set of global configuration parameters that align with those available in the NGINX App Protect DoS module. See [ConfigMap keys]({{< relref "configuration/global-configuration/configmap-resource.md#modules" >}}) for the complete list. The App Protect parameters use the `app-protect-dos*` prefix. diff --git a/docs/content/installation/integrations/app-protect-dos/dos-protected.md b/docs/content/installation/integrations/app-protect-dos/dos-protected.md deleted file mode 100644 index fcc42aff2d..0000000000 --- a/docs/content/installation/integrations/app-protect-dos/dos-protected.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -docs: DOCS-581 -doctypes: -- '' -title: DoS protected resource specification -toc: true -weight: 300 ---- - -NGINX App Protect DoS protected resource specification - -{{< note >}} This feature is only available using the NGINX Plus [NGINX App Protect DoS Module](/nginx-app-protect-dos/deployment-guide/learn-about-deployment/). {{< /note >}} - -## DoS Protected resource specification - -Below is an example of a DoS protected resource. - -```yaml -apiVersion: appprotectdos.f5.com/v1beta1 -kind: DosProtectedResource -metadata: - name: dos-protected -spec: - enable: true - name: "my-dos" - apDosMonitor: - uri: "webapp.example.com" -``` - -{{% table %}} -|Field | Description | Type | Required | -| ---| ---| ---| --- | -|``enable`` | Enables NGINX App Protect DoS, Default value: false. | ``bool`` | No | -|``name`` | Name of the protected object, max of 63 characters. | ``string`` | Yes | -|``dosAccessLogDest`` | The log destination for the access log with dos log format. Accepted variables are ``syslog:server=:``, ``stderr``, ````. | ``string`` | No | -|``apDosMonitor.uri`` | The destination to the desired protected object. [App Protect DoS monitor](#dosprotectedresourceapdosmonitor) Default value: None, URL will be extracted from the first request which arrives and taken from "Host" header or from destination ip+port. | ``string`` | No | -|``apDosMonitor.protocol`` | Determines if the server listens on http1 / http2 / grpc / websocket. [App Protect DoS monitor](#dosprotectedresourceapdosmonitor) Default value: http1. | ``enum`` | No | -|``apDosMonitor.timeout`` | Determines how long (in seconds) should NGINX App Protect DoS wait for a response. [App Protect DoS monitor](#dosprotectedresourceapdosmonitor) Default value: 10 seconds for http1/http2 and 5 seconds for grpc. | ``int64`` | No | -|``apDosPolicy`` | The [App Protect DoS policy](#dosprotectedresourceapdospolicy) of the dos. Accepts an optional namespace. | ``string`` | No | -|``dosSecurityLog.enable`` | Enables security log. | ``bool`` | No | -|``dosSecurityLog.apDosLogConf`` | The [App Protect DoS log conf]({{< relref "installation/integrations/app-protect-dos/configuration.md#app-protect-dos-logs" >}}) resource. Accepts an optional namespace. | ``string`` | No | -|``dosSecurityLog.dosLogDest`` | The log destination for the security log. Accepted variables are ``syslog:server=:``, ``stderr``, ````. Default is ``"syslog:server=127.0.0.1:514"``. | ``string`` | No | -{{% /table %}} - -### DosProtectedResource.apDosPolicy - -The `apDosPolicy` is a reference (qualified identifier in the format `namespace/name`) to the policy configuration defined as an `ApDosPolicy`. - -### DosProtectedResource.apDosMonitor - -This is how NGINX App Protect DoS monitors the stress level of the protected object. The monitor requests are sent from localhost (127.0.0.1). - -### Invalid DoS Protected resources - -NGINX will treat a DoS protected resource as invalid if one of the following conditions is met: - -- The DoS protected resource doesn't pass the [comprehensive validation](#comprehensive-validation). -- The DoS protected resource isn't present in the cluster. - -### Validation - -Two types of validation are available for the DoS protected resource: - -- *Structural validation*, done by `kubectl` and the Kubernetes API server. -- *Comprehensive validation*, done by NGINX Ingress Controller. - -#### Structural validation - -The custom resource definition for the DoS protected resource includes a structural OpenAPI schema, which describes the type of every field of the resource. - -If you try to create (or update) a resource that violates the structural schema -- for example, the resource uses a string value instead of a bool in the `enable` field -- `kubectl` and the Kubernetes API server will reject the resource. - -- Example of `kubectl` validation: - - ```shell - kubectl apply -f apdos-protected.yaml - ``` - ```shell - error: error validating "examples/app-protect-dos/apdos-protected.yaml": error validating data: ValidationError(DosProtectedResource.spec.enable): invalid type for com.f5.appprotectdos.v1beta1.DosProtectedResource.spec.enable: got "string", expected "boolean"; if you choose to ignore these errors, turn validation off with --validate=false - ``` - -- Example of Kubernetes API server validation: - - ```shell - kubectl apply -f access-control-policy-allow.yaml --validate=false - ``` - ```shell - The DosProtectedResource "dos-protected" is invalid: spec.enable: Invalid value: "string": spec.enable in body must be of type boolean: "string" - ``` - -If a resource passes structural validation, then NGINX Ingress Controller will start comprehensive validation. - -#### Comprehensive validation - -NGINX Ingress Controller validates the fields of a DoS protected resource. If a resource is invalid, NGINX Ingress Controller will reject it. The resource will continue to exist in the cluster, but NGINX Ingress Controller will ignore it. - -You can use `kubectl` to check if NGINX Ingress Controller successfully applied a DoS protected resource configuration. For our example `dos-protected` DoS protected resource, we can run: - -```shell -kubectl describe dosprotectedresource dos-protected -``` -```shell -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 12s (x2 over 18h) nginx-ingress-controller Configuration for default/dos-protected was added or updated -``` - -Note how the events section includes a Normal event with the AddedOrUpdated reason that informs us that the configuration was successfully applied. - -If you create an invalid resource, NGINX Ingress Controller will reject it and emit a Rejected event. For example, if you create a dos protected resource `dos-protected` with an invalid URI `bad` in the `dosSecurityLog/dosLogDest` field, you will get: - -```shell -kubectl describe policy webapp-policy -``` -```shell -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 2s nginx-ingress-controller error validating DosProtectedResource: dos-protected invalid field: dosSecurityLog/dosLogDest err: invalid log destination: bad, must follow format: : or stderr -``` - -The events section has Warning event with the rejection error in the message. - -{{< warning >}} If you invalidate an existing resource, NGINX Ingress Controller will reject it. {{< /warning >}} diff --git a/docs/content/installation/integrations/app-protect-dos/installation.md b/docs/content/installation/integrations/app-protect-dos/installation.md deleted file mode 100644 index dc699bdb66..0000000000 --- a/docs/content/installation/integrations/app-protect-dos/installation.md +++ /dev/null @@ -1,228 +0,0 @@ ---- -docs: DOCS-583 -doctypes: -- '' -title: Build NGINX Ingress Controller with NGINX App Protect DoS -toc: true -weight: 100 ---- - -This document explains how to build an image for NGINX Ingress Controller with NGINX App Protect DoS from source code. - -{{}}If you'd rather not build your own NGINX Ingress Controller image, see the [pre-built image options](#pre-built-images) at the end of this guide.{{}} - -## Before you start - -- To use NGINX App Protect DoS with NGINX Ingress Controller, you must have NGINX Plus. - ---- - -## Prepare the environment {#prepare-environment} - -Get your system ready for building and pushing the NGINX Ingress Controller image with NGINX App Protect DoS. - -1. Sign in to your private registry. Replace `` with the path to your own private registry. - - ```shell - docker login - ``` - -2. Clone the NGINX Ingress Controller GitHub repository. Replace `` with the version of NGINX Ingress Controller you want. - - ```shell - git clone https://github.com/nginxinc/kubernetes-ingress.git --branch - cd kubernetes-ingress - ``` - - For instance if you want to clone version v3.5.1, the commands to run would be: - - ```shell - git clone https://github.com/nginxinc/kubernetes-ingress.git --branch v3.5.1 - cd kubernetes-ingress/deployments - ``` - ---- - -## Build the image {#build-docker-image} - -Follow these steps to build the NGINX Controller Image with NGINX App Protect DoS. - -1. Place your NGINX Plus license files (_nginx-repo.crt_ and _nginx-repo.key_) in the project's root folder. To verify they're in place, run: - - ```shell - ls nginx-repo.* - ``` - - You should see: - - ```shell - nginx-repo.crt nginx-repo.key - ``` - -2. Build the image. Replace `` with your chosen build option and `` with your private registry's path. Refer to the [Makefile targets](#makefile-targets) table below for the list of build options. - - ```shell - make PREFIX=/nginx-plus-ingress TARGET=download - ``` - - For example, to build a Debian-based image with NGINX Plus and NGINX App Protect DoS, run: - - ```shell - make debian-image-dos-plus PREFIX=/nginx-plus-ingress TARGET=download - ``` - - **What to expect**: The image is built and tagged with a version number, which is derived from the `VERSION` variable in the [_Makefile_]({{< relref "installation/building-nginx-ingress-controller.md#makefile-details" >}}). This version number is used for tracking and deployment purposes. - -{{}}In the event a patch version of NGINX Plus is released, make sure to rebuild your image to get the latest version. If your system is caching the Docker layers and not updating the packages, add `DOCKER_BUILD_OPTIONS="--pull --no-cache"` to the make command.{{}} - -### Makefile targets {#makefile-targets} - -{{}} -| Makefile Target | Description | Compatible Systems | -|---------------------------|-------------------------------------------------------------------|---------------------| -| **debian-image-dos-plus** | Builds a Debian-based image with NGINX Plus and the [NGINX App Protect DoS](/nginx-app-protect-dos/) module. | Debian | -| **debian-image-nap-dos-plus** | Builds a Debian-based image with NGINX Plus, [NGINX App Protect DoS](/nginx-app-protect-dos/), and [NGINX App Protect WAF](/nginx-app-protect/). | Debian | -| **ubi-image-dos-plus** | Builds a UBI-based image with NGINX Plus and the [NGINX App Protect DoS](/nginx-app-protect-dos/) module. | OpenShift | -| **ubi-image-nap-dos-plus** | Builds a UBI-based image with NGINX Plus, [NGINX App Protect DoS](/nginx-app-protect-dos/), and [NGINX App Protect WAF](/nginx-app-protect/). | OpenShift | -{{}} - -
- -{{}}For the complete list of _Makefile_ targets and customizable variables, see the [Building NGINX Ingress Controller]({{< relref "installation/building-nginx-ingress-controller.md#makefile-details" >}}) guide{{}} - ---- - -## Push the image to your private registry - -Once you've successfully built the NGINX Ingress Controller image with NGINX App Protect DoS, the next step is to upload it to your private Docker registry. This makes the image available for deployment to your Kubernetes cluster. - -To upload the image, run the following command. If you're using a custom tag, add `TAG=your-tag` to the end of the command. Replace `` with your private registry's path. - -```shell -make push PREFIX=/nginx-plus-ingress -``` - ---- - -## Set up role-based access control (RBAC) {#set-up-rbac} - -{{< include "rbac/set-up-rbac.md" >}} - ---- - -## Create common resources {#create-common-resources} - -{{< include "installation/create-common-resources.md" >}} - ---- - -## Create custom resources {#create-custom-resources} - -{{< include "installation/create-custom-resources.md" >}} - ---- - -## Create App Protect DoS custom resources - -{{}} - -{{%tab name="Install CRDs from single YAML"%}} - -This single YAML file creates CRDs for the following resources: - -- `APDosPolicy` -- `APDosLogConf` -- `DosProtectedResource` - -```shell -kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/deploy/crds-nap-dos.yaml -``` - -{{%/tab%}} - -{{%tab name="Install CRDs after cloning the repo"%}} - -These YAML files create CRDs for the following resources: - -- `APDosPolicy` -- `APDosLogConf` -- `DosProtectedResource` - -```shell -kubectl apply -f config/crd/bases/appprotectdos.f5.com_apdoslogconfs.yaml -kubectl apply -f config/crd/bases/appprotectdos.f5.com_apdospolicy.yaml -kubectl apply -f config/crd/bases/appprotectdos.f5.com_dosprotectedresources.yaml -``` - -{{%/tab%}} - -{{}} - ---- - -## Deploy NGINX Ingress Controller {#deploy-ingress-controller} - -{{< include "installation/deploy-controller.md" >}} - -### Using a Deployment - -{{< include "installation/manifests/deployment.md" >}} - -### Using a DaemonSet - -{{< include "installation/manifests/daemonset.md" >}} - ---- - -## Install the App Protect DoS Arbitrator - -### Helm Chart - -The App Protect DoS Arbitrator can be installed using the [NGINX App Protect DoS Helm Chart](https://github.com/nginxinc/nap-dos-arbitrator-helm-chart). -If you have the NGINX Helm Repository already added, you can install the App Protect DoS Arbitrator by running the following command: - -```shell -helm install my-release-dos nginx-stable/nginx-appprotect-dos-arbitrator -``` - -### YAML Manifests - -Alternatively, you can install the App Protect DoS Arbitrator using the YAML manifests provided in the NGINX Ingress Controller repo. - -1. Create the namespace and service account: - - ```shell - kubectl apply -f common/ns-and-sa.yaml - ``` - -2. Deploy the NGINX App Protect Arbitrator as a Deployment and service: - - ```shell - kubectl apply -f deployment/appprotect-dos-arb.yaml - kubectl apply -f service/appprotect-dos-arb-svc.yaml - ``` - ---- - -## Enable NGINX App Protect DoS module - -To enable the NGINX App Protect DoS Module: - -- Add the `enable-app-protect-dos` [command-line argument]({{< relref "configuration/global-configuration/command-line-arguments.md#cmdoption-enable-app-protect-dos" >}}) to your Deployment or DaemonSet file. - ---- - -## Confirm NGINX Ingress Controller is running - -{{< include "installation/manifests/verify-pods-are-running.md" >}} - -For more information, see the [Configuration guide]({{< relref "installation/integrations/app-protect-dos/configuration.md" >}}),the [NGINX Ingress Controller with App Protect DoS example for VirtualServer](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources/app-protect-dos) and the [NGINX Ingress Controller with App Protect DoS example for Ingress](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-dos). - ---- - -## Alternatives to building your own image {#pre-built-images} - -If you prefer not to build your own NGINX Ingress Controller image, you can use pre-built images. Here are your options: - -- Download the image using your NGINX Ingress Controller subscription certificate and key. See the [Getting the F5 Registry NGINX Ingress Controller Image]({{< relref "installation/nic-images/pulling-ingress-controller-image.md" >}}) guide. -- Use your NGINX Ingress Controller subscription JWT token to get the image: Instructions are in [Getting the NGINX Ingress Controller Image with JWT]({{< relref "installation/nic-images/using-the-jwt-token-docker-secret.md" >}}). diff --git a/docs/content/installation/integrations/app-protect-dos/troubleshooting-app-protect-dos.md b/docs/content/installation/integrations/app-protect-dos/troubleshooting-app-protect-dos.md deleted file mode 100644 index ad8aee8705..0000000000 --- a/docs/content/installation/integrations/app-protect-dos/troubleshooting-app-protect-dos.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -docs: DOCS-1456 -doctypes: -- '' -title: Troubleshooting NGINX App Protect DoS -toc: true -weight: 400 ---- - -This document describes how to troubleshoot problems when using NGINX Ingress Controller and the App Protect DoS module. - -To troubleshoot other parts of NGINX Ingress Controller, check the [troubleshooting]({{< relref "troubleshooting/troubleshoot-common.md" >}}) section of the documentation. - -## Potential problems - -The table below outlines potential problems with NGINX Ingress Controller when the App Protect DoS module is enabled. It suggests how to troubleshoot those problems with methods explained in the next section. - -{{% table %}} -|Problem area | Symptom | Troubleshooting method | Common cause | -| ---| ---| ---| --- | -|Start | NGINX Ingress Controller fails to start. | Check the NGINX Ingress Controller logs. | Misconfigured DosProtectedResource, APDosLogConf or APDosPolicy. | -|DosProtectedResource, APDosLogConf, APDosPolicy or Ingress Resource. | The configuration is not applied. | Check the events of the DosProtectedResource, APDosLogConf, APDosPolicy and Ingress Resource, check the Ingress Controller logs. | DosProtectedResource, APDosLogConf or APDosPolicy is invalid. | -{{% /table %}} - -## Troubleshooting ethods - -### Checking NGINX Ingress Controller and App Protect DoS logs - -App Protect DoS logs are part of the NGINX Ingress Controller logs when the module is enabled. To check the Ingress Controller logs, follow the steps of [Checking the Ingress Controller Logs]({{< relref "troubleshooting/troubleshoot-common#checking-nginx-ingress-controller-logs" >}}s) of the Troubleshooting guide. - -For App Protect DoS specific logs, look for messages starting with `APP_PROTECT_DOS`, such as: - -```shell -2021/06/14 08:17:50 [notice] 242#242: APP_PROTECT_DOS { "event": "shared_memory_connected", "worker_pid": 242, "mode": "operational", "mode_changed": true } -``` - -### Checking Ingress Resource Events - -Follow the steps of [Troubleshooting Ingress Resources]({{< relref "troubleshooting/troubleshoot-ingress" >}}). - -### Checking VirtualServer Resource Events - -Follow the steps of [Troubleshooting VirtualServer Resources]({{< relref "troubleshooting/troubleshoot-virtualserver" >}}). - -### Checking for DoSProtectedResource Events - -After you create or update an DosProtectedResource, you can immediately check if the NGINX configuration was successfully applied by NGINX: - -```shell -kubectl describe dosprotectedresource dos-protected -Name: dos-protected -Namespace: default - -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 2s nginx-ingress-controller Configuration for default/dos-protected was added or updated -``` - -Note that in the events section, we have a `Normal` event with the `AddedOrUpdated` reason, which informs us that the configuration was successfully applied. - -If the DosProtectedResource refers to a missing resource, you should see a message like the following: - -```shell -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning Rejected 8s nginx-ingress-controller dos protected refers (default/dospolicy) to an invalid DosPolicy: DosPolicy default/dospolicy not found -``` - -This can be fixed by adding the missing resource. - -### Checking for APDosLogConf Events - -After you create or update an APDosLogConf, you can immediately check if the NGINX configuration was successfully applied by NGINX: - -```shell -kubectl describe apdoslogconf logconf -Name: logconf -Namespace: default - -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 11s nginx-ingress-controller AppProtectDosLogConfig default/logconf was added or updated -``` - -Note that in the events section, we have a `Normal` event with the `AddedOrUpdated` reason, which informs us that the configuration was successfully applied. - -### Check events of APDosPolicy - -After you create or update an APDosPolicy, you can immediately check if the NGINX configuration was successfully applied by NGINX: - -```shell -kubectl describe apdospolicy dospolicy -Name: dospolicy -Namespace: default -. . . -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal AddedOrUpdated 2m25s nginx-ingress-controller AppProtectDosPolicy default/dospolicy was added or updated -``` - -The events section has a *Normal* event with the *AddedOrUpdated reason*, indicating the policy was successfully accepted. - -## Run App Protect DoS in Debug log Mode - -When you set the Ingress Controller to use debug log mode, the setting also applies to the App Protect DoS module. See [Running NGINX in the Debug Mode](/nginx-ingress-controller/troubleshooting/#running-nginx-in-the-debug-mode) for instructions. - -You can enable debug log mode to App Protect DoS module only by setting the `app-protect-dos-debug` [configmap](/nginx-ingress-controller/configuration/global-configuration/configmap-resource#modules). diff --git a/docs/content/installation/integrations/app-protect-waf/_index.md b/docs/content/installation/integrations/app-protect-waf/_index.md deleted file mode 100644 index 1a1573fec0..0000000000 --- a/docs/content/installation/integrations/app-protect-waf/_index.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: NGINX App Protect WAF -description: Learn how to use NGINX Ingress Controller for Kubernetes with NGINX App Protect. -weight: 100 -aliases: ["/nginx-ingress-controller/app-protect/"] -menu: - docs: - parent: NGINX Ingress Controller ---- diff --git a/docs/content/installation/integrations/app-protect-waf/configuration.md b/docs/content/installation/integrations/app-protect-waf/configuration.md deleted file mode 100644 index 944e2e5590..0000000000 --- a/docs/content/installation/integrations/app-protect-waf/configuration.md +++ /dev/null @@ -1,546 +0,0 @@ ---- -docs: DOCS-578 -doctypes: -- '' -title: Configuration -toc: true -weight: 200 ---- - -This document explains how to use F5 NGINX Ingress Controller to configure NGINX App Protect WAF. - -{{< note >}} Check out the complete NGINX Ingress Controller with NGINX App Protect WAF example resources on GitHub [for VirtualServer resources](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources/app-protect-waf) and [for Ingress resources](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/ingress-resources/app-protect-waf).{{< /note >}} - -## Global Configuration - -NGINX Ingress Controller has global configuration parameters that match those in NGINX App Protect WAF. They are found in the [ConfigMap resource]({{< relref "configuration/global-configuration/configmap-resource.md#modules" >}}): the NGINX App Protect WAF parameters are prefixed with `app-protect*`. - -## Enable NGINX App Protect WAF - -NGINX App Protect WAF can be enabled and configured for custom resources (VirtualServer, VirtualServerRoute) or Ingress resources. - -- For custom resources, you need to create a Policy Custom Resource referencing the `APPolicy` custom resource or bundle, then add it to the VirtualServer definition. Additional detail can be found in the [Policy Resource documentation]({{< relref "configuration/policy-resource.md#waf" >}}). -- For Ingress resources, apply the [`app-protect` annotations]({{< relref "configuration/ingress-resources/advanced-configuration-with-annotations.md#app-protect" >}}) to each desired resource. - - -## NGINX App Protect WAF Policies {#waf-policies} - -NGINX App Protect WAF Policies can be created for VirtualServer, VirtualServerRoute, or Ingress resources by creating an `APPolicy` [custom resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). There are some caveats: - -- The fields `policy.signature-requirements[].minRevisionDatetime` and `policy.signature-requirements[].maxRevisionDatetime` are not supported. -- [The Advanced gRPC Protection for Unary Traffic](/nginx-app-protect-waf/v4/configuration-guide/configuration/#grpc-protection-for-unary-traffic) only supports providing an `idl-file` inline. The fields `policy.idl-files[].link`, `policy.idl-files[].$ref`, and - `policy.idl-files[].file` are not supported. The IDL file should be provided in field `policy.idl-files[].contents`. The value of this field can be base64 encoded. In this case the field `policy.idl-files[].isBase64` should be set to `true`. - -{{}} External references are deprecated in NGINX Ingress Controller and will not be supported in future releases. {{}} - -To add an [NGINX App Protect WAF policy](/nginx-app-protect-waf/v4/declarative-policy/policy/) to an Ingress resource: - -1. Create an `APPolicy` custom resource manifest. -1. Add the policy to the `spec` field in the `APPolicy` resource. - -A resource specification and its Policy JSON **must** match. The fields must be identical in name and nesting level. If the resources are defined with YAML, the policy must also be represented in YAML. - -As an example, this is a [DataGuard policy](/nginx-app-protect-waf/v4/declarative-policy/policy/#policy/data-guard): - -```json -{ - "policy": { - "name": "dataguard_blocking", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_DATA_GUARD", - "alarm": true, - "block": true - } - ] - }, - "data-guard": { - "enabled": true, - "maskData": true, - "creditCardNumbers": true, - "usSocialSecurityNumbers": true, - "enforcementMode": "ignore-urls-in-list", - "enforcementUrls": [] - } - } -} - ``` - -This is what its corresponding `APPolicy` resource defined in the `spec` would look like: - -```yaml -apiVersion: appprotect.f5.com/v1beta1 -kind: APPolicy -metadata: - name: dataguard-blocking -spec: - policy: - name: dataguard_blocking - template: - name: POLICY_TEMPLATE_NGINX_BASE - applicationLanguage: utf-8 - enforcementMode: blocking - blocking-settings: - violations: - - name: VIOL_DATA_GUARD - alarm: true - block: true - data-guard: - enabled: true - maskData: true - creditCardNumbers: true - usSocialSecurityNumbers: true - enforcementMode: ignore-urls-in-list - enforcementUrls: [] -``` - -Notice that the fields match in name and nesting: NGINX Ingress Controller will transform the YAML into a valid JSON WAF policy config. - -## NGINX App Protect WAF Logs {#waf-logs} - -Configuring - -You can set the [NGINX App Protect WAF log configurations](/nginx-app-protect-waf/v4/logging-overview/logs-overview/) by creating an `APLogConf` [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - -To add the [log configurations](/nginx-app-protect-waf/v4/logging-overview/security-log/) to a VirtualServer or an Ingress resource: - -1. Create an `APLogConf` Custom Resource manifest. -1. Add the log configuration to the `spec` field in the `APLogConf` resource. -1. Add a reference to `APLogConf` in the [VirtualServer Policy resource]({{< relref "configuration/policy-resource.md#waf" >}}) or the [Ingress resource]({{< relref "configuration/ingress-resources/advanced-configuration-with-annotations.md#app-protect" >}}) as per the documentation. - - > **Note**: The fields from the JSON must be presented in the YAML *exactly* the same, in name and level. NGINX Ingress Controller will transform the YAML into a valid JSON WAF log config. - -For example, say you want to [log state changing requests](/nginx-app-protect-waf/v4/logging-overview/security-log/#security-log-configuration-file) for your VirtualServer or Ingress resources using NGINX App Protect WAF. The log configuration looks like this: - -```json -{ - "filter": { - "request_type": "all" - }, - "content": { - "format": "default", - "max_message_size": "5k" - } -} -``` - -You would define that config in the `spec` of your `APLogConf` resource as follows: - -```yaml -apiVersion: appprotect.f5.com/v1beta1 -kind: APLogConf -metadata: - name: logconf -spec: - filter: - request_type: all - content: - format: default - max_message_size: 5k -``` - -## NGINX App Protect WAF User Defined Signatures - -You can define NGINX App Protect WAF [User-Defined Signatures](/nginx-app-protect-waf/v4/configuration-guide/configuration/#user-defined-signatures) for your VirtualServer or Ingress resources by creating an `APUserSig` [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - - > **Note**: The field `revisionDatetime` is not currently supported. - -> **Note**: `APUserSig` resources increase the reload time of NGINX Plus compared with `APPolicy` and `APLogConf` resources. Refer to [NGINX Fails to Start or Reload]({{< relref "installation/integrations/app-protect-waf/troubleshooting-app-protect-waf.md#nginx-fails-to-start-or-reload" >}}) for more information. - -To add the [User Defined Signatures](/nginx-app-protect-waf/v4/configuration-guide/configuration/#user-defined-signatures) to a VirtualServer or Ingress resource: - -1. Create an `APUserSig` Custom resource manifest. -2. Add the desired User defined signature to the `spec` field in the `APUserSig` resource. - - > **Note**: The fields from the JSON must be presented in the YAML *exactly* the same, in name and level. The Ingress Controller will transform the YAML into a valid JSON User-Defined signature. There is no need to reference the user defined signature resource in the Policy or Ingress resources. - -For example, say you want to create the following user defined signature: - -```json -{ "softwareVersion": "15.1.0", - "tag": "Fruits", - "signatures": [ - { - "name": "Apple_medium_acc", - "rule": "content:\"apple\"; nocase;", - "signatureType": "request", - "attackType": { - "name": "Brute Force Attack" - }, - "systems": [ - {"name": "Microsoft Windows"}, - {"name": "Unix/Linux"} - ], - "risk": "medium", - "accuracy": "medium", - "description": "Medium accuracy user defined signature with tag (Fruits)" - } - ] -} -``` - -You would add that config in the `spec` of your `APUserSig` resource as follows: - -```yaml -apiVersion: appprotect.f5.com/v1beta1 -kind: APUserSig -metadata: - name: apple -spec: - signatures: - - accuracy: medium - attackType: - name: Brute Force Attack - description: Medium accuracy user defined signature with tag (Fruits) - name: Apple_medium_acc - risk: medium - rule: content:"apple"; nocase; - signatureType: request - systems: - - name: Microsoft Windows - - name: Unix/Linux - softwareVersion: 15.1.0 - tag: Fruits -``` - -## NGINX App Protect WAF Bundles {#waf-bundles} - -You can define App Protect WAF bundles for VirtualServer custom resources by creating policy bundles and putting them on a mounted volume accessible from NGINX Ingress Controller. - -Before applying a policy, a WAF policy bundle must be created, then copied to a volume mounted to `/etc/nginx/waf/bundles`. - -{{< note >}} NGINX Ingress Controller supports `securityLogs` for policy bundles when using `apLogBundle` instead of `apLogConf`. Log bundles must also be copied to a volume mounted to `/etc/nginx/waf/bundles`. {{< /note >}} - -This example shows how a policy is configured by referencing a generated WAF Policy Bundle: - - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: Policy -metadata: - name: -spec: - waf: - enable: true - apBundle: ".tgz" -``` - -This example shows the same policy as above but with a log bundle used for security log configuration: - - -```yaml -apiVersion: k8s.nginx.org/v1 -kind: Policy -metadata: - name: -spec: - waf: - enable: true - apBundle: ".tgz" - securityLogs: - - enable: true - apLogBundle: ".tgz" - logDest: "syslog:server=syslog-svc.default:514" -``` - -## OpenAPI Specification in NGINX Ingress Controller - -The OpenAPI Specification defines the spec file format needed to describe RESTful APIs. The spec file can be written either in JSON or YAML. Using a spec file simplifies the work of implementing API protection. Refer to the [OpenAPI Specification](https://github.com/OAI/OpenAPI-Specification) (formerly called Swagger) for details. - -NGINX Ingress Controller supports OpenAPI Specification versions 2.0 and 3.0. - -The simplest way to create an API protection policy is using an OpenAPI Specification file to import the details of the APIs. If you use an OpenAPI Specification file, NGINX App Protect WAF will automatically create a policy for the following properties (depending on what's included in the spec file): - -- Methods -- URLs -- Parameters -- JSON profiles - -An OpenAPI-ready policy template is provided with the NGINX App Protect WAF packages and is located in: `/etc/app_protect/conf/NginxApiSecurityPolicy.json` - -It contains violations related to OpenAPI set to blocking (enforced). - -### Types of OpenAPI References - -There are different ways of referencing OpenAPI Specification files. The configuration is similar to [External References](/nginx-app-protect-waf/v4/configuration-guide/configuration/#external-references). - -**Note**: Any update of an OpenAPI Specification file referenced in the policy will not trigger a policy compilation. This action needs to be done actively by reloading the NGINX configuration. - -#### URL Reference - -URL reference is the method of referencing an external source by providing its full URL. - -Make sure to configure certificates prior to using the HTTPS protocol - see the [External References](/nginx-app-protect-waf/v4/configuration-guide/configuration/#types-of-references) for details. - -## Configuration in NGINX Ingress Controller - -These are the typical steps to deploy an OpenAPI protection Policy in NGINX Ingress Controller: - -1. Copy the API security policy `/etc/app_protect/conf/NginxApiSecurityPolicy.json` to a different file so that it can be edited. -2. Add the reference to the desired OpenAPI file. -3. Make other custom changes if needed (e.g. enable Data Guard protection). -4. Use a tool to convert the result to YAML. There are many, for example: [`yq` utility](https://github.com/mikefarah/yq). -5. Add the YAML properties to create an `APPolicy` Custom Resource putting the policy itself (as in step 4) within the `spec` property of the Custom Resource. Refer to the [NGINX App Protect Policies](#nginx-app-protect-waf-policies) section above. -6. Create a `Policy` object which references the `APPolicy` Custom Resource as in [this example](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/examples/custom-resources/app-protect-waf/waf.yaml). -7. Finally, attach the `Policy` object to a `VirtualServer` resource as in [this example](https://github.com/nginxinc/kubernetes-ingress/blob/v3.5.1/examples/custom-resources/app-protect-waf/virtual-server.yaml). - -{{< note >}} You need to make sure that the server where the resource files are located is available while you are compiling your policy. {{< /note >}} - -### Example Configuration - -In this example, we are adding an OpenAPI Specification file reference to `/etc/app_protect/conf/NginxApiSecurityPolicy.yaml` using the [link](https://raw.githubusercontent.com/aws-samples/api-gateway-secure-pet-store/master/src/main/resources/swagger.yaml). This will configure allowed data types for `query_int` and `query_str` parameters values. - -**Policy configuration:** - -```yaml ---- -apiVersion: appprotect.f5.com/v1beta1 - kind: APPolicy - metadata: - name: petstore_api_security_policy - spec: - policy: - name: petstore_api_security_policy - description: NGINX App Protect WAF API Security Policy for the Petstore API - template: - name: POLICY_TEMPLATE_NGINX_BASE - open-api-files: - - link: https://raw.githubusercontent.com/aws-samples/api-gateway-secure-pet-store/master/src/main/resources/swagger.yaml - blocking-settings: - violations: - - block: true - description: Disallowed file upload content detected in body - name: VIOL_FILE_UPLOAD_IN_BODY - - block: true - description: Mandatory request body is missing - name: VIOL_MANDATORY_REQUEST_BODY - - block: true - description: Illegal parameter location - name: VIOL_PARAMETER_LOCATION - - block: true - description: Mandatory parameter is missing - name: VIOL_MANDATORY_PARAMETER - - block: true - description: JSON data does not comply with JSON schema - name: VIOL_JSON_SCHEMA - - block: true - description: Illegal parameter array value - name: VIOL_PARAMETER_ARRAY_VALUE - - block: true - description: Illegal Base64 value - name: VIOL_PARAMETER_VALUE_BASE64 - - block: true - description: Disallowed file upload content detected - name: VIOL_FILE_UPLOAD - - block: true - description: Illegal request content type - name: VIOL_URL_CONTENT_TYPE - - block: true - description: Illegal static parameter value - name: VIOL_PARAMETER_STATIC_VALUE - - block: true - description: Illegal parameter value length - name: VIOL_PARAMETER_VALUE_LENGTH - - block: true - description: Illegal parameter data type - name: VIOL_PARAMETER_DATA_TYPE - - block: true - description: Illegal parameter numeric value - name: VIOL_PARAMETER_NUMERIC_VALUE - - block: true - description: Parameter value does not comply with regular expression - name: VIOL_PARAMETER_VALUE_REGEXP - - block: true - description: Illegal URL - name: VIOL_URL - - block: true - description: Illegal parameter - name: VIOL_PARAMETER - - block: true - description: Illegal empty parameter value - name: VIOL_PARAMETER_EMPTY_VALUE - - block: true - description: Illegal repeated parameter name - name: VIOL_PARAMETER_REPEATED -``` - -Content of the referenced file `myapi.yaml`: - -```yaml -openapi: 3.0.1 -info: - title: 'Primitive data types' - description: 'Primitive data types.' - version: '2.5.0' -servers: - - url: http://localhost -paths: - /query: - get: - tags: - - query_int_str - description: query_int_str - operationId: query_int_str - parameters: - - name: query_int - in: query - required: false - allowEmptyValue: false - schema: - type: integer - - name: query_str - in: query - required: false - allowEmptyValue: true - schema: - type: string - responses: - 200: - description: OK - 404: - description: NotFound -``` - -In this case, the following request will trigger an `Illegal parameter data type` violation, as we expect to have an integer value in the `query_int` parameter: - -```none -http://localhost/query?query_int=abc -``` - -The request will be blocked. - -The `link` option is also available in the `openApiFileReference` property and is synonymous with the `open-api-files` property as seen in the policy example above. - -**Note**: `openApiFileReference` is not an array. - -## Configuration in NGINX Plus Ingress Controller using Virtual Server Resource - -In this example we deploy NGINX Ingress Controller with NGINX Plus and NGINX App Protect WAF, deploy a simple web application, and then configure load balancing and WAF protection for that application using the VirtualServer resource. - -{{< note >}} You can find the example, and the files referenced, on [GitHub](https://github.com/nginxinc/kubernetes-ingress/tree/v3.5.1/examples/custom-resources/app-protect-waf).{{< /note >}} - -## Prerequisites - -1. Follow the installation [instructions]({{< relref "installation/integrations/app-protect-waf/installation.md" >}}) to deploy NGINX Ingress Controller with NGINX Plus and NGINX App Protect WAF. -2. Save the public IP address of NGINX Ingress Controller into a shell variable: - - ```shell - IC_IP=XXX.YYY.ZZZ.III - ``` - -3. Save the HTTP port of NGINX Ingress Controller into a shell variable: - - ```shell - IC_HTTP_PORT= - ``` - -### Step 1. Deploy a Web Application - -Create the application deployment and service: - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/examples/custom-resources/app-protect-waf/webapp.yaml - ``` - -### Step 2. Deploy the AP Policy - -1. Create the syslog service and pod for the NGINX App Protect WAF security logs: - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/examples/custom-resources/app-protect-waf/syslog.yaml - ``` - -2. Create the User-Defined Signature, WAF policy, and log configuration: - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/examples/custom-resources/app-protect-waf/ap-apple-uds.yaml - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/examples/custom-resources/app-protect-waf/ap-dataguard-alarm-policy.yaml - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/examples/custom-resources/app-protect-waf/ap-logconf.yaml - ``` - -### Step 3 - Deploy the WAF Policy - -Create the WAF policy - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/examples/custom-resources/app-protect-waf/waf.yaml - ``` - - Note the NGINX App Protect WAF configuration settings in the Policy resource. They enable WAF protection by configuring NGINX App Protect WAF with the policy and log configuration created in the previous step. - -### Step 4 - Configure Load Balancing - -1. Create the VirtualServer Resource: - - ```shell - kubectl apply -f https://raw.githubusercontent.com/nginxinc/kubernetes-ingress/v3.5.1/examples/custom-resources/app-protect-waf/virtual-server.yaml - ``` - -Note that the VirtualServer references the policy waf-policy created in Step 3. - -### Step 5 - Test the Application - -To access the application, curl the coffee and the tea services. We'll use the --resolve option to set the Host header of a request with `webapp.example.com` - -1. Send a request to the application: - - ```shell - curl --resolve webapp.example.com:$IC_HTTP_PORT:$IC_IP http://webapp.example.com:$IC_HTTP_PORT/ - ``` - ```shell - Server address: 10.12.0.18:80 - Server name: webapp-7586895968-r26zn - ``` - -2. Now, let's try to send a request with a suspicious URL: - - ```shell - curl --resolve webapp.example.com:$IC_HTTP_PORT:$IC_IP "http://webapp.example.com:$IC_HTTP_PORT/