mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Fix links
This commit is contained in:
Billy Tat
@@ -57,12 +57,12 @@ RKE2 provisioning is built on top of a new provisioning framework that leverages
|
||||
- Fully configure RKE2 clusters within Rancher
|
||||
- Choose CNI options Calico, Cilium, and Multus in addition to Canal
|
||||
|
||||
RKE2 provisioning also includes installing RKE2 on clusters with Windows nodes.
|
||||
RKE2 provisioning also includes installing RKE2 on clusters with Windows nodes.
|
||||
|
||||
Windows features for RKE2 include:
|
||||
|
||||
- Windows supports the vSphere node driver
|
||||
- Calico CNI for Windows RKE2 custom clusters
|
||||
- Calico CNI for Windows RKE2 custom clusters
|
||||
- Project Network Isolation (PNI) for Calico
|
||||
- Windows Containers with RKE2 powered by containerd
|
||||
- Provisioning of Windows RKE2 clusters through Terraform
|
||||
|
||||
@@ -60,12 +60,12 @@ Each version of the hardening guide is intended to be used with specific version
|
||||
|
||||
Hardening Guide Version | Rancher Version | CIS Benchmark Version | Kubernetes Version
|
||||
------------------------|----------------|-----------------------|------------------
|
||||
[Hardening Guide v2.4](security/hardening-2.4/) | Rancher v2.4 | Benchmark v1.5 | Kubernetes v1.15
|
||||
[Hardening Guide v2.3.5](security/hardening-2.3.5/) | Rancher v2.3.5 | Benchmark v1.5 | Kubernetes v1.15
|
||||
[Hardening Guide v2.3.3](security/hardening-2.3.3/) | Rancher v2.3.3 | Benchmark v1.4.1 | Kubernetes v1.14, v1.15, and v1.16
|
||||
[Hardening Guide v2.3](security/hardening-2.3/) | Rancher v2.3.0-v2.3.2 | Benchmark v1.4.1 | Kubernetes v1.15
|
||||
[Hardening Guide v2.2](security/hardening-2.2/) | Rancher v2.2.x | Benchmark v1.4.1 and 1.4.0 | Kubernetes v1.13
|
||||
[Hardening Guide v2.1](security/hardening-2.1/) | Rancher v2.1.x | Benchmark v1.3.0 | Kubernetes v1.11
|
||||
[Hardening Guide v2.4](../reference-guides/rancher-security/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](../reference-guides/rancher-security/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](../reference-guides/rancher-security/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](../reference-guides/rancher-security/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](../reference-guides/rancher-security/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](../reference-guides/rancher-security/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
|
||||
|
||||
|
||||
+6
-3
@@ -7,6 +7,9 @@ aliases:
|
||||
|
||||
The relevant Hardening Guide and Self Assessment guide depends on your Rancher version:
|
||||
|
||||
- [Rancher v2.3.5](security/rancher-2.3.x/rancher-v2.3.5)
|
||||
- [Rancher v2.3.3](security/rancher-2.3.x/rancher-v2.3.3)
|
||||
- [Rancher v2.3.0](security/rancher-2.3.x/rancher-v2.3.0)
|
||||
- [Rancher v2.3.5 Hardening Guide](../reference-guides/rancher-security/rancher-v2.3-hardening-guides/rancher-v2.3.5-hardening-guide-with-cis-v1.5-benchmark.md)
|
||||
- [Rancher v2.3.5 Self Assessment Guide](../reference-guides/rancher-security/rancher-v2.3-hardening-guides/rancher-v2.3.5-self-assessment-guide-with-cis-v1.5-benchmark.md)
|
||||
- [Rancher v2.3.3 Hardening Guide](../reference-guides/rancher-security/rancher-v2.3-hardening-guides/rancher-v2.3.3-hardening-guide-with-cis-v1.4.1-benchmark.md)
|
||||
- [Rancher v2.3.3 Self Assessment Guide](../reference-guides/rancher-security/rancher-v2.3-hardening-guides/rancher-v2.3.3-self-assessment-guide-with-cis-v1.4.1-benchmark.md)
|
||||
- [Rancher v2.3.0 Hardening Guide](../reference-guides/rancher-security/rancher-v2.3-hardening-guides/rancher-v2.3.0-hardening-guide-with-cis-v1.4.1-benchmark.md)
|
||||
- [Rancher v2.3.0 Self Assessment Guide](../reference-guides/rancher-security/rancher-v2.3-hardening-guides/rancher-v2.3.0-self-assessment-guide-with-cis-v1.4.1-benchmark.md)
|
||||
@@ -23,8 +23,8 @@ When installing Rancher, there are several advanced options that can be enabled
|
||||
|
||||
| Advanced Option | Available as of |
|
||||
| ----------------------------------------------------------------------------------------------------------------------- | --------------- |
|
||||
| [Custom CA Certificate](installation/options/custom-ca-root-certificate/) | v2.0.0 |
|
||||
| [API Audit Log](installation/options/api-audit-log/) | v2.0.0 |
|
||||
| [TLS Settings](installation/options/tls-settings/) | v2.1.7 |
|
||||
| [etcd configuration](installation/options/etcd/) | v2.2.0 |
|
||||
| [Local System Charts for Air Gap Installations](installation/options/local-system-charts) | v2.3.0 |
|
||||
| [Custom CA Certificate](../getting-started/installation-and-upgrade/resources/custom-ca-root-certificates.md) | v2.0.0 |
|
||||
| [API Audit Log](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md) | v2.0.0 |
|
||||
| [TLS Settings](../reference-guides/installation-references/tls-settings.md) | v2.1.7 |
|
||||
| [etcd configuration](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/tune-etcd-for-large-installs.md) | v2.2.0 |
|
||||
| [Local System Charts for Air Gap Installations](../getting-started/installation-and-upgrade/resources/local-system-charts.md) | v2.3.0 |
|
||||
|
||||
@@ -26,7 +26,7 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa
|
||||
|
||||
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
|
||||
|
||||
If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade](upgrades/upgrades/migrating-from-rke-add-on).
|
||||
If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md).
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Upgrade Outline](#upgrade-outline)
|
||||
@@ -55,7 +55,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](installation/upgrades-rollbacks/upgrades/ha/helm2)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air gap installs: Populate private registry
|
||||
|
||||
@@ -67,7 +67,7 @@ If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS
|
||||
|
||||
### For upgrades with cert-manager older than 0.8.0
|
||||
|
||||
[Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](installation/options/upgrading-cert-manager)
|
||||
[Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../getting-started/installation-and-upgrade/resources/upgrade-cert-manager.md)
|
||||
|
||||
# Upgrade Outline
|
||||
|
||||
@@ -285,4 +285,4 @@ Upgrading from v2.0.7 or earlier | Rancher introduced the `system` project, whic
|
||||
|
||||
Please use the Rancher helm chart to install Rancher on a Kubernetes cluster. For details, see the [Kubernetes Install](install-upgrade-on-a-kubernetes-cluster.md).
|
||||
|
||||
If you are currently using the RKE add-on install method, see [Migrating from a RKE add-on install](upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart.
|
||||
If you are currently using the RKE add-on install method, see [Migrating from a RKE add-on install](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/migrating-from-rke-add-on.md) for details on how to move to using the helm chart.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
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
|
||||
description: To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements
|
||||
metaDescription: "To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements"
|
||||
weight: 2225
|
||||
aliases:
|
||||
@@ -36,7 +36,7 @@ Begin creation of a custom cluster by provisioning a Linux host. Your host can b
|
||||
- An on-prem VM
|
||||
- A bare-metal server
|
||||
|
||||
If you want to reuse a node from a previous custom cluster, [clean the node](admin-settings/removing-rancher/rancher-cluster-nodes/) before using it in a cluster again. If you reuse a node that hasn't been cleaned, cluster provisioning may fail.
|
||||
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.](checklist-for-production-ready-clusters.md)
|
||||
|
||||
@@ -75,13 +75,13 @@ Provision the host according to the [installation requirements](../how-to-guides
|
||||
|
||||
11. When you finish running the command(s) on your Linux host(s), click **Done**.
|
||||
|
||||
**Result:**
|
||||
**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:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
@@ -97,7 +97,7 @@ Windows requires that containers must be built on the same Windows Server versio
|
||||
|
||||
### Cloud Provider Specific Requirements
|
||||
|
||||
If you set a Kubernetes cloud provider in your cluster, some additional steps are required. You might want to set a cloud provider if you want to want to leverage a cloud provider's capabilities, for example, to automatically provision storage, load balancers, or other infrastructure for your cluster. Refer to [this page](cluster-provisioning/rke-clusters/options/cloud-providers/) for details on how to configure a cloud provider cluster of nodes that meet the prerequisites.
|
||||
If you set a Kubernetes cloud provider in your cluster, some additional steps are required. You might want to set a cloud provider if you want to want to leverage a cloud provider's capabilities, for example, to automatically provision storage, load balancers, or other infrastructure for your cluster. Refer to [this page](../pages-for-subheaders/set-up-cloud-providers.md) for details on how to configure a cloud provider cluster of nodes that meet the prerequisites.
|
||||
|
||||
If you are using the GCE (Google Compute Engine) cloud provider, you must do the following:
|
||||
|
||||
@@ -142,7 +142,7 @@ You will provision three nodes:
|
||||
| Node 2 | Linux (Ubuntu Server 18.04 recommended) |
|
||||
| Node 3 | Windows (Windows Server core version 1809 or above required) |
|
||||
|
||||
If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.](cluster-provisioning/rke-clusters/options/cloud-providers)
|
||||
If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.](../pages-for-subheaders/set-up-cloud-providers.md)
|
||||
|
||||
# 2. Create the Cluster on Existing Nodes
|
||||
|
||||
@@ -171,18 +171,18 @@ The first node in your cluster should be a Linux host has both the **Control Pla
|
||||
|
||||
1. In the **Node Operating System** section, click **Linux**.
|
||||
1. In the **Node Role** section, choose at least **etcd** and **Control Plane**. We recommend selecting all three.
|
||||
1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](admin-settings/agent-options/) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
|
||||
1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
|
||||
1. Copy the command displayed on the screen to your clipboard.
|
||||
1. SSH into your Linux host and run the command that you copied to your clipboard.
|
||||
1. When you are finished provisioning your Linux node(s), select **Done**.
|
||||
|
||||
**Result:**
|
||||
**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:
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: Creating a vSphere Cluster
|
||||
shortTitle: vSphere
|
||||
description: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
metaDescription: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
description: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
metaDescription: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes.
|
||||
weight: 2225
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/
|
||||
@@ -37,7 +37,7 @@ _Available as of v2.3.3_
|
||||
|
||||
Node templates for vSphere have been updated so that when you create a node template with your vSphere credentials, the template is automatically populated with the same options for provisioning VMs that you have access to in the vSphere console.
|
||||
|
||||
For the fields to be populated, your setup needs to fulfill the [prerequisites.](cluster-provisioning/rke-clusters/node-pools/vsphercluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/#prerequisites)
|
||||
For the fields to be populated, your setup needs to fulfill the [prerequisites.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md#prerequisites)
|
||||
|
||||
### More Supported Operating Systems
|
||||
|
||||
|
||||
@@ -17,13 +17,13 @@ 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](backups/restorations/) 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](../../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.
|
||||
|
||||
### 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://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md)
|
||||
|
||||
### When using RKE: Backup the Statefile
|
||||
RKE keeps record of the cluster state in a file called `cluster.rkestate`. This file is important for the recovery of a cluster and/or the continued maintenance of the cluster through RKE. Because this file contains certificate material, we strongly recommend encrypting this file before backing up. After each run of `rke up` you should backup the state file.
|
||||
RKE keeps record of the cluster state in a file called `cluster.rkestate`. This file is important for the recovery of a cluster and/or the continued maintenance of the cluster through RKE. Because this file contains certificate material, we strongly recommend encrypting this file before backing up. After each run of `rke up` you should backup the state file.
|
||||
|
||||
### Run All Nodes in the Cluster in the Same Datacenter
|
||||
For best performance, run all three of your nodes in the same geographic datacenter. If you are running nodes in the cloud, such as AWS, run each node in a separate Availability Zone. For example, launch node 1 in us-west-2a, node 2 in us-west-2b, and node 3 in us-west-2c.
|
||||
@@ -36,7 +36,7 @@ The Rancher server's Kubernetes cluster should run within the [system and hardwa
|
||||
|
||||
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.
|
||||
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](monitoring-alerting/legacy/monitoring/cluster-monitoring/) in the cluster, you can set up [a notification channel](../../explanations/integrations-in-rancher/notifiers.md) and [cluster alerts](cluster-admin/tools/alerts/) 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](../../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.
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ Provision 3 or 5 etcd nodes. Etcd requires a quorum to determine a leader by the
|
||||
Provision three or more control plane nodes. Some control plane components, such as the `kube-apiserver`, run in [active-active](https://www.jscape.com/blog/active-active-vs-active-passive-high-availability-cluster) mode and will give you more scalability. Other components such as kube-scheduler and kube-controller run in active-passive mode (leader elect) and give you more fault tolerance.
|
||||
|
||||
### Monitor Your Cluster
|
||||
Closely monitor and scale your nodes as needed. You should [enable cluster monitoring](monitoring-alerting/legacy/monitoring/cluster-monitoring/) 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](../../pages-for-subheaders/cluster-monitoring.md) and use the Prometheus metrics and Grafana visualization options as a starting point.
|
||||
|
||||
|
||||
# Tips for Security
|
||||
|
||||
+1
-1
@@ -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](cluster-provisioning/rke-clusters/options/cloud-providers) 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](../../../../pages-for-subheaders/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
|
||||
|
||||
+4
-4
@@ -60,9 +60,9 @@ Out of the box, Rancher is compatible with the following network providers:
|
||||
|
||||
**Notes on Canal:**
|
||||
|
||||
In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects](k8s-in-rancher/projects-and-namespaces/).
|
||||
In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects](../../../how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md).
|
||||
|
||||
As of v2.0.7, if you use Canal, you also have the option of using **Project Network Isolation**, which will enable or disable communication between pods in different [projects](k8s-in-rancher/projects-and-namespaces/).
|
||||
As of v2.0.7, if you use Canal, you also have the option of using **Project Network Isolation**, which will enable or disable communication between pods in different [projects](../../../how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md).
|
||||
|
||||
>**Attention Rancher v2.0.0 - v2.0.6 Users**
|
||||
>
|
||||
@@ -79,7 +79,7 @@ When Weave is selected as network provider, Rancher will automatically enable en
|
||||
|
||||
### Kubernetes Cloud Providers
|
||||
|
||||
You can configure a [Kubernetes cloud provider](cluster-provisioning/rke-clusters/options/cloud-providers). If you want to use [volumes and storage](k8s-in-rancher/volumes-and-storage/) 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](../../../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.
|
||||
|
||||
>**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.
|
||||
|
||||
@@ -371,7 +371,7 @@ See [Docker Root Directory](#docker-root-directory).
|
||||
|
||||
### enable_cluster_monitoring
|
||||
|
||||
Option to enable or disable [Cluster Monitoring](monitoring-alerting/legacy/monitoring/cluster-monitoring/).
|
||||
Option to enable or disable [Cluster Monitoring](../../../pages-for-subheaders/cluster-monitoring.md).
|
||||
|
||||
### enable_network_policy
|
||||
|
||||
|
||||
+5
-6
@@ -46,7 +46,7 @@ For information on enabling experimental features, refer to [this page.](../../p
|
||||
| `antiAffinity` | "preferred" | `string` - AntiAffinity rule for Rancher pods - "preferred, required" |
|
||||
| `auditLog.destination` | "sidecar" | `string` - Stream to sidecar container console or hostPath volume - "sidecar, hostPath" |
|
||||
| `auditLog.hostPath` | "/var/log/rancher/audit" | `string` - log file destination on host (only applies when `auditLog.destination` is set to `hostPath`) |
|
||||
| `auditLog.level` | 0 | `int` - set the [API Audit Log](installation/api-auditing) level. 0 is off. [0-3] |
|
||||
| `auditLog.level` | 0 | `int` - set the [API Audit Log](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md) level. 0 is off. [0-3] |
|
||||
| `auditLog.maxAge` | 1 | `int` - maximum number of days to retain old audit log files (only applies when `auditLog.destination` is set to `hostPath`) |
|
||||
| `auditLog.maxBackup` | 1 | `int` - maximum number of audit log files to retain (only applies when `auditLog.destination` is set to `hostPath`) |
|
||||
| `auditLog.maxSize` | 100 | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`) |
|
||||
@@ -75,7 +75,7 @@ For information on enabling experimental features, refer to [this page.](../../p
|
||||
|
||||
Enabling the [API Audit Log](installation/api-auditing/).
|
||||
|
||||
You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools](cluster-admin/tools/logging/) 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](../../pages-for-subheaders/cluster-logging.md) for the `System` Project on the Rancher server cluster.
|
||||
|
||||
```plain
|
||||
--set auditLog.level=1
|
||||
@@ -103,7 +103,7 @@ To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` a
|
||||
--set 'extraEnv[0].value=1.0'
|
||||
```
|
||||
|
||||
See [TLS settings](admin-settings/tls-settings) for more information and options.
|
||||
See [TLS settings](./tls-settings.md) for more information and options.
|
||||
|
||||
### Import `local` Cluster
|
||||
|
||||
@@ -164,8 +164,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: Docker Install](installation/air-gap-single-node/)
|
||||
- [Air Gap: Kubernetes Install](installation/air-gap-high-availability/)
|
||||
- [Air Gap: Kubernetes Install](../../pages-for-subheaders/air-gap-helm2.md)
|
||||
|
||||
# External TLS Termination
|
||||
|
||||
@@ -173,7 +172,7 @@ We recommend configuring your load balancer as a Layer 4 balancer, forwarding pl
|
||||
|
||||
You may terminate the SSL/TLS on a L7 load balancer external to the Rancher cluster (ingress). Use the `--set tls=external` option and point your load balancer at port http 80 on all of the Rancher cluster nodes. This will expose the Rancher interface on http port 80. Be aware that clients that are allowed to connect directly to the Rancher cluster will not be encrypted. If you choose to do this we recommend that you restrict direct access at the network level to just your load balancer.
|
||||
|
||||
> **Note:** If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](installation/resources/encryption/tls-secrets/) to add the CA cert for Rancher.
|
||||
> **Note:** If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md#using-a-private-ca-signed-certificate) to add the CA cert for Rancher.
|
||||
|
||||
Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ aliases:
|
||||
|
||||
Pipelines can be configured either through the UI or using a yaml file in the repository, i.e. `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`.
|
||||
|
||||
In the [pipeline configuration reference](k8s-in-rancher/pipelines/config), we provide examples of how to configure each feature using the Rancher UI or using YAML configuration.
|
||||
In the [pipeline configuration reference](./pipeline-configuration.md), we provide examples of how to configure each feature using the Rancher UI or using YAML configuration.
|
||||
|
||||
Below is a full example `rancher-pipeline.yml` for those who want to jump right in.
|
||||
|
||||
@@ -68,7 +68,7 @@ notification:
|
||||
notifier: "c-wdcsr:n-c9pg7"
|
||||
- recipient: "test@example.com"
|
||||
notifier: "c-wdcsr:n-lkrhd"
|
||||
# Select which statuses you want the notification to be sent
|
||||
# Select which statuses you want the notification to be sent
|
||||
condition: ["Failed", "Success", "Changed"]
|
||||
# Ability to override the default message (Optional)
|
||||
message: "my-message"
|
||||
|
||||
@@ -158,7 +158,7 @@ stages:
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a [git hosted chart repository](catalog/custom/). It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. Any variables in the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) is supported for any file in the chart folder.
|
||||
The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a [git hosted chart repository](../../how-to-guides/new-user-guides/helm-charts-in-rancher/creating-apps.md). It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. Any variables in the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) is supported for any file in the chart folder.
|
||||
|
||||
### Configuring Publishing a Catalog Template by UI
|
||||
|
||||
@@ -309,7 +309,7 @@ timeout: 30
|
||||
|
||||
# Notifications
|
||||
|
||||
You can enable notifications to any [notifiers](../../explanations/integrations-in-rancher/notifiers.md) based on the build status of a pipeline. Before enabling notifications, Rancher recommends [setting up notifiers](monitoring-alerting/legacy/notifiers/) so it will be easy to add recipients immediately.
|
||||
You can enable notifications to any [notifiers](../../explanations/integrations-in-rancher/notifiers.md) based on the build status of a pipeline. Before enabling notifications, Rancher recommends [setting up notifiers](../../explanations/integrations-in-rancher/notifiers.md) so it will be easy to add recipients immediately.
|
||||
|
||||
### Configuring Notifications by UI
|
||||
|
||||
@@ -653,8 +653,8 @@ If you want to use a version control provider with a certificate from a custom/i
|
||||
|
||||
The internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
|
||||
|
||||
For details on setting up persistent storage for pipelines, refer to [this page.](k8s-in-rancher/pipelines/storage)
|
||||
For details on setting up persistent storage for pipelines, refer to [this page.](./configure-persistent-data.md)
|
||||
|
||||
# Example rancher-pipeline.yml
|
||||
|
||||
An example pipeline configuration file is on [this page.](k8s-in-rancher/pipelines/example)
|
||||
An example pipeline configuration file is on [this page.](./example-yaml.md)
|
||||
|
||||
@@ -8,7 +8,7 @@ aliases:
|
||||
- /rancher/v2.x/en/pipelines/docs-for-v2.0.x/
|
||||
---
|
||||
|
||||
>**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](k8s-in-rancher/pipelines/).
|
||||
>**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).
|
||||
|
||||
|
||||
|
||||
|
||||
+2
-2
@@ -114,8 +114,8 @@ Because no additional workloads will be deployed on the Rancher server cluster,
|
||||
|
||||
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)
|
||||
|
||||
# Architecture for an Authorized Cluster Endpoint
|
||||
# Architecture for an Authorized Cluster Endpoint
|
||||
|
||||
If you are using an [authorized cluster endpoint,](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role.
|
||||
|
||||
If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files](k8s-in-rancher/kubeconfig/) and [API keys](../user-settings/api-keys.md#creating-an-api-key) for more information.
|
||||
If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) and [API keys](../user-settings/api-keys.md#creating-an-api-key) for more information.
|
||||
+2
-2
@@ -31,7 +31,7 @@ This section covers the following topics:
|
||||
|
||||
# Alerts Scope
|
||||
|
||||
The scope for alerts can be set at either the [cluster level](cluster-admin/tools/alerts/) or project level.
|
||||
The scope for alerts can be set at either the [cluster level](../../pages-for-subheaders/cluster-alerts.md) or project level.
|
||||
|
||||
At the project level, Rancher monitors specific deployments and sends alerts for:
|
||||
|
||||
@@ -49,7 +49,7 @@ When you enable monitoring for the project, some project-level alerts are provid
|
||||
| Less than half workload available | A critical alert is triggered if less than half of a workload is available, based on workloads where the key is `app` and the value is `workload`. |
|
||||
| Memory usage close to the quota | A warning alert is triggered if the workload's memory usage exceeds the memory resource quota that is set for the workload. You can see the memory limit in the Rancher UI if you go to the workload under the **Security & Host Config** tab. |
|
||||
|
||||
For information on other default alerts, refer to the section on [cluster-level alerts.](cluster-admin/tools/alerts/default-alerts)
|
||||
For information on other default alerts, refer to the section on [cluster-level alerts.](../../explanations/integrations-in-rancher/cluster-alerts/default-alerts.md)
|
||||
|
||||
# Adding Project Alerts
|
||||
|
||||
|
||||
+8
-8
@@ -12,7 +12,7 @@ aliases:
|
||||
|
||||
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.](logging/v2.0.x-v2.4.x/cluster-logging/#how-logging-integrations-work)
|
||||
For background information about how logging integrations work, refer to the [cluster administration section.](../../pages-for-subheaders/cluster-logging.md#how-logging-integrations-work)
|
||||
|
||||
Rancher supports the following services:
|
||||
|
||||
@@ -48,7 +48,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](cluster-admin/tools/logging/) 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](../../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.
|
||||
|
||||
- Project logging writes logs for every pod in that particular project.
|
||||
|
||||
@@ -66,11 +66,11 @@ Logs that are sent to your logging service are from the following locations:
|
||||
|
||||
1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports the following services:
|
||||
|
||||
- [Elasticsearch](cluster-admin/tools/logging/elasticsearch/)
|
||||
- [Splunk](cluster-admin/tools/logging/splunk/)
|
||||
- [Kafka](cluster-admin/tools/logging/kafka/)
|
||||
- [Syslog](cluster-admin/tools/logging/syslog/)
|
||||
- [Fluentd](cluster-admin/tools/logging/fluentd/)
|
||||
- [Elasticsearch](../../explanations/integrations-in-rancher/cluster-logging/elasticsearch.md)
|
||||
- [Splunk](../../explanations/integrations-in-rancher/cluster-logging/splunk.md)
|
||||
- [Kafka](../../explanations/integrations-in-rancher/cluster-logging/kafka.md)
|
||||
- [Syslog](../../explanations/integrations-in-rancher/cluster-logging/syslog.md)
|
||||
- [Fluentd](../../explanations/integrations-in-rancher/cluster-logging/fluentd.md)
|
||||
|
||||
1. (Optional) Instead of using the UI to configure the logging services, you can enter custom advanced configurations by clicking on **Edit as File**, which is located above the logging targets. This link is only visible after you select a logging service.
|
||||
|
||||
@@ -92,7 +92,7 @@ Logs that are sent to your logging service are from the following locations:
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
2. If you are using a self-signed certificate, provide the **CA Certificate PEM**.
|
||||
2. If you are using a self-signed certificate, provide the **CA Certificate PEM**.
|
||||
|
||||
1. (Optional) Complete the **Additional Logging Configuration** form.
|
||||
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ Hardening Guide v2.1 | Rancher v2.1.x | Benchmark v1.3.0 | Kubernetes 1.11
|
||||
|
||||
[Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.1.x/Rancher_Hardening_Guide.pdf)
|
||||
|
||||
For more detail on how a hardened cluster scores against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.1.x](security/benchmark-2.1/).
|
||||
For more detail on how a hardened cluster scores against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.1.x](./self-assessment-guide-with-cis-v1.3-benchmark.md).
|
||||
|
||||
### Profile Definitions
|
||||
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ Hardening Guide v2.2 | Rancher v2.2.x | Benchmark v1.4.1, 1.4.0 | Kubernetes 1.1
|
||||
|
||||
[Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.2.x/Rancher_Hardening_Guide.pdf)
|
||||
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.2.x](security/benchmark-2.2/).
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.2.x](./self-assessment-guide-with-cis-v1.4-benchmark.md).
|
||||
|
||||
### Profile Definitions
|
||||
|
||||
|
||||
+2
-2
@@ -17,7 +17,7 @@ Hardening Guide v2.3 | Rancher v2.3.0-v2.3.2 | Benchmark v1.4.1 | Kubernetes 1.1
|
||||
|
||||
[Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.3.x/Rancher_Hardening_Guide.pdf)
|
||||
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.3.x](security/benchmark-2.3/).
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.3.x](./rancher-v2.3.0-self-assessment-guide-with-cis-v1.4.1-benchmark.md).
|
||||
|
||||
### Profile Definitions
|
||||
|
||||
@@ -434,7 +434,7 @@ etcd is a highly-available key-value store used by Kubernetes deployments for pe
|
||||
|
||||
On a etcd server node, get the etcd data directory, passed as an argument `--data-dir`, from the below command:
|
||||
|
||||
``` bash
|
||||
``` bash
|
||||
ps -ef | grep etcd
|
||||
```
|
||||
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ Hardening Guide v2.3.3 | Rancher v2.3.3 | Benchmark v1.4.1 | Kubernetes 1.14, 1.
|
||||
|
||||
[Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.3.3/Rancher_Hardening_Guide.pdf)
|
||||
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide v2.3.3](security/benchmark-2.3.3/).
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide v2.3.3](./rancher-v2.3.3-self-assessment-guide-with-cis-v1.4.1-benchmark.md).
|
||||
|
||||
### Profile Definitions
|
||||
|
||||
|
||||
+18
-18
@@ -23,7 +23,7 @@ Hardening Guide v2.3.5 | Rancher v2.3.5 | Benchmark v1.5 | Kubernetes 1.15
|
||||
|
||||
This document provides prescriptive guidance for hardening a production installation of Rancher v2.3.5 with Kubernetes v1.15. It outlines the configurations required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
|
||||
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.3.5](security/benchmark-2.3.5/).
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.3.5](./rancher-v2.3.5-self-assessment-guide-with-cis-v1.5-benchmark.md).
|
||||
|
||||
#### Known Issues
|
||||
|
||||
@@ -65,7 +65,7 @@ services:
|
||||
```
|
||||
|
||||
#### Set `automountServiceAccountToken` to `false` for `default` service accounts
|
||||
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
For each namespace the **default** service account must include this value:
|
||||
|
||||
@@ -85,7 +85,7 @@ automountServiceAccountToken: false
|
||||
|
||||
Create a bash script file called `account_update.sh`. Be sure to `chmod +x account_update.sh` so the script has execute permissions.
|
||||
|
||||
```
|
||||
```
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o json | jq -r '.items[].metadata.name'); do
|
||||
@@ -355,7 +355,7 @@ addons: |
|
||||
- kind: ServiceAccount
|
||||
name: tiller
|
||||
namespace: kube-system
|
||||
|
||||
|
||||
addons_include: []
|
||||
system_images:
|
||||
etcd: ""
|
||||
@@ -426,24 +426,24 @@ restore:
|
||||
dns: null
|
||||
```
|
||||
|
||||
### Reference Hardened RKE Template configuration
|
||||
### Reference Hardened RKE Template configuration
|
||||
|
||||
The reference RKE Template provides the configuration needed to achieve a hardened install of Kubenetes.
|
||||
RKE Templates are used to provision Kubernetes and define Rancher settings. Follow the Rancher
|
||||
[documentaion](https://rancher.com/docs/rancher/v2.0-v2.4/en/installation) for additional installation and RKE Template details.
|
||||
|
||||
``` yaml
|
||||
#
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
#
|
||||
default_pod_security_policy_template_id: restricted
|
||||
docker_root_dir: /var/lib/docker
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
enable_network_policy: true
|
||||
#
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 30
|
||||
addons: |-
|
||||
@@ -598,32 +598,32 @@ rancher_kubernetes_engine_config:
|
||||
namespace: kube-system
|
||||
ignore_docker_version: true
|
||||
kubernetes_version: v1.15.9-rancher1-1
|
||||
#
|
||||
#
|
||||
# If you are using calico on AWS
|
||||
#
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
#
|
||||
# # To specify flannel interface
|
||||
#
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
#
|
||||
# # To specify flannel interface for canal plugin
|
||||
#
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
#
|
||||
network:
|
||||
mtu: 0
|
||||
plugin: canal
|
||||
#
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
@@ -633,7 +633,7 @@ rancher_kubernetes_engine_config:
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
#
|
||||
services:
|
||||
etcd:
|
||||
backup_config:
|
||||
|
||||
+18
-18
@@ -23,7 +23,7 @@ Hardening Guide v2.4 | Rancher v2.4 | Benchmark v1.5 | Kubernetes 1.15
|
||||
|
||||
This document provides prescriptive guidance for hardening a production installation of Rancher v2.4 with Kubernetes v1.15. It outlines the configurations required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
|
||||
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.4](security/benchmark-2.4/).
|
||||
For more detail about evaluating a hardened cluster against the official CIS benchmark, refer to the [CIS Benchmark Rancher Self-Assessment Guide - Rancher v2.4](./self-assessment-guide-with-cis-v1.5-benchmark.md).
|
||||
|
||||
#### Known Issues
|
||||
|
||||
@@ -67,7 +67,7 @@ services:
|
||||
```
|
||||
|
||||
#### Set `automountServiceAccountToken` to `false` for `default` service accounts
|
||||
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
For each namespace including **default** and **kube-system** on a standard RKE install the **default** service account must include this value:
|
||||
|
||||
@@ -87,7 +87,7 @@ automountServiceAccountToken: false
|
||||
|
||||
Create a bash script file called `account_update.sh`. Be sure to `chmod +x account_update.sh` so the script has execute permissions.
|
||||
|
||||
```
|
||||
```
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o json | jq -r '.items[].metadata.name'); do
|
||||
@@ -362,7 +362,7 @@ addons: |
|
||||
- kind: ServiceAccount
|
||||
name: tiller
|
||||
namespace: kube-system
|
||||
|
||||
|
||||
addons_include: []
|
||||
system_images:
|
||||
etcd: ""
|
||||
@@ -433,24 +433,24 @@ restore:
|
||||
dns: null
|
||||
```
|
||||
|
||||
### Reference Hardened RKE Template configuration
|
||||
### Reference Hardened RKE Template configuration
|
||||
|
||||
The reference RKE Template provides the configuration needed to achieve a hardened install of Kubenetes.
|
||||
RKE Templates are used to provision Kubernetes and define Rancher settings. Follow the Rancher
|
||||
[documentaion](https://rancher.com/docs/rancher/v2.0-v2.4/en/installation) for additional installation and RKE Template details.
|
||||
|
||||
``` yaml
|
||||
#
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
#
|
||||
default_pod_security_policy_template_id: restricted
|
||||
docker_root_dir: /var/lib/docker
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
enable_network_policy: true
|
||||
#
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 30
|
||||
addons: |-
|
||||
@@ -605,32 +605,32 @@ rancher_kubernetes_engine_config:
|
||||
namespace: kube-system
|
||||
ignore_docker_version: true
|
||||
kubernetes_version: v1.15.9-rancher1-1
|
||||
#
|
||||
#
|
||||
# If you are using calico on AWS
|
||||
#
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
#
|
||||
# # To specify flannel interface
|
||||
#
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
#
|
||||
# # To specify flannel interface for canal plugin
|
||||
#
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
#
|
||||
network:
|
||||
mtu: 0
|
||||
plugin: canal
|
||||
#
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
@@ -640,7 +640,7 @@ rancher_kubernetes_engine_config:
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
#
|
||||
services:
|
||||
etcd:
|
||||
backup_config:
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
| [CVE-2021-31999](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31999) | A vulnerability was discovered where a malicious Rancher user could craft an API request directed at the proxy for the Kubernetes API of a managed cluster to gain access to information they do not have access to. This is done by passing the "Impersonate-User" or "Impersonate-Group" header in the Connection header, which is then removed by the proxy. At this point, instead of impersonating the user and their permissions, the request will act as if it was from the Rancher management server, i.e. local server, and return the requested information. You are vulnerable if you are running any Rancher 2.x version. Only valid Rancher users who have some level of permission on the cluster can perform the request. There is no direct mitigation besides upgrading to the patched versions. You can limit wider exposure by ensuring all Rancher users are trusted. | 14 Jul 2021 | [Rancher v2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9), [Rancher v2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25318](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25318) | A vulnerability was discovered in Rancher where users were granted access to resources regardless of the resource's API group. For example Rancher should have allowed users access to `apps.catalog.cattle.io`, but instead incorrectly gave access to `apps.*`. You are vulnerable if you are running any Rancher 2.x version. The extent of the exploit increases if there are other matching CRD resources installed in the cluster. There is no direct mitigation besides upgrading to the patched versions. | 14 Jul 2021 | [Rancher v2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9), [Rancher v2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25320](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25320) | A vulnerability was discovered in Rancher where cloud credentials weren't being properly validated through the Rancher API. Specifically through a proxy designed to communicate with cloud providers. Any Rancher user that was logged-in and aware of a cloud credential ID that was valid for a given cloud provider could make requests against that cloud provider's API through the proxy API, and the cloud credential would be attached. You are vulnerable if you are running any Rancher 2.2.0 or above and use cloud credentials. The exploit is limited to valid Rancher users. There is no direct mitigation besides upgrading to the patched versions. You can limit wider exposure by ensuring all Rancher users are trusted. | 14 Jul 2021 | [Rancher v2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9), [Rancher v2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321) | Any project member with access to the `default` namespace can mount the `netes-default` service account in a pod and then use that pod to execute administrative privileged commands against the Kubernetes cluster. | 29 Jan 2019 | [Rancher v2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) and [Rancher v2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) - Rolling back from these versions or greater have specific [instructions](upgrades/rollbacks/). |
|
||||
| [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321) | Any project member with access to the `default` namespace can mount the `netes-default` service account in a pod and then use that pod to execute administrative privileged commands against the Kubernetes cluster. | 29 Jan 2019 | [Rancher v2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) and [Rancher v2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) - Rolling back from these versions or greater have specific [instructions](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md). |
|
||||
| [CVE-2019-6287](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6287) | Project members continue to get access to namespaces from projects that they were removed from if they were added to more than one project. | 29 Jan 2019 | [Rancher v2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) and [Rancher v2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) |
|
||||
| [CVE-2019-11202](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11202) | The default admin, that is shipped with Rancher, will be re-created upon restart of Rancher despite being explicitly deleted. | 16 Apr 2019 | [Rancher v2.2.2](https://github.com/rancher/rancher/releases/tag/v2.2.2), [Rancher v2.1.9](https://github.com/rancher/rancher/releases/tag/v2.1.9) and [Rancher v2.0.14](https://github.com/rancher/rancher/releases/tag/v2.0.14) |
|
||||
| [CVE-2019-12274](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12274) | Nodes using the built-in node drivers using a file path option allows the machine to read arbitrary files including sensitive ones from inside the Rancher server container. | 5 Jun 2019 | [Rancher v2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4), [Rancher v2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) and [Rancher v2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15) |
|
||||
|
||||
+3
-3
@@ -3,7 +3,7 @@ title: Advanced Options for Docker Installs
|
||||
weight: 5
|
||||
---
|
||||
|
||||
When installing Rancher, there are several [advanced options](installation/options/) that can be enabled:
|
||||
When installing Rancher, there are several [advanced options](../../pages-for-subheaders/resources.md) that can be enabled:
|
||||
|
||||
- [Custom CA Certificate](#custom-ca-certificate)
|
||||
- [API Audit Log](#api-audit-log)
|
||||
@@ -39,7 +39,7 @@ The API Audit Log records all the user and system transactions made through Ranc
|
||||
|
||||
The API Audit Log writes to `/var/log/auditlog` inside the rancher container by default. Share that directory as a volume and set your `AUDIT_LEVEL` to enable the log.
|
||||
|
||||
See [API Audit Log](installation/api-auditing) for more information and options.
|
||||
See [API Audit Log](../../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/enable-api-audit-log.md) for more information and options.
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -62,7 +62,7 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
See [TLS settings](admin-settings/tls-settings) for more information and options.
|
||||
See [TLS settings](../installation-references/tls-settings.md) for more information and options.
|
||||
|
||||
### Air Gap
|
||||
|
||||
|
||||
+1
-1
@@ -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](installation/single-node-install/) 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](../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md) are:
|
||||
|
||||
- `localhost`
|
||||
- `127.0.0.1`
|
||||
|
||||
@@ -41,7 +41,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]({{<baseurl>}}//rancher/v2.0-v2.4/en/troubleshooting/) 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](../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.
|
||||
|
||||
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`.
|
||||
|
||||
@@ -81,7 +81,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](backups/backups) before executing the command.
|
||||
>**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.
|
||||
|
||||
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:
|
||||
|
||||
|
||||
+2
-2
@@ -45,7 +45,7 @@ Run the command below and check the following:
|
||||
|
||||
```
|
||||
kubectl get nodes -o wide
|
||||
```
|
||||
```
|
||||
|
||||
Example output:
|
||||
|
||||
@@ -266,6 +266,6 @@ kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .statu
|
||||
|
||||
### Job does not complete
|
||||
|
||||
If you have enabled Istio, and you are having issues with a Job you deployed not completing, you will need to add an annotation to your pod using [these steps.](istio/v2.3.x-v2.4.x/setup/enable-istio-in-namespace/#excluding-workloads-from-being-injected-with-the-istio-sidecar)
|
||||
If you have enabled Istio, and you are having issues with a Job you deployed not completing, you will need to add an annotation to your pod using [these steps.](../../how-to-guides/advanced-user-guides/istio-setup-guide/enable-istio-in-namespace.md#excluding-workloads-from-being-injected-with-the-istio-sidecar)
|
||||
|
||||
Since Istio Sidecars run indefinitely, a Job cannot be considered complete even after its task has completed. This is a temporary workaround and will disable Istio for any traffic to/from the annotated Pod. Keep in mind this may not allow you to continue to use a Job for integration testing, as the Job will not have access to the service mesh.
|
||||
+2
-2
@@ -52,7 +52,7 @@ To test the overlay network, you can launch the following `DaemonSet` definition
|
||||
#!/bin/bash
|
||||
echo "=> Start network overlay test"
|
||||
kubectl get pods -l name=overlaytest -o jsonpath='{range .items[*]}{@.metadata.name}{" "}{@.spec.nodeName}{"\n"}{end}' |
|
||||
while read spod shost
|
||||
while read spod shost
|
||||
do kubectl get pods -l name=overlaytest -o jsonpath='{range .items[*]}{@.status.podIP}{" "}{@.spec.nodeName}{"\n"}{end}' |
|
||||
while read tip thost
|
||||
do kubectl --request-timeout='10s' exec $spod -c overlaytest -- /bin/sh -c "ping -c2 $tip > /dev/null 2>&1"
|
||||
@@ -125,7 +125,7 @@ If there is no output, the cluster is not affected.
|
||||
|------------|------------|
|
||||
| GitHub issue | [#15146](https://github.com/rancher/rancher/issues/15146) |
|
||||
|
||||
If pods in system namespaces cannot communicate with pods in other system namespaces, you will need to follow the instructions in [Upgrading to v2.0.7+ — Namespace Migration](upgrades/upgrades/namespace-migration/) to restore connectivity. Symptoms include:
|
||||
If pods in system namespaces cannot communicate with pods in other system namespaces, you will need to follow the instructions in [Upgrading to v2.0.7+ — Namespace Migration](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md) to restore connectivity. Symptoms include:
|
||||
|
||||
- NGINX ingress controller showing `504 Gateway Time-out` when accessed.
|
||||
- NGINX ingress controller logging `upstream timed out (110: Connection timed out) while connecting to upstream` when accessed.
|
||||
|
||||
Reference in New Issue
Block a user