Merge pull request #2306 from sunilarjun/cve-april-2026

Adding CVEs for April Release

.github/workflows/create-issue.yml

@@ -1,29 +0,0 @@
-name: Create issue to track porting between Community and Product docs
-
-on:
-  pull_request_target:
-    types:
-      - closed
-    paths-ignore:
-      - '**/README.md'
-
-permissions:
-  issues: write
-  pull-requests: read
-
-jobs:
-  create_issue:
-    if: github.event.pull_request.merged == true && contains( github.event.pull_request.labels.*.name, 'port/community-product')
-    runs-on: ubuntu-latest
-    steps:
-    - name: Create issue
-      env:
-        GH_TOKEN: ${{ github.token }}
-        REPO_TYPE: ${{ contains( github.repository, 'product-docs') && 'Product' || 'Community' }}
-        PR_TITLE: ${{ github.event.pull_request.title }}
-      run: |
-        gh issue create \
-          --repo ${{ github.repository }} \
-          --title "Port $REPO_TYPE docs PR #${{ github.event.pull_request.number }}: $PR_TITLE" \
-          --body "Reference: https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}" \
-          --label port/community-product

.github/workflows/deploy.yml

@@ -13,10 +13,10 @@ jobs:
     name: Build Docusaurus
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
         with:
           fetch-depth: 0
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
         with:
           node-version: 18
           cache: yarn
@@ -25,11 +25,11 @@ jobs:
         run: yarn install --frozen-lockfile
       - name: Build website
         env:
-          NODE_OPTIONS: "--max_old_space_size=8192"
+          NODE_OPTIONS: "--max_old_space_size=10240"
         run: yarn build --no-minify
 
       - name: Upload Build Artifact
-        uses: actions/upload-pages-artifact@v3
+        uses: actions/upload-pages-artifact@56afc609e74202658d3ffba0e8f6dda462b719fa # v3
         with:
           path: build
 
@@ -49,4 +49,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v4
+        uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4

.github/workflows/test-deploy.yml

@@ -11,10 +11,10 @@ jobs:
     name: Test deployment
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
         with:
           fetch-depth: 0
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
         with:
           node-version: 18
           cache: yarn
@@ -27,5 +27,5 @@ jobs:
         run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
       - name: Test build website
         env:
-          NODE_OPTIONS: "--max_old_space_size=7168"
+          NODE_OPTIONS: "--max_old_space_size=10240"
-        run: yarn build --no-minify
+        run: yarn build --no-minify

README.md

@@ -93,7 +93,7 @@ Subsequent executions will check for updated dependencies, if there are none, it
 
 License
 =======
-Copyright (c) 2014-2025 [SUSE, LLC.](https://www.suse.com/)
+Copyright (c) 2014-2026 [SUSE, LLC.](https://www.suse.com/)
 
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.

archived_docs/en/version-2.6/faq/deprecated-features.md

@@ -6,10 +6,6 @@ title: Deprecated Features in Rancher
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>
 
-## What is Rancher's deprecation policy?
-
-We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
-
 ## Where can I find out which features have been deprecated in Rancher?
 
 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:

archived_docs/en/version-2.7/faq/deprecated-features.md

@@ -6,10 +6,6 @@ title: Deprecated Features in Rancher
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>
 
-## What is Rancher's deprecation policy?
-
-We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
-
 ## Where can I find out which features have been deprecated in Rancher?
 
 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:

archived_docs/en/version-2.8/api/workflows/projects.md

@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
   annotations: 
-  field.cattle.io/creatorId:
+    field.cattle.io/creatorId: user-id
-    user-id
   generateName: p-
   namespace: c-m-abcde
 spec:

archived_docs/en/version-2.9/api/workflows/projects.md

@@ -25,11 +25,15 @@ spec:
 EOF
 ```
 
-Use `metadata.generateName` to ensure a unique project ID, but note that `kubectl apply` does not work with `metadata.generateName`, so `kubectl create` must be used instead.
+When creating a new project, you have two primary options for setting the name:
+
+- **Automatic Generation:** Use `metadata.generateName` to ensure a unique project ID. However, note that you must use `kubectl create` (instead of `kubectl apply`) with this option, as `kubectl apply` does not support it.
+- **Manual Naming:** You can explicitly set the project ID using `metadata.name`. If a project with that exact name already exists, the name request is denied.
+The display name seen in the UI is set by `spec.displayName`. If `spec.displayName` is not provided, the field `metadata.name` is used instead.
 
 Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.
 
-If you create a project through a cluster member account, you must include the annotation, `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
+If you create a project through a cluster member account and want that account to be able to access the project, you must include the annotation `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
 
 ```bash
 kubectl create -f - <<EOF
@@ -37,8 +41,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
   annotations: 
-  field.cattle.io/creatorId:
+    field.cattle.io/creatorId: user-id
-    user-id
   generateName: p-
   namespace: c-m-abcde
 spec:
@@ -47,7 +50,11 @@ spec:
 EOF
 ```
 
-Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
+Setting the `field.cattle.io/creatorId` field creates a `ProjectRoleTemplateBinding` that grants the specified user the ability to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
+
+Setting the  `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.
+
+If you don't want the creator to be added as the owner member (e.g. if the creator is a cluster administrator) to the project you may set the `field.cattle.io/no-creator-rbac` annotation to `true`, which will prevent the corresponding projectroletemplatebinding from being created.
 
 ### Creating a Project With a Resource Quota
 
@@ -94,9 +101,13 @@ spec:
 EOF
 ```
 
+### Backing Namespace
+
+After creating the project, the field `status.backingNamespace` gets populated. This represents the namespace in the management cluster that is created to manage project related resources. Examples of resources stored in the backing namespace are [project scoped secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) and [project role template bindings](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles).
+
 ## Adding a Member to a Project
 
-Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
+Look up the project's [backing namespace](#backing-namespace) to specify the `metadata.namespace` field value and look up the project's ID to specify the `projectName` field value.
 
 ```bash
 kubectl --namespace c-m-abcde get projects
@@ -116,7 +127,7 @@ apiVersion: management.cattle.io/v3
 kind: ProjectRoleTemplateBinding
 metadata:
   generateName: prtb-
-  namespace: p-vwxyz
+  namespace: c-m-abcde-p-vwxyz
 projectName: c-m-abcde:p-vwxyz
 roleTemplateName: project-member
 userPrincipalName: keycloak_user://user
@@ -142,16 +153,16 @@ Create a projectroletemplatebinding for each role you want to assign to the proj
 
 ## Listing Project Members
 
-Look up the project ID:
+Look up the project backing namespace:
 
 ```bash
 kubectl --namespace c-m-abcde get projects
 ```
 
-to list projectroletemplatebindings in the project's namespace:
+To list projectroletemplatebindings in the project's backing namespace:
 
 ```bash
-kubectl --namespace p-vwxyz get projectroletemplatebindings
+kubectl --namespace c-m-abcde-p-vwxyz get projectroletemplatebindings
 ```
 
 ## Deleting a Member From a Project
@@ -161,14 +172,14 @@ Lookup the projectroletemplatebinding IDs containing the member in the project's
 Delete the projectroletemplatebinding from the project's namespace:
 
 ```bash
-kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
+kubectl --namespace c-m-abcde-p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
 ```
 
 ## Creating a Namespace in a Project
 
 The Project resource resides in the management cluster, even if the Project is for a managed cluster. The namespaces under the project reside in the managed cluster.
 
-On the management cluster, look up the project ID for the cluster you are administrating since it generated using `metadata.generateName`:
+On the management cluster, look up the project ID for the cluster you are administrating if generated using `metadata.generateName`:
 
 ```bash
 kubectl --namespace c-m-abcde get projects
@@ -204,3 +215,5 @@ kubectl --namespace c-m-abcde delete project p-vwxyz
 ```
 
 Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
+
+It does delete all project role template bindings for the projects, so recreating the project will not restore members added to the project, and you have to add users as members again.

archived_docs/en/version-2.9/faq/container-network-interface-providers.md

@@ -65,7 +65,7 @@ Kubernetes workers should open UDP port `8472` (VXLAN) and TCP port `9099` (heal
 
 ![](/img/canal-diagram.png)
 
-For more information, see the [Canal GitHub Page.](https://github.com/projectcalico/canal)
+For more information, refer to the [Rancher maintained Canal source](https://github.com/rancher/rke2-charts/tree/main-source/packages/rke2-canal) and the [Canal GitHub Page](https://github.com/projectcalico/canal).
 
 #### Flannel
 

archived_docs/en/version-2.9/faq/deprecated-features.md

@@ -6,10 +6,6 @@ title: Deprecated Features in Rancher
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
 </head>
 
-## What is Rancher's deprecation policy?
-
-We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
-
 ## Where can I find out which features have been deprecated in Rancher?
 
 Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:

archived_docs/en/version-2.9/getting-started/installation-and-upgrade/resources/add-tls-secrets.md

@@ -42,8 +42,24 @@ kubectl -n cattle-system create secret generic tls-ca \
 
 The configured `tls-ca` secret is retrieved when Rancher starts. On a running Rancher installation the updated CA will take effect after new Rancher pods are started.
 
+The certificate chain must be properly formatted, or components may fail to download resources from the Rancher server. 
+
 :::
 
+## Adding Additional CA Certificates
+
+If you are using a node driver that makes API requests with a different CA than the one configured for Rancher, you can add additional root certificates and certificate chains. 
+
+Create a unique file ending in `.pem` for each certificate that is required, and use kubectl to create the 
+`tls-additional` secret in the `cattle-system` namespace.
+
+```console
+kubectl -n cattle-system create secret generic tls-additional \
+  --from-file=cacerts1.pem=cacerts1.pem --from-file=cacerts2.pem=cacerts2.pem
+```
+
+Rancher mounts these CA root certificates and certificate chains into the node driver pod during provisioning.
+
 ## Updating a Private CA Certificate
 
-Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
+Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.

archived_docs/en/version-2.9/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md

@@ -96,7 +96,8 @@ To enable draining each node during a cluster upgrade,
 
 :::note
 
-There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show the state of etcd and controlplane as drained, even though they are being drained.
+- There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show the state of etcd and controlplane as drained, even though they are being drained.
+- During an upgrade, nodes may be drained even when no user-visible YAML changes are present. This can occur if non-dynamic configuration files are updated or if a new `system-agent-installer` image is introduced. In such cases, Rancher generates a new upgrade plan, resulting in a new plan hash. When `Upgrade Strategy` is set to `Drain nodes`, this plan change can trigger node draining.
 
 :::
 

archived_docs/en/version-2.9/how-to-guides/advanced-user-guides/enable-api-audit-log-in-downstream-clusters.md

@@ -16,11 +16,15 @@ For configuration details, refer to the [official Kubernetes documentation](http
 <Tabs groupId="k8s-distro">
 <TabItem value="RKE2" default>
 
-### Method 1 (Recommended): Set `audit-policy-file` in `machineGlobalConfig`
+### Method 1 (Recommended): Set `audit-policy-file` in `machineGlobalConfig` or `machineSelectorConfig`
 
-You can set `audit-policy-file` in the configuration file. Rancher delivers the file to the path `/var/lib/rancher/rke2/etc/config-files/audit-policy-file` in control plane nodes, and sets the proper options in the RKE2 server.
+You can set `audit-policy-file` in the configuration file using either `machineGlobalConfig` or `machineSelectorConfig`.
 
-Example:
+When using `machineGlobalConfig`, Rancher delivers the file to the path `/var/lib/rancher/rke2/etc/config-files/audit-policy-file` on **all nodes** (both control plane and worker nodes), and sets the proper options in the RKE2 server. This may cause unwanted worker node reconciliation when the audit policy is modified.
+
+To avoid worker node reconciliation, use `machineSelectorConfig` with a label selector to target only control plane nodes. This ensures that the audit policy file is only delivered to control plane nodes.
+
+Example using `machineGlobalConfig`:
 ```yaml
 apiVersion: provisioning.cattle.io/v1
 kind: Cluster
@@ -38,6 +42,28 @@ spec:
                   - pods
 ```
 
+Example using `machineSelectorConfig` (recommended to avoid worker node reconciliation):
+```yaml
+apiVersion: provisioning.cattle.io/v1
+kind: Cluster
+spec:
+  rkeConfig:
+    machineSelectorConfig:
+      - config:
+          audit-policy-file: |
+            apiVersion: audit.k8s.io/v1
+            kind: Policy
+            rules:
+              - level: RequestResponse
+                resources:
+                  - group: ""
+                    resources:
+                      - pods
+        machineLabelSelector:
+          matchLabels:
+            rke.cattle.io/control-plane-role: 'true'
+```
+
 ### Method 2: Use the Directives, `machineSelectorFiles` and `machineGlobalConfig`
 
 :::note
@@ -103,12 +129,6 @@ spec:
             rke.cattle.io/control-plane-role: 'true'
 ```
 
-:::tip
-
-You can also use the directive `machineSelectorConfig` with proper machineLabelSelectors to achieve the same effect.
-
-:::
-
 For more information about cluster configuration, refer to the [RKE2 cluster configuration reference](../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) pages.
 
 </TabItem>
@@ -178,12 +198,6 @@ spec:
             rke.cattle.io/control-plane-role: 'true'
 ```
 
-:::tip
-
-You can also use the directive `machineSelectorConfig` with proper machineLabelSelectors to achieve the same effect.
-
-:::
-
 For more information about cluster configuration, refer to the [K3s cluster configuration reference](../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) pages.
 
 </TabItem>