Merge pull request #1492 from martyav/fix-order-of-headings-2

Fix order of headings 2
2026-09-12 12:07:20 +00:00 · 2024-09-23 10:24:47 -07:00
parent cefe2dede2 6c694a48fb
commit c58f080356
75 changed files with 314 additions and 305 deletions
@@ -16,11 +16,11 @@ Want to provide a user with access to _all_ projects within a cluster? See [Addi

 :::

-### Adding Members to a New Project
+## Adding Members to a New Project

 You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)

-### Adding Members to an Existing Project
+## Adding Members to an Existing Project

 Following project creation, you can add users as project members so that they can access its resources.

@@ -19,7 +19,7 @@ To provision new storage for your workloads, follow these steps:
 1. [Add a storage class and configure it to use your storage.](#1-add-a-storage-class-and-configure-it-to-use-your-storage)
 2. [Use the Storage Class for Pods Deployed with a StatefulSet.](#2-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To set up persistent storage, the `Manage Volumes` [role](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference) is required.
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
@@ -42,7 +42,7 @@ hostPath | `host-path`

 To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](../../../../advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)

-### 1. Add a storage class and configure it to use your storage
+## 1. Add a storage class and configure it to use your storage

 These steps describe how to set up a storage class at the cluster level.

@@ -59,7 +59,7 @@ These steps describe how to set up a storage class at the cluster level.

 For full information about the storage class parameters, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).

-### 2. Use the Storage Class for Pods Deployed with a StatefulSet
+## 2. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the StorageClass that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound to dynamically provisioned storage using the StorageClass defined in its PersistentVolumeClaim.

@@ -88,4 +88,4 @@ To attach the PVC to an existing workload,
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Save**.

-**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC. If not, Rancher will provision new persistent storage.
+**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC. If not, Rancher will provision new persistent storage.
@@ -20,12 +20,12 @@ To set up storage, follow these steps:
 2. [Add a PersistentVolume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
 3. [Use the Storage Class for Pods Deployed with a StatefulSet.](#3-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To create a persistent volume as a Kubernetes resource, you must have the `Manage Volumes` [role.](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference)
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.

-### 1. Set up persistent storage
+## 1. Set up persistent storage

 Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.

@@ -33,7 +33,7 @@ The steps to set up a persistent storage device will differ based on your infras

 If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [Cloud Native Storage with Longhorn](../../../../../integrations-in-rancher/longhorn/longhorn.md).

-### 2. Add a PersistentVolume that refers to the persistent storage
+## 2. Add a PersistentVolume that refers to the persistent storage

 These steps describe how to set up a PersistentVolume at the cluster level in Kubernetes.

@@ -52,7 +52,7 @@ These steps describe how to set up a PersistentVolume at the cluster level in Ku
 **Result:** Your new persistent volume is created.


-### 3. Use the Storage Class for Pods Deployed with a StatefulSet
+## 3. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the PersistentVolume that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound a PersistentVolume as defined in its PersistentVolumeClaim.

@@ -86,4 +86,4 @@ The following steps describe how to assign persistent storage to an existing wor
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Launch**.

-**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
+**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
@@ -95,4 +95,4 @@ If any value not described above is returned, Rancher Logging will not be able t
 * Reboot your machine.
 * Set `systemdLogPath` to `/run/log/journal`.

-:::
+:::
@@ -8,11 +8,11 @@ title: DigitalOcean Node Template Configuration

 Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.

-### Droplet Options
+## Droplet Options

 The **Droplet Options** provision your cluster's geographical region and specifications.

-### Docker Daemon
+## Docker Daemon

 If you use Docker, the [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) configuration options include:

@@ -8,11 +8,11 @@ title: Private Clusters

 In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".

-### Private Nodes
+## Private Nodes

 Because the nodes in a private cluster only have internal IP addresses, they will not be able to install the cluster agent and Rancher will not be able to fully manage the cluster. This can be overcome in a few ways.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -22,7 +22,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).

 If restricting outgoing internet access is not a concern for your organization, use Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service to allow nodes in the private network to access the internet, enabling them to download the required images from Docker Hub and contact the Rancher management server. This is the simplest solution.

-#### Private registry
+### Private Registry

 :::caution

@@ -32,11 +32,11 @@ This scenario is not officially supported, but is described for cases in which u

 If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](../../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.

-### Private Control Plane Endpoint
+## Private Control Plane Endpoint

 If the cluster has a public endpoint exposed, Rancher will be able to reach the cluster, and no additional steps need to be taken. However, if the cluster has no public endpoint, then considerations must be made to ensure Rancher can access the cluster.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -47,7 +47,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
 As above, if restricting outgoing internet access to the nodes is not a concern, then Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service can be used to allow the nodes to access the internet. While the cluster is provisioning, Rancher will provide a registration command to run on the cluster. Download the [kubeconfig](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) for the new cluster and run the provided kubectl command on the cluster. Gaining access
 to the cluster in order to run this command can be done by creating a temporary node or using an existing node in the VPC, or by logging on to or creating an SSH tunnel through one of the cluster nodes.

-#### Direct access
+### Direct Access

 If the Rancher server is run on the same VPC as the cluster's control plane, it will have direct access to the control plane's private endpoint. The cluster nodes will need to have access to a [private registry](#private-registry) to download images as described above.

@@ -26,18 +26,18 @@ Prometheus Federator is designed to be deployed alongside an existing Prometheus
 2. On seeing each ProjectHelmChartCR, the operator will automatically deploy a Project Prometheus stack on the Project Owner's behalf in the **Project Release Namespace (`cattle-project-<id>-monitoring`)** based on a HelmChart CR and a HelmRelease CR automatically created by the ProjectHelmChart controller in the **Operator / System Namespace**.
 3. RBAC will automatically be assigned in the Project Release Namespace to allow users to view the Prometheus, Alertmanager, and Grafana UIs of the Project Monitoring Stack deployed; this will be based on RBAC defined on the Project Registration Namespace against the [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles). For more information, see the section on [configuring RBAC](rbac.md).

-### What is a Project?
+## What is a Project?

 In Prometheus Federator, a Project is a group of namespaces that can be identified by a `metav1.LabelSelector`. By default, the label used to identify projects is `field.cattle.io/projectId`, the label used to identify namespaces that are contained within a given Rancher Project.

-### Configuring the Helm release created by a ProjectHelmChart
+## Configuring the Helm release created by a ProjectHelmChart

 The `spec.values` of this ProjectHelmChart's resources will correspond to the `values.yaml` override to be supplied to the underlying Helm chart deployed by the operator on the user's behalf; to see the underlying chart's `values.yaml` spec, either:

 - View the chart's definition located at [`rancher/prometheus-federator` under `charts/rancher-project-monitoring`](https://github.com/rancher/prometheus-federator/blob/main/charts/rancher-project-monitoring) (where the chart version will be tied to the version of this operator).
 - Look for the ConfigMap named `monitoring.cattle.io.v1alpha1` that is automatically created in each Project Registration Namespace, which will contain both the `values.yaml` and `questions.yaml` that was used to configure the chart (which was embedded directly into the `prometheus-federator` binary).

-### Namespaces
+## Namespaces

 As a Project Operator based on [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator), Prometheus Federator has three different classifications of namespaces that the operator looks out for:

@@ -65,7 +65,7 @@ As a Project Operator based on [rancher/helm-project-operator](https://github.co

    :::

-### Helm Resources (HelmChart, HelmRelease)
+## Helm Resources (HelmChart, HelmRelease)

 On deploying a ProjectHelmChart, the Prometheus Federator will automatically create and manage two child custom resources that manage the underlying Helm resources in turn:

@@ -103,6 +103,6 @@ For more information on advanced configurations, refer to [this page](https://gi
 |`helmProjectOperator.hardenedNamespaces.configuration`| The configuration to be supplied to the default ServiceAccount or auto-generated NetworkPolicy on managing a namespace. |
 -->

-### Prometheus Federator on the Local Cluster
+## Prometheus Federator on the Local Cluster

 Prometheus Federator is a resource intensive application. Installing it to the local cluster is possible, but **not recommended**.
@@ -21,7 +21,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

-### 1. The Authentication Proxy
+## 1. The Authentication Proxy

 In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
 the pods. Bob is authenticated through Rancher's authentication proxy.
@@ -32,7 +32,7 @@ Rancher communicates with Kubernetes clusters using a [service account](https://

 By default, Rancher generates a [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.

-### 2. Cluster Controllers and Cluster Agents
+## 2. Cluster Controllers and Cluster Agents

 Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.

@@ -52,13 +52,13 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
 -  Applies the roles and bindings defined in each cluster's global policies
 - Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health

-### 3. Node Agents
+## 3. Node Agents

 If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.

 The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.

-### 4. Authorized Cluster Endpoint
+## 4. Authorized Cluster Endpoint

 An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.

@@ -6,7 +6,7 @@ title: Kubernetes Security Best Practices
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
 </head>

-### Restricting cloud metadata API access
+## Restricting Cloud Metadata API Access

 Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -27,11 +27,11 @@ Security is at the heart of all Rancher features. From integrating with all the

 On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters.

-### NeuVector Integration with Rancher
+## NeuVector Integration with Rancher

 NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information.

-### Running a CIS Security Scan on a Kubernetes Cluster
+## Running a CIS Security Scan on a Kubernetes Cluster

 Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.

@@ -47,13 +47,13 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).

-### SELinux RPM
+## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.

 We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -63,7 +63,7 @@ The hardening guides provide prescriptive guidance for hardening a production in

 Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher.

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -71,7 +71,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o

 Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -82,14 +82,14 @@ Results:

 Please note that new reports are no longer shared or made publicly available.

-### Rancher Security Advisories and CVEs
+## Rancher Security Advisories and CVEs

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)

-### Kubernetes Security Best Practices
+## Kubernetes Security Best Practices

 For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.

-### Rancher Security Best Practices
+## Rancher Security Best Practices

 For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.
@@ -6,7 +6,7 @@ title: Advanced Options for Docker Installs
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/single-node-rancher-in-docker/advanced-options"/>
 </head>

-### Custom CA Certificate
+## Custom CA Certificate

 If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate.

@@ -30,7 +30,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### API Audit Log
+## API Audit Log

 The API Audit Log records all the user and system transactions made through Rancher server.

@@ -49,7 +49,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### TLS settings
+## TLS settings

 To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:

@@ -65,7 +65,7 @@ Privileged access is [required.](../../getting-started/installation-and-upgrade/

 See [TLS settings](../../getting-started/installation-and-upgrade/installation-references/tls-settings.md) for more information and options.

-### Air Gap
+## Air Gap

 If you are visiting this page to complete an air gap installation, you must prepend your private registry URL to the server tag when running the installation command in the option that you choose. Add `<REGISTRY.DOMAIN.COM:PORT>` with your private registry URL in front of `rancher/rancher:latest`.

@@ -73,7 +73,7 @@ If you are visiting this page to complete an air gap installation, you must prep

     <REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest

-### Persistent Data
+## Persistent Data

 Rancher uses etcd as a datastore. When Rancher is installed with Docker, the embedded etcd is being used. The persistent data is at the following path in the container: `/var/lib/rancher`.

@@ -89,7 +89,7 @@ docker run -d --restart=unless-stopped \

 Privileged access is [required.](../../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)

-### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node
+## Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node

 In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container.

@@ -10,14 +10,15 @@ For Rancher versions that have `rancher-webhook` installed, certain versions cre

 In Rancher v2.6.3 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.6.2 or below, there are two methods to work around this issue:

-##### 1. Users with cluster access, run the following commands:
+## 1. Users with Cluster Access, Run the Following Commands:
+
 ```
 kubectl delete secret -n cattle-system cattle-webhook-tls
 kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
 kubectl delete pod -n cattle-system -l app=rancher-webhook
 ```

-##### 2. Users with no cluster access via `kubectl`:
+## 2. Users with No Cluster Access Via `kubectl`:

 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.

@@ -10,11 +10,12 @@ The commands/steps listed on this page can be used to check networking related i

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI.

-### Double check if all the required ports are opened in your (host) firewall
+## Double Check if All the Required Ports are Opened in Your (Host) Firewall

 Double check if all the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) are opened in your (host) firewall. The overlay network uses UDP in comparison to all other required ports which are TCP.

-### Check if overlay network is functioning correctly
+
+## Check if Overlay Network is Functioning Correctly

 The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod.

@@ -98,7 +99,7 @@ The `swiss-army-knife` container does not support Windows nodes. It also [does n
 6. You can now clean up the DaemonSet by running `kubectl delete ds/overlaytest`.


-### Check if MTU is correctly configured on hosts and on peering/tunnel appliances/devices
+### Check if MTU is Correctly Configured on Hosts and on Peering/Tunnel Appliances/Devices

 When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:

@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

-#### Pod details
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod Container Logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ NAME      HOSTS                    ADDRESS                   PORTS     AGE
 rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
 ```

-### Check ingress controller logs
+## Check Ingress Controller Logs

 When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+## Leader Election

 The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` Lease in the `kube-system` namespace (in this example, `rancher-dbc7ff869-gvg6k`).

@@ -87,7 +87,7 @@ NAME                 HOLDER                    AGE
 cattle-controllers   rancher-dbc7ff869-gvg6k   6h10m
 ```

-#### Configuration
+### Configuration

 _Available as of Rancher 2.8.3_

@@ -10,13 +10,13 @@ The commands/steps listed on this page can be used to check clusters that you ar

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kubeconfig_from_imported_cluster.yml`)

-### Rancher agents
+## Rancher Agents

 Communication to the cluster (Kubernetes API via cattle-cluster-agent) and communication to the nodes is done through Rancher agents.

 If the cattle-cluster-agent cannot connect to the configured `server-url`, the cluster will remain in **Pending** state, showing `Waiting for full cluster configuration`.

-#### cattle-node-agent
+### cattle-node-agent

 :::note

@@ -49,7 +49,7 @@ Check logging of a specific cattle-node-agent pod or all cattle-node-agent pods:
 kubectl -n cattle-system logs -l app=cattle-agent
 ```

-#### cattle-cluster-agent
+### cattle-cluster-agent

 Check if the cattle-cluster-agent pod is present in the cluster, has status **Running** and doesn't have a high count of Restarts:

@@ -20,7 +20,7 @@ Now with this feature, a downstream cluster admin should be able to look at the
 If the audit logs are shipped off of the cluster, a user of the logging system should be able to identify the user in the external Identity Provider system.
 A Rancher Admin should now be able to view Rancher audit logs and follow through to the Kubernetes audit log by using the external Identity Provider username.

-### Feature Description
+## Feature Description

 - When Kubernetes Audit logs are enabled on the downstream cluster, in each event that is logged, the external Identity Provider's username is now logged for each request, at the "metadata" level.
 - When Rancher API Audit logs are enabled on the Rancher installation, the external Identity Provider's username is also logged now at the `auditLog.level=1` for each request that hits the Rancher API server, including the login requests.
@@ -21,7 +21,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

-### 1. The Authentication Proxy
+## 1. The Authentication Proxy

 In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
 the pods. Bob is authenticated through Rancher's authentication proxy.
@@ -32,7 +32,7 @@ Rancher communicates with Kubernetes clusters using a [service account,](https:/

 By default, Rancher generates a [kubeconfig file](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.

-### 2. Cluster Controllers and Cluster Agents
+## 2. Cluster Controllers and Cluster Agents

 Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.

@@ -52,13 +52,13 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
 -  Applies the roles and bindings defined in each cluster's global policies
 - Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health

-### 3. Node Agents
+## 3. Node Agents

 If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.

 The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.

-### 4. Authorized Cluster Endpoint
+## 4. Authorized Cluster Endpoint

 An authorized cluster endpoint allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.

@@ -33,7 +33,7 @@ On this page, we provide security-related documentation along with resources to
 - [Third-party penetration test reports](#third-party-penetration-test-reports)
 - [Rancher CVEs and resolutions](#rancher-cves-and-resolutions)

-### Running a CIS Security Scan on a Kubernetes Cluster
+## Running a CIS Security Scan on a Kubernetes Cluster

 _Available as of v2.4.0_

@@ -51,7 +51,7 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans.](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md)

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -70,7 +70,7 @@ Hardening Guide Version | Rancher Version | CIS Benchmark Version | Kubernetes V
 [Hardening Guide v2.2](rancher-v2.2-hardening-guides/hardening-guide-with-cis-v1.4-benchmark.md) | Rancher v2.2.x | Benchmark v1.4.1 and 1.4.0 | Kubernetes v1.13
 [Hardening Guide v2.1](rancher-v2.1-hardening-guides/hardening-guide-with-cis-v1.3-benchmark.md) | Rancher v2.1.x | Benchmark v1.3.0 | Kubernetes v1.11

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -87,7 +87,7 @@ Self Assessment Guide Version | Rancher Version | Hardening Guide Version | Kube
 [Self Assessment Guide v2.2](rancher-v2.2-hardening-guides/self-assessment-guide-with-cis-v1.4-benchmark.md) | Rancher v2.2.x | Hardening Guide v2.2 | Kubernetes v1.13 | Benchmark v1.4.0 and v1.4.1
 [Self Assessment Guide v2.1](rancher-v2.1-hardening-guides/self-assessment-guide-with-cis-v1.3-benchmark.md) | Rancher v2.1.x | Hardening Guide v2.1 | Kubernetes v1.11 | Benchmark 1.3.0

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher 2.x software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -96,6 +96,6 @@ Results:
 - [Cure53 Pen Test - 7/2019](https://releases.rancher.com/documents/security/pen-tests/2019/RAN-01-cure53-report.final.pdf)
 - [Untamed Theory Pen Test- 3/2019](https://releases.rancher.com/documents/security/pen-tests/2019/UntamedTheory-Rancher_SecurityAssessment-20190712_v5.pdf)

-### Rancher CVEs and Resolutions
+## Rancher CVEs and Resolutions

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)
@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

-#### Pod details
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod Container Logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ NAME      HOSTS                    ADDRESS                   PORTS     AGE
 rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
 ```

-### Check ingress controller logs
+### Check Ingress Controller Logs

 When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+### Leader Election

 The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).

@@ -6,7 +6,7 @@ title: Kubernetes Security Best Practices
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
 </head>

-### Restricting cloud metadata API access
+## Restricting Cloud Metadata API Access

 Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -26,7 +26,8 @@ title: Rancher Security Guides
 Security is at the heart of all Rancher features. From integrating with all the popular authentication tools and services, to an enterprise grade [RBAC capability,](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md) Rancher makes your Kubernetes clusters even more secure.

 On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters.
-### Running a CIS Security Scan on a Kubernetes Cluster
+
+## Running a CIS Security Scan on a Kubernetes Cluster

 Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.

@@ -42,13 +43,13 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).

-### SELinux RPM
+## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.

 We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -58,7 +59,7 @@ The hardening guides provide prescriptive guidance for hardening a production in

 Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher.

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -66,7 +67,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o

 Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher 2.x software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -75,10 +76,10 @@ Results:
 - [Cure53 Pen Test - July 2019](https://releases.rancher.com/documents/security/pen-tests/2019/RAN-01-cure53-report.final.pdf)
 - [Untamed Theory Pen Test - March 2019](https://releases.rancher.com/documents/security/pen-tests/2019/UntamedTheory-Rancher_SecurityAssessment-20190712_v5.pdf)

-### Rancher Security Advisories and CVEs
+## Rancher Security Advisories and CVEs

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)

-### Kubernetes Security Best Practices
+## Kubernetes Security Best Practices

 For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.
@@ -10,14 +10,15 @@ For Rancher versions that have `rancher-webhook` installed, certain versions cre

 In Rancher v2.5.12 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.5.11 or below, there are two methods to work around this issue:

-##### 1. Users with cluster access, run the following commands:
+## 1. Users with Cluster Access, Run the Following Commands:
+
 ```
 kubectl delete secret -n cattle-system cattle-webhook-tls
 kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
 kubectl delete pod -n cattle-system -l app=rancher-webhook
 ```

-##### 2. Users with no cluster access via `kubectl`:
+## 2. Users with No Cluster Access Via `kubectl`:

 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.

@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

-#### Pod details
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod container logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ NAME      HOSTS                    ADDRESS                   PORTS     AGE
 rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
 ```

-### Check ingress controller logs
+## Check Ingress Controller Logs

 When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+## Leader Election

 The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).

@@ -21,7 +21,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

-### 1. The Authentication Proxy
+## 1. The Authentication Proxy

 In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
 the pods. Bob is authenticated through Rancher's authentication proxy.
@@ -32,7 +32,7 @@ Rancher communicates with Kubernetes clusters using a [service account](https://

 By default, Rancher generates a [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.

-### 2. Cluster Controllers and Cluster Agents
+## 2. Cluster Controllers and Cluster Agents

 Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.

@@ -52,13 +52,13 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
 -  Applies the roles and bindings defined in each cluster's global policies
 - Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health

-### 3. Node Agents
+## 3. Node Agents

 If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.

 The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.

-### 4. Authorized Cluster Endpoint
+## 4. Authorized Cluster Endpoint

 An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.

@@ -6,7 +6,7 @@ title: Kubernetes Security Best Practices
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
 </head>

-### Restricting cloud metadata API access
+## Restricting Cloud Metadata API Access

 Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -26,13 +26,14 @@ title: Rancher Security Guides
 Security is at the heart of all Rancher features. From integrating with all the popular authentication tools and services, to an enterprise grade [RBAC capability](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md), Rancher makes your Kubernetes clusters even more secure.

 On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters.
-### NeuVector Integration with Rancher
+
+## NeuVector Integration with Rancher

 _New in v2.6.5_

 NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information.

-### Running a CIS Security Scan on a Kubernetes Cluster
+## Running a CIS Security Scan on a Kubernetes Cluster

 Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.

@@ -48,13 +49,13 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).

-### SELinux RPM
+## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.

 We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -64,7 +65,7 @@ The hardening guides provide prescriptive guidance for hardening a production in

 Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher.

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -72,7 +73,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o

 Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher 2.x software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -81,10 +82,10 @@ Results:
 - [Cure53 Pen Test - July 2019](https://releases.rancher.com/documents/security/pen-tests/2019/RAN-01-cure53-report.final.pdf)
 - [Untamed Theory Pen Test - March 2019](https://releases.rancher.com/documents/security/pen-tests/2019/UntamedTheory-Rancher_SecurityAssessment-20190712_v5.pdf)

-### Rancher Security Advisories and CVEs
+## Rancher Security Advisories and CVEs

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)

-### Kubernetes Security Best Practices
+## Kubernetes Security Best Practices

 For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.
@@ -10,14 +10,15 @@ For Rancher versions that have `rancher-webhook` installed, certain versions cre

 In Rancher v2.6.3 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.6.2 or below, there are two methods to work around this issue:

-##### 1. Users with cluster access, run the following commands:
+## 1. Users with Cluster Access, Run the Following Commands:
+
 ```
 kubectl delete secret -n cattle-system cattle-webhook-tls
 kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
 kubectl delete pod -n cattle-system -l app=rancher-webhook
 ```

-##### 2. Users with no cluster access via `kubectl`:
+## 2. Users with No Cluster Access Via `kubectl`:

 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.

@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

-#### Pod details
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod Container Logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ NAME      HOSTS                    ADDRESS                   PORTS     AGE
 rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
 ```

-### Check ingress controller logs
+## Check Ingress Controller Logs

 When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+## Leader Election

 The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).

@@ -16,11 +16,11 @@ Want to provide a user with access to _all_ projects within a cluster? See [Addi

 :::

-### Adding Members to a New Project
+## Adding Members to a New Project

 You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)

-### Adding Members to an Existing Project
+## Adding Members to an Existing Project

 Following project creation, you can add users as project members so that they can access its resources.

@@ -19,7 +19,7 @@ To provision new storage for your workloads, follow these steps:
 1. [Add a storage class and configure it to use your storage.](#1-add-a-storage-class-and-configure-it-to-use-your-storage)
 2. [Use the Storage Class for Pods Deployed with a StatefulSet.](#2-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To set up persistent storage, the `Manage Volumes` [role](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference) is required.
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
@@ -42,7 +42,7 @@ hostPath | `host-path`

 To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](../../../../advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)

-### 1. Add a storage class and configure it to use your storage
+## 1. Add a storage class and configure it to use your storage

 These steps describe how to set up a storage class at the cluster level.

@@ -59,7 +59,7 @@ These steps describe how to set up a storage class at the cluster level.

 For full information about the storage class parameters, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).

-### 2. Use the Storage Class for Pods Deployed with a StatefulSet
+## 2. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the StorageClass that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound to dynamically provisioned storage using the StorageClass defined in its PersistentVolumeClaim.

@@ -20,12 +20,12 @@ To set up storage, follow these steps:
 2. [Add a PersistentVolume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
 3. [Use the Storage Class for Pods Deployed with a StatefulSet.](#3-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To create a persistent volume as a Kubernetes resource, you must have the `Manage Volumes` [role.](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference)
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.

-### 1. Set up persistent storage
+## 1. Set up persistent storage

 Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.

@@ -33,7 +33,7 @@ The steps to set up a persistent storage device will differ based on your infras

 If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [this page.](../../../../../integrations-in-rancher/longhorn.md)

-### 2. Add a PersistentVolume that refers to the persistent storage
+## 2. Add a PersistentVolume that refers to the persistent storage

 These steps describe how to set up a PersistentVolume at the cluster level in Kubernetes.

@@ -51,8 +51,7 @@ These steps describe how to set up a PersistentVolume at the cluster level in Ku

 **Result:** Your new persistent volume is created.

-
-### 3. Use the Storage Class for Pods Deployed with a StatefulSet
+## 3. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the PersistentVolume that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound a PersistentVolume as defined in its PersistentVolumeClaim.

@@ -86,4 +85,4 @@ The following steps describe how to assign persistent storage to an existing wor
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Launch**.

-**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
+**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
@@ -87,7 +87,7 @@ K3s and RKE2 Kubernetes distributions log to journald, which is the subsystem of
  * If `/var/log/journal` exists, then use `/var/log/journal`.
  * If `/var/log/journal` does not exist, then use `/run/log/journal`.

-:::note Notes:
+:::note

 If any value not described above is returned, Rancher Logging will not be able to collect control plane logs. To address this issue, you will need to perform the following actions on every control plane node:

@@ -8,11 +8,11 @@ title: DigitalOcean Node Template Configuration

 Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.

-### Droplet Options
+## Droplet Options

 The **Droplet Options** provision your cluster's geographical region and specifications.

-### Docker Daemon
+## Docker Daemon

 If you use Docker, the [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) configuration options include:

@@ -8,11 +8,11 @@ title: Private Clusters

 In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".

-### Private Nodes
+## Private Nodes

 Because the nodes in a private cluster only have internal IP addresses, they will not be able to install the cluster agent and Rancher will not be able to fully manage the cluster. This can be overcome in a few ways.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -22,7 +22,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).

 If restricting outgoing internet access is not a concern for your organization, use Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service to allow nodes in the private network to access the internet, enabling them to download the required images from Docker Hub and contact the Rancher management server. This is the simplest solution.

-#### Private registry
+### Private Registry

 :::caution

@@ -32,11 +32,11 @@ This scenario is not officially supported, but is described for cases in which u

 If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](../../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.

-### Private Control Plane Endpoint
+## Private Control Plane Endpoint

 If the cluster has a public endpoint exposed, Rancher will be able to reach the cluster, and no additional steps need to be taken. However, if the cluster has no public endpoint, then considerations must be made to ensure Rancher can access the cluster.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -47,7 +47,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
 As above, if restricting outgoing internet access to the nodes is not a concern, then Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service can be used to allow the nodes to access the internet. While the cluster is provisioning, Rancher will provide a registration command to run on the cluster. Download the [kubeconfig](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) for the new cluster and run the provided kubectl command on the cluster. Gaining access
 to the cluster in order to run this command can be done by creating a temporary node or using an existing node in the VPC, or by logging on to or creating an SSH tunnel through one of the cluster nodes.

-#### Direct access
+### Direct Access

 If the Rancher server is run on the same VPC as the cluster's control plane, it will have direct access to the control plane's private endpoint. The cluster nodes will need to have access to a [private registry](#private-registry) to download images as described above.

@@ -26,18 +26,18 @@ Prometheus Federator is designed to be deployed alongside an existing Prometheus
 2. On seeing each ProjectHelmChartCR, the operator will automatically deploy a Project Prometheus stack on the Project Owner's behalf in the **Project Release Namespace (`cattle-project-<id>-monitoring`)** based on a HelmChart CR and a HelmRelease CR automatically created by the ProjectHelmChart controller in the **Operator / System Namespace**.
 3. RBAC will automatically be assigned in the Project Release Namespace to allow users to view the Prometheus, Alertmanager, and Grafana UIs of the Project Monitoring Stack deployed; this will be based on RBAC defined on the Project Registration Namespace against the [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles). For more information, see the section on [configuring RBAC](rbac.md).

-### What is a Project?
+## What is a Project?

 In Prometheus Federator, a Project is a group of namespaces that can be identified by a `metav1.LabelSelector`. By default, the label used to identify projects is `field.cattle.io/projectId`, the label used to identify namespaces that are contained within a given Rancher Project.

-### Configuring the Helm release created by a ProjectHelmChart
+## Configuring the Helm release created by a ProjectHelmChart

 The `spec.values` of this ProjectHelmChart's resources will correspond to the `values.yaml` override to be supplied to the underlying Helm chart deployed by the operator on the user's behalf; to see the underlying chart's `values.yaml` spec, either:

 - View the chart's definition located at [`rancher/prometheus-federator` under `charts/rancher-project-monitoring`](https://github.com/rancher/prometheus-federator/blob/main/charts/rancher-project-monitoring) (where the chart version will be tied to the version of this operator).
 - Look for the ConfigMap named `monitoring.cattle.io.v1alpha1` that is automatically created in each Project Registration Namespace, which will contain both the `values.yaml` and `questions.yaml` that was used to configure the chart (which was embedded directly into the `prometheus-federator` binary).

-### Namespaces
+## Namespaces

 As a Project Operator based on [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator), Prometheus Federator has three different classifications of namespaces that the operator looks out for:

@@ -65,7 +65,7 @@ As a Project Operator based on [rancher/helm-project-operator](https://github.co

    :::

-### Helm Resources (HelmChart, HelmRelease)
+## Helm Resources (HelmChart, HelmRelease)

 On deploying a ProjectHelmChart, the Prometheus Federator will automatically create and manage two child custom resources that manage the underlying Helm resources in turn:

@@ -87,7 +87,7 @@ HelmRelease CRs emit Kubernetes Events that detect when an underlying Helm relea

 Both of these resources are created for all Helm charts in the Operator / System namespaces to avoid escalation of privileges to underprivileged users.

-### Advanced Helm Project Operator Configuration
+## Advanced Helm Project Operator Configuration

 For more information on advanced configurations, refer to [this page](https://github.com/rancher/prometheus-federator/blob/main/charts/prometheus-federator/0.0.1/README.md#advanced-helm-project-operator-configuration).

@@ -103,6 +103,6 @@ For more information on advanced configurations, refer to [this page](https://gi
 |`helmProjectOperator.hardenedNamespaces.configuration`| The configuration to be supplied to the default ServiceAccount or auto-generated NetworkPolicy on managing a namespace. |
 -->

-### Prometheus Federator on the Local Cluster
+## Prometheus Federator on the Local Cluster

 Prometheus Federator is a resource intensive application. Installing it to the local cluster is possible, but **not recommended**.
@@ -21,7 +21,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

-### 1. The Authentication Proxy
+## 1. The Authentication Proxy

 In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
 the pods. Bob is authenticated through Rancher's authentication proxy.
@@ -32,7 +32,7 @@ Rancher communicates with Kubernetes clusters using a [service account](https://

 By default, Rancher generates a [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.

-### 2. Cluster Controllers and Cluster Agents
+## 2. Cluster Controllers and Cluster Agents

 Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.

@@ -52,13 +52,13 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
 -  Applies the roles and bindings defined in each cluster's global policies
 - Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health

-### 3. Node Agents
+## 3. Node Agents

 If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.

 The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.

-### 4. Authorized Cluster Endpoint
+## 4. Authorized Cluster Endpoint

 An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.

@@ -6,7 +6,7 @@ title: Kubernetes Security Best Practices
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
 </head>

-### Restricting cloud metadata API access
+## Restricting Cloud Metadata API Access

 Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -28,11 +28,11 @@ Security is at the heart of all Rancher features. From integrating with all the

 On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters.

-### NeuVector Integration with Rancher
+## NeuVector Integration with Rancher

 NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information.

-### Running a CIS Security Scan on a Kubernetes Cluster
+## Running a CIS Security Scan on a Kubernetes Cluster

 Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.

@@ -48,13 +48,13 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).

-### SELinux RPM
+## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.

 We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -64,7 +64,7 @@ The hardening guides provide prescriptive guidance for hardening a production in

 Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher.

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -72,7 +72,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o

 Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -83,14 +83,14 @@ Results:

 Please note that new reports are no longer shared or made publicly available.

-### Rancher Security Advisories and CVEs
+## Rancher Security Advisories and CVEs

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)

-### Kubernetes Security Best Practices
+## Kubernetes Security Best Practices

 For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.

-### Rancher Security Best Practices
+## Rancher Security Best Practices

 For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.
@@ -6,7 +6,7 @@ title: Advanced Options for Docker Installs
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/single-node-rancher-in-docker/advanced-options"/>
 </head>

-### Custom CA Certificate
+## Custom CA Certificate

 If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate.

@@ -30,7 +30,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### API Audit Log
+## API Audit Log

 The API Audit Log records all the user and system transactions made through Rancher server.

@@ -49,7 +49,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### TLS settings
+## TLS settings

 To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:

@@ -65,7 +65,7 @@ Privileged access is [required.](../../getting-started/installation-and-upgrade/

 See [TLS settings](../../getting-started/installation-and-upgrade/installation-references/tls-settings.md) for more information and options.

-### Air Gap
+## Air Gap

 If you are visiting this page to complete an air gap installation, you must prepend your private registry URL to the server tag when running the installation command in the option that you choose. Add `<REGISTRY.DOMAIN.COM:PORT>` with your private registry URL in front of `rancher/rancher:latest`.

@@ -73,7 +73,7 @@ If you are visiting this page to complete an air gap installation, you must prep

     <REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest

-### Persistent Data
+## Persistent Data

 Rancher uses etcd as a datastore. When Rancher is installed with Docker, the embedded etcd is being used. The persistent data is at the following path in the container: `/var/lib/rancher`.

@@ -89,7 +89,7 @@ docker run -d --restart=unless-stopped \

 Privileged access is [required.](../../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)

-### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node
+## Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node

 In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container.

@@ -10,14 +10,15 @@ For Rancher versions that have `rancher-webhook` installed, certain versions cre

 In Rancher v2.6.3 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.6.2 or below, there are two methods to work around this issue:

-##### 1. Users with cluster access, run the following commands:
+## 1. Users with Cluster Access, Run the Following Commands:
+
 ```
 kubectl delete secret -n cattle-system cattle-webhook-tls
 kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
 kubectl delete pod -n cattle-system -l app=rancher-webhook
 ```

-##### 2. Users with no cluster access via `kubectl`:
+## 2. Users with No Cluster Access Via `kubectl`:

 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.

@@ -10,10 +10,12 @@ The commands/steps listed on this page can be used to check networking related i

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI.

-### Double check if all the required ports are opened in your (host) firewall
+## Double Check if All the Required Ports are Opened in Your (Host) Firewall

 Double check if all the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) are opened in your (host) firewall. The overlay network uses UDP in comparison to all other required ports which are TCP.
-### Check if overlay network is functioning correctly
+
+
+## Check if Overlay Network is Functioning Correctly

 The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod.

@@ -97,7 +99,7 @@ The `swiss-army-knife` container does not support Windows nodes. It also [does n
 6. You can now clean up the DaemonSet by running `kubectl delete ds/overlaytest`.


-### Check if MTU is correctly configured on hosts and on peering/tunnel appliances/devices
+### Check if MTU is Correctly Configured on Hosts and on Peering/Tunnel Appliances/Devices

 When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:

@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

-#### Pod details
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod Container Logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ NAME      HOSTS                    ADDRESS                   PORTS     AGE
 rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
 ```

-### Check ingress controller logs
+## Check Ingress Controller Logs

 When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+## Leader Election

 The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` ConfigMap (in this example, `rancher-7dbd7875f7-qbj5k`).

@@ -10,13 +10,13 @@ The commands/steps listed on this page can be used to check clusters that you ar

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kubeconfig_from_imported_cluster.yml`)

-### Rancher agents
+## Rancher Agents

 Communication to the cluster (Kubernetes API via cattle-cluster-agent) and communication to the nodes is done through Rancher agents.

 If the cattle-cluster-agent cannot connect to the configured `server-url`, the cluster will remain in **Pending** state, showing `Waiting for full cluster configuration`.

-#### cattle-node-agent
+### cattle-node-agent

 :::note

@@ -49,7 +49,7 @@ Check logging of a specific cattle-node-agent pod or all cattle-node-agent pods:
 kubectl -n cattle-system logs -l app=cattle-agent
 ```

-#### cattle-cluster-agent
+### cattle-cluster-agent

 Check if the cattle-cluster-agent pod is present in the cluster, has status **Running** and doesn't have a high count of Restarts:

@@ -20,7 +20,7 @@ Now with this feature, a downstream cluster admin should be able to look at the
 If the audit logs are shipped off of the cluster, a user of the logging system should be able to identify the user in the external Identity Provider system.
 A Rancher Admin should now be able to view Rancher audit logs and follow through to the Kubernetes audit log by using the external Identity Provider username.

-### Feature Description
+## Feature Description

 - When Kubernetes Audit logs are enabled on the downstream cluster, in each event that is logged, the external Identity Provider's username is now logged for each request, at the "metadata" level.
 - When Rancher API Audit logs are enabled on the Rancher installation, the external Identity Provider's username is also logged now at the `auditLog.level=1` for each request that hits the Rancher API server, including the login requests.
@@ -16,11 +16,11 @@ Want to provide a user with access to _all_ projects within a cluster? See [Addi

 :::

-### Adding Members to a New Project
+## Adding Members to a New Project

 You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)

-### Adding Members to an Existing Project
+## Adding Members to an Existing Project

 Following project creation, you can add users as project members so that they can access its resources.

@@ -19,7 +19,7 @@ To provision new storage for your workloads, follow these steps:
 1. [Add a storage class and configure it to use your storage.](#1-add-a-storage-class-and-configure-it-to-use-your-storage)
 2. [Use the Storage Class for Pods Deployed with a StatefulSet.](#2-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To set up persistent storage, the `Manage Volumes` [role](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference) is required.
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
@@ -42,7 +42,7 @@ hostPath | `host-path`

 To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](../../../../advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)

-### 1. Add a storage class and configure it to use your storage
+## 1. Add a storage class and configure it to use your storage

 These steps describe how to set up a storage class at the cluster level.

@@ -59,7 +59,7 @@ These steps describe how to set up a storage class at the cluster level.

 For full information about the storage class parameters, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).

-### 2. Use the Storage Class for Pods Deployed with a StatefulSet
+## 2. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the StorageClass that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound to dynamically provisioned storage using the StorageClass defined in its PersistentVolumeClaim.

@@ -20,12 +20,12 @@ To set up storage, follow these steps:
 2. [Add a PersistentVolume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
 3. [Use the Storage Class for Pods Deployed with a StatefulSet.](#3-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To create a persistent volume as a Kubernetes resource, you must have the `Manage Volumes` [role.](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference)
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.

-### 1. Set up persistent storage
+## 1. Set up persistent storage

 Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.

@@ -33,7 +33,7 @@ The steps to set up a persistent storage device will differ based on your infras

 If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [Cloud Native Storage with Longhorn](../../../../../integrations-in-rancher/longhorn/longhorn.md).

-### 2. Add a PersistentVolume that refers to the persistent storage
+## 2. Add a PersistentVolume that refers to the persistent storage

 These steps describe how to set up a PersistentVolume at the cluster level in Kubernetes.

@@ -51,8 +51,7 @@ These steps describe how to set up a PersistentVolume at the cluster level in Ku

 **Result:** Your new persistent volume is created.

-
-### 3. Use the Storage Class for Pods Deployed with a StatefulSet
+## 3. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the PersistentVolume that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound a PersistentVolume as defined in its PersistentVolumeClaim.

@@ -86,4 +85,4 @@ The following steps describe how to assign persistent storage to an existing wor
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Launch**.

-**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
+**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
@@ -8,11 +8,11 @@ title: DigitalOcean Node Template Configuration

 Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.

-### Droplet Options
+## Droplet Options

 The **Droplet Options** provision your cluster's geographical region and specifications.

-### Docker Daemon
+## Docker Daemon

 If you use Docker, the [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) configuration options include:

@@ -8,11 +8,11 @@ title: Private Clusters

 In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".

-### Private Nodes
+## Private Nodes

 Because the nodes in a private cluster only have internal IP addresses, they will not be able to install the cluster agent and Rancher will not be able to fully manage the cluster. This can be overcome in a few ways.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -22,7 +22,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).

 If restricting outgoing internet access is not a concern for your organization, use Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service to allow nodes in the private network to access the internet, enabling them to download the required images from Docker Hub and contact the Rancher management server. This is the simplest solution.

-#### Private registry
+### Private Registry

 :::caution

@@ -32,11 +32,11 @@ This scenario is not officially supported, but is described for cases in which u

 If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](../../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.

-### Private Control Plane Endpoint
+## Private Control Plane Endpoint

 If the cluster has a public endpoint exposed, Rancher will be able to reach the cluster, and no additional steps need to be taken. However, if the cluster has no public endpoint, then considerations must be made to ensure Rancher can access the cluster.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -47,7 +47,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
 As above, if restricting outgoing internet access to the nodes is not a concern, then Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service can be used to allow the nodes to access the internet. While the cluster is provisioning, Rancher will provide a registration command to run on the cluster. Download the [kubeconfig](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) for the new cluster and run the provided kubectl command on the cluster. Gaining access
 to the cluster in order to run this command can be done by creating a temporary node or using an existing node in the VPC, or by logging on to or creating an SSH tunnel through one of the cluster nodes.

-#### Direct access
+### Direct Access

 If the Rancher server is run on the same VPC as the cluster's control plane, it will have direct access to the control plane's private endpoint. The cluster nodes will need to have access to a [private registry](#private-registry) to download images as described above.

@@ -26,18 +26,18 @@ Prometheus Federator is designed to be deployed alongside an existing Prometheus
 2. On seeing each ProjectHelmChartCR, the operator will automatically deploy a Project Prometheus stack on the Project Owner's behalf in the **Project Release Namespace (`cattle-project-<id>-monitoring`)** based on a HelmChart CR and a HelmRelease CR automatically created by the ProjectHelmChart controller in the **Operator / System Namespace**.
 3. RBAC will automatically be assigned in the Project Release Namespace to allow users to view the Prometheus, Alertmanager, and Grafana UIs of the Project Monitoring Stack deployed; this will be based on RBAC defined on the Project Registration Namespace against the [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles). For more information, see the section on [configuring RBAC](rbac.md).

-### What is a Project?
+## What is a Project?

 In Prometheus Federator, a Project is a group of namespaces that can be identified by a `metav1.LabelSelector`. By default, the label used to identify projects is `field.cattle.io/projectId`, the label used to identify namespaces that are contained within a given Rancher Project.

-### Configuring the Helm release created by a ProjectHelmChart
+## Configuring the Helm release created by a ProjectHelmChart

 The `spec.values` of this ProjectHelmChart's resources will correspond to the `values.yaml` override to be supplied to the underlying Helm chart deployed by the operator on the user's behalf; to see the underlying chart's `values.yaml` spec, either:

 - View the chart's definition located at [`rancher/prometheus-federator` under `charts/rancher-project-monitoring`](https://github.com/rancher/prometheus-federator/blob/main/charts/rancher-project-monitoring) (where the chart version will be tied to the version of this operator).
 - Look for the ConfigMap named `monitoring.cattle.io.v1alpha1` that is automatically created in each Project Registration Namespace, which will contain both the `values.yaml` and `questions.yaml` that was used to configure the chart (which was embedded directly into the `prometheus-federator` binary).

-### Namespaces
+## Namespaces

 As a Project Operator based on [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator), Prometheus Federator has three different classifications of namespaces that the operator looks out for:

@@ -65,7 +65,7 @@ As a Project Operator based on [rancher/helm-project-operator](https://github.co

    :::

-### Helm Resources (HelmChart, HelmRelease)
+## Helm Resources (HelmChart, HelmRelease)

 On deploying a ProjectHelmChart, the Prometheus Federator will automatically create and manage two child custom resources that manage the underlying Helm resources in turn:

@@ -87,7 +87,7 @@ HelmRelease CRs emit Kubernetes Events that detect when an underlying Helm relea

 Both of these resources are created for all Helm charts in the Operator / System namespaces to avoid escalation of privileges to underprivileged users.

-### Advanced Helm Project Operator Configuration
+## Advanced Helm Project Operator Configuration

 For more information on advanced configurations, refer to [this page](https://github.com/rancher/prometheus-federator/blob/main/charts/prometheus-federator/0.0.1/README.md#advanced-helm-project-operator-configuration).

@@ -103,6 +103,6 @@ For more information on advanced configurations, refer to [this page](https://gi
 |`helmProjectOperator.hardenedNamespaces.configuration`| The configuration to be supplied to the default ServiceAccount or auto-generated NetworkPolicy on managing a namespace. |
 -->

-### Prometheus Federator on the Local Cluster
+## Prometheus Federator on the Local Cluster

 Prometheus Federator is a resource intensive application. Installing it to the local cluster is possible, but **not recommended**.
@@ -21,7 +21,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

-### 1. The Authentication Proxy
+## 1. The Authentication Proxy

 In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
 the pods. Bob is authenticated through Rancher's authentication proxy.
@@ -32,7 +32,7 @@ Rancher communicates with Kubernetes clusters using a [service account](https://

 By default, Rancher generates a [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.

-### 2. Cluster Controllers and Cluster Agents
+## 2. Cluster Controllers and Cluster Agents

 Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.

@@ -52,13 +52,13 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
 -  Applies the roles and bindings defined in each cluster's global policies
 - Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health

-### 3. Node Agents
+## 3. Node Agents

 If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.

 The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.

-### 4. Authorized Cluster Endpoint
+## 4. Authorized Cluster Endpoint

 An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.

@@ -6,7 +6,7 @@ title: Kubernetes Security Best Practices
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
 </head>

-### Restricting cloud metadata API access
+## Restricting Cloud Metadata API Access

 Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -27,11 +27,11 @@ Security is at the heart of all Rancher features. From integrating with all the

 On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters.

-### NeuVector Integration with Rancher
+## NeuVector Integration with Rancher

 NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information.

-### Running a CIS Security Scan on a Kubernetes Cluster
+## Running a CIS Security Scan on a Kubernetes Cluster

 Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.

@@ -47,13 +47,13 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).

-### SELinux RPM
+## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.

 We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -63,7 +63,7 @@ The hardening guides provide prescriptive guidance for hardening a production in

 Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher.

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -71,7 +71,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o

 Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -82,18 +82,18 @@ Results:

 Please note that new reports are no longer shared or made publicly available.

-### Rancher Security Advisories and CVEs
+## Rancher Security Advisories and CVEs

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)

-### Kubernetes Security Best Practices
+## Kubernetes Security Best Practices

 For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.

-### Rancher Security Best Practices
+## Rancher Security Best Practices

 For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.

-### Rancher Webhook Hardening
+## Rancher Webhook Hardening

 The Rancher webhook deploys on both the upstream Rancher cluster and all provisioned clusters. For recommendations on hardening the Rancher webhook, see the [Hardening the Rancher Webhook](rancher-webhook-hardening.md) guide.
@@ -6,7 +6,7 @@ title: Advanced Options for Docker Installs
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/single-node-rancher-in-docker/advanced-options"/>
 </head>

-### Custom CA Certificate
+## Custom CA Certificate

 If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate.

@@ -30,7 +30,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### API Audit Log
+## API Audit Log

 The API Audit Log records all the user and system transactions made through Rancher server.

@@ -49,7 +49,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### TLS settings
+## TLS settings

 To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:

@@ -65,7 +65,7 @@ Privileged access is [required.](../../getting-started/installation-and-upgrade/

 See [TLS settings](../../getting-started/installation-and-upgrade/installation-references/tls-settings.md) for more information and options.

-### Air Gap
+## Air Gap

 If you are visiting this page to complete an air gap installation, you must prepend your private registry URL to the server tag when running the installation command in the option that you choose. Add `<REGISTRY.DOMAIN.COM:PORT>` with your private registry URL in front of `rancher/rancher:latest`.

@@ -73,7 +73,7 @@ If you are visiting this page to complete an air gap installation, you must prep

     <REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest

-### Persistent Data
+## Persistent Data

 Rancher uses etcd as a datastore. When Rancher is installed with Docker, the embedded etcd is being used. The persistent data is at the following path in the container: `/var/lib/rancher`.

@@ -89,7 +89,7 @@ docker run -d --restart=unless-stopped \

 Privileged access is [required.](../../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)

-### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node
+## Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node

 In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container.

@@ -10,14 +10,15 @@ For Rancher versions that have `rancher-webhook` installed, certain versions cre

 In Rancher v2.6.3 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.6.2 or below, there are two methods to work around this issue:

-##### 1. Users with cluster access, run the following commands:
+## 1. Users with Cluster Access, Run the Following Commands:
+
 ```
 kubectl delete secret -n cattle-system cattle-webhook-tls
 kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
 kubectl delete pod -n cattle-system -l app=rancher-webhook
 ```

-##### 2. Users with no cluster access via `kubectl`:
+## 2. Users with No Cluster Access Via `kubectl`:

 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.

@@ -10,10 +10,11 @@ The commands/steps listed on this page can be used to check networking related i

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI.

-### Double check if all the required ports are opened in your (host) firewall
+## Double check if all the required ports are opened in your (host) firewall

 Double check if all the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) are opened in your (host) firewall. The overlay network uses UDP in comparison to all other required ports which are TCP.
-### Check if overlay network is functioning correctly
+
+## Check if overlay network is functioning correctly

 The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod.

@@ -97,7 +98,7 @@ The `swiss-army-knife` container does not support Windows nodes. It also [does n
 6. You can now clean up the DaemonSet by running `kubectl delete ds/overlaytest`.


-### Check if MTU is correctly configured on hosts and on peering/tunnel appliances/devices
+## Check if MTU is Correctly Configured on Hosts and on Peering/Tunnel Appliances/Devices

 When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:

@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

-#### Pod details
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod Container Logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ NAME      HOSTS                    ADDRESS                   PORTS     AGE
 rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
 ```

-### Check ingress controller logs
+## Check Ingress Controller Logs

 When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+## Leader Election

 The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` Lease in the `kube-system` namespace (in this example, `rancher-dbc7ff869-gvg6k`).

@@ -87,7 +87,7 @@ NAME                 HOLDER                    AGE
 cattle-controllers   rancher-dbc7ff869-gvg6k   6h10m
 ```

-#### Configuration
+### Configuration

 _Available as of Rancher 2.8.3_

@@ -10,13 +10,13 @@ The commands/steps listed on this page can be used to check clusters that you ar

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kubeconfig_from_imported_cluster.yml`)

-### Rancher agents
+## Rancher Agents

 Communication to the cluster (Kubernetes API via cattle-cluster-agent) and communication to the nodes is done through Rancher agents.

 If the cattle-cluster-agent cannot connect to the configured `server-url`, the cluster will remain in **Pending** state, showing `Waiting for full cluster configuration`.

-#### cattle-node-agent
+### cattle-node-agent

 :::note

@@ -49,7 +49,7 @@ Check logging of a specific cattle-node-agent pod or all cattle-node-agent pods:
 kubectl -n cattle-system logs -l app=cattle-agent
 ```

-#### cattle-cluster-agent
+### cattle-cluster-agent

 Check if the cattle-cluster-agent pod is present in the cluster, has status **Running** and doesn't have a high count of Restarts:

@@ -20,7 +20,7 @@ Now with this feature, a downstream cluster admin should be able to look at the
 If the audit logs are shipped off of the cluster, a user of the logging system should be able to identify the user in the external Identity Provider system.
 A Rancher Admin should now be able to view Rancher audit logs and follow through to the Kubernetes audit log by using the external Identity Provider username.

-### Feature Description
+## Feature Description

 - When Kubernetes Audit logs are enabled on the downstream cluster, in each event that is logged, the external Identity Provider's username is now logged for each request, at the "metadata" level.
 - When Rancher API Audit logs are enabled on the Rancher installation, the external Identity Provider's username is also logged now at the `auditLog.level=1` for each request that hits the Rancher API server, including the login requests.
@@ -16,11 +16,11 @@ Want to provide a user with access to _all_ projects within a cluster? See [Addi

 :::

-### Adding Members to a New Project
+## Adding Members to a New Project

 You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)

-### Adding Members to an Existing Project
+## Adding Members to an Existing Project

 Following project creation, you can add users as project members so that they can access its resources.

@@ -19,7 +19,7 @@ To provision new storage for your workloads, follow these steps:
 1. [Add a storage class and configure it to use your storage.](#1-add-a-storage-class-and-configure-it-to-use-your-storage)
 2. [Use the Storage Class for Pods Deployed with a StatefulSet.](#2-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To set up persistent storage, the `Manage Volumes` [role](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference) is required.
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
@@ -42,7 +42,7 @@ hostPath | `host-path`

 To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](../../../../advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)

-### 1. Add a storage class and configure it to use your storage
+## 1. Add a storage class and configure it to use your storage

 These steps describe how to set up a storage class at the cluster level.

@@ -59,7 +59,7 @@ These steps describe how to set up a storage class at the cluster level.

 For full information about the storage class parameters, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).

-### 2. Use the Storage Class for Pods Deployed with a StatefulSet
+## 2. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the StorageClass that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound to dynamically provisioned storage using the StorageClass defined in its PersistentVolumeClaim.

@@ -20,12 +20,12 @@ To set up storage, follow these steps:
 2. [Add a PersistentVolume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
 3. [Use the Storage Class for Pods Deployed with a StatefulSet.](#3-use-the-storage-class-for-pods-deployed-with-a-statefulset)

-### Prerequisites
+## Prerequisites

 - To create a persistent volume as a Kubernetes resource, you must have the `Manage Volumes` [role.](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference)
 - If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.

-### 1. Set up persistent storage
+## 1. Set up persistent storage

 Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.

@@ -33,7 +33,7 @@ The steps to set up a persistent storage device will differ based on your infras

 If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [Cloud Native Storage with Longhorn](../../../../../integrations-in-rancher/longhorn/longhorn.md).

-### 2. Add a PersistentVolume that refers to the persistent storage
+## 2. Add a PersistentVolume that refers to the persistent storage

 These steps describe how to set up a PersistentVolume at the cluster level in Kubernetes.

@@ -51,8 +51,7 @@ These steps describe how to set up a PersistentVolume at the cluster level in Ku

 **Result:** Your new persistent volume is created.

-
-### 3. Use the Storage Class for Pods Deployed with a StatefulSet
+## 3. Use the Storage Class for Pods Deployed with a StatefulSet

 StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the PersistentVolume that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound a PersistentVolume as defined in its PersistentVolumeClaim.

@@ -86,4 +85,4 @@ The following steps describe how to assign persistent storage to an existing wor
 1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
 1. Click **Launch**.

-**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
+**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
@@ -196,4 +196,3 @@ kubectl patch cronjob neuvector-updater-pod -n cattle-neuvector-system --patch '
 * Sometimes when the controllers are not ready, the NeuVector UI is not accessible from the Rancher UI. During this time, controllers will try to restart, and it takes a few minutes for the controllers to be active.

 * Container runtime is not auto-detected for different cluster types when installing the NeuVector chart. To work around this, you can specify the runtime manually.
-
@@ -8,11 +8,11 @@ title: DigitalOcean Node Template Configuration

 Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.

-### Droplet Options
+## Droplet Options

 The **Droplet Options** provision your cluster's geographical region and specifications.

-### Docker Daemon
+## Docker Daemon

 If you use Docker, the [Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) configuration options include:

@@ -8,11 +8,11 @@ title: Private Clusters

 In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".

-### Private Nodes
+## Private Nodes

 Because the nodes in a private cluster only have internal IP addresses, they will not be able to install the cluster agent and Rancher will not be able to fully manage the cluster. This can be overcome in a few ways.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -22,7 +22,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).

 If restricting outgoing internet access is not a concern for your organization, use Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service to allow nodes in the private network to access the internet, enabling them to download the required images from Docker Hub and contact the Rancher management server. This is the simplest solution.

-#### Private registry
+### Private Registry

 :::caution

@@ -32,11 +32,11 @@ This scenario is not officially supported, but is described for cases in which u

 If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](../../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.

-### Private Control Plane Endpoint
+## Private Control Plane Endpoint

 If the cluster has a public endpoint exposed, Rancher will be able to reach the cluster, and no additional steps need to be taken. However, if the cluster has no public endpoint, then considerations must be made to ensure Rancher can access the cluster.

-#### Cloud NAT
+### Cloud NAT

 :::caution

@@ -47,7 +47,7 @@ Cloud NAT will [incur charges](https://cloud.google.com/nat/pricing).
 As above, if restricting outgoing internet access to the nodes is not a concern, then Google's [Cloud NAT](https://cloud.google.com/nat/docs/using-nat) service can be used to allow the nodes to access the internet. While the cluster is provisioning, Rancher will provide a registration command to run on the cluster. Download the [kubeconfig](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl) for the new cluster and run the provided kubectl command on the cluster. Gaining access
 to the cluster in order to run this command can be done by creating a temporary node or using an existing node in the VPC, or by logging on to or creating an SSH tunnel through one of the cluster nodes.

-#### Direct access
+### Direct Access

 If the Rancher server is run on the same VPC as the cluster's control plane, it will have direct access to the control plane's private endpoint. The cluster nodes will need to have access to a [private registry](#private-registry) to download images as described above.

@@ -26,18 +26,18 @@ Prometheus Federator is designed to be deployed alongside an existing Prometheus
 2. On seeing each ProjectHelmChartCR, the operator will automatically deploy a Project Prometheus stack on the Project Owner's behalf in the **Project Release Namespace (`cattle-project-<id>-monitoring`)** based on a HelmChart CR and a HelmRelease CR automatically created by the ProjectHelmChart controller in the **Operator / System Namespace**.
 3. RBAC will automatically be assigned in the Project Release Namespace to allow users to view the Prometheus, Alertmanager, and Grafana UIs of the Project Monitoring Stack deployed; this will be based on RBAC defined on the Project Registration Namespace against the [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles). For more information, see the section on [configuring RBAC](rbac.md).

-### What is a Project?
+## What is a Project?

 In Prometheus Federator, a Project is a group of namespaces that can be identified by a `metav1.LabelSelector`. By default, the label used to identify projects is `field.cattle.io/projectId`, the label used to identify namespaces that are contained within a given Rancher Project.

-### Configuring the Helm release created by a ProjectHelmChart
+## Configuring the Helm release created by a ProjectHelmChart

 The `spec.values` of this ProjectHelmChart's resources will correspond to the `values.yaml` override to be supplied to the underlying Helm chart deployed by the operator on the user's behalf; to see the underlying chart's `values.yaml` spec, either:

 - View the chart's definition located at [`rancher/prometheus-federator` under `charts/rancher-project-monitoring`](https://github.com/rancher/prometheus-federator/blob/main/charts/rancher-project-monitoring) (where the chart version will be tied to the version of this operator).
 - Look for the ConfigMap named `monitoring.cattle.io.v1alpha1` that is automatically created in each Project Registration Namespace, which will contain both the `values.yaml` and `questions.yaml` that was used to configure the chart (which was embedded directly into the `prometheus-federator` binary).

-### Namespaces
+## Namespaces

 As a Project Operator based on [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator), Prometheus Federator has three different classifications of namespaces that the operator looks out for:

@@ -65,7 +65,7 @@ As a Project Operator based on [rancher/helm-project-operator](https://github.co

    :::

-### Helm Resources (HelmChart, HelmRelease)
+## Helm Resources (HelmChart, HelmRelease)

 On deploying a ProjectHelmChart, the Prometheus Federator will automatically create and manage two child custom resources that manage the underlying Helm resources in turn:

@@ -87,7 +87,7 @@ HelmRelease CRs emit Kubernetes Events that detect when an underlying Helm relea

 Both of these resources are created for all Helm charts in the Operator / System namespaces to avoid escalation of privileges to underprivileged users.

-### Advanced Helm Project Operator Configuration
+## Advanced Helm Project Operator Configuration

 For more information on advanced configurations, refer to [this page](https://github.com/rancher/prometheus-federator/blob/main/charts/prometheus-federator/0.0.1/README.md#advanced-helm-project-operator-configuration).

@@ -103,6 +103,6 @@ For more information on advanced configurations, refer to [this page](https://gi
 |`helmProjectOperator.hardenedNamespaces.configuration`| The configuration to be supplied to the default ServiceAccount or auto-generated NetworkPolicy on managing a namespace. |
 -->

-### Prometheus Federator on the Local Cluster
+## Prometheus Federator on the Local Cluster

 Prometheus Federator is a resource intensive application. Installing it to the local cluster is possible, but **not recommended**.
@@ -21,7 +21,7 @@ The following descriptions correspond to the numbers in the diagram above:
 3. [Node Agents](#3-node-agents)
 4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)

-### 1. The Authentication Proxy
+## 1. The Authentication Proxy

 In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
 the pods. Bob is authenticated through Rancher's authentication proxy.
@@ -32,7 +32,7 @@ Rancher communicates with Kubernetes clusters using a [service account](https://

 By default, Rancher generates a [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.

-### 2. Cluster Controllers and Cluster Agents
+## 2. Cluster Controllers and Cluster Agents

 Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.

@@ -52,13 +52,13 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
 -  Applies the roles and bindings defined in each cluster's global policies
 - Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health

-### 3. Node Agents
+## 3. Node Agents

 If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.

 The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.

-### 4. Authorized Cluster Endpoint
+## 4. Authorized Cluster Endpoint

 An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.

@@ -6,7 +6,7 @@ title: Kubernetes Security Best Practices
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
 </head>

-### Restricting cloud metadata API access
+## Restricting Cloud Metadata API Access

 Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.

@@ -27,11 +27,11 @@ Security is at the heart of all Rancher features. From integrating with all the

 On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters.

-### NeuVector Integration with Rancher
+## NeuVector Integration with Rancher

 NeuVector is an open-source, container-focused security application that is now integrated into Rancher. NeuVector provides production security, DevOps vulnerability protection, and a container firewall, et al. Please see the [Rancher docs](../../integrations-in-rancher/neuvector/neuvector.md) and the [NeuVector docs](https://open-docs.neuvector.com/) for more information.

-### Running a CIS Security Scan on a Kubernetes Cluster
+## Running a CIS Security Scan on a Kubernetes Cluster

 Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark.

@@ -47,13 +47,13 @@ When Rancher runs a CIS security scan on a cluster, it generates a report showin

 For details, refer to the section on [security scans](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md).

-### SELinux RPM
+## SELinux RPM

 [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.

 We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

-### Rancher Hardening Guide
+## Rancher Hardening Guide

 The Rancher Hardening Guide is based on controls and best practices found in the <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a> from the Center for Internet Security.

@@ -63,7 +63,7 @@ The hardening guides provide prescriptive guidance for hardening a production in

 Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher.

-### The CIS Benchmark and Self-Assessment
+## The CIS Benchmark and Self-Assessment

 The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.

@@ -71,7 +71,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o

 Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.

-### Third-party Penetration Test Reports
+## Third-party Penetration Test Reports

 Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Previous penetration test reports are available below.

@@ -82,14 +82,14 @@ Results:

 Please note that new reports are no longer shared or made publicly available.

-### Rancher Security Advisories and CVEs
+## Rancher Security Advisories and CVEs

 Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](security-advisories-and-cves.md)

-### Kubernetes Security Best Practices
+## Kubernetes Security Best Practices

 For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.

-### Rancher Security Best Practices
+## Rancher Security Best Practices

 For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.
@@ -6,7 +6,7 @@ title: Advanced Options for Docker Installs
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/single-node-rancher-in-docker/advanced-options"/>
 </head>

-### Custom CA Certificate
+## Custom CA Certificate

 If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate.

@@ -30,7 +30,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### API Audit Log
+## API Audit Log

 The API Audit Log records all the user and system transactions made through Rancher server.

@@ -49,7 +49,7 @@ docker run -d --restart=unless-stopped \
  rancher/rancher:latest
 ```

-### TLS settings
+## TLS settings

 To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:

@@ -65,7 +65,7 @@ Privileged access is [required.](../../getting-started/installation-and-upgrade/

 See [TLS settings](../../getting-started/installation-and-upgrade/installation-references/tls-settings.md) for more information and options.

-### Air Gap
+## Air Gap

 If you are visiting this page to complete an air gap installation, you must prepend your private registry URL to the server tag when running the installation command in the option that you choose. Add `<REGISTRY.DOMAIN.COM:PORT>` with your private registry URL in front of `rancher/rancher:latest`.

@@ -73,7 +73,7 @@ If you are visiting this page to complete an air gap installation, you must prep

     <REGISTRY.DOMAIN.COM:PORT>/rancher/rancher:latest

-### Persistent Data
+## Persistent Data

 Rancher uses etcd as a datastore. When Rancher is installed with Docker, the embedded etcd is being used. The persistent data is at the following path in the container: `/var/lib/rancher`.

@@ -89,7 +89,7 @@ docker run -d --restart=unless-stopped \

 Privileged access is [required.](../../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)

-### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node
+## Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node

 In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container.

@@ -10,14 +10,15 @@ For Rancher versions that have `rancher-webhook` installed, certain versions cre

 In Rancher v2.6.3 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.6.2 or below, there are two methods to work around this issue:

-##### 1. Users with cluster access, run the following commands:
+## 1. Users with Cluster Access, Run the Following Commands:
+
 ```
 kubectl delete secret -n cattle-system cattle-webhook-tls
 kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
 kubectl delete pod -n cattle-system -l app=rancher-webhook
 ```

-##### 2. Users with no cluster access via `kubectl`:
+## 2. Users with No Cluster Access Via `kubectl`:

 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.

@@ -10,11 +10,12 @@ The commands/steps listed on this page can be used to check networking related i

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI.

-### Double check if all the required ports are opened in your (host) firewall
+## Double Check if All the Required Ports are Opened in Your (Host) Firewall

 Double check if all the [required ports](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) are opened in your (host) firewall. The overlay network uses UDP in comparison to all other required ports which are TCP.

-### Check if overlay network is functioning correctly
+
+## Check if Overlay Network is Functioning Correctly

 The pod can be scheduled to any of the hosts you used for your cluster, but that means that the NGINX ingress controller needs to be able to route the request from `NODE_1` to `NODE_2`. This happens over the overlay network. If the overlay network is not functioning, you will experience intermittent TCP/HTTP connection failures due to the NGINX ingress controller not being able to route to the pod.

@@ -98,7 +99,7 @@ The `swiss-army-knife` container does not support Windows nodes. It also [does n
 6. You can now clean up the DaemonSet by running `kubectl delete ds/overlaytest`.


-### Check if MTU is correctly configured on hosts and on peering/tunnel appliances/devices
+### Check if MTU is Correctly Configured on Hosts and on Peering/Tunnel Appliances/Devices

 When the MTU is incorrectly configured (either on hosts running Rancher, nodes in created/imported clusters or on appliances/devices in between), error messages will be logged in Rancher and in the agents, similar to:

@@ -10,7 +10,7 @@ The commands/steps listed on this page can be used to check your Rancher Kuberne

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`).

-### Check Rancher pods
+## Check Rancher Pods

 Rancher pods are deployed as a Deployment in the `cattle-system` namespace.

@@ -31,25 +31,25 @@ rancher-7dbd7875f7-qw7wb   1/1     Running   0          8m    x.x.x.x     x.x.x.

 If a pod is unable to run (Status is not **Running**, Ready status is not showing `1/1` or you see a high count of Restarts), check the pod details, logs and namespace events.

-#### Pod details
+### Pod Details

 ```
 kubectl -n cattle-system describe pods -l app=rancher
 ```

-#### Pod container logs
+### Pod Container Logs

 ```
 kubectl -n cattle-system logs -l app=rancher
 ```

-#### Namespace events
+### Namespace Events

 ```
 kubectl -n cattle-system get events
 ```

-### Check ingress
+## Check Ingress

 Ingress should have the correct `HOSTS` (showing the configured FQDN) and `ADDRESS` (host address(es) it will be routed to).

@@ -64,7 +64,7 @@ NAME      HOSTS                    ADDRESS                   PORTS     AGE
 rancher   rancher.yourdomain.com   x.x.x.x,x.x.x.x,x.x.x.x   80, 443   2m
 ```

-### Check ingress controller logs
+## Check Ingress Controller Logs

 When accessing your configured Rancher FQDN does not show you the UI, check the ingress controller logging to see what happens when you try to access Rancher:

@@ -72,7 +72,7 @@ When accessing your configured Rancher FQDN does not show you the UI, check the
 kubectl -n ingress-nginx logs -l app=ingress-nginx
 ```

-### Leader election
+## Leader Election

 The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `cattle-controllers` Lease in the `kube-system` namespace (in this example, `rancher-dbc7ff869-gvg6k`).

@@ -87,7 +87,7 @@ NAME                 HOLDER                    AGE
 cattle-controllers   rancher-dbc7ff869-gvg6k   6h10m
 ```

-#### Configuration
+### Configuration

 _Available as of Rancher 2.8.3_

@@ -10,13 +10,13 @@ The commands/steps listed on this page can be used to check clusters that you ar

 Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kubeconfig_from_imported_cluster.yml`)

-### Rancher agents
+## Rancher Agents

 Communication to the cluster (Kubernetes API via cattle-cluster-agent) and communication to the nodes is done through Rancher agents.

 If the cattle-cluster-agent cannot connect to the configured `server-url`, the cluster will remain in **Pending** state, showing `Waiting for full cluster configuration`.

-#### cattle-node-agent
+### cattle-node-agent

 :::note

@@ -49,7 +49,7 @@ Check logging of a specific cattle-node-agent pod or all cattle-node-agent pods:
 kubectl -n cattle-system logs -l app=cattle-agent
 ```

-#### cattle-cluster-agent
+### cattle-cluster-agent

 Check if the cattle-cluster-agent pod is present in the cluster, has status **Running** and doesn't have a high count of Restarts:

@@ -20,7 +20,7 @@ Now with this feature, a downstream cluster admin should be able to look at the
 If the audit logs are shipped off of the cluster, a user of the logging system should be able to identify the user in the external Identity Provider system.
 A Rancher Admin should now be able to view Rancher audit logs and follow through to the Kubernetes audit log by using the external Identity Provider username.

-### Feature Description
+## Feature Description

 - When Kubernetes Audit logs are enabled on the downstream cluster, in each event that is logged, the external Identity Provider's username is now logged for each request, at the "metadata" level.
 - When Rancher API Audit logs are enabled on the Rancher installation, the external Identity Provider's username is also logged now at the `auditLog.level=1` for each request that hits the Rancher API server, including the login requests.