[2.0-2.4] Move files out of pages-for-subheaders

2026-09-26 13:08:11 +00:00 · 2024-01-12 16:07:44 -08:00
parent 3a4b7e73c0
commit c32fd49367
256 changed files with 1241 additions and 1241 deletions
@@ -0,0 +1,55 @@
+---
+title: API
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/about-the-api"/>
+</head>
+
+## How to use the API
+
+The API has its own user interface accessible from a web browser.  This is an easy way to see resources, perform actions, and see the equivalent cURL or HTTP request & response.  To access it, click on your user avatar in the upper right corner. Under **API & Keys**, you can find the URL endpoint as well as create [API keys](../user-settings/api-keys.md).
+
+## Authentication
+
+API requests must include authentication information.  Authentication is done with HTTP basic authentication using [API Keys](../user-settings/api-keys.md). API keys can create new clusters and have access to multiple clusters via `/v3/clusters/`. [Cluster and project roles](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md) apply to these keys and restrict what clusters and projects the account can see and what actions they can take.
+
+By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. For details on how to invalidate them, refer to the [API tokens page](api-tokens.md).
+
+## Making requests
+
+The API is generally RESTful but has several features to make the definition of everything discoverable by a client so that generic clients can be written instead of having to write specific code for every type of resource.  For detailed info about the generic API spec, [see here](https://github.com/rancher/api-spec/blob/master/specification.md).
+
+- Every type has a Schema which describes:
+  - The URL to get to the collection of this type of resources
+  - Every field the resource can have, along with their type, basic validation rules, whether they are required or optional, etc.
+  - Every action that is possible on this type of resource, with their inputs and outputs (also as schemas).
+  - Every field that filtering is allowed on
+  - What HTTP verb methods are available for the collection itself, or for individual resources in the collection.
+
+
+- So the theory is that you can load just the list of schemas and know everything about the API.  This is in fact how the UI for the API works, it contains no code specific to Rancher itself.  The URL to get Schemas is sent in every HTTP response as a `X-Api-Schemas` header.  From there you can follow the `collection` link on each schema to know where to list resources, and other `links` inside of the returned resources to get any other information.
+
+- In practice, you will probably just want to construct URL strings.  We highly suggest limiting this to the top-level to list a collection (`/v3/<type>`) or get a specific resource (`/v3/<type>/<id>`).  Anything deeper than that is subject to change in future releases.
+
+- Resources have relationships between each other called links.  Each resource includes a map of `links` with the name of the link and the URL to retrieve that information.  Again you should `GET` the resource and then follow the URL in the `links` map, not construct these strings yourself.
+
+- Most resources have actions, which do something or change the state of the resource.  To use these, send a HTTP `POST` to the URL in the `actions` map for the action you want.  Some actions require input or produce output, see the individual documentation for each type or the schemas for specific information.
+
+- To edit a resource, send a HTTP `PUT` to the `links.update` link on the resource with the fields that you want to change.  If the link is missing then you don't have permission to update the resource. Unknown fields and ones that are not editable are ignored.
+
+- To delete a resource, send a HTTP `DELETE` to the `links.remove` link on the resource.  If the link is missing then you don't have permission to update the resource.
+
+- To create a new resource, HTTP `POST` to the collection URL in the schema (which is `/v3/<type>`).
+
+## Filtering
+
+Most collections can be filtered on the server-side by common fields using HTTP query parameters.  The `filters` map shows you what fields can be filtered on and what the filtered values were for the request you made.  The API UI has controls to setup filtering and show you the appropriate request.  For simple "equals" matches it's just `field=value`.  Modifiers can be added to the field name, e.g. `field_gt=42` for "field is greater than 42".  See the [API spec](https://github.com/rancher/api-spec/blob/master/specification.md#filtering) for full details.
+
+## Sorting
+
+Most collections can be sorted on the server-side by common fields using HTTP query parameters.  The `sortLinks` map shows you what sorts are available, along with the URL to get the collection sorted by that.  It also includes info about what the current response was sorted by, if specified.
+
+## Pagination
+
+API responses are paginated with a limit of 100 resources per page by default.  This can be changed with the `limit` query parameter, up to a maximum of 1000, e.g. `/v3/pods?limit=1000`.  The `pagination` map in collection responses tells you whether or not you have the full result set and has a link to the next page if you do not.
@@ -0,0 +1,21 @@
+---
+title: Best Practices Guide
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/best-practices"/>
+</head>
+
+The purpose of this section is to consolidate best practices for Rancher implementations. This also includes recommendations for related technologies, such as Kubernetes, Docker, containers, and more. The objective is to improve the outcome of a Rancher implementation using the operational experience of Rancher and its customers.
+
+If you have any questions about how these might apply to your use case, please contact your Customer Success Manager or Support.
+
+Use the navigation bar on the left to find the current best practices for managing and deploying the Rancher Server.
+
+For more guidance on best practices, you can consult these resources:
+
+- [Security](../rancher-security/rancher-security.md)
+- [Rancher Blog](https://www.suse.com/c/rancherblog/)
+- [Rancher Forum](https://forums.rancher.com/)
+- [Rancher Users Slack](https://slack.rancher.io/)
+- [Rancher Labs YouTube Channel - Online Meetups, Demos, Training, and Webinars](https://www.youtube.com/channel/UCh5Xtp82q8wjijP8npkVTBA/featured)
@@ -12,7 +12,7 @@ Don't run other workloads or microservices in the Kubernetes cluster that Ranche
 ### Don't Run Rancher on a Hosted Kubernetes Environment
 When the Rancher server is installed on a Kubernetes cluster, it should not be run in a hosted Kubernetes environment such as Google's GKE, Amazon's EKS, or Microsoft's AKS. These hosted Kubernetes solutions do not expose etcd to a degree that is manageable for Rancher, and their customizations can interfere with Rancher operations.

-It is strongly recommended to use hosted infrastructure such as Amazon's EC2 or Google's GCE instead. When you create a cluster using RKE on an infrastructure provider, you can configure the cluster to create etcd snapshots as a backup. You can then [use RKE](https://rancher.com/docs/rke/latest/en/etcd-snapshots/) or [Rancher](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md) to restore your cluster from one of these snapshots. In a hosted Kubernetes environment, this backup and restore functionality is not supported.
+It is strongly recommended to use hosted infrastructure such as Amazon's EC2 or Google's GCE instead. When you create a cluster using RKE on an infrastructure provider, you can configure the cluster to create etcd snapshots as a backup. You can then [use RKE](https://rancher.com/docs/rke/latest/en/etcd-snapshots/) or [Rancher](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md) to restore your cluster from one of these snapshots. In a hosted Kubernetes environment, this backup and restore functionality is not supported.

 ### Make sure nodes are configured correctly for Kubernetes
 It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd.  More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.4/op-guide/performance/)
@@ -27,11 +27,11 @@ For best performance, run all three of your nodes in the same geographic datacen
 It's strongly recommended to have a "staging" or "pre-production" environment of the Kubernetes cluster that Rancher runs on. This environment should mirror your production environment as closely as possible in terms of software and hardware configuration.

 ### Monitor Your Clusters to Plan Capacity
-The Rancher server's Kubernetes cluster should run within the [system and hardware requirements](../../pages-for-subheaders/installation-requirements.md) as closely as possible. The more you deviate from the system and hardware requirements, the more risk you take.
+The Rancher server's Kubernetes cluster should run within the [system and hardware requirements](../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) as closely as possible. The more you deviate from the system and hardware requirements, the more risk you take.

 However, metrics-driven capacity planning analysis should be the ultimate guidance for scaling Rancher, because the published requirements take into account a variety of workload types.

 Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution, and Grafana, which lets you visualize the metrics from Prometheus.

-After you [enable monitoring](../../pages-for-subheaders/cluster-monitoring.md) in the cluster, you can set up [a notification channel](../../explanations/integrations-in-rancher/notifiers.md) and [cluster alerts](../../pages-for-subheaders/cluster-alerts.md) to let you know if your cluster is approaching its capacity. You can also use the Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale.
+After you [enable monitoring](../../explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md) in the cluster, you can set up [a notification channel](../../explanations/integrations-in-rancher/notifiers.md) and [cluster alerts](../../explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md) to let you know if your cluster is approaching its capacity. You can also use the Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale.

@@ -18,7 +18,7 @@ These tips can help you solve problems before they happen.

 ### Run Rancher on a Supported OS and Supported Docker Version

-Rancher is container-based and can potentially run on any Linux-based operating system. However, only operating systems listed in the [requirements documentation](../../pages-for-subheaders/installation-requirements.md) should be used for running Rancher, along with a supported version of Docker. These versions have been most thoroughly tested and can be properly supported by the Rancher Support team.
+Rancher is container-based and can potentially run on any Linux-based operating system. However, only operating systems listed in the [requirements documentation](../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) should be used for running Rancher, along with a supported version of Docker. These versions have been most thoroughly tested and can be properly supported by the Rancher Support team.

 ### Upgrade Your Kubernetes Version

@@ -50,7 +50,7 @@ Certificates can be renewed for Rancher-provisioned clusters [through the Ranche

 ### Enable Recurring Snapshots for Backing up and Restoring the Cluster

-Make sure etcd recurring snapshots are enabled. Extend the snapshot retention to a period of time that meets your business needs. In the event of a catastrophic failure or deletion of data, this may be your only recourse for recovery. For details about configuring snapshots, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/etcd-snapshots/) or the [Rancher documentation on backups](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md).
+Make sure etcd recurring snapshots are enabled. Extend the snapshot retention to a period of time that meets your business needs. In the event of a catastrophic failure or deletion of data, this may be your only recourse for recovery. For details about configuring snapshots, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/etcd-snapshots/) or the [Rancher documentation on backups](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md).

 ### Provision Clusters with Rancher

@@ -102,13 +102,13 @@ Provision three or more control plane nodes. Some control plane components, such

 ### Monitor Your Cluster

-Closely monitor and scale your nodes as needed. You should [enable cluster monitoring](../../pages-for-subheaders/cluster-monitoring.md) and use the Prometheus metrics and Grafana visualization options as a starting point.
+Closely monitor and scale your nodes as needed. You should [enable cluster monitoring](../../explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md) and use the Prometheus metrics and Grafana visualization options as a starting point.

 ## Tips for Security

 Below are some basic tips for increasing security in Rancher. For more detailed information about securing your cluster, you can refer to these resources:

- Rancher's [security documentation and Kubernetes cluster hardening guide](../../pages-for-subheaders/rancher-security.md)
+- Rancher's [security documentation and Kubernetes cluster hardening guide](../rancher-security/rancher-security.md)
 - [101 More Security Best Practices for Kubernetes](https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/)

 ### Update Rancher with Security Patches
@@ -0,0 +1,9 @@
+---
+title: CLI with Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/cli-with-rancher"/>
+</head>
+
+Interact with Rancher using command line interface (CLI) tools from your workstation. The following docs will describe the [Rancher CLI](rancher-cli.md) and [kubectl Utility](kubectl-utility.md).
@@ -65,16 +65,16 @@ The following commands are available for use in Rancher CLI.
 | Command  | Result  |
 |---|---|
 | `apps, [app]`  | Performs operations on catalog applications (i.e., individual [Helm charts](https://docs.helm.sh/developing_charts/)) or Rancher charts.  |
-| `catalog`  | Performs operations on [catalogs](../../pages-for-subheaders/helm-charts-in-rancher.md).  |
-| `clusters, [cluster]`  | Performs operations on your [clusters](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md).  |
+| `catalog`  | Performs operations on [catalogs](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md).  |
+| `clusters, [cluster]`  | Performs operations on your [clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md).  |
 | `context`  | Switches between Rancher [projects](../../how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md). For an example, see [Project Selection](#project-selection).  |
-| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]`  | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects](../../how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md) and [workloads](../../pages-for-subheaders/workloads-and-pods.md)). Specify resources by name or ID.  |
+| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]`  | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects](../../how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md) and [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md)). Specify resources by name or ID.  |
 | `kubectl`  |Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations).   |
 | `login, [l]`  | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication).  |
 | `namespaces, [namespace]`  |Performs operations on namespaces.   |
 | `nodes, [node]`  |Performs operations on nodes.   |
 | `projects, [project]`  | Performs operations on [projects](../../how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md).  |
-| `ps`  | Displays [workloads](../../pages-for-subheaders/workloads-and-pods.md) in a project.  |
+| `ps`  | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project.  |
 | `settings, [setting]`  | Shows the current settings for your Rancher Server.  |
 | `ssh`  | Connects to one of your cluster nodes using the SSH protocol.  |
 | `help, [h]`  | Shows a list of commands or help for one command.  |
@@ -88,4 +88,4 @@ All commands accept the `--help` flag, which documents each command's usage.

 ### Limitations

-The Rancher CLI **cannot** be used to install [dashboard apps or Rancher feature charts](../../pages-for-subheaders/helm-charts-in-rancher.md).
+The Rancher CLI **cannot** be used to install [dashboard apps or Rancher feature charts](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md).
@@ -0,0 +1,73 @@
+---
+title: Cluster Configuration
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/cluster-configuration"/>
+</head>
+
+After you provision a Kubernetes cluster using Rancher, you can still edit options and settings for the cluster.
+
+For information on editing cluster membership, go to [this page.](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md)
+
+- [Cluster Management Capabilities by Cluster Type](#cluster-management-capabilities-by-cluster-type)
+- [Editing Clusters in the Rancher UI](#editing-clusters-in-the-rancher-ui)
+- [Editing Clusters with YAML](#editing-clusters-with-yaml)
+- [Updating ingress-nginx](#updating-ingress-nginx)
+
+### Cluster Management Capabilities by Cluster Type
+
+The options and settings available for an existing cluster change based on the method that you used to provision it. For example, only clusters [provisioned by RKE](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) have **Cluster Options** available for editing.
+
+The following table summarizes the options and settings available for each cluster type:
+
+import ClusterCapabilitiesTable from '../shared-files/_cluster-capabilities-table.md';
+
+<ClusterCapabilitiesTable />
+
+### Editing Clusters in the Rancher UI
+
+To edit your cluster, open the **Global** view, make sure the **Clusters** tab is selected, and then select **&#8942; > Edit** for the cluster that you want to edit.
+
+In [clusters launched by RKE](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md), you can edit any of the remaining options that follow.
+
+Note that these options are not available for imported clusters or hosted Kubernetes clusters.
+
+Option | Description |
+---------|----------|
+ Kubernetes Version | The version of Kubernetes installed on each cluster node. For more detail, see [Upgrading Kubernetes](../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md). |
+ Network Provider | The \container networking interface (CNI) that powers networking for your cluster.<br/><br/>**Note:** You can only choose this option while provisioning your cluster. It cannot be edited later. |
+ Project Network Isolation | As of Rancher v2.0.7, if you're using the Canal network provider, you can choose whether to enable or disable inter-project communication. |
+ Nginx Ingress | If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use Nginx ingress within the cluster. |
+ Metrics Server Monitoring | Each cloud provider capable of launching a cluster using RKE can collect metrics and monitor for your cluster nodes. Enable this option to view your node metrics from your cloud provider's portal. |
+ Pod Security Policy Support | Enables [pod security policies](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) for the cluster. After enabling this option, choose a policy using the **Default Pod Security Policy** drop-down. |
+ Docker version on nodes | Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support. If you choose to require a [supported Docker version](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-7-lb.md), Rancher will stop pods from running on nodes that don't have a supported Docker version installed. |
+ Docker Root Directory | The directory on your cluster nodes where you've installed Docker. If you install Docker on your nodes to a non-default directory, update this path. |
+ Default Pod Security Policy | If you enable **Pod Security Policy Support**, use this drop-down to choose the pod security policy that's applied to the cluster. |
+ Cloud Provider | If you're using a cloud provider to host cluster nodes launched by RKE, enable [this option](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md) so that you can use the cloud provider's native features. If you want to store persistent data for your cloud-hosted cluster, this option is required.  |
+
+### Editing Clusters with YAML
+
+Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the options available in an RKE installation, except for system_images configuration, by specifying them in YAML.
+
+- To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
+- To read from an existing RKE file, click **Read from File**.
+
+![image](/img/cluster-options-yaml.png)
+
+For an example of RKE config file syntax, see the [RKE documentation](https://rancher.com/docs/rke/latest/en/example-yamls/).
+
+For the complete reference of configurable options for RKE Kubernetes clusters in YAML, see the [RKE documentation.](https://rancher.com/docs/rke/latest/en/config-options/)
+
+In Rancher v2.0.0-v2.2.x, the config file is identical to the  [cluster config file for the Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/config-options/), which is the tool Rancher uses to provision clusters. In Rancher v2.3.0, the RKE information is still included in the config file, but it is separated from other options, so that the RKE cluster config options are nested under the `rancher_kubernetes_engine_config` directive. For more information, see the [cluster configuration reference.](rancher-server-configuration/rke1-cluster-configuration.md)
+
+>**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`.
+
+
+
+
+### Updating ingress-nginx
+
+Clusters that were created before Kubernetes 1.16 will have an `ingress-nginx` `updateStrategy` of `OnDelete`. Clusters that were created with Kubernetes 1.16 or newer will have `RollingUpdate`.
+
+If the `updateStrategy` of `ingress-nginx` is `OnDelete`, you will need to delete these pods to get the correct version for your deployment.
@@ -0,0 +1,9 @@
+---
+title: Downstream Cluster Configuration
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/downstream-cluster-configuration"/>
+</head>
+
+The following docs will discuss [node template configuration](node-template-configuration/node-template-configuration.md).
@@ -28,7 +28,7 @@ See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.
 See our three example JSON policies:

 - [Example IAM Policy](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy)
- [Example IAM Policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider](../../../../pages-for-subheaders/set-up-cloud-providers.md) or want to pass an IAM Profile to an instance)
+- [Example IAM Policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md) or want to pass an IAM Profile to an instance)
 - [Example IAM Policy to allow encrypted EBS volumes](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-to-allow-encrypted-ebs-volumes) policy to an user.

 ### Authenticate & Configure Nodes
@@ -45,7 +45,7 @@ Please refer to [Amazon EC2 security group when using Node Driver](../../../../g

 Configure the instances that will be created. Make sure you configure the correct **SSH User** for the configured AMI.

-If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider](../../../../pages-for-subheaders/set-up-cloud-providers.md), you will need an additional permission in your policy. See [Example IAM policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) for an example policy.
+If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md), you will need an additional permission in your policy. See [Example IAM policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) for an example policy.

 ### Engine Options

@@ -67,7 +67,7 @@ See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.
 See our three example JSON policies:

 - [Example IAM Policy](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy)
- [Example IAM Policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider](../../../../pages-for-subheaders/set-up-cloud-providers.md) or want to pass an IAM Profile to an instance)
+- [Example IAM Policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md) or want to pass an IAM Profile to an instance)
 - [Example IAM Policy to allow encrypted EBS volumes](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-to-allow-encrypted-ebs-volumes) policy to an user.

 ### Zone and Network
@@ -88,7 +88,7 @@ Make sure you configure the correct **SSH User** for the configured AMI.

 ### IAM Instance Profile Name

-If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider](../../../../pages-for-subheaders/set-up-cloud-providers.md), you will need an additional permission in your policy. See [Example IAM policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) for an example policy.
+If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md), you will need an additional permission in your policy. See [Example IAM policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) for an example policy.

 ### Docker Daemon

@@ -0,0 +1,9 @@
+---
+title: Node Template Configuration
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/node-template-configuration"/>
+</head>
+
+To learn about node template config, refer to [EC2 Node Template Configuration](amazon-ec2.md), [DigitalOcean Node Template Configuration](digitalocean.md), [Azure Node Template Configuration](azure.md), and [vSphere Node Template Configuration](vsphere/vsphere.md).
@@ -0,0 +1,16 @@
+---
+title: VSphere Node Template Configuration
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere"/>
+</head>
+
+The vSphere node templates in Rancher were updated in the following Rancher versions. Refer to the newest configuration reference that is less than or equal to your Rancher version:
+
+- [v2.3.3](v2.3.3.md)
+- [v2.3.0](v2.3.0.md)
+- [v2.2.0](v2.2.0.md)
+- [v2.0.4](v2.0.4.md)
+
+For Rancher versions before v2.0.4, refer to [this version.](prior-to-v2.0.4.md)
@@ -0,0 +1,10 @@
+---
+title: Rancher Server Configuration
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/rancher-server-configuration"/>
+</head>
+
+- [RKE1 Cluster Configuration](rke1-cluster-configuration.md)
+- [Use Existing Nodes](use-existing-nodes/use-existing-nodes.md)
@@ -6,7 +6,7 @@ title: RKE Cluster Configuration Reference
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration"/>
 </head>

-When Rancher installs Kubernetes, it uses [RKE](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) as the Kubernetes distribution.
+When Rancher installs Kubernetes, it uses [RKE](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) as the Kubernetes distribution.

 This section covers the configuration options that are available in Rancher for a new or existing RKE Kubernetes cluster.

@@ -22,7 +22,7 @@ This section is a cluster configuration reference, covering the following topics

 ## Rancher UI Options

-When creating a cluster using one of the options described in [Rancher Launched Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md), you can configure basic Kubernetes options using the **Cluster Options** section.
+When creating a cluster using one of the options described in [Rancher Launched Kubernetes](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md), you can configure basic Kubernetes options using the **Cluster Options** section.

 ### Kubernetes Version

@@ -62,7 +62,7 @@ When Weave is selected as network provider, Rancher will automatically enable en

 ### Kubernetes Cloud Providers

-You can configure a [Kubernetes cloud provider](../../../pages-for-subheaders/set-up-cloud-providers.md). If you want to use [volumes and storage](../../../pages-for-subheaders/create-kubernetes-persistent-storage.md) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
+You can configure a [Kubernetes cloud provider](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/set-up-cloud-providers.md). If you want to use [volumes and storage](../../../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.

 >**Note:** If the cloud provider you want to use is not listed as an option, you will need to use the [config file option](#cluster-config-file) to configure the cloud provider. Please reference the [RKE cloud provider documentation](https://rancher.com/docs/rke/latest/en/config-options/cloud-providers/) on how to configure the cloud provider.

@@ -101,7 +101,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det

 ### Node Pools

-For information on using the Rancher UI to set up node pools in an RKE cluster, refer to [this page.](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md)
+For information on using the Rancher UI to set up node pools in an RKE cluster, refer to [this page.](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)

 ## Advanced Options

@@ -125,7 +125,7 @@ Option to enable and select a default [Pod Security Policy](../../../how-to-guid

 ### Docker Version on Nodes

-Option to require [a supported Docker version](../../../pages-for-subheaders/installation-requirements.md) installed on the cluster nodes that are added to the cluster, or to allow unsupported Docker versions installed on the cluster nodes.
+Option to require [a supported Docker version](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) installed on the cluster nodes that are added to the cluster, or to allow unsupported Docker versions installed on the cluster nodes.

 ### Docker Root Directory

@@ -354,7 +354,7 @@ See [Docker Root Directory](#docker-root-directory).

 ### enable_cluster_monitoring

-Option to enable or disable [Cluster Monitoring](../../../pages-for-subheaders/cluster-monitoring.md).
+Option to enable or disable [Cluster Monitoring](../../../explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md).

 ### enable_network_policy

@@ -6,7 +6,7 @@ title: Rancher Agent Options
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
 </head>

-Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](../../../../pages-for-subheaders/use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
+Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.

 For an overview of how Rancher communicates with downstream clusters using node agents, refer to the [architecture section.](../../../rancher-manager-architecture/communicating-with-downstream-user-clusters.md#3-node-agents)

@@ -0,0 +1,118 @@
+---
+title: Launching Kubernetes on Existing Custom Nodes
+description: To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/use-existing-nodes"/>
+</head>
+
+When you create a custom cluster, Rancher uses RKE (the Rancher Kubernetes Engine) to create a Kubernetes cluster in on-prem bare-metal servers, on-prem virtual machines, or in any node hosted by an infrastructure provider.
+
+To use this option you'll need access to servers you intend to use in your Kubernetes cluster. Provision each server according to the [requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md), which includes some hardware specifications and Docker. After you install Docker on each server, you willl also run the command provided in the Rancher UI on each server to turn each one into a Kubernetes node.
+
+This section describes how to set up a custom cluster.
+
+## Creating a Cluster with Custom Nodes
+
+>**Want to use Windows hosts as Kubernetes workers?**
+>
+>See [Configuring Custom Clusters for Windows](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/use-windows-clusters.md) before you start.
+
+
+### 1. Provision a Linux Host
+
+Begin creation of a custom cluster by provisioning a Linux host. Your host can be:
+
+- A cloud-host virtual machine (VM)
+- An on-prem VM
+- A bare-metal server
+
+If you want to reuse a node from a previous custom cluster, [clean the node](../../../../how-to-guides/advanced-user-guides/manage-clusters/clean-cluster-nodes.md) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
+
+Provision the host according to the [installation requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) and the [checklist for production-ready clusters.](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md)
+
+### 2. Create the Custom Cluster
+
+1. From the **Clusters** page, click **Add Cluster**.
+
+2. Choose **Custom**.
+
+3. Enter a **Cluster Name**.
+
+4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
+
+5. Use **Cluster Options** to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options.**
+
+    >**Using Windows nodes as Kubernetes workers?**
+    >
+    >- See [Enable the Windows Support Option](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/use-windows-clusters.md).
+    >- The only Network Provider available for clusters with Windows support is Flannel.
+6.	<a id="step-6"></a>Click **Next**.
+
+7.	From **Node Role**, choose the roles that you want filled by a cluster node.
+
+    >**Notes:**
+    >
+    >- Using Windows nodes as Kubernetes workers? See [this section](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/use-windows-clusters.md).
+    >- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
+
+8.	<a id="step-8"></a>**Optional**: Click **[Show advanced options](rancher-agent-options.md)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
+
+9. Copy the command displayed on screen to your clipboard.
+
+10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
+
+    >**Note:** Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles. Repeat the steps as many times as needed.
+
+11. When you finish running the command(s) on your Linux host(s), click **Done**.
+
+**Result:**
+
+Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
+
+You can access your cluster after its state is updated to **Active.**
+
+**Active** clusters are assigned two Projects:
+
+- `Default`, containing the `default` namespace
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
+
+
+### 3. Amazon Only: Tag Resources
+
+If you have configured your cluster to use Amazon as **Cloud Provider**, tag your AWS resources with a cluster ID.
+
+[Amazon Documentation: Tagging Your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
+
+>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md)
+
+
+The following resources need to tagged with a `ClusterID`:
+
+- **Nodes**: All hosts added in Rancher.
+- **Subnet**: The subnet used for your cluster
+- **Security Group**: The security group used for your cluster.
+
+    >**Note:** Do not tag multiple security groups. Tagging multiple groups generates an error when creating Elastic Load Balancer.
+
+The tag that should be used is:
+
+```
+Key=kubernetes.io/cluster/<CLUSTERID>, Value=owned
+```
+
+`<CLUSTERID>` can be any string you choose. However, the same string must be used on every resource you tag. Setting the tag value to `owned` informs the cluster that all resources tagged with the `<CLUSTERID>` are owned and managed by this cluster.
+
+If you share resources between clusters, you can change the tag to:
+
+```
+Key=kubernetes.io/cluster/CLUSTERID, Value=shared
+```
+
+## Optional Next Steps
+
+After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
+
+- **Access your cluster with the kubectl CLI:** Follow [these steps](../../../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-from-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
+- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../../../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
@@ -0,0 +1,53 @@
+---
+title: Configuring OpenLDAP
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/configure-openldap"/>
+</head>
+
+_Available as of v2.0.5_
+
+If your organization uses LDAP for user authentication, you can configure Rancher to communicate with an OpenLDAP server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the organisation's central user repository, while allowing end-users to authenticate with their LDAP credentials when logging in to the Rancher UI.
+
+## Prerequisites
+
+Rancher must be configured with a LDAP bind account (aka service account) to search and retrieve LDAP entries pertaining to users and groups that should have access. It is recommended to not use an administrator account or personal account for this purpose and instead create a dedicated account in OpenLDAP with read-only access to users and groups under the configured search base (see below).
+
+> **Using TLS?**
+>
+> If the certificate used by the OpenLDAP server is self-signed or not from a recognised certificate authority, make sure have at hand the CA certificate (concatenated with any intermediate certificates) in PEM format. You will have to paste in this certificate during the configuration so that Rancher is able to validate the certificate chain.
+
+## Configure OpenLDAP in Rancher
+
+Configure the settings for the OpenLDAP server, groups and users. For help filling out each field, refer to the [configuration reference.](openldap-config-reference.md)
+
+> Before you proceed with the configuration, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/about-authentication.md#external-authentication-configuration-and-principal-users).
+
+1. Log into the Rancher UI using the initial local `admin` account.
+2. From the **Global** view, navigate to **Security** > **Authentication**
+3. Select **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.
+
+### Test Authentication
+
+Once you have completed the configuration, proceed by testing  the connection to the OpenLDAP server. Authentication with OpenLDAP will be enabled implicitly if the test is successful.
+
+> **Note:**
+>
+> The OpenLDAP user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned administrator privileges in Rancher. You should therefore make a conscious decision on which LDAP account you use to perform this step.
+
+1. Enter the **username** and **password** for the OpenLDAP account that should be mapped to the local principal account.
+2. Click **Authenticate With OpenLDAP** to test the OpenLDAP connection and finalise the setup.
+
+**Result:**
+
+- OpenLDAP authentication is configured.
+- The LDAP user pertaining to the entered credentials is mapped to the local principal (administrative) account.
+
+> **Note:**
+>
+> You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services.
+
+## Annex: Troubleshooting
+
+If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -8,7 +8,7 @@ title: OpenLDAP Configuration Reference

 For further details on configuring OpenLDAP authentication, refer to the [official documentation.](https://www.openldap.org/doc/)

-> Before you proceed with the configuration, please familiarize yourself with the concepts of [External Authentication Configuration and Principal Users](../../pages-for-subheaders/about-authentication.md#external-authentication-configuration-and-principal-users).
+> Before you proceed with the configuration, please familiarize yourself with the concepts of [External Authentication Configuration and Principal Users](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/about-authentication.md#external-authentication-configuration-and-principal-users).

 ## Background: OpenLDAP Authentication Flow

@@ -8,7 +8,7 @@ title: Feature Flags

 Feature flags were introduced to allow you to try experimental features that are not enabled by default.

-To learn about feature values and how to enable features, refer [here](../../pages-for-subheaders/enable-experimental-features.md).
+To learn about feature values and how to enable features, refer [here](../../getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/enable-experimental-features.md).

 :::note 

@@ -11,7 +11,7 @@ This page is a configuration reference for the Rancher Helm chart.

 For help choosing a Helm chart version, refer to [this page.](../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)

-For information on enabling experimental features, refer to [this page.](../../pages-for-subheaders/enable-experimental-features.md)
+For information on enabling experimental features, refer to [this page.](../../getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/enable-experimental-features.md)


 ## Common Options
@@ -64,13 +64,13 @@ For information on enabling experimental features, refer to [this page.](../../p

 Enabling the [API Audit Log](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md).

-You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](../../pages-for-subheaders/cluster-logging.md) for the `System` Project on the Rancher server cluster.
+You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) for the `System` Project on the Rancher server cluster.

 ```plain
 --set auditLog.level=1
 ```

-By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable the [Logging service under Rancher Tools](../../pages-for-subheaders/cluster-logging.md) for the Rancher server cluster or System Project.
+By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable the [Logging service under Rancher Tools](../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) for the Rancher server cluster or System Project.

 Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.

@@ -153,7 +153,7 @@ kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-

 For details on installing Rancher with a private registry, see:

- [Air Gap: Kubernetes Install](../../pages-for-subheaders/air-gap-helm2.md)
+- [Air Gap: Kubernetes Install](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/air-gap-helm2/air-gap-helm2.md)

 ## External TLS Termination

@@ -0,0 +1,9 @@
+---
+title: Installation References
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/installation-references"/>
+</head>
+
+Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
@@ -54,7 +54,7 @@ Each [worker node](https://kubernetes.io/docs/concepts/architecture/nodes/) runs
 - **Kubelets:** An agent that monitors the state of the node, ensuring your containers are healthy.
 - **Workloads:** The containers and pods that hold your apps, as well as other types of deployments.

-Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your  [workloads](../pages-for-subheaders/workloads-and-pods.md).
+Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your  [workloads](../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md).

 ## About Helm

@@ -8,7 +8,7 @@ This section assumes that you understand how persistent storage works in Kuberne

 >**Prerequisites (for both parts A and B):**
 >
->[Persistent volumes](../../pages-for-subheaders/create-kubernetes-persistent-storage.md) must be available for the cluster.
+>[Persistent volumes](../../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) must be available for the cluster.

 ### A. Configuring Persistent Data for Docker Registry

@@ -0,0 +1,265 @@
+---
+title: Pipelines
+---
+
+Rancher's pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds or scripts, publish Docker images or catalog applications, and deploy the updated software to users.
+
+Setting up a pipeline can help developers deliver new software as quickly and efficiently as possible. Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline.
+
+After configuring Rancher and GitHub, you can deploy containers running Jenkins to automate a pipeline execution:
+
+- Build your application from code to image.
+- Validate your builds.
+- Deploy your build images to your cluster.
+- Run unit tests.
+- Run regression tests.
+
+>**Notes:**
+>
+>- Pipelines improved in Rancher v2.1. Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1.
+>- Still using v2.0.x? See the pipeline documentation for [previous versions](v2.0.x.md).
+>- Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
+
+
+## Concepts
+
+For an explanation of concepts and terminology used in this section, refer to [this page.](concepts.md)
+
+## How Pipelines Work
+
+After enabling the ability to use pipelines in a project, you can configure multiple pipelines in each project. Each pipeline is unique and can be configured independently.
+
+A pipeline is configured off of a group of files that are checked into source code repositories. Users can configure their pipelines either through the Rancher UI or by adding a `.rancher-pipeline.yml` into the repository.
+
+Before pipelines can be configured, you will need to configure authentication to your version control provider, e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories](example-repositories.md) to view some common pipeline deployments.
+
+When you configure a pipeline in one of your projects, a namespace specifically for the pipeline is automatically created. The following components are deployed to it:
+
+  - **Jenkins:**
+
+    The pipeline's build engine. Because project users do not directly interact with Jenkins, it's managed and locked.
+
+    >**Note:**  There is no option to use existing Jenkins deployments as the pipeline engine.
+
+  - **Docker Registry:**
+
+    Out-of-the-box, the default target for your build-publish step is an internal Docker Registry. However, you can make configurations to push to a remote registry instead. The internal Docker Registry is only accessible from cluster nodes and cannot be directly accessed by users. Images are not persisted beyond the lifetime of the pipeline and should only be used in pipeline runs. If you need to access your images outside of pipeline runs, please push to an external registry.
+
+  - **Minio:**
+
+    Minio storage is used to store the logs for pipeline executions.
+
+  >**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components](configure-persistent-data.md).
+
+## Roles-based Access Control for Pipelines
+
+If you can access a project, you can enable repositories to start building pipelines.
+
+Only [administrators](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), [cluster owners or members](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), or [project owners](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) can configure version control providers and manage global pipeline execution settings.
+
+Project members can only configure repositories and pipelines.
+
+## Setting up Pipelines
+
+To set up pipelines, you will need to do the following:
+
+1. [Configure version control providers](#1-configure-version-control-providers)
+2. [Configure repositories](#2-configure-repositories)
+3. [Configure the pipeline](#3-configure-the-pipeline)
+
+### 1. Configure Version Control Providers
+
+Before you can start configuring a pipeline for your repository, you must configure and authorize a version control provider.
+
+| Provider  | Available as of  |
+| --- | --- |
+| GitHub  | v2.0.0           |
+| GitLab | v2.1.0 |
+| Bitbucket | v2.2.0 |
+
+Select your provider's tab below and follow the directions.
+
+<Tabs>
+<TabItem value="GitHub">
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar. In versions before v2.2.0, you can select **Resources > Pipelines**.
+
+1. Follow the directions displayed to **Setup a Github application**. Rancher redirects you to Github to setup an OAuth App in Github.
+
+1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher.
+
+1. If you're using GitHub for enterprise, select **Use a private github enterprise installation**. Enter the host address of your GitHub installation.
+
+1. Click **Authenticate**.
+
+
+</TabItem>
+<TabItem value="GitLab">
+
+_Available as of v2.1.0_
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar. In versions before v2.2.0, you can select **Resources > Pipelines**.
+
+1. Follow the directions displayed to **Setup a GitLab application**. Rancher redirects you to GitLab.
+
+1. From GitLab, copy the **Application ID** and **Secret**. Paste them into Rancher.
+
+1. If you're using GitLab for enterprise setup, select **Use a private gitlab enterprise installation**. Enter the host address of your GitLab installation.
+
+1. Click **Authenticate**.
+
+>**Note:**
+> 1. Pipeline uses Gitlab [v4 API](https://github.com/gitlabhq/gitlabhq/blob/9-0-stable/doc/api/v3_to_v4.md) and the supported Gitlab version is 9.0+.
+> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
+
+</TabItem>
+<TabItem value="Bitbucket Cloud">
+
+_Available as of v2.2.0_
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar.
+
+1. Choose the **Use public Bitbucket Cloud** option.
+
+1. Follow the directions displayed to **Setup a Bitbucket Cloud application**. Rancher redirects you to Bitbucket to setup an OAuth consumer in Bitbucket.
+
+1. From Bitbucket, copy the consumer **Key** and **Secret**. Paste them into Rancher.
+
+1. Click **Authenticate**.
+
+
+</TabItem>
+<TabItem value="Bitbucket Server">
+
+_Available as of v2.2.0_
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Select **Tools > Pipelines** in the navigation bar.
+
+1. Choose the **Use private Bitbucket Server setup** option.
+
+1. Follow the directions displayed to **Setup a Bitbucket Server application**.
+
+1. Enter the host address of your Bitbucket server installation.
+
+1. Click **Authenticate**.
+
+>**Note:**
+> Bitbucket server needs to do SSL verification when sending webhooks to Rancher. Please ensure that Rancher server's certificate is trusted by the Bitbucket server. There are two options:
+>
+> 1. Setup Rancher server with a certificate from a trusted CA.
+> 1. If you're using self-signed certificates, import Rancher server's certificate to the Bitbucket server. For instructions, see the Bitbucket server documentation for [configuring self-signed certificates](https://confluence.atlassian.com/bitbucketserver/if-you-use-self-signed-certificates-938028692.html).
+>
+
+</TabItem>
+</Tabs>
+
+**Result:** After the version control provider is authenticated, you will be automatically re-directed to start configuring which repositories you want start using with a pipeline.
+
+### 2. Configure Repositories
+
+After the version control provider is authorized, you are automatically re-directed to start configuring which repositories that you want start using pipelines with. Even if someone else has set up the version control provider, you will see their repositories and can build a pipeline.
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Click **Resources > Pipelines.** In versions before v2.3.0, click **Workloads > Pipelines.**
+
+1. Click on **Configure Repositories**.
+
+1. A list of repositories are displayed. If you are configuring repositories the first time, click on **Authorize & Fetch Your Own Repositories** to fetch your repository list.
+
+1. For each repository that you want to set up a pipeline, click on **Enable**.
+
+1. When you're done enabling all your repositories, click on **Done**.
+
+**Results:** You have a list of repositories that you can start configuring pipelines for.
+
+### 3. Configure the Pipeline
+
+Now that repositories are added to your project, you can start configuring the pipeline by adding automated stages and steps. For your convenience, there are multiple built-in step types for dedicated tasks.
+
+1. From the **Global** view, navigate to the project that you want to configure pipelines.
+
+1. Click **Resources > Pipelines.** In versions before v2.3.0, click **Workloads > Pipelines.**
+
+1. Find the repository that you want to set up a pipeline for.
+
+1. Configure the pipeline through the UI or using a yaml file in the repository, i.e. `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`. Pipeline configuration is split into stages and steps. Stages must fully complete before moving onto the next stage, but steps in a stage run concurrently. For each stage, you can add different step types. Note: As you build out each step, there are different advanced options based on the step type. Advanced options include trigger rules, environment variables, and secrets. For more information on configuring the pipeline through the UI or the YAML file, refer to the [pipeline configuration reference.](pipeline-configuration.md)
+
+   * If you are going to use the UI, select the vertical **&#8942; > Edit Config** to configure the pipeline using the UI. After the pipeline is configured, you must view the YAML file and push it to the repository.
+   * If you are going to use the YAML file, select the vertical **&#8942; > View/Edit YAML** to configure the pipeline. If you choose to use a YAML file, you need to push it to the repository after any changes in order for it to be updated in the repository. When editing the pipeline configuration, it takes a few moments for Rancher to check for an existing pipeline configuration.
+
+1. Select which `branch` to use from the list of branches.
+
+1. _Available as of v2.2.0_ Optional: Set up notifications.
+
+1. Set up the trigger rules for the pipeline.
+
+1. Enter a **Timeout** for the pipeline.
+
+1. When all the stages and steps are configured, click **Done**.
+
+**Results:** Your pipeline is now configured and ready to be run.
+
+
+## Pipeline Configuration Reference
+
+Refer to [this page](pipeline-configuration.md) for details on how to configure a pipeline to:
+
+- Run a script
+- Build and publish images
+- Publish catalog templates
+- Deploy YAML
+- Deploy a catalog app
+
+The configuration reference also covers how to configure:
+
+- Notifications
+- Timeouts
+- The rules that trigger a pipeline
+- Environment variables
+- Secrets
+
+
+## Running your Pipelines
+
+Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** (In versions before v2.3.0, go to the **Pipelines** tab.) Find your pipeline and select the vertical **&#8942; > Run**.
+
+During this initial run, your pipeline is tested, and the following pipeline components are deployed to your project as workloads in a new namespace dedicated to the pipeline:
+
+- `docker-registry`
+- `jenkins`
+- `minio`
+
+This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab.
+
+## Triggering a Pipeline
+
+When a repository is enabled, a webhook is automatically set in the version control provider. By default, the pipeline is triggered by a **push** event to a repository, but you can modify the event(s) that trigger running the pipeline.
+
+Available Events:
+
+* **Push**: Whenever a commit is pushed to the branch in the repository, the pipeline is triggered.
+* **Pull Request**: Whenever a pull request is made to the repository, the pipeline is triggered.
+* **Tag**: When a tag is created in the repository, the pipeline is triggered.
+
+> **Note:** This option doesn't exist for Rancher's [example repositories](example-repositories.md).
+
+### Modifying the Event Triggers for the Repository
+
+1. From the **Global** view, navigate to the project that you want to modify the event trigger for the pipeline.
+
+1. 1. Click **Resources > Pipelines.** In versions before v2.3.0, click **Workloads > Pipelines.**
+
+1. Find the repository that you want to modify the event triggers. Select the vertical **&#8942; > Setting**.
+
+1. Select which event triggers (**Push**, **Pull Request** or **Tag**) you want for the repository.
+
+1. Click **Save**.
@@ -2,7 +2,7 @@
 title: v2.0.x Pipeline Documentation
 ---

->**Note:** This section describes the pipeline feature as implemented in Rancher v2.0.x. If you are using Rancher v2.1 or later, where pipelines have been significantly improved, please refer to the new documentation for [v2.1 or later](../../pages-for-subheaders/pipelines.md).
+>**Note:** This section describes the pipeline feature as implemented in Rancher v2.0.x. If you are using Rancher v2.1 or later, where pipelines have been significantly improved, please refer to the new documentation for [v2.1 or later](pipelines.md).



@@ -21,13 +21,13 @@ Logging is helpful because it allows you to:

 Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.

-Refer to the logging documentation [here.](../pages-for-subheaders/cluster-logging.md)
+Refer to the logging documentation [here.](../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md)

 ## Monitoring

 Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution.

-For details, refer to [Monitoring.](../pages-for-subheaders/cluster-monitoring.md)
+For details, refer to [Monitoring.](../explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md)

 ## Alerts

@@ -35,7 +35,7 @@ After monitoring is enabled, you can set up alerts and notifiers that provide th

 Alerts are rules that trigger notifications. Before you can receive alerts, you must configure one or more notifier in Rancher. The scope for alerts can be set at either the cluster or project level.

-For details, refer to [Alerts.](../pages-for-subheaders/cluster-alerts.md)
+For details, refer to [Alerts.](../explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md)

 ## Notifiers

@@ -49,7 +49,7 @@ _Available as of v2.3_

 [Istio](https://istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, control, troubleshoot, and secure the traffic within a complex network of microservices.

-Refer to the Istio documentation [here.](../pages-for-subheaders/istio.md)
+Refer to the Istio documentation [here.](../explanations/integrations-in-rancher/istio/istio.md)

 ## OPA Gatekeeper

@@ -59,4 +59,4 @@ Refer to the Istio documentation [here.](../pages-for-subheaders/istio.md)

 Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.

-Refer to the CIS scan documentation [here.](../pages-for-subheaders/cis-scans.md)
+Refer to the CIS scan documentation [here.](../explanations/integrations-in-rancher/cis-scans/cis-scans.md)
@@ -65,7 +65,7 @@ We recommend the following configurations for the load balancer and Ingress cont

 It is strongly recommended to install Rancher on a Kubernetes cluster on hosted infrastructure such as Amazon's EC2 or Google Compute Engine.

-For the best performance and greater security, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) for running your workloads.
+For the best performance and greater security, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) for running your workloads.

 It is not recommended to install Rancher on top of a managed Kubernetes service such as Amazon’s EKS or Google Kubernetes Engine. These hosted Kubernetes solutions do not expose etcd to a degree that is manageable for Rancher, and their customizations can interfere with Rancher operations.

@@ -109,7 +109,7 @@ With that said, it is safe to use all three roles on three nodes when setting up

 Because no additional workloads will be deployed on the Rancher server cluster, in most cases it is not necessary to use the same architecture that we recommend for the scalability and reliability of downstream clusters.

-For more best practices for downstream clusters, refer to the [production checklist](../../pages-for-subheaders/checklist-for-production-ready-clusters.md) or our [best practices guide.](../../pages-for-subheaders/best-practices.md)
+For more best practices for downstream clusters, refer to the [production checklist](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md) or our [best practices guide.](../best-practices/best-practices.md)

 ## Architecture for an Authorized Cluster Endpoint

@@ -62,7 +62,7 @@ The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/do

 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.

-> The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) to provision the cluster. It is not available for imported clusters, or for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
+> The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) to provision the cluster. It is not available for imported clusters, or for clusters in a hosted Kubernetes provider, such as Amazon's EKS.

 There are two main reasons why a user might need the authorized cluster endpoint:

@@ -0,0 +1,21 @@
+---
+title: Architecture
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/rancher-manager-architecture"/>
+</head>
+
+This section focuses on the [Rancher server and its components](rancher-server-and-components.md) and how [Rancher communicates with downstream Kubernetes clusters](communicating-with-downstream-user-clusters.md).
+
+For information on the different ways that Rancher can be installed, refer to the [overview of installation options.](../../getting-started/installation-and-upgrade/installation-and-upgrade.md#overview-of-installation-options)
+
+For a list of main features of the Rancher API server, refer to the [overview section.](../../getting-started/introduction/overview.md#features-of-the-rancher-api-server)
+
+For guidance about setting up the underlying infrastructure for the Rancher server, refer to the [architecture recommendations.](architecture-recommendations.md)
+
+:::note
+
+This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts](../kubernetes-concepts.md) page.
+
+:::
@@ -10,9 +10,9 @@ The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server

 The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service).

-For the best performance and security, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) for running your workloads.
+For the best performance and security, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md) for running your workloads.

-The diagram below shows how users can manipulate both [Rancher-launched Kubernetes](../../pages-for-subheaders/launch-kubernetes-with-rancher.md) clusters and [hosted Kubernetes](../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md) clusters through Rancher's authentication proxy:
+The diagram below shows how users can manipulate both [Rancher-launched Kubernetes](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) clusters and [hosted Kubernetes](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md) clusters through Rancher's authentication proxy:

 <figcaption>Managing Kubernetes Clusters through Rancher's Authentication Proxy</figcaption>

@@ -13,7 +13,7 @@ Only [administrators](../../how-to-guides/advanced-user-guides/authentication-pe

 ## Alerts Scope

-The scope for alerts can be set at either the [cluster level](../../pages-for-subheaders/cluster-alerts.md) or project level.
+The scope for alerts can be set at either the [cluster level](../../explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md) or project level.

 At the project level, Rancher monitors specific deployments and sends alerts for:

@@ -184,7 +184,7 @@ You can disable these advanced options when configuring a specific rule.
 ## Metric Expression Alerts
 _Available as of v2.2.4_

-If you enable [project monitoring](../../pages-for-subheaders/project-tools.md#monitoring), this alert type monitors for the overload from Prometheus expression querying.
+If you enable [project monitoring](rancher-project-tools.md#monitoring), this alert type monitors for the overload from Prometheus expression querying.

 Each of the below sections corresponds to a part of the alert rule configuration section in the Rancher UI.

@@ -4,7 +4,7 @@ title: Project Logging

 Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.

-For background information about how logging integrations work, refer to the [cluster administration section.](../../pages-for-subheaders/cluster-logging.md#how-logging-integrations-work)
+For background information about how logging integrations work, refer to the [cluster administration section.](../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md#how-logging-integrations-work)

 Rancher supports the following services:

@@ -40,7 +40,7 @@ Setting up a logging service to collect logs from your cluster/project has sever

 You can configure logging at either cluster level or project level.

- [Cluster logging](../../pages-for-subheaders/cluster-logging.md) writes logs for every pod in the cluster, i.e. in all the projects. For [RKE clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md), it also writes logs for all the Kubernetes system components.
+- [Cluster logging](../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) writes logs for every pod in the cluster, i.e. in all the projects. For [RKE clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md), it also writes logs for all the Kubernetes system components.

 - Project logging writes logs for every pod in that particular project.

@@ -0,0 +1,37 @@
+---
+title: Tools for Logging, Monitoring, and More
+---
+
+Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently.
+
+## Notifiers
+
+[Notifiers](../../explanations/integrations-in-rancher/notifiers.md) are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Notifications can be sent with Slack, email, PagerDuty, WeChat, and webhooks.
+
+## Alerts
+
+[Alerts](../../explanations/integrations-in-rancher/cluster-alerts/cluster-alerts.md) are rules that trigger notifications. Before you can receive alerts, you must configure one or more notifier in Rancher. The scope for alerts can be set at either the cluster or project level.
+
+For details on project-level alerts, see [this page.](project-alerts.md)
+
+## Logging
+
+Logging is helpful because it allows you to:
+
+- Capture and analyze the state of your cluster
+- Look for trends in your environment
+- Save your logs to a safe location outside of your cluster
+- Stay informed of events like a container crashing, a pod eviction, or a node dying
+- More easily debug and troubleshoot problems
+
+Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
+
+For details on setting up logging at the cluster level, refer to the [logging section.](../../explanations/integrations-in-rancher/cluster-logging/cluster-logging.md)
+
+For details on project-level logging, see [this section.](project-logging.md)
+
+## Monitoring
+
+_Available as of v2.2.0_
+
+Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. For details, refer to the [monitoring section.](../../explanations/integrations-in-rancher/cluster-monitoring/cluster-monitoring.md)
@@ -0,0 +1,101 @@
+---
+title: Security
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/rancher-security"/>
+</head>
+
+<table width="100%">
+<tr style={{verticalAlign: 'top'}}>
+<td width="30%" style={{border: 'none'}}>
+<h4>Security policy</h4>
+<p style={{padding: '8px'}}>Rancher Labs supports responsible disclosure, and endeavours to resolve all issues in a reasonable time frame. </p>
+</td>
+<td width="30%" style={{border: 'none'}}>
+<h4>Reporting process</h4>
+<p style={{padding: '8px'}}>Please submit possible security issues by emailing <a href="mailto:security@rancher.com">security@rancher.com</a></p>
+</td>
+<td width="30%" style={{border: 'none'}}>
+<h4>Announcements</h4>
+<p style={{padding: '8px'}}>Subscribe to the <a href="https://forums.rancher.com/c/announcements">Rancher announcements forum</a> for release updates.</p>
+</td>
+</tr>
+</table>
+
+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)
+- [Guide to hardening Rancher installations](#rancher-hardening-guide)
+- [The CIS Benchmark and self-assessment](#the-cis-benchmark-and-self-assessment)
+- [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
+
+_Available as of v2.4.0_
+
+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 (Center for Internet Security) Kubernetes Benchmark.
+
+The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes.
+
+The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace."
+
+CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team.
+
+The Benchmark provides recommendations of two types: Scored and Not Scored. We run tests related to only Scored recommendations.
+
+When Rancher runs a CIS security scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests.
+
+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
+
+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.
+
+The hardening guide provides prescriptive guidance for hardening a production installation of Rancher v2.1.x, v2.2.x and v.2.3.x. See Rancher's guides for [Self Assessment of the CIS Kubernetes Benchmark](#the-cis-benchmark-and-self-assessment) for the full list of security controls.
+
+> The hardening guides describe how to secure the nodes in your cluster, and it is recommended to follow a hardening guide before installing Kubernetes.
+
+Each version of the hardening guide is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
+
+Hardening Guide Version | Rancher Version | CIS Benchmark Version | Kubernetes Version
+------------------------|----------------|-----------------------|------------------
+[Hardening Guide v2.4](rancher-v2.4-hardening-guides/hardening-guide-with-cis-v1.5-benchmark.md) | Rancher v2.4 | Benchmark v1.5 | Kubernetes v1.15
+[Hardening Guide v2.3.5](rancher-v2.3-hardening-guides/rancher-v2.3.5-hardening-guide-with-cis-v1.5-benchmark.md) | Rancher v2.3.5 | Benchmark v1.5 | Kubernetes v1.15
+[Hardening Guide v2.3.3](rancher-v2.3-hardening-guides/rancher-v2.3.3-hardening-guide-with-cis-v1.4.1-benchmark.md) | Rancher v2.3.3 | Benchmark v1.4.1 | Kubernetes v1.14, v1.15, and v1.16
+[Hardening Guide v2.3](rancher-v2.3-hardening-guides/rancher-v2.3.0-hardening-guide-with-cis-v1.4.1-benchmark.md) | Rancher v2.3.0-v2.3.2 | Benchmark v1.4.1 | Kubernetes v1.15
+[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 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.
+
+Because Rancher and RKE install Kubernetes services as Docker containers, many of the control verification checks in the CIS Kubernetes Benchmark don't apply. This guide will walk through the various controls and provide updated example commands to audit compliance in Rancher created clusters. The original benchmark documents can be downloaded from the [CIS website](https://www.cisecurity.org/benchmark/kubernetes/).
+
+Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark:
+
+Self Assessment Guide Version | Rancher Version | Hardening Guide Version | Kubernetes Version | CIS Benchmark Version
+---------------------------|----------|---------|-------|-----
+[Self Assessment Guide v2.4](rancher-v2.4-hardening-guides/self-assessment-guide-with-cis-v1.5-benchmark.md#cis-kubernetes-benchmark-v15---rancher-v24-with-kubernetes-v115) | Rancher v2.4 | Hardening Guide v2.4 | Kubernetes v1.15 | Benchmark v1.5
+[Self Assessment Guide v2.3.5](rancher-v2.3-hardening-guides/rancher-v2.3.5-self-assessment-guide-with-cis-v1.5-benchmark.md#cis-kubernetes-benchmark-v15---rancher-v235-with-kubernetes-v115) | Rancher v2.3.5 | Hardening Guide v2.3.5 | Kubernetes v1.15 | Benchmark v1.5
+[Self Assessment Guide v2.3.3](rancher-v2.3-hardening-guides/rancher-v2.3.3-self-assessment-guide-with-cis-v1.4.1-benchmark.md) | Rancher v2.3.3 | Hardening Guide v2.3.3 | Kubernetes v1.16 | Benchmark v1.4.1
+[Self Assessment Guide v2.3](rancher-v2.3-hardening-guides/rancher-v2.3.0-self-assessment-guide-with-cis-v1.4.1-benchmark.md) | Rancher v2.3.0-2.3.2 | Hardening Guide v2.3 | Kubernetes v1.15 | Benchmark v1.4.1
+[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
+
+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.
+
+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 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)
@@ -0,0 +1,19 @@
+---
+title: Rancher v2.1
+---
+
+### Self Assessment Guide
+
+This [guide](self-assessment-guide-with-cis-v1.3-benchmark.md) corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark:
+
+Self Assessment Guide Version | Rancher Version | Hardening Guide Version | Kubernetes Version | CIS Benchmark Version
+---------------------------|----------|---------|-------|-----
+Self Assessment Guide v2.1 | Rancher v2.1.x | Hardening Guide v2.1 | Kubernetes 1.11 | Benchmark 1.3.0
+
+### Hardening Guide
+
+This hardening [guide](hardening-guide-with-cis-v1.3-benchmark.md) is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
+
+Hardening Guide Version | Rancher Version | CIS Benchmark Version | Kubernetes Version
+------------------------|----------------|-----------------------|------------------
+Hardening Guide v2.1 | Rancher v2.1.x | Benchmark v1.3.0 | Kubernetes 1.11
@@ -0,0 +1,19 @@
+---
+title: Rancher v2.2
+---
+
+### Self Assessment Guide
+
+This [guide](self-assessment-guide-with-cis-v1.4-benchmark.md) corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark:
+
+Self Assessment Guide Version | Rancher Version | Hardening Guide Version | Kubernetes Version | CIS Benchmark Version
+---------------------------|----------|---------|-------|-----
+Self Assessment Guide v2.2 | Rancher v2.2.x | Hardening Guide v2.2 | Kubernetes 1.13 | Benchmark v1.4.0 and v1.4.1
+
+### Hardening Guide
+
+This hardening [guide](hardening-guide-with-cis-v1.4-benchmark.md) is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
+
+Hardening Guide Version | Rancher Version | CIS Benchmark Version | Kubernetes Version
+------------------------|----------------|-----------------------|------------------
+Hardening Guide v2.2 | Rancher v2.2.x | Benchmark v1.4.1, 1.4.0 | Kubernetes 1.13
@@ -0,0 +1,12 @@
+---
+title: Rancher v2.3.x
+---
+
+The relevant Hardening Guide and Self Assessment guide depends on your Rancher version:
+
+- [Rancher v2.3.5 Hardening Guide](rancher-v2.3.5-hardening-guide-with-cis-v1.5-benchmark.md)
+- [Rancher v2.3.5 Self Assessment Guide](rancher-v2.3.5-self-assessment-guide-with-cis-v1.5-benchmark.md)
+- [Rancher v2.3.3 Hardening Guide](rancher-v2.3.3-hardening-guide-with-cis-v1.4.1-benchmark.md)
+- [Rancher v2.3.3 Self Assessment Guide](rancher-v2.3.3-self-assessment-guide-with-cis-v1.4.1-benchmark.md)
+- [Rancher v2.3.0 Hardening Guide](rancher-v2.3.0-hardening-guide-with-cis-v1.4.1-benchmark.md)
+- [Rancher v2.3.0 Self Assessment Guide](rancher-v2.3.0-self-assessment-guide-with-cis-v1.4.1-benchmark.md)
@@ -0,0 +1,19 @@
+---
+title: Rancher v2.4
+---
+
+### Self Assessment Guide
+
+This [guide](self-assessment-guide-with-cis-v1.5-benchmark.md) corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark:
+
+Self Assessment Guide Version | Rancher Version | Hardening Guide Version | Kubernetes Version | CIS Benchmark Version
+---------------------------|----------|---------|-------|-----
+Self Assessment Guide v2.4 | Rancher v2.4 | Hardening Guide v2.4 | Kubernetes v1.15 | Benchmark v1.5
+
+### Hardening Guide
+
+This hardening [guide](hardening-guide-with-cis-v1.5-benchmark.md) is intended to be used with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
+
+Hardening Guide Version | Rancher Version | CIS Benchmark Version | Kubernetes Version
+------------------------|----------------|-----------------------|------------------
+Hardening Guide v2.4 | Rancher v2.4 | Benchmark v1.5 | Kubernetes 1.15
@@ -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>

-When installing Rancher, there are several [advanced options](../../pages-for-subheaders/resources.md) that can be enabled.
+When installing Rancher, there are several [advanced options](../../getting-started/installation-and-upgrade/resources/resources.md) that can be enabled.

 ### Custom CA Certificate

@@ -20,7 +20,7 @@ Make sure `NO_PROXY` contains the network addresses, network address ranges and

 ## Docker Installation

-Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. Required values for `NO_PROXY` in a [Docker Installation](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md) are:
+Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. Required values for `NO_PROXY` in a [Docker Installation](../../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) are:

 - `localhost`
 - `127.0.0.1`
@@ -0,0 +1,9 @@
+---
+title: Single Node Rancher in Docker
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/single-node-rancher-in-docker"/>
+</head>
+
+The following docs will discuss [HTTP proxy configuration](http-proxy-configuration.md) and [advanced options](advanced-options.md) for Docker installs.
@@ -6,7 +6,7 @@ title: System Tools
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/system-tools"/>
 </head>

-System Tools is a tool to perform operational tasks on [Rancher Launched Kubernetes](../pages-for-subheaders/launch-kubernetes-with-rancher.md) clusters or [installations of Rancher on an RKE cluster.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) The tasks include:
+System Tools is a tool to perform operational tasks on [Rancher Launched Kubernetes](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) clusters or [installations of Rancher on an RKE cluster.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) The tasks include:

 * Collect logging and system metrics from nodes.
 * Remove Kubernetes resources created by Rancher.
@@ -44,7 +44,7 @@ After you download the tools, complete the following actions:

 ## Logs

-The logs subcommand will collect log files of core Kubernetes cluster components from nodes in [Rancher-launched Kubernetes clusters](../pages-for-subheaders/launch-kubernetes-with-rancher.md) or nodes on an [RKE Kubernetes cluster that Rancher is installed on.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md). See [Troubleshooting](../troubleshooting.md) for a list of core Kubernetes cluster components.
+The logs subcommand will collect log files of core Kubernetes cluster components from nodes in [Rancher-launched Kubernetes clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) or nodes on an [RKE Kubernetes cluster that Rancher is installed on.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md). See [Troubleshooting](../troubleshooting.md) for a list of core Kubernetes cluster components.

 System Tools will use the provided kubeconfig file to deploy a DaemonSet, that will copy all the logfiles from the core Kubernetes cluster components and add them to a single tar file (`cluster-logs.tar` by default). If you only want to collect logging from a single node, you can specify the node by using `--node NODENAME` or `-n NODENAME`.

@@ -64,7 +64,7 @@ The following are the options for the logs command:

 ## Stats

-The stats subcommand will display system metrics from nodes in [Rancher-launched Kubernetes clusters](../pages-for-subheaders/launch-kubernetes-with-rancher.md) or nodes in an [RKE Kubernetes cluster that Rancher is installed on.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md).
+The stats subcommand will display system metrics from nodes in [Rancher-launched Kubernetes clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) or nodes in an [RKE Kubernetes cluster that Rancher is installed on.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md).

 System Tools will deploy a DaemonSet, and run a predefined command based on `sar` (System Activity Report) to show system metrics.

@@ -84,7 +84,7 @@ The following are the options for the stats command:

 ## Remove

->**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd](../pages-for-subheaders/backup-restore-and-disaster-recovery.md) before executing the command.
+>**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md) before executing the command.

 When you install Rancher on a Kubernetes cluster, it will create Kubernetes resources to run and to store configuration data. If you want to remove Rancher from your cluster, you can use the `remove` subcommand to remove the Kubernetes resources. When you use the `remove` subcommand, the following resources will be removed:

@@ -104,7 +104,7 @@ When you install Rancher on a Kubernetes cluster, it will create Kubernetes reso

 When you run the command below, all the resources listed [above](#remove) will be removed from the cluster.

->**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd](../pages-for-subheaders/backup-restore-and-disaster-recovery.md) before executing the command.
+>**Warning:** This command will remove data from your etcd nodes. Make sure you have created a [backup of etcd](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md) before executing the command.

 ```
 ./system-tools remove --kubeconfig <KUBECONFIG> --namespace <NAMESPACE>
@@ -46,7 +46,7 @@ API Keys are composed of four components:

 - Enter your API key information into the application that will send requests to the Rancher API.
 - Learn more about the Rancher endpoints and parameters by selecting **View in API** for an object in the Rancher UI.
- API keys are used for API calls and [Rancher CLI](../../pages-for-subheaders/cli-with-rancher.md).
+- API keys are used for API calls and [Rancher CLI](../cli-with-rancher/cli-with-rancher.md).

 ## Deleting API Keys

@@ -8,7 +8,7 @@ title: Managing Cloud Credentials

 _Available as of v2.2.0_

-When you create a cluster [hosted by an infrastructure provider](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), [node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node.
+When you create a cluster [hosted by an infrastructure provider](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md), [node templates](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node.

 Node templates can use cloud credentials to access the credential information required to provision nodes in the infrastructure providers. The same cloud credential can be used by multiple node templates. By using a cloud credential, you do not have to re-enter access keys for the same cloud provider. Cloud credentials are stored as Kubernetes secrets.

@@ -16,7 +16,7 @@ Cloud credentials are only used by node templates if there are fields marked as

 You can create cloud credentials in two contexts:

- [During creation of a node template](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) for a cluster.
+- [During creation of a node template](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) for a cluster.
 - In the **User Settings**

 Cloud credentials are bound to their creator's user profile. They **cannot** be shared between non-admin users. However, admins are able to view and manage the cloud credentials of other users.
@@ -30,7 +30,7 @@ Cloud credentials are bound to their creator's user profile. They **cannot** be
 1. Based on the selected cloud credential type, enter the required values to authenticate with the infrastructure provider.
 1. Click **Create**.

-**Result:** The cloud credential is created and can immediately be used to [create node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates).
+**Result:** The cloud credential is created and can immediately be used to [create node templates](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates).

 ## Updating a Cloud Credential

@@ -40,7 +40,7 @@ When access credentials are changed or compromised, updating a cloud credential
 1. Choose the cloud credential you want to edit and click the **&#8942; > Edit**.
 1. Update the credential information and click **Save**.

-**Result:** The cloud credential is updated with the new access credentials. All existing node templates using this cloud credential will automatically use the updated information whenever [new nodes are added](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
+**Result:** The cloud credential is updated with the new access credentials. All existing node templates using this cloud credential will automatically use the updated information whenever [new nodes are added](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).

 ## Deleting a Cloud Credential

@@ -6,9 +6,9 @@ title: Managing Node Templates
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/user-settings/manage-node-templates"/>
 </head>

-When you provision a cluster [hosted by an infrastructure provider](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), [node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:
+When you provision a cluster [hosted by an infrastructure provider](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md), [node templates](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:

- While [provisioning a node pool cluster](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
+- While [provisioning a node pool cluster](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
 - At any time, from your [user settings](#creating-a-node-template-from-user-settings).

 When you create a node template, it is bound to your user profile. Node templates cannot be shared among users. You can delete stale node templates that you no longer user from your user settings.
@@ -19,7 +19,7 @@ When you create a node template, it is bound to your user profile. Node template
 1. Click **Add Template**.
 1. Select one of the cloud providers available. Then follow the instructions on screen to configure the template.

-**Result:** The template is configured. You can use the template later when you [provision a node pool cluster](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
+**Result:** The template is configured. You can use the template later when you [provision a node pool cluster](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).

 ## Updating a Node Template

@@ -28,7 +28,7 @@ When you create a node template, it is bound to your user profile. Node template

    :::note

-    As of v2.2.0, the default `active` [node drivers](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md) and any node driver, that has fields marked as `password`, are required to use [cloud credentials](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#cloud-credentials). If you have upgraded to v2.2.0, existing node templates will continue to work with the previous account access  information, but when you edit the node template, you will be required to create a cloud credential and the node template will start using it.
+    As of v2.2.0, the default `active` [node drivers](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md) and any node driver, that has fields marked as `password`, are required to use [cloud credentials](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#cloud-credentials). If you have upgraded to v2.2.0, existing node templates will continue to work with the previous account access  information, but when you edit the node template, you will be required to create a cloud credential and the node template will start using it.

    :::

@@ -44,7 +44,7 @@ When creating new node templates from your user settings, you can clone an exist
 1. Find the template you want to clone. Then select **&#8942; > Clone**.
 1. Complete the rest of the form.

-**Result:** The template is cloned and configured. You can use the template later when you [provision a node pool cluster](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
+**Result:** The template is cloned and configured. You can use the template later when you [provision a node pool cluster](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).

 ## Deleting a Node Template

@@ -0,0 +1,19 @@
+---
+title: User Settings
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/user-settings"/>
+</head>
+
+Within Rancher, each user has a number of settings associated with their login: personal preferences, API keys, etc. You can configure these settings by choosing from the **User Settings** menu. You can open this menu by clicking your avatar, located within the main menu.
+
+![User Settings Menu](/img/user-settings.png)
+
+The available user settings are:
+
+- [API & Keys](api-keys.md): If you want to interact with Rancher programmatically, you need an API key. Follow the directions in this section to obtain a key.
+- [Cloud Credentials](manage-cloud-credentials.md): Manage cloud credentials [used by node templates](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) to [provision nodes for clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md). Note: Available as of v2.2.0.
+- [Node Templates](manage-node-templates.md): Manage templates [used by Rancher to provision nodes for clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
+- [Preferences](user-preferences.md): Sets superficial preferences for the Rancher UI.
+- Log Out: Ends your user session.