From 7fda11cc47e62dd3df44bfb7023f5a07e5bfdbb0 Mon Sep 17 00:00:00 2001 From: oseoin Date: Wed, 24 Jul 2024 12:00:04 +0100 Subject: [PATCH 1/2] Align OSS and Plus UBI images (#6008) --- build/Dockerfile | 58 ++++++++++++++++++++++++++++++++++-------------- 1 file changed, 41 insertions(+), 17 deletions(-) diff --git a/build/Dockerfile b/build/Dockerfile index c46f8c2095..20184de840 100644 --- a/build/Dockerfile +++ b/build/Dockerfile @@ -12,6 +12,7 @@ ARG WAF_VERSION=v4 ############################################# Base images containing libs for Opentracing and FIPS ############################################# FROM ghcr.io/nginxinc/dependencies/nginx-ot:nginx-1.27.0@sha256:1a77df60fd641db9e6a9323c8a484f642eb0e276df06104b592ecfd515bc1aef AS opentracing-lib FROM ghcr.io/nginxinc/dependencies/nginx-ot:nginx-1.27.0-alpine@sha256:8e582e8cac837ad71372fbe1d80ab4d9894fa9dd9d3ad61163ebe87403b6b9db AS alpine-opentracing-lib +FROM ghcr.io/nginxinc/dependencies/nginx-ubi-ppc64le:nginx-1.27.0@sha256:760ed8cff8e0ae835b1873400673d95642e39420e42a02379e0619545008bc07 AS ubi-ppc64le FROM ghcr.io/nginxinc/alpine-fips:0.1.0-alpine3.17@sha256:f00b3f266422feaaac7b733b46903bd19eb1cd1caa6991131576f5f767db76f8 AS alpine-fips-3.17 FROM ghcr.io/nginxinc/alpine-fips:0.2.0-alpine3.19@sha256:1744ae3a8e795daf771f3f7df33b83160981545abb1f1597338e2769d06aa1cc AS alpine-fips-3.19 FROM redhat/ubi9-minimal@sha256:a7d837b00520a32502ada85ae339e33510cdfdbc8d2ddf460cc838e12ec5fa5a AS ubi-minimal @@ -39,23 +40,6 @@ RUN --mount=type=bind,from=opentracing-lib,target=/tmp/ot/ \ && ldconfig -############################################# Base image for UBI ############################################# -FROM nginxcontrib/nginx:1.27.0-ubi@sha256:5547fe1036d63cc9dfdc3aba1cfc822dbb42dbf63ec68e32bcf363e0b1653fc4 AS ubi -ARG IC_VERSION - -LABEL name="NGINX Ingress Controller" \ - maintainer="kubernetes@nginx.com" \ - vendor="NGINX Inc" \ - version="${IC_VERSION}" \ - release="1" \ - summary="The Ingress Controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources." \ - description="The Ingress Controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources." \ - io.k8s.description="NGINX Ingress Controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources." \ - io.openshift.tags="nginx,ingress-controller,ingress,controller,kubernetes,openshift" - -COPY --link --chown=101:0 LICENSE /licenses/ - - ############################################# NGINX files ############################################# FROM scratch AS nginx-files ARG IC_VERSION @@ -318,6 +302,46 @@ RUN --mount=type=secret,id=nginx-repo.crt,dst=/etc/ssl/nginx/nginx-repo.crt,mode fi +############################################# Base image for UBI ############################################# +FROM ubi-minimal AS ubi +ARG IC_VERSION + +LABEL name="NGINX Ingress Controller" \ + maintainer="kubernetes@nginx.com" \ + vendor="NGINX Inc" \ + version="${IC_VERSION}" \ + release="1" \ + summary="The Ingress Controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources." \ + description="The Ingress Controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources." \ + io.k8s.description="NGINX Ingress Controller is an application that runs in a cluster and configures an HTTP load balancer according to Ingress resources." \ + io.openshift.tags="nginx,ingress-controller,ingress,controller,kubernetes,openshift" + +COPY --link --chown=101:0 LICENSE /licenses/ + +SHELL ["/bin/bash", "-o", "pipefail", "-c"] +RUN --mount=type=bind,from=nginx-files,src=nginx_signing.key,target=/tmp/nginx_signing.key \ + --mount=type=bind,from=nginx-files,src=ubi-setup.sh,target=/usr/local/bin/ubi-setup.sh \ + --mount=type=bind,from=nginx-files,src=ubi-clean.sh,target=/usr/local/bin/ubi-clean.sh \ + --mount=type=bind,from=ubi-ppc64le,src=/,target=/ubi-bin/ \ + ubi-setup.sh; \ + if [ $(uname -p) != ppc64le ]; then \ + printf "%s\n" "[nginx]" "name=nginx repo" \ + "baseurl=https://nginx.org/packages/mainline/centos/9/\$basearch/" \ + "gpgcheck=1" "enabled=1" "module_hotfixes=true" > /etc/yum.repos.d/nginx.repo \ + && microdnf --nodocs install -y nginx nginx-module-njs nginx-module-image-filter nginx-module-xslt \ + && rm /etc/yum.repos.d/nginx.repo; \ + else \ + rpm -qa --queryformat "%{NAME}\n" | sort > pkgs-installed \ + && microdnf --nodocs --setopt=install_weak_deps=0 install -y diffutils dnf \ + && rpm -qa --queryformat "%{NAME}\n" | sort > pkgs-new \ + && dnf install -y /ubi-bin/*.rpm \ + && dnf -q repoquery --resolve --requires --recursive --whatrequires nginx --queryformat "%{NAME}" > pkgs-nginx \ + && dnf --setopt=protected_packages= remove -y $(comm -13 pkgs-installed pkgs-new | comm -13 pkgs-nginx -) \ + && rm pkgs-installed pkgs-new pkgs-nginx; \ + fi \ + && ubi-clean.sh + + ############################################# Base image for UBI with NGINX Plus ############################################# FROM ubi-minimal AS ubi-plus ARG NGINX_PLUS_VERSION From ae0a1e9bfc381220a4082864dfef3212881f3a24 Mon Sep 17 00:00:00 2001 From: Alan Dooley Date: Wed, 24 Jul 2024 11:49:35 +0000 Subject: [PATCH 2/2] Update plain Markdown callouts to Hugo callouts (#6038) This commit updates instance of plain Markdown callouts ("> Text") to instead use a Hugo callout, which are more visually distinct from text on a page. This is more consistent across the documentation set. --- docs/content/configuration/policy-resource.md | 116 ++++++++++++++---- .../installing-nic/installation-with-helm.md | 4 +- .../app-protect-dos/configuration.md | 6 +- .../app-protect-waf/configuration.md | 22 +++- .../tutorials/oidc-custom-configuration.md | 12 +- 5 files changed, 125 insertions(+), 35 deletions(-) diff --git a/docs/content/configuration/policy-resource.md b/docs/content/configuration/policy-resource.md index c5d6adf17c..55b91fa8aa 100644 --- a/docs/content/configuration/policy-resource.md +++ b/docs/content/configuration/policy-resource.md @@ -67,8 +67,11 @@ accessControl: deny: - 10.0.0.0/8 ``` +{{< note >}} -> 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). +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). + +{{< /note >}} {{% table %}} |Field | Description | Type | Required | @@ -110,8 +113,11 @@ rateLimit: 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). -> 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). +{{< /note >}} {{% table %}} |Field | Description | Type | Required | @@ -128,7 +134,11 @@ rateLimit: |``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. +{{< note >}} + +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. + +{{< /note >}} #### RateLimit Merging Behavior @@ -147,7 +157,11 @@ When you reference more than one rate limit policy, NGINX Ingress Controller wil The API Key auth policy configures NGINX to authorize client requests based on the presence of a valid API Key in a header or query param specified in the policy. -> Note: The feature is implemented using NGINX [ngx_http_auth_request_module](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) and [NGINX JavaScript (NJS)](https://nginx.org/en/docs/njs/). +{{< note >}} + +The feature is implemented using NGINX [ngx_http_auth_request_module](http://nginx.org/en/docs/http/ngx_http_auth_request_module.html) and [NGINX JavaScript (NJS)](https://nginx.org/en/docs/njs/). + +{{< /note >}} The policies' API keys are securely stored using SHA-256 hashing. When a client sends an API Key, it is hashed by NJS and then compared to the hashed API Key in the NGINX config. @@ -229,8 +243,9 @@ 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). +{{< 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). +{{< /note >}} {{% table %}} |Field | Description | Type | Required | @@ -253,7 +268,11 @@ In this example NGINX Ingress Controller will use the configuration from the fir ### JWT Using Local Kubernetes Secret -> Note: This feature is only available in NGINX Plus. +{{< note >}} + +This feature is only available with NGINX Plus. + +{{< /note >}} The JWT policy configures NGINX Plus to authenticate client requests using JSON Web Tokens. @@ -284,7 +303,11 @@ We use the `requestHeaders` of the [Action.Proxy](/nginx-ingress-controller/conf 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). +{{< 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). + +{{< /note >}} {{% table %}} |Field | Description | Type | Required | @@ -308,7 +331,11 @@ In this example NGINX Ingress Controller will use the configuration from the fir ### JWT Using JWKS From Remote Location -> Note: This feature is only available in NGINX Plus. +{{< note >}} + +This feature is only available with NGINX Plus. + +{{< /note >}} 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. @@ -322,7 +349,11 @@ jwt: 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). +{{< 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). + +{{< /note >}} {{% table %}} |Field | Description | Type | Required | @@ -333,8 +364,13 @@ jwt: |``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. +{{< 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. + +{{< /note >}} #### JWT Merging Behavior @@ -396,14 +432,22 @@ action: 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). +{{< note >}} + + The feature is implemented using the NGINX [ngx_http_ssl_module](https://nginx.org/en/docs/http/ngx_http_ssl_module.html). + + {{< /note >}} #### 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. +{{< note >}} + + Only one of these configurations options can be used at a time. + +{{< /note >}} 1. Adding the `ca.crl` field to the `nginx.org/ca` secret type, which accepts a base64 encoded certificate revocation list (crl). Example YAML: @@ -421,8 +465,13 @@ data: 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. +{{< 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. + +{{< /note >}} Example YAML: @@ -482,7 +531,11 @@ egressMTLS: 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). +{{< note >}} + +The feature is implemented using the NGINX [ngx_http_proxy_module](https://nginx.org/en/docs/http/ngx_http_proxy_module.html). + +{{< /note >}} {{% table %}} |Field | Description | Type | Required | @@ -512,7 +565,11 @@ In this example NGINX Ingress Controller will use the configuration from the fir ### 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. +{{< tip >}} + +This feature is disabled by default. To enable it, set the [enable-oidc]({{< relref "configuration/global-configuration/command-line-arguments.md#cmdoption-enable-oidc" >}}) command-line argument of NGINX Ingress Controller. + +{{< /tip >}} The OIDC policy configures NGINX Plus as a relying party for OpenID Connect authentication. @@ -531,14 +588,22 @@ spec: 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. +{{< 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. + +{{< /note >}} #### 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/v{{< nic-version >}}/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. +{{< warning >}} + +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. + +{{< /warning >}} #### Limitations @@ -559,7 +624,11 @@ The OIDC policy defines a few internal locations that can't be customized: `/_jw |``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. +{{< 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. + +{{< /note >}} #### OIDC Merging Behavior @@ -598,7 +667,7 @@ For `kubectl get` and similar commands, you can also use the short name `pol` in ### WAF {#waf} -> Note: This feature is only available in NGINX Plus with AppProtect. +{{< note >}} The feature is implemented using the NGINX Plus [NGINX App Protect WAF Module](https://docs.nginx.com/nginx-app-protect/configuration/). {{< /note >}} The WAF policy configures NGINX Plus to secure client requests using App Protect WAF policies. @@ -617,8 +686,7 @@ waf: 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/). +{{< note >}} The field `waf.securityLog` is deprecated and will be removed in future releases.It will be ignored if `waf.securityLogs` is populated. {{< /note >}} {{% table %}} |Field | Description | Type | Required | diff --git a/docs/content/installation/installing-nic/installation-with-helm.md b/docs/content/installation/installing-nic/installation-with-helm.md index 4662f67004..9dd6b409b2 100644 --- a/docs/content/installation/installing-nic/installation-with-helm.md +++ b/docs/content/installation/installing-nic/installation-with-helm.md @@ -110,9 +110,7 @@ You can install the `edge` version by specifying the `--version` flag with the v 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. +{{< warning >}} The `edge` version is not intended for production use. It is intended for testing and development purposes only. {{< /warning >}} ## Managing the Chart via Sources diff --git a/docs/content/installation/integrations/app-protect-dos/configuration.md b/docs/content/installation/integrations/app-protect-dos/configuration.md index 2c49791866..8362dd3fbb 100644 --- a/docs/content/installation/integrations/app-protect-dos/configuration.md +++ b/docs/content/installation/integrations/app-protect-dos/configuration.md @@ -7,7 +7,11 @@ toc: true weight: 200 --- -> Check out the complete [NGINX Ingress Controller with App Protect DoS example for VirtualServer](https://github.com/nginxinc/kubernetes-ingress/tree/v{{< nic-version >}}/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/v{{< nic-version >}}/examples/ingress-resources/app-protect-dos). +{{< tip >}} + + Check out the complete [NGINX Ingress Controller with App Protect DoS example for VirtualServer](https://github.com/nginxinc/kubernetes-ingress/tree/v{{< nic-version >}}/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/v{{< nic-version >}}/examples/ingress-resources/app-protect-dos). + +{{< /tip >}} ## App Protect DoS Configuration diff --git a/docs/content/installation/integrations/app-protect-waf/configuration.md b/docs/content/installation/integrations/app-protect-waf/configuration.md index 6f601fe28f..287aed7bb1 100644 --- a/docs/content/installation/integrations/app-protect-waf/configuration.md +++ b/docs/content/installation/integrations/app-protect-waf/configuration.md @@ -113,7 +113,11 @@ To add the [log configurations](/nginx-app-protect-waf/v4/logging-overview/secur 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. +{{< 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. + +{{< /note >}} 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: @@ -148,16 +152,26 @@ spec: 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 >}} + +The field `revisionDatetime` is not currently supported. + +`APUserSig` resources increase the reload time of NGINX Plus compared with `APPolicy` and `APLogConf` resources. Read [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. -> **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. +{{< /note >}} 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. +{{< 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 User-Defined signature. There is no need to reference the user defined signature resource in the Policy or Ingress resources. + +{{< /note >}} For example, say you want to create the following user defined signature: diff --git a/docs/content/tutorials/oidc-custom-configuration.md b/docs/content/tutorials/oidc-custom-configuration.md index 70b1eabd28..975279162d 100644 --- a/docs/content/tutorials/oidc-custom-configuration.md +++ b/docs/content/tutorials/oidc-custom-configuration.md @@ -92,9 +92,15 @@ data: # Rest of configuration file truncated ``` -> **IMPORTANT** -> -> In Step 3 an NGINX Ingress Controller will be deployed/updated that will use this ConfigMap. Any changes made to this ConfigMap must be made **before** deploying/updating NGINX Ingress Controller. If an update is applied to the ConfigMap after NGINX Ingress Controller is deployed, it will not get applied. Applying any updates to the data in this ConfigMap will require NGINX Ingress Controller to be re-deployed. +{{< important >}} + +In the next step, NGINX Ingress Controller will be deployed using this ConfigMap. + +Any changes made to this ConfigMap must be made **before** deploying or updating NGINX Ingress Controller. If an update is applied to the ConfigMap after NGINX Ingress Controller is deployed, it will not be applied. + +Applying any updates to the data in this ConfigMap will require NGINX Ingress Controller to be re-deployed. + +{{< /important >}} ## Step 3 - Add Volume and VolumeMount to the Ingress Controller deployment