Merge branch 'main' into config-path

Author: y82

content/nap-dos/deployment-guide/learn-about-deployment.md

@@ -413,22 +413,28 @@ When deploying App Protect DoS on NGINX Plus take the following precautions to s
 
 6. Enable Yum repositories to pull NGINX App Protect DoS dependencies:
 
-    If you have a RHEL subscription:
+    For RHEL subscription:
 
     ```shell
     sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
     sudo subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms
     sudo dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
     ```
 
-7. Add NGINX Plus and NGINX App Protect DoS repository:
+    For RockyLinux:
+   
+    ```shell
+    sudo dnf -y install epel-release
+    ```
+
+8. Add NGINX Plus and NGINX App Protect DoS repository:
 
     ```shell
     sudo wget -P /etc/yum.repos.d https://cs.nginx.com/static/files/nginx-plus-8.repo
     sudo wget -P /etc/yum.repos.d https://cs.nginx.com/static/files/app-protect-dos-8.repo
     ```
 
-8. In case of fresh installation, update the repository and install the most recent version of the NGINX Plus App Protect DoS package (which includes NGINX Plus):
+9. In case of fresh installation, update the repository and install the most recent version of the NGINX Plus App Protect DoS package (which includes NGINX Plus):
 
     ```shell
     sudo dnf install app-protect-dos
@@ -457,7 +463,7 @@ When deploying App Protect DoS on NGINX Plus take the following precautions to s
     sudo dnf install app-protect-dos-27+2.4.0
     ```
 
-9. In case of upgrading from previously installed NGINX Plus App Protect DoS package (which includes NGINX Plus):
+10. In case of upgrading from previously installed NGINX Plus App Protect DoS package (which includes NGINX Plus):
 
     ```shell
     sudo dnf remove nginx-plus
@@ -621,14 +627,20 @@ When deploying App Protect DoS on NGINX Plus take the following precautions to s
 
 6. Enable the yum repositories to pull NGINX App Protect DoS dependencies:
 
-    If you have a RHEL subscription:
+    For RHEL subscription:
 
     ```shell
     sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms
     sudo subscription-manager repos --enable=rhel-9-for-x86_64-appstream-rpms
     sudo dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
     ```
 
+    For RockyLinux:
+   
+    ```shell
+    sudo dnf -y install epel-release
+    ```
+
 7. Add the NGINX Plus and NGINX App Protect DoS repositories:
 
     ```shell

content/nginx/fips-compliance-nginx-plus.md

@@ -24,36 +24,42 @@ Some industries such as finance, healthcare, energy, also adopt FIPS to enhance
 
 Currently, both FIPS 140-2 and FIPS 140-3 certifications are accepted. However, FIPS 140-2 is being phased out as part of the [FIPS 140-3 transition plan](https://csrc.nist.gov/projects/fips-140-3-transition-effort). After September 22, 2026, only FIPS 140-3 certifications will be recognized. Organizations are encouraged to migrate to FIPS 140-3 to meet updated cryptographic security requirements.
 
-{{<bootstrap-table "table table-striped table-bordered table-sm">}}
-| **Program/Regulation/Industry** | **FIPS 140-2/140-3 Requirement** | **Current Status**                                                  |
-|---------------------------------|----------------------------------|---------------------------------------------------------------------|
-| CJIS                          | 140-2 or 140-3               | FIPS required for systems protecting criminal justice data.               |
-| CMMC                          | 140-2 or 140-3               | FIPS required for Levels 2 and 3 compliance.                              |
-| Common Criteria               | 140-2 or 140-3               | Evaluations reference both FIPS versions for cryptographic security.      |
-| Critical Infrastructure       | 140-2 or 140-3               | Utilities and systems accept both versions depending on deployments.      |
-| Department of Veterans Affairs| 140-2 or 140-3               | Both versions used for securing sensitive health and personal data.       |
-| DFARS                         | 140-2 or 140-3               | Cryptographic modules for CUI must be FIPS compliant.                     |
-| DoDIN APL                     | 140-2 or 140-3               | Approved IT products must include FIPS validation.                        |
-| FAA                           | 140-2 transitioning to 140-3 | 140-2 modules common in existing systems; new systems use 140-3.          |
-| FERPA                         | 140-2 or 140-3               | Federal-funded educational systems align with 140-2 or 140-3.             |
-| FedRAMP                       | 140-2 or 140-3               | FIPS required for encryption; both versions accepted.                     |
-| FISMA                         | 140-2 or 140-3               | Both versions accepted; agencies adopt existing 140-2 modules.            |
-| HIPAA                         | 140-2 or 140-3               | FIPS ensures encryption for ePHI; both versions are valid.                |
-| HITECH                        | 140-2 or 140-3               | FIPS use aligns with encryption best practices for ePHI.                  |
-| Intelligence Community        | 140-2 transitioning to 140-3 | Current systems mostly use 140-2; newer systems adopt 140-3.              |
-| Military & Tactical Systems   | 140-2 transitioning to 140-3 | 140-2 used widely; transitioning to 140-3 certifications for future tools.|
-| NSA CSfC                      | 140-2 transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3.           |
-| Nuclear Regulatory Commission | 140-2 or 140-3               | Cryptography for nuclear systems relies on both versions.                 |
-| PCI DSS                       | 140-2 or 140-3               | Both versions recommended but not mandatory.                              |
-| State and Local Gov Programs  | 140-2 or 140-3               | FIPS required for federal grant-funded security systems.                  |
-| TSA                           | 140-2 or 140-3               | Best practice for cryptographic protection; both versions accepted.       |
-{{< /bootstrap-table >}}
+{{< table >}}
+| **Sector / Program**           | **Version**    | **Status**    |
+|--------------------------------|----------------|---------------|
+| **Federal Programs**           |                |               |
+| CJIS                           | 140-2 or 140-3 | Mandatory     |
+| FedRAMP                        | 140-2 or 140-3 | Mandatory     |
+| FISMA                          | 140-2 or 140-3 | Mandatory     |
+| DFARS                          | 140-2 or 140-3 | Mandatory     |
+| DoDIN APL                      | 140-2 or 140-3 | Mandatory     |
+| FAA                            | 140-2 to 140-3 | Transitioning |
+| TSA                            | 140-2 or 140-3 | Recommended   |
+| **Defense & Intelligence**     |                |               |
+| CMMC                           | 140-2 or 140-3 | Mandatory     |
+| Intelligence Community         | 140-2 to 140-3 | Transitioning |
+| NSA CSfC                       | 140-2 to 140-3 | Transitioning |
+| Military & Tactical Systems    | 140-2 to 140-3 | Transitioning |
+| **Healthcare & Education**     |                |               |
+| HIPAA                          | 140-2 or 140-3 | Mandatory     |
+| HITECH                         | 140-2 or 140-3 | Mandatory     |
+| Department of Veterans Affairs | 140-2 or 140-3 | Mandatory     |
+| FERPA                          | 140-2 or 140-3 | Recommended   |
+| **Commercial/Private Sector**  |                |               |
+| PCI DSS                        | 140-2 or 140-3 | Recommended   |
+| Common Criteria                | 140-2 or 140-3 | Recommended   |
+| **Infrastructure & Critical Systems** |         |               |
+| Critical Infrastructure        | 140-2 or 140-3 | Recommended   |
+| Nuclear Regulatory Commission  | 140-2 or 140-3 | Recommended   |
+| **State & Local Government**   |                |               |
+| State and Local Gov Programs   | 140-2 or 140-3 | Mandatory     |
+{{< /table >}}
 
 ### FIPS compliance in other countries
 
 Although FIPS 140 is primarily a North American government cryptographic standard, it is widely recognized as a global benchmark for cryptographic security. Numerous countries outside North America align their cryptographic requirements with FIPS, especially in regulated sectors such as finance, defense, healthcare, and critical infrastructure.
 
-{{<bootstrap-table "table table-striped table-bordered table-sm">}}
+{{< table >}}
 | Country/Region | FIPS Use                                                                    |
 |----------------|-----------------------------------------------------------------------------|
 | Australia      | Referenced for government, defense, and cryptography systems.               |
@@ -74,7 +80,7 @@ Although FIPS 140 is primarily a North American government cryptographic standar
 | UAE            | Trusted in finance, energy, and interoperability with the U.S. cryptography.|
 | United Kingdom | Referenced for defense, health, and procurement standards.                  |
 | United States  | Mandatory for federal government systems and contractors.                   |
-{{< /bootstrap-table >}}
+{{< /table >}}
 
 ## FIPS compliant vs FIPS validated
 
@@ -129,7 +135,7 @@ The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example and c
 
 ### Step 1: Configure the operating system to use FIPS mode {#os-fips-setup}
 
-For the purposes of the following demonstration, we installed and configured a RHEL 9.6 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system.
+For the purposes of the following demonstration, we installed and configured a RHEL 9.6 server. The [Red Hat FIPS documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system.
 
 For instructions for enabling FIPS mode on other FIPS‑compliant Linux operating systems, see the operating system documentation, for example:
 

content/nginxaas-azure/changelog.md

@@ -14,6 +14,17 @@ To see a list of currently active issues, visit the [Known issues]({{< ref "/ngi
 To review older entries, visit the [Changelog archive]({{< ref "/nginxaas-azure/changelog-archive" >}}) section.
 
 
+## September 18, 2025
+
+- {{% icon-feature %}} **Notification on update to deployments using the Stable Upgrade Channel**
+
+   NGINXaaS for Azure deployments using the **Stable** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}) will be updated to [NGINX Plus Release 35 (R35)]({{< ref "/nginx/releases.md#nginxplusrelease-35-r35" >}}) during the week of Oct 06-10, 2025. This will also include updates to the following NGINX Plus modules:
+  - nginx-plus-module-njs
+
+   Please review the [NGINX Plus Release 35 (R35)]({{< ref "/nginx/releases.md#nginxplusrelease-35-r35" >}}) Release Notes carefully. If you have any concerns, it's recommended to validate your configuration against NGINX Plus R35 by setting up a test deployment using the **Preview** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}). See [these instructions]({{< ref "/nginxaas-azure/quickstart/recreate.md" >}}) on how to set up a deployment similar to your current one.
+
+   If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/get-help.md" >}}).
+
 ## August 18, 2025
 
 - {{% icon-feature %}} **Updates to NGINXaaS for Azure GitHub Action**

content/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-azure-cli.md

@@ -127,6 +127,15 @@ az nginx deployment configuration analyze --deployment-name $DEPLOYMENT_NAME \
       --package data="$TAR_DATA"
    ```
 
+   Upload a package with config files and protected files:
+
+   ```shell
+   az nginx deployment configuration create --deployment-name myDeployment \
+      --resource-group myResourceGroup --root-file nginx.conf --name default \
+      --package data="$TAR_DATA" \
+      protected-files="['nginx/servers/server1.conf','nginx/servers/server2.conf']"
+   ```
+
 - Multiple file configuration with protected files:
 
    ```shell

content/nginxaas-azure/getting-started/nginx-configuration/overview.md

@@ -25,17 +25,20 @@ The topics below provide information on NGINX configuration restrictions and dir
 NGINX configurations stored in GitHub can be applied to existing NGINXaaS for Azure deployments using custom GitHub Action workflows. See [NGINXaaS for Azure Deployment Action](https://github.com/nginxinc/nginx-for-azure-deploy-action) for documentation and examples on how to incorporate these workflows in your GitHub Actions CI/CD pipelines.
 
 ## NGINX filesystem restrictions
-NGINXaaS for Azure places restrictions on the instance's filesystem; only a specific set of directories are allowed to be read from and written to. Below is a table describing what directories the NGINX worker process can read and write to and what directories files can be written to. These files include certificate files and any files uploaded to the deployment, excluding NGINX configuration files.
 
-  {{< table >}}
-  | Allowed Directory | NGINX worker process can read/write to | Files can be written to |
-  |------------------ | ----------------- | ----------------- |
-  | /etc/nginx        |                   | &check;           |
-  | /opt              | &check;           | &check;           |
-  | /srv              | &check;           | &check;           |
-  | /tmp              | &check;           |                   |
-  | /var/cache/nginx  | &check;           |                   |
-  | /var/www          | &check;           | &check;           |
+NGINXaaS for Azure places restrictions on the instance’s filesystem; only a specific set of directories are allowed to be read from and written to. Below is a table describing what directories the NGINX worker process can read and write to and what directories files can be written to. These files include certificate files and any files uploaded to the deployment, excluding NGINX configuration files.
+
+ {{< table >}}
+
+| Directory         | Master Read | Master Write | Worker Read | Worker Write | Recommended Use                  |
+|-------------------|:-----------:|:------------:|:-----------:|:------------:|----------------------------------|
+| /etc/nginx/       |     ✔️      |      ✔️      |     ❌      |      ❌      | NGINX configuration, certificates, keys, application files (e.g. Lua or njs scripts)  |
+| /opt/             |     ✔️      |      ✔️      |     ✔️      |      ❌      | Application files (e.g. Lua scripts) |
+| /srv/             |     ✔️      |      ✔️      |     ✔️      |      ❌      | Application files                |
+| /var/www/         |     ✔️      |      ✔️      |     ✔️      |      ❌      | Static files (e.g. index.html)   |
+| /tmp/             |     ✔️      |      ✔️      |     ✔️      |      ✔️      | Temporary files                  |
+| /var/cache/nginx/ |     ✔️      |      ✔️      |     ✔️      |      ✔️      | Cache data                       |
+
 {{< /table >}}
 
 Attempts to access other directories will be denied and result in a `5xx` error.

content/nginxaas-azure/module-changelog.md

@@ -7,6 +7,29 @@ url: /nginxaas/azure/module-changelog/
 
 Learn about the modules supported by the latest versions of F5 NGINXaaS for Azure.
 
+## September 18, 2025 
+
+### Preview
+
+ {{<bootstrap-table "table table-bordered table-striped table-responsive table-sm">}}
+
+| Name                                     | Version                  | Description                                                            |
+|------------------------------------------|--------------------------|------------------------------------------------------------------------|
+| nginx-plus                               | 1.29.0 (nginx-plus-r35)    | NGINX Plus, provided by Nginx, Inc.                          |
+| nginx-agent                              | 1.20.16-2026591880  | NGINX Agent - Management for NGINXaaS                                  |
+| Operating System                         | Ubuntu 22.04.5      | Jammy Jellyfish, provided by Canonical Ltd.                            |
+| nginx-plus-module-geoip2                 | 35+3.4-1            | NGINX Plus 3rd-party GeoIP2 dynamic modules                            |
+| nginx-plus-module-headers-more           | 35+0.37-1           | NGINX Plus 3rd-party headers-more dynamic module                       |
+| nginx-plus-module-image-filter           | 35-1                | NGINX Plus image filter dynamic module                                 |
+| nginx-plus-module-lua                    | 35+0.10.28-1        | NGINX Plus 3rd-party Lua dynamic modules                               |
+| nginx-plus-module-ndk                    | 35+0.3.3-1          | NGINX Plus 3rd-party NDK dynamic module                                |
+| nginx-plus-module-njs                    | 35+0.9.1-1          | NGINX Plus njs dynamic modules                                         |
+| nginx-plus-module-otel                   | 35+0.1.2-1          | NGINX Plus OpenTelemetry dynamic module                                |
+| nginx-plus-module-xslt                   | 35-1                | NGINX Plus xslt dynamic module                                         |
+| nginx-plus-module-appprotect             | 35+5.498.0-1        | NGINX Plus app protect dynamic module version 5.498.0                  |
+| app-protect-module-plus                  | 35+5.498.0-1        | App-Protect package for Nginx Plus, includes all of the default files and examples. NGINX App Protect provides web application firewall (WAF) security protection for your web applications, including OWASP Top 10 attacks. |
+| app-protect-plugin                       | 6.20.0-1            | NGINX App Protect plugin |
+{{</bootstrap-table>}}
 
 ## Access module versions using data plane API:
 

content/nic/configuration/policy-resource.md

@@ -793,29 +793,6 @@ The feature is implemented using the NGINX [ngx_http_proxy_module](https://nginx
 
 A VirtualServer/VirtualServerRoute can reference multiple cache policies. However, only one can be applied: every subsequent reference will be ignored.
 
-## 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
 
 {{< call-out "note" >}} The feature is implemented using the NGINX Plus [NGINX App Protect WAF Module]({{< ref "/nap-waf/" >}}). {{< /call-out >}}
@@ -863,6 +840,29 @@ policies:
 
 In this example NGINX Ingress Controller will use the configuration from the first policy reference `waf-policy-one`, and ignores `waf-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`.
+
 ### Applying Policies
 
 You can apply policies to both VirtualServer and VirtualServerRoute resources. For example: