diff --git a/.github/stale.yml b/.github/stale.yml
new file mode 100644
index 00000000000..972e235a185
--- /dev/null
+++ b/.github/stale.yml
@@ -0,0 +1,39 @@
+# Configuration for probot-stale - https://github.com/probot/stale
+
+# Number of days of inactivity before an Issue or Pull Request becomes stale
+daysUntilStale: 90
+
+# Number of days of inactivity before an Issue or Pull Request with the stale label is closed.
+# Set to false to disable. If disabled, issues still need to be closed manually, but will remain marked as stale.
+daysUntilClose: 30
+
+# Only issues or pull requests with all of these labels are check if stale. Defaults to `[]` (disabled)
+onlyLabels: []
+
+# Issues or Pull Requests with these labels will never be considered stale. Set to `[]` to disable
+exemptLabels: []
+
+# Set to true to ignore issues in a project (defaults to false)
+exemptProjects: true
+
+# Set to true to ignore issues in a milestone (defaults to false)
+exemptMilestones: true
+
+# Set to true to ignore issues with an assignee (defaults to false)
+exemptAssignees: true
+
+# Label to use when marking as stale
+staleLabel: status/stale
+
+# Comment to post when marking as stale. Set to `false` to disable
+markComment: >
+ This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label)
+ for 90 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the
+ issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the
+ latest release), the bot will automatically close the issue in 30 days. Thank you for your contributions.
+
+# Limit the number of actions per hour, from 1-30. Default is 30
+limitPerRun: 30
+
+# Limit to only `issues`
+only: issues
diff --git a/.gitignore b/.gitignore
index daefacf85e2..e50d424efcf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,5 @@ package-lock.json
/scripts/converters/results_to_markdown/.terraform
/scripts/converters/results_to_markdown/terraform.tfstate*
/scripts/converters/results_to_markdown/*.tfvars
+
+.idea/
diff --git a/Dockerfile.build b/Dockerfile.build
index 614b1980fc8..a50a0e1e472 100644
--- a/Dockerfile.build
+++ b/Dockerfile.build
@@ -1,4 +1,4 @@
-FROM node:8-alpine
+FROM node:16-alpine
RUN apk update && apk add py-pygments bash git asciidoc gcompat && rm -rf /var/cache/apk/*
diff --git a/config.toml b/config.toml
index 35fdfda6e03..6ea4f5e3a0b 100644
--- a/config.toml
+++ b/config.toml
@@ -209,4 +209,4 @@ pre = "keyboard_arrow_down"
[[menu.main]]
name = "Partners"
url = "https://rancher.com/partners/"
- parent = "about"
\ No newline at end of file
+ parent = "about"
diff --git a/content/k3s/latest/en/_index.md b/content/k3s/latest/en/_index.md
index a02147dc599..4d71be76b38 100644
--- a/content/k3s/latest/en/_index.md
+++ b/content/k3s/latest/en/_index.md
@@ -26,7 +26,7 @@ K3s is a fully compliant Kubernetes distribution with the following enhancements
* Secure by default with reasonable defaults for lightweight environments.
* Simple but powerful "batteries-included" features have been added, such as: a local storage provider, a service load balancer, a Helm controller, and the Traefik ingress controller.
* Operation of all Kubernetes control plane components is encapsulated in a single binary and process. This allows K3s to automate and manage complex cluster operations like distributing certificates.
-* External dependencies have been minimized (just a modern kernel and cgroup mounts needed). K3s packages required dependencies, including:
+* External dependencies have been minimized (just a modern kernel and cgroup mounts needed). K3s packages the required dependencies, including:
* containerd
* Flannel
* CoreDNS
@@ -38,4 +38,4 @@ K3s is a fully compliant Kubernetes distribution with the following enhancements
# What's with the name?
-We wanted an installation of Kubernetes that was half the size in terms of memory footprint. Kubernetes is a 10-letter word stylized as K8s. So something half as big as Kubernetes would be a 5-letter word stylized as K3s. There is no long form of K3s and no official pronunciation.
\ No newline at end of file
+We wanted an installation of Kubernetes that was half the size in terms of memory footprint. Kubernetes is a 10-letter word stylized as K8s. So something half as big as Kubernetes would be a 5-letter word stylized as K3s. There is no long form of K3s and no official pronunciation.
diff --git a/content/k3s/latest/en/advanced/_index.md b/content/k3s/latest/en/advanced/_index.md
index 494650ebf82..554a0e5469a 100644
--- a/content/k3s/latest/en/advanced/_index.md
+++ b/content/k3s/latest/en/advanced/_index.md
@@ -13,18 +13,18 @@ This section contains advanced information describing the different ways you can
- [Using Docker as the container runtime](#using-docker-as-the-container-runtime)
- [Using etcdctl](#using-etcdctl)
- [Configuring containerd](#configuring-containerd)
-- [Secrets Encryption Config (Experimental)](#secrets-encryption-config-experimental)
- [Running K3s with Rootless mode (Experimental)](#running-k3s-with-rootless-mode-experimental)
- [Node labels and taints](#node-labels-and-taints)
- [Starting the server with the installation script](#starting-the-server-with-the-installation-script)
- [Additional preparation for Alpine Linux setup](#additional-preparation-for-alpine-linux-setup)
+- [Additional preparation for (Red Hat/CentOS) Enterprise Linux](#additional-preparation-for-red-hat/centos-enterprise-linux)
+- [Additional preparation for Raspberry Pi OS Setup](#additional-preparation-for-raspberry-pi-os-setup)
+- [Enabling vxlan on Ubuntu 21.10+ on Raspberry Pi](#enabling-vxlan-on-ubuntu-21.10+-on-raspberry-pi)
- [Running K3d (K3s in Docker) and docker-compose](#running-k3d-k3s-in-docker-and-docker-compose)
-- [Enabling legacy iptables on Raspbian Buster](#enabling-legacy-iptables-on-raspbian-buster)
-- [Enabling cgroups for Raspbian Buster](#enabling-cgroups-for-raspbian-buster)
- [SELinux Support](#selinux-support)
-- [Additional preparation for (Red Hat/CentOS) Enterprise Linux](#additional-preparation-for-red-hat-centos-enterprise-linux)
- [Enabling Lazy Pulling of eStargz (Experimental)](#enabling-lazy-pulling-of-estargz-experimental)
- [Additional Logging Sources](#additional-logging-sources)
+- [Server and agent tokens](#server-and-agent-tokens)
# Certificate Rotation
@@ -127,8 +127,8 @@ If you would like to use etcdctl after installing K3s with embedded etcd, instal
```
$ VERSION="v3.5.0"
-$ curl -L https://github.com/etcd-io/etcd/releases/download/${VERSION}/etcd-${VERSION}-linux-amd64.tar.gz --output etcdctl-${VERSION}-linux-amd64.tar.gz
-$ sudo tar -zxvf etcdctl-${VERSION}-linux-amd64.tar.gz -C /usr/local/bin
+$ curl -L https://github.com/etcd-io/etcd/releases/download/${VERSION}/etcd-${VERSION}-linux-amd64.tar.gz --output etcdctl-linux-amd64.tar.gz
+$ sudo tar -zxvf etcdctl-linux-amd64.tar.gz --strip-components=1 -C /usr/local/bin etcd-${VERSION}-linux-amd64/etcdctl
```
Then start using etcdctl commands with the appropriate K3s flags:
@@ -143,46 +143,8 @@ K3s will generate config.toml for containerd in `/var/lib/rancher/k3s/agent/etc/
For advanced customization for this file you can create another file called `config.toml.tmpl` in the same directory and it will be used instead.
-The `config.toml.tmpl` will be treated as a Go template file, and the `config.Node` structure is being passed to the template. [This template](https://github.com/rancher/k3s/blob/master/pkg/agent/templates/templates.go#L16-L32) example on how to use the structure to customize the configuration file.
+The `config.toml.tmpl` will be treated as a Go template file, and the `config.Node` structure is being passed to the template. See [this folder](https://github.com/k3s-io/k3s/blob/master/pkg/agent/templates) for Linux and Windows examples on how to use the structure to customize the configuration file.
-# Secrets Encryption Config (Experimental)
-As of v1.17.4+k3s1, K3s added the experimental feature of enabling secrets encryption at rest by passing the flag `--secrets-encryption` on a server, this flag will do the following automatically:
-
-- Generate an AES-CBC key
-- Generate an encryption config file with the generated key
-
-```
-{
- "kind": "EncryptionConfiguration",
- "apiVersion": "apiserver.config.k8s.io/v1",
- "resources": [
- {
- "resources": [
- "secrets"
- ],
- "providers": [
- {
- "aescbc": {
- "keys": [
- {
- "name": "aescbckey",
- "secret": "xxxxxxxxxxxxxxxxxxx"
- }
- ]
- }
- },
- {
- "identity": {}
- }
- ]
- }
- ]
-}
-```
-
-- Pass the config to the KubeAPI as encryption-provider-config
-
-Once enabled any created secret will be encrypted with this key. Note that if you disable encryption then any encrypted secrets will not be readable until you enable encryption again.
# Running K3s with Rootless mode (Experimental)
@@ -294,6 +256,39 @@ Then update the config and reboot:
update-extlinux
reboot
```
+# Additional preparation for (Red Hat/CentOS) Enterprise Linux
+
+It is recommended to turn off firewalld:
+```
+systemctl disable firewalld --now
+```
+
+If enabled, it is required to disable nm-cloud-setup and reboot the node:
+```
+systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
+reboot
+```
+
+# Additional preparation for Raspberry Pi OS Setup
+## Enabling legacy iptables on Raspberry Pi OS
+Raspberry Pi OS (formerly Raspbian) defaults to using `nftables` instead of `iptables`. **K3S** networking features require `iptables` and do not work with `nftables`. Follow the steps below to switch configure **Buster** to use `legacy iptables`:
+```
+sudo iptables -F
+sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
+sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
+sudo reboot
+```
+
+## Enabling cgroups for Raspberry Pi OS
+
+Standard Raspberry Pi OS installations do not start with `cgroups` enabled. **K3S** needs `cgroups` to start the systemd service. `cgroups`can be enabled by appending `cgroup_memory=1 cgroup_enable=memory` to `/boot/cmdline.txt`.
+
+# Enabling vxlan on Ubuntu 21.10+ on Raspberry Pi
+
+Starting with Ubuntu 21.10, vxlan support on Raspberry Pi has been moved into a seperate kernel module.
+```
+sudo apt install linux-modules-extra-raspi
+```
# Running K3d (K3s in Docker) and docker-compose
@@ -331,20 +326,6 @@ Alternatively the `docker run` command can also be used:
--privileged rancher/k3s:vX.Y.Z
-# Enabling legacy iptables on Raspbian Buster
-
-Raspbian Buster defaults to using `nftables` instead of `iptables`. **K3S** networking features require `iptables` and do not work with `nftables`. Follow the steps below to switch configure **Buster** to use `legacy iptables`:
-```
-sudo iptables -F
-sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
-sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
-sudo reboot
-```
-
-# Enabling cgroups for Raspbian Buster
-
-Standard Raspbian Buster installations do not start with `cgroups` enabled. **K3S** needs `cgroups` to start the systemd service. `cgroups`can be enabled by appending `cgroup_memory=1 cgroup_enable=memory` to `/boot/cmdline.txt`.
-
### example of /boot/cmdline.txt
```
console=serial0,115200 console=tty1 root=PARTUUID=58b06195-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait cgroup_memory=1 cgroup_enable=memory
@@ -403,19 +384,6 @@ Using a custom `--data-dir` under SELinux is not supported. To customize it, you
{{%/tab%}}
{{% /tabs %}}
-# Additional preparation for (Red Hat/CentOS) Enterprise Linux
-
-It is recommended to turn off firewalld:
-```
-systemctl disable firewalld --now
-```
-
-If enabled, it is required to disable nm-cloud-setup and reboot the node:
-```
-systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
-reboot
-```
-
# Enabling Lazy Pulling of eStargz (Experimental)
### What's lazy pulling and eStargz?
@@ -479,4 +447,14 @@ helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm install --create-namespace -n cattle-logging-system rancher-logging-crd rancher-charts/rancher-logging-crd
helm install --create-namespace -n cattle-logging-system rancher-logging --set additionalLoggingSources.k3s.enabled=true rancher-charts/rancher-logging
-```
\ No newline at end of file
+```
+
+# Server and agent tokens
+
+In K3s, there are two types of tokens: K3S_TOKEN and K3S_AGENT_TOKEN.
+
+K3S_TOKEN: Defines the key required by the server to offer the HTTP config resources. These resources are requested by the other servers before joining the K3s HA cluster. If the K3S_AGENT_TOKEN is not defined, the agents use this token as well to access the required HTTP resources to join the cluster. Note that this token is also used to generate the encryption key for important content in the database (e.g., bootstrap data).
+
+K3S_AGENT_TOKEN: Optional. Defines the key required by the server to offer HTTP config resources to the agents. If not defined, agents will require K3S_TOKEN. Defining K3S_AGENT_TOKEN is encouraged to avoid agents having to know K3S_TOKEN, which is also used to encrypt data.
+
+If no K3S_TOKEN is defined, the first K3s server will generate a random one. The result is part of the content in `/var/lib/rancher/k3s/server/token`. For example, `K1070878408e06a827960208f84ed18b65fa10f27864e71a57d9e053c4caff8504b::server:df54383b5659b9280aa1e73e60ef78fc`, where `df54383b5659b9280aa1e73e60ef78fc` is the K3S_TOKEN.
diff --git a/content/k3s/latest/en/backup-restore/_index.md b/content/k3s/latest/en/backup-restore/_index.md
index 27252dbb6fb..13031a06c35 100644
--- a/content/k3s/latest/en/backup-restore/_index.md
+++ b/content/k3s/latest/en/backup-restore/_index.md
@@ -18,7 +18,7 @@ For details on taking database snapshots and restoring your database from them,
- [Official MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html)
- [Official PostgreSQL documentation](https://www.postgresql.org/docs/8.3/backup-dump.html)
-- [Official etcd documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md)
+- [Official etcd documentation](https://etcd.io/docs/latest/op-guide/recovery/)
# Backup and Restore with Embedded etcd Datastore (Experimental)
@@ -57,7 +57,7 @@ These options can be passed in with the command line, or in the [configuration f
| Options | Description |
| ----------- | --------------- |
| `--etcd-disable-snapshots` | Disable automatic etcd snapshots |
-| `--etcd-snapshot-schedule-cron` value | Snapshot interval time in cron spec. eg. every 5 hours `* */5 * * *`(default: `0 */12 * * *`) |
+| `--etcd-snapshot-schedule-cron` value | Snapshot interval time in cron spec. eg. every 5 hours `0 */5 * * *`(default: `0 */12 * * *`) |
| `--etcd-snapshot-retention` value | Number of snapshots to retain (default: 5) |
| `--etcd-snapshot-dir` value | Directory to save db snapshots. (Default location: `${data-dir}/db/snapshots`) |
| `--cluster-reset` | Forget all peers and become sole member of a new cluster. This can also be set with the environment variable `[$K3S_CLUSTER_RESET]`.
diff --git a/content/k3s/latest/en/helm/_index.md b/content/k3s/latest/en/helm/_index.md
index 89d21d70ba5..5d43acbb78f 100644
--- a/content/k3s/latest/en/helm/_index.md
+++ b/content/k3s/latest/en/helm/_index.md
@@ -96,8 +96,9 @@ metadata:
namespace: kube-system
spec:
valuesContent: |-
- image: traefik
- imageTag: v1.7.26-alpine
+ image:
+ name: traefik
+ tag: v2.6.1
proxyProtocol:
enabled: true
trustedIPs:
diff --git a/content/k3s/latest/en/installation/airgap/_index.md b/content/k3s/latest/en/installation/airgap/_index.md
index 91d37c00830..303cebab4b9 100644
--- a/content/k3s/latest/en/installation/airgap/_index.md
+++ b/content/k3s/latest/en/installation/airgap/_index.md
@@ -3,7 +3,7 @@ title: "Air-Gap Install"
weight: 60
---
-You can install K3s in an air-gapped environment using two different methods. You can either deploy a private registry and mirror docker.io or you can manually deploy images such as for small clusters.
+You can install K3s in an air-gapped environment using two different methods. An air-gapped environment is any environment that is not directly connected to the Internet. You can either deploy a private registry and mirror docker.io, or you can manually deploy images such as for small clusters.
# Private Registry Method
@@ -39,22 +39,23 @@ Follow the steps in the next section to install K3s.
# Install K3s
-Only after you have completed either the [Private Registry Method](#private-registry-method) or the [Manually Deploy Images Method](#manually-deploy-images-method) above should you install K3s.
+### Prerequisites
-Obtain the K3s binary from the [releases](https://github.com/rancher/k3s/releases) page, matching the same version used to get the airgap images.
-Obtain the K3s install script at https://get.k3s.io
+- Before installing K3s, complete the the [Private Registry Method](#private-registry-method) or the [Manually Deploy Images Method](#manually-deploy-images-method) above to prepopulate the images that K3s needs to install.
+- Download the K3s binary from the [releases](https://github.com/rancher/k3s/releases) page, matching the same version used to get the airgap images. Place the binary in `/usr/local/bin` on each air-gapped node and ensure it is executable.
+- Download the K3s install script at https://get.k3s.io. Place the install script anywhere on each air-gapped node, and name it `install.sh`.
-Place the binary in `/usr/local/bin` on each node and ensure it is executable.
-Place the install script anywhere on each node, and name it `install.sh`.
+When running the K3s script with the `INSTALL_K3S_SKIP_DOWNLOAD` environment variable, K3s will use the local version of the script and binary.
-### Install Options
+### Installing K3s in an Air-Gapped Environment
+
You can install K3s on one or more servers as described below.
{{% tabs %}}
{{% tab "Single Server Configuration" %}}
-To install K3s on a single server simply do the following on the server node.
+To install K3s on a single server, simply do the following on the server node:
```
INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh
@@ -75,13 +76,13 @@ For example, step two of the High Availability with an External DB guide mention
```
curl -sfL https://get.k3s.io | sh -s - server \
- --datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"
+ --datastore-endpoint='mysql://username:password@tcp(hostname:3306)/database-name'
```
Instead, you would modify such examples like below:
```
-INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_EXEC='server --datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"' ./install.sh
+INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_EXEC='server' K3S_DATASTORE_ENDPOINT='mysql://username:password@tcp(hostname:3306)/database-name' ./install.sh
```
{{% /tab %}}
diff --git a/content/k3s/latest/en/installation/datastore/_index.md b/content/k3s/latest/en/installation/datastore/_index.md
index 059d73e16fe..b5476b42f35 100644
--- a/content/k3s/latest/en/installation/datastore/_index.md
+++ b/content/k3s/latest/en/installation/datastore/_index.md
@@ -23,7 +23,7 @@ If you wish to use an external datastore such as PostgreSQL, MySQL, or etcd you
CLI Flag | Environment Variable | Description
------------|-------------|------------------
- `--datastore-endpoint` | `K3S_DATASTORE_ENDPOINT` | Specify a PostgresSQL, MySQL, or etcd connection string. This is a string used to describe the connection to the datastore. The structure of this string is specific to each backend and is detailed below.
+ `--datastore-endpoint` | `K3S_DATASTORE_ENDPOINT` | Specify a PostgreSQL, MySQL, or etcd connection string. This is a string used to describe the connection to the datastore. The structure of this string is specific to each backend and is detailed below.
`--datastore-cafile` | `K3S_DATASTORE_CAFILE` | TLS Certificate Authority (CA) file used to help secure communication with the datastore. If your datastore serves requests over TLS using a certificate signed by a custom certificate authority, you can specify that CA using this parameter so that the K3s client can properly verify the certificate. |
| `--datastore-certfile` | `K3S_DATASTORE_CERTFILE` | TLS certificate file used for client certificate based authentication to your datastore. To use this feature, your datastore must be configured to support client certificate based authentication. If you specify this parameter, you must also specify the `datastore-keyfile` parameter. |
| `--datastore-keyfile` | `K3S_DATASTORE_KEYFILE` | TLS key file used for client certificate based authentication to your datastore. See the previous `datastore-certfile` parameter for more details. |
@@ -81,7 +81,7 @@ The above assumes a typical three node etcd cluster. The parameter can accept on
{{% /tab %}}
{{% /tabs %}}
-
Based on the above, the following example command could be used to launch a server instance that connects to a PostgresSQL database named k3s:
+
Based on the above, the following example command could be used to launch a server instance that connects to a PostgreSQL database named k3s:
```
K3S_DATASTORE_ENDPOINT='postgres://username:password@hostname:5432/k3s' k3s server
```
diff --git a/content/k3s/latest/en/installation/disable-flags/_index.md b/content/k3s/latest/en/installation/disable-flags/_index.md
index 83b6b692cca..2dbbfeb8920 100644
--- a/content/k3s/latest/en/installation/disable-flags/_index.md
+++ b/content/k3s/latest/en/installation/disable-flags/_index.md
@@ -3,7 +3,7 @@ title: "Disable Components Flags"
weight: 60
---
-When starting K3s server with --cluster-init it will run all control plane components that includes (api server, controller manager, scheduler, and etcd). However you can run server nodes with certain components and execlude others, the following sections will explain how to do that.
+Starting the K3s server with `--cluster-init` will run all control plane components, including the api server, controller manager, scheduler, and etcd. However, you can run server nodes with certain components and exclude others; the following sections will explain how to do that.
# ETCD Only Nodes
diff --git a/content/k3s/latest/en/installation/ha-embedded/_index.md b/content/k3s/latest/en/installation/ha-embedded/_index.md
index f8fe7d2ebea..6d4bb7bab49 100644
--- a/content/k3s/latest/en/installation/ha-embedded/_index.md
+++ b/content/k3s/latest/en/installation/ha-embedded/_index.md
@@ -23,3 +23,14 @@ K3S_TOKEN=SECRET k3s server --server https://:6443
```
Now you have a highly available control plane. Joining additional worker nodes to the cluster follows the same procedure as a single server cluster.
+
+There are a few config flags that must be the same in all server nodes:
+
+* Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
+* Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
+* Feature related flags: `--secrets-encryption`
+
+## Existing clusters
+If you have an existing cluster using the default embedded SQLite database, you can convert it to etcd by simply restarting your K3s server with the `--cluster-init` flag. Once you've done that, you'll be able to add additional instances as described above.
+
+>**Important:** K3s v1.22.2 and newer support migration from SQLite to etcd. Older versions will create a new empty datastore if you add `--cluster-init` to an existing server.
diff --git a/content/k3s/latest/en/installation/ha/_index.md b/content/k3s/latest/en/installation/ha/_index.md
index 00c082d2ac5..4e5072bfff8 100644
--- a/content/k3s/latest/en/installation/ha/_index.md
+++ b/content/k3s/latest/en/installation/ha/_index.md
@@ -33,12 +33,13 @@ You will first need to create an external datastore for the cluster. See the [Cl
### 2. Launch Server Nodes
K3s requires two or more server nodes for this HA configuration. See the [Installation Requirements]({{}}/k3s/latest/en/installation/installation-requirements/) guide for minimum machine requirements.
-When running the `k3s server` command on these nodes, you must set the `datastore-endpoint` parameter so that K3s knows how to connect to the external datastore.
+When running the `k3s server` command on these nodes, you must set the `datastore-endpoint` parameter so that K3s knows how to connect to the external datastore. The `token` parameter can also be used to set a deterministic token when adding nodes. When empty, this token will be generated automatically for further use.
-For example, a command like the following could be used to install the K3s server with a MySQL database as the external datastore:
+For example, a command like the following could be used to install the K3s server with a MySQL database as the external datastore and [set a token]({{}}/k3s/latest/en/installation/install-options/server-config/#cluster-options):
-```
+```bash
curl -sfL https://get.k3s.io | sh -s - server \
+ --token=SECRET \
--datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"
```
@@ -62,12 +63,37 @@ Agent nodes need a URL to register against. This can be the IP or hostname of an
This endpoint can also be used for accessing the Kubernetes API. So you can, for example, modify your [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file to point to it instead of a specific node. To avoid certificate errors in such a configuration, you should install the server with the `--tls-san YOUR_IP_OR_HOSTNAME_HERE` option. This option adds an additional hostname or IP as a Subject Alternative Name in the TLS cert, and it can be specified multiple times if you would like to access via both the IP and the hostname.
-### 4. Optional: Join Agent Nodes
+### 4. Optional: Join Additional Server Nodes
+
+The same example command in Step 2 can be used to join additional server nodes, where the token from the first node needs to be used.
+
+If the first server node was started without the `--token` CLI flag or `K3S_TOKEN` variable, the token value can be retrieved from any server already joined to the cluster:
+```bash
+cat /var/lib/rancher/k3s/server/token
+```
+
+Additional server nodes can then be added [using the token]({{}}/k3s/latest/en/installation/install-options/server-config/#cluster-options):
+
+```bash
+curl -sfL https://get.k3s.io | sh -s - server \
+ --token=SECRET \
+ --datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"
+```
+
+There are a few config flags that must be the same in all server nodes:
+
+* Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
+* Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
+* Feature related flags: `--secrets-encryption`
+
+> **Note:** Ensure that you retain a copy of this token as it is required when restoring from backup and adding nodes. Previously, K3s did not enforce the use of a token when using external SQL datastores.
+
+### 5. Optional: Join Agent Nodes
Because K3s server nodes are schedulable by default, the minimum number of nodes for an HA K3s server cluster is two server nodes and zero agent nodes. To add nodes designated to run your apps and services, join agent nodes to your cluster.
Joining agent nodes in an HA cluster is the same as joining agent nodes in a single server cluster. You just need to specify the URL the agent should register to and the token it should use.
-```
+```bash
K3S_TOKEN=SECRET k3s agent --server https://fixed-registration-address:6443
```
diff --git a/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md b/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md
index 25aa9b43567..447dfdc40f9 100644
--- a/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md
+++ b/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md
@@ -27,9 +27,23 @@ If this command is not specified as a server or agent command, it will default t
The final systemd command resolves to a combination of this environment variable and script args. To illustrate this, the following commands result in the same behavior of registering a server without flannel:
```bash
-curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--no-flannel" sh -s -
-curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --no-flannel" sh -s -
-curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --no-flannel
-curl -sfL https://get.k3s.io | sh -s - server --no-flannel
-curl -sfL https://get.k3s.io | sh -s - --no-flannel
-```
\ No newline at end of file
+curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--flannel-backend none" sh -s -
+curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --flannel-backend none" sh -s -
+curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --flannel-backend none
+curl -sfL https://get.k3s.io | sh -s - server --flannel-backend none
+curl -sfL https://get.k3s.io | sh -s - --flannel-backend none
+```
+
+### Example C: CONFIG FILE
+
+Before installing k3s, you can create a file called `config.yaml` containing fields that match CLI flags. That file needs to be in the path: `/etc/rancher/k3s/config.yaml` for k3s to consume it.
+
+The fields in the config file drop the starting `--` from the matching CLI flag. For example:
+
+```
+write-kubeconfig-mode: 644
+token: "secret"
+node-ip: 10.0.10.22,2a05:d012:c6f:4655:d73c:c825:a184:1b75
+cluster-cidr: 10.42.0.0/16,2001:cafe:42:0::/56
+service-cidr: 10.43.0.0/16,2001:cafe:42:1::/112
+```
diff --git a/content/k3s/latest/en/installation/install-options/server-config/_index.md b/content/k3s/latest/en/installation/install-options/server-config/_index.md
index 687133583d8..853d2ccb491 100644
--- a/content/k3s/latest/en/installation/install-options/server-config/_index.md
+++ b/content/k3s/latest/en/installation/install-options/server-config/_index.md
@@ -152,6 +152,7 @@ the agent options are there because the server has the agent process embedded wi
| Flag | Description |
|------|--------------|
+| `--etcd-arg` value | Customized flag for etcd process |
| `--kube-apiserver-arg` value | Customized flag for kube-apiserver process |
| `--kube-scheduler-arg` value | Customized flag for kube-scheduler process |
| `--kube-controller-manager-arg` value | Customized flag for kube-controller-manager process |
@@ -234,6 +235,7 @@ OPTIONS:
--token-file value (cluster) File containing the cluster-secret/token [$K3S_TOKEN_FILE]
--write-kubeconfig value, -o value (client) Write kubeconfig for admin client to this file [$K3S_KUBECONFIG_OUTPUT]
--write-kubeconfig-mode value (client) Write kubeconfig with this mode [$K3S_KUBECONFIG_MODE]
+ --etcd-arg value (flags) Customized flag for etcd process
--kube-apiserver-arg value (flags) Customized flag for kube-apiserver process
--kube-scheduler-arg value (flags) Customized flag for kube-scheduler process
--kube-controller-manager-arg value (flags) Customized flag for kube-controller-manager process
diff --git a/content/k3s/latest/en/installation/installation-requirements/_index.md b/content/k3s/latest/en/installation/installation-requirements/_index.md
index 1b5d14825de..f4fd336d7f7 100644
--- a/content/k3s/latest/en/installation/installation-requirements/_index.md
+++ b/content/k3s/latest/en/installation/installation-requirements/_index.md
@@ -44,13 +44,14 @@ K3s performance depends on the performance of the database. To ensure optimal sp
The K3s server needs port 6443 to be accessible by all nodes.
-The nodes need to be able to reach other nodes over UDP port 8472 when Flannel VXLAN is used. The node should not listen on any other port. K3s uses reverse tunneling such that the nodes make outbound connections to the server and all kubelet traffic runs through that tunnel. However, if you do not use Flannel and provide your own custom CNI, then port 8472 is not needed by K3s.
+The nodes need to be able to reach other nodes over UDP port 8472 when Flannel VXLAN is used or over UDP ports 51820 and 51821 (when using IPv6) when Flannel Wireguard backend is used. The node should not listen on any other port. K3s uses reverse tunneling such that the nodes make outbound connections to the server and all kubelet traffic runs through that tunnel. However, if you do not use Flannel and provide your own custom CNI, then the ports needed by Flannel are not needed by K3s.
If you wish to utilize the metrics server, you will need to open port 10250 on each node.
If you plan on achieving high availability with embedded etcd, server nodes must be accessible to each other on ports 2379 and 2380.
> **Important:** The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
+> **Warning:** Flannel relies on the [Bridge CNI plugin](https://www.cni.dev/plugins/current/main/bridge/) to create a L2 network that switches traffic. Rogue pods with NET_RAW capabilities can abuse that L2 network to launch attacks such as [ARP spoofing](https://static.sched.com/hosted_files/kccncna19/72/ARP%20DNS%20spoof.pdf). Therefore, as documented in the [kubernetes docs](https://kubernetes.io/docs/concepts/security/pod-security-standards/), please set a restricted profile that disables NET_RAW on non-trustable pods.
Inbound Rules for K3s Server Nodes
@@ -58,6 +59,8 @@ If you plan on achieving high availability with embedded etcd, server nodes must
|-----|-----|----------------|---|
| TCP | 6443 | K3s agent nodes | Kubernetes API Server
| UDP | 8472 | K3s server and agent nodes | Required only for Flannel VXLAN
+| UDP | 51820 | K3s server and agent nodes | Required only for Flannel Wireguard backend
+| UDP | 51821 | K3s server and agent nodes | Required only for Flannel Wireguard backend with IPv6
| TCP | 10250 | K3s server and agent nodes | Kubelet metrics
| TCP | 2379-2380 | K3s server nodes | Required only for HA with embedded etcd
diff --git a/content/k3s/latest/en/installation/network-options/_index.md b/content/k3s/latest/en/installation/network-options/_index.md
index dcc65a03aea..652f22f6adc 100644
--- a/content/k3s/latest/en/installation/network-options/_index.md
+++ b/content/k3s/latest/en/installation/network-options/_index.md
@@ -19,10 +19,11 @@ If you wish to use WireGuard as your flannel backend it may require additional k
`--flannel-backend=ipsec` | Uses the IPSEC backend which encrypts network traffic. |
`--flannel-backend=host-gw` | Uses the host-gw backend. |
`--flannel-backend=wireguard` | Uses the WireGuard backend which encrypts network traffic. May require additional kernel modules and configuration. |
+ `--flannel-ipv6-masq` | Apply masquerading rules to IPv6 traffic (default for IPv4). Only applies on dual-stack or IPv6-only clusters |
### Custom CNI
-Run K3s with `--flannel-backend=none` and install your CNI of choice. IP Forwarding should be enabled for Canal and Calico. Please reference the steps below.
+Run K3s with `--flannel-backend=none` and install your CNI of choice. Most CNI plugins come with their own network policy engine, so it is recommended to set `--disable-network-policy` as well to avoid conflicts. IP Forwarding should be enabled for Canal and Calico. Please reference the steps below.
{{% tabs %}}
{{% tab "Canal" %}}
@@ -74,15 +75,22 @@ You should see that IP forwarding is set to true.
Dual-stack networking must be configured when the cluster is first created. It cannot be enabled on an existing single-stack cluster.
-To enable dual-stack in k3s, you must provide valid dual-stack `cluster-cidr` and `service-cidr`, and set `disable-network-policy` on all server nodes. Both servers and agents must provide valid dual-stack `node-ip` settings. Node address auto-detection and network policy enforcement are not supported on dual-stack clusters when using the default flannel CNI. Besides, only vxlan backend is supported at the moment. This is an example of a valid configuration:
+Dual-stack is supported on k3s v1.21 or above.
+
+To enable dual-stack in K3s, you must provide valid dual-stack `cluster-cidr` and `service-cidr` on all server nodes. Both servers and agents must provide valid dual-stack `node-ip` settings. Node address auto-detection is not supported on dual-stack clusters, because kubelet fetches only the first IP address that it finds. Additionally, only vxlan backend is supported currently. This is an example of a valid configuration:
```
-node-ip: 10.0.10.7,2a05:d012:c6f:4611:5c2:5602:eed2:898c
-cluster-cidr: 10.42.0.0/16,2001:cafe:42:0::/56
-service-cidr: 10.43.0.0/16,2001:cafe:42:1::/112
-disable-network-policy: true
+k3s server --node-ip 10.0.10.7,2a05:d012:c6f:4611:5c2:5602:eed2:898c --cluster-cidr 10.42.0.0/16,2001:cafe:42:0::/56 --service-cidr 10.43.0.0/16,2001:cafe:42:1::/112
```
Note that you can choose whatever `cluster-cidr` and `service-cidr` value, however the `node-ip` values must correspond to the ip addresses of your main interface. Remember to allow ipv6 traffic if you are deploying in a public cloud.
If you are using a custom cni plugin, i.e. a cni plugin different from flannel, the previous configuration might not be enough to enable dual-stack in the cni plugin. Please check how to enable dual-stack in its documentation and verify if network policies can be enabled.
+
+### IPv6 only installation
+
+IPv6 only setup is supported on k3s v1.22 or above. Note that network policy enforcement is not supported on IPv6-only clusters when using the default flannel CNI. This is an example of a valid configuration:
+
+```
+k3s server --disable-network-policy
+```
diff --git a/content/k3s/latest/en/installation/private-registry/_index.md b/content/k3s/latest/en/installation/private-registry/_index.md
index c87ee3df0cb..523ae6c8586 100644
--- a/content/k3s/latest/en/installation/private-registry/_index.md
+++ b/content/k3s/latest/en/installation/private-registry/_index.md
@@ -32,22 +32,43 @@ mirrors:
Each mirror must have a name and set of endpoints. When pulling an image from a registry, containerd will try these endpoint URLs one by one, and use the first working one.
+#### Rewrites
+
+Each mirror can have a set of rewrites. Rewrites can change the tag of an image based on a regular expression. This is useful if the organization/project structure in the mirror registry is different to the upstream one.
+
+For example, the following configuration would transparently pull the image `docker.io/rancher/coredns-coredns:1.6.3` from `registry.example.com:5000/mirrorproject/rancher-images/coredns-coredns:1.6.3`:
+
+```
+mirrors:
+ docker.io:
+ endpoint:
+ - "https://registry.example.com:5000"
+ rewrite:
+ "^rancher/(.*)": "mirrorproject/rancher-images/$1"
+```
+
+The image will still be stored under the original name so that a `crictl image ls` will show `docker.io/rancher/coredns-coredns:1.6.3` as available on the node, even though the image was pulled from the mirrored registry with a different name.
+
### Configs
-The configs section defines the TLS and credential configuration for each mirror. For each mirror you can define `auth` and/or `tls`. The TLS part consists of:
+The `configs` section defines the TLS and credential configuration for each mirror. For each mirror you can define `auth` and/or `tls`.
-Directive | Description
-----------|------------
-`cert_file` | The client certificate path that will be used to authenticate with the registry
-`key_file` | The client key path that will be used to authenticate with the registry
-`ca_file` | Defines the CA certificate path to be used to verify the registry's server cert file
-`insecure_skip_verify` | Boolean that defines if TLS verification should be skipped for the registry
+The `tls` part consists of:
-The credentials consist of either username/password or authentication token:
+| Directive | Description |
+|------------------------|--------------------------------------------------------------------------------------|
+| `cert_file` | The client certificate path that will be used to authenticate with the registry |
+| `key_file` | The client key path that will be used to authenticate with the registry |
+| `ca_file` | Defines the CA certificate path to be used to verify the registry's server cert file |
+| `insecure_skip_verify` | Boolean that defines if TLS verification should be skipped for the registry |
-- username: user name of the private registry basic auth
-- password: user password of the private registry basic auth
-- auth: authentication token of the private registry basic auth
+The `auth` part consists of either username/password or authentication token:
+
+| Directive | Description |
+|------------|---------------------------------------------------------|
+| `username` | user name of the private registry basic auth |
+| `password` | user password of the private registry basic auth |
+| `auth` | authentication token of the private registry basic auth |
Below are basic examples of using private registries in different modes:
@@ -142,4 +163,4 @@ Example: `docker tag coredns-coredns:1.6.3 mycustomreg:5000/coredns-coredns`
Last, push the images to the private registry.
-Example: `docker push mycustomreg:5000/coredns-coredns`
+Example: `docker push mycustomreg.com:5000/coredns-coredns`
diff --git a/content/k3s/latest/en/networking/_index.md b/content/k3s/latest/en/networking/_index.md
index 49ed55deb46..2dff22e927d 100644
--- a/content/k3s/latest/en/networking/_index.md
+++ b/content/k3s/latest/en/networking/_index.md
@@ -42,7 +42,7 @@ To migrate from an older Traefik v1 instance please refer to the [Traefik docume
# Service Load Balancer
-Any service load balancer (LB) can be leveraged in your Kubernetes cluster. K3s provides a load balancer known as [Klipper Load Balancer](https://github.com/rancher/klipper-lb) that uses available host ports.
+Any service load balancer (LB) can be leveraged in your Kubernetes cluster. K3s provides a load balancer known as [Klipper Load Balancer](https://github.com/k3s-io/klipper-lb) that uses available host ports.
Upstream Kubernetes allows a Service of type LoadBalancer to be created, but doesn't include the implementation of the LB. Some LB services require a cloud provider such as Amazon EC2 or Microsoft Azure. By contrast, the K3s service LB makes it possible to use an LB service without a cloud provider.
diff --git a/content/k3s/latest/en/security/_index.md b/content/k3s/latest/en/security/_index.md
index f8b4285fc49..ba6ef7ccbd6 100644
--- a/content/k3s/latest/en/security/_index.md
+++ b/content/k3s/latest/en/security/_index.md
@@ -5,7 +5,7 @@ weight: 90
This section describes the methodology and means of securing a K3s cluster. It's broken into 2 sections. These guides assume k3s is running with embedded etcd.
-The documents below apply to both CIS 1.5 & 1.6.
+The documents below apply to CIS Kubernetes Benchmark v1.6.
* [Hardening Guide](./hardening_guide/)
* [CIS Benchmark Self-Assessment Guide](./self_assessment/)
diff --git a/content/k3s/latest/en/security/hardening_guide/_index.md b/content/k3s/latest/en/security/hardening_guide/_index.md
index 6a66acc02aa..e22571f30ef 100644
--- a/content/k3s/latest/en/security/hardening_guide/_index.md
+++ b/content/k3s/latest/en/security/hardening_guide/_index.md
@@ -3,12 +3,12 @@ title: "CIS Hardening Guide"
weight: 80
---
-This document provides prescriptive guidance for hardening a production installation of K3s. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
+This document provides prescriptive guidance for hardening a production installation of K3s. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Internet Security (CIS).
K3s has a number of security mitigations applied and turned on by default and will pass a number of the Kubernetes CIS controls without modification. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
1. K3s will not modify the host operating system. Any host-level modifications will need to be done manually.
-2. Certain CIS policy controls for PodSecurityPolicies and NetworkPolicies will restrict the functionality of this cluster. You must opt into having K3s configure these by adding the appropriate options (enabling of admission plugins) to your command-line flags or configuration file as well as manually applying appropriate policies. Further detail in the sections below.
+2. Certain CIS policy controls for `PodSecurityPolicies` and `NetworkPolicies` will restrict the functionality of the cluster. You must opt into having K3s configure these by adding the appropriate options (enabling of admission plugins) to your command-line flags or configuration file as well as manually applying appropriate policies. Further details are presented in the sections below.
The first section (1.1) of the CIS Benchmark concerns itself primarily with pod manifest permissions and ownership. K3s doesn't utilize these for the core components since everything is packaged into a single binary.
@@ -31,23 +31,24 @@ vm.panic_on_oom=0
vm.overcommit_memory=1
kernel.panic=10
kernel.panic_on_oops=1
+kernel.keys.root_maxbytes=25000000
```
## Kubernetes Runtime Requirements
-The runtime requirements to comply with the CIS Benchmark are centered around pod security (PSPs) and network policies. These are outlined in this section. K3s doesn't apply any default PSPs or network policies however K3s ships with a controller that is meant to apply a given set of network policies. By default, K3s runs with the "NodeRestriction" admission controller. To enable PSPs, add the following to the K3s start command: `--kube-apiserver-arg="enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount"`. This will have the effect of maintaining the "NodeRestriction" plugin as well as enabling the "PodSecurityPolicy".
+The runtime requirements to comply with the CIS Benchmark are centered around pod security (PSPs), network policies and API Server auditing logs. These are outlined in this section. K3s doesn't apply any default PSPs or network policies. However, K3s ships with a controller that is meant to apply a given set of network policies. By default, K3s runs with the `NodeRestriction` admission controller. To enable PSPs, add the following to the K3s start command: `--kube-apiserver-arg="enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount"`. This will have the effect of maintaining the `NodeRestriction` plugin as well as enabling the `PodSecurityPolicy`. The same happens with the API Server auditing logs, K3s doesn't enable them by default, so audit log configuration and audit policy must be created manually.
-### PodSecurityPolicies
+### Pod Security Policies
When PSPs are enabled, a policy can be applied to satisfy the necessary controls described in section 5.2 of the CIS Benchmark.
-Here's an example of a compliant PSP.
+Here is an example of a compliant PSP.
```yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
- name: cis1.5-compliant-psp
+ name: restricted-psp
spec:
privileged: false # CIS - 5.2.1
allowPrivilegeEscalation: false # CIS - 5.2.5
@@ -59,7 +60,9 @@ spec:
- 'projected'
- 'secret'
- 'downwardAPI'
+ - 'csi'
- 'persistentVolumeClaim'
+ - 'ephemeral'
hostNetwork: false # CIS - 5.2.4
hostIPC: false # CIS - 5.2.3
hostPID: false # CIS - 5.2.2
@@ -80,7 +83,7 @@ spec:
readOnlyRootFilesystem: false
```
-Before the above PSP to be effective, we need to create a couple ClusterRoles and ClusterRole. We also need to include a "system unrestricted policy" which is needed for system-level pods that require additional privileges.
+For the above PSP to be effective, we need to create a ClusterRole and a ClusterRoleBinding. We also need to include a "system unrestricted policy" which is needed for system-level pods that require additional privileges.
These can be combined with the PSP yaml above and NetworkPolicy yaml below into a single file and placed in the `/var/lib/rancher/k3s/server/manifests` directory. Below is an example of a `policy.yaml` file.
@@ -88,7 +91,7 @@ These can be combined with the PSP yaml above and NetworkPolicy yaml below into
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
- name: cis1.5-compliant-psp
+ name: restricted-psp
spec:
privileged: false
allowPrivilegeEscalation: false
@@ -100,7 +103,9 @@ spec:
- 'projected'
- 'secret'
- 'downwardAPI'
+ - 'csi'
- 'persistentVolumeClaim'
+ - 'ephemeral'
hostNetwork: false
hostIPC: false
hostPID: false
@@ -123,7 +128,7 @@ spec:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
- name: psp:restricted
+ name: psp:restricted-psp
labels:
addonmanager.kubernetes.io/mode: EnsureExists
rules:
@@ -131,62 +136,23 @@ rules:
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
- - cis1.5-compliant-psp
+ - restricted-psp
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
- name: default:restricted
+ name: default:restricted-psp
labels:
addonmanager.kubernetes.io/mode: EnsureExists
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
- name: psp:restricted
+ name: psp:restricted-psp
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
---
-kind: NetworkPolicy
-apiVersion: networking.k8s.io/v1
-metadata:
- name: intra-namespace
- namespace: kube-system
-spec:
- podSelector: {}
- ingress:
- - from:
- - namespaceSelector:
- matchLabels:
- name: kube-system
----
-kind: NetworkPolicy
-apiVersion: networking.k8s.io/v1
-metadata:
- name: intra-namespace
- namespace: default
-spec:
- podSelector: {}
- ingress:
- - from:
- - namespaceSelector:
- matchLabels:
- name: default
----
-kind: NetworkPolicy
-apiVersion: networking.k8s.io/v1
-metadata:
- name: intra-namespace
- namespace: kube-public
-spec:
- podSelector: {}
- ingress:
- - from:
- - namespaceSelector:
- matchLabels:
- name: kube-public
----
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
@@ -253,6 +219,45 @@ subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
+---
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+ name: intra-namespace
+ namespace: kube-system
+spec:
+ podSelector: {}
+ ingress:
+ - from:
+ - namespaceSelector:
+ matchLabels:
+ name: kube-system
+---
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+ name: intra-namespace
+ namespace: default
+spec:
+ podSelector: {}
+ ingress:
+ - from:
+ - namespaceSelector:
+ matchLabels:
+ name: default
+---
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+ name: intra-namespace
+ namespace: kube-public
+spec:
+ podSelector: {}
+ ingress:
+ - from:
+ - namespaceSelector:
+ matchLabels:
+ name: kube-public
```
> **Note:** The Kubernetes critical additions such as CNI, DNS, and Ingress are ran as pods in the `kube-system` namespace. Therefore, this namespace will have a policy that is less restrictive so that these components can run properly.
@@ -263,7 +268,7 @@ subjects:
CIS requires that all namespaces have a network policy applied that reasonably limits traffic into namespaces and pods.
-Here's an example of a compliant network policy.
+Here is an example of a compliant network policy.
```yaml
kind: NetworkPolicy
@@ -302,11 +307,25 @@ spec:
- Ingress
```
-If you are using the default traefik ingress controller with k3s, it will also be blocked by default, so the following network policies must be added to allow traffic to both traefik pods and svclb pods in the kube-system namespace. For version 1.20 and below there is a different label `traefik` used than in 1.21 and above, so remove the one that is not associated with your Kubernetes version.
+The metrics-server and Traefik ingress controller will be blocked by default if network policies are not created to allow access. Traefik v1 as packaged in K3s version 1.20 and below uses different labels than Traefik v2. Ensure that you only use the sample yaml below that is associated with the version of Traefik present on your cluster.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
+metadata:
+ name: allow-all-metrics-server
+ namespace: kube-system
+spec:
+ podSelector:
+ matchLabels:
+ k8s-app: metrics-server
+ ingress:
+ - {}
+ policyTypes:
+ - Ingress
+---
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
metadata:
name: allow-all-svclbtraefik-ingress
namespace: kube-system
@@ -319,7 +338,7 @@ spec:
policyTypes:
- Ingress
---
-# 1.20
+# Below is for 1.20 ONLY -- remove if on 1.21 or above
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
@@ -334,7 +353,7 @@ spec:
policyTypes:
- Ingress
---
-# 1.21
+# Below is for 1.21 and above ONLY -- remove if on 1.20 or below
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
@@ -352,24 +371,67 @@ spec:
> **Note:** Operators must manage network policies as normal for additional namespaces that are created.
+### API Server audit configuration
+
+CIS requirements 1.2.22 to 1.2.25 are related to configuring audit logs for the API Server. K3s doesn't create by default the log directory and audit policy, as auditing requirements are specific to each user's policies and environment.
+
+The log directory, ideally, must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
+
+```bash
+sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
+```
+
+A starter audit policy to log request metadata is provided below. The policy should be written to a file named `audit.yaml` in `/var/lib/rancher/k3s/server` directory. Detailed information about policy configuration for the API server can be found in the Kubernetes [documentation](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/).
+
+```yaml
+apiVersion: audit.k8s.io/v1
+kind: Policy
+rules:
+- level: Metadata
+```
+
+Both configurations must be passed as arguments to the API Server as:
+
+```bash
+--kube-apiserver-arg='audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log'
+--kube-apiserver-arg='audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml'
+```
+
+If the configurations are created after K3s is installed, they must be added to K3s' systemd service in `/etc/systemd/system/k3s.service`.
+
+```bash
+ExecStart=/usr/local/bin/k3s \
+ server \
+ '--kube-apiserver-arg=audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log' \
+ '--kube-apiserver-arg=audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml' \
+```
+
+K3s must be restarted to load the new configuration.
+
+```bash
+sudo systemctl daemon-reload
+sudo systemctl restart k3s.service
+```
+
+Additional information about CIS requirements 1.2.22 to 1.2.25 is presented below.
+
## Known Issues
The following are controls that K3s currently does not pass by default. Each gap will be explained, along with a note clarifying whether it can be passed through manual operator intervention, or if it will be addressed in a future release of K3s.
-
### Control 1.2.15
Ensure that the admission control plugin `NamespaceLifecycle` is set.
Rationale
-Setting admission control policy to NamespaceLifecycle ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects.
+Setting admission control policy to `NamespaceLifecycle` ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects.
This can be remediated by passing this argument as a value to the `enable-admission-plugins=` and pass that to `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below.
-### Control 1.2.16 (mentioned above)
+### Control 1.2.16
Ensure that the admission control plugin `PodSecurityPolicy` is set.
Rationale
-A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions.
+A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The `PodSecurityPolicy` objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions.
This can be remediated by passing this argument as a value to the `enable-admission-plugins=` and pass that to `--kube-apiserver-arg=` argument to `k3s server`. An example can be found below.
@@ -432,16 +494,18 @@ This can be remediated by passing this argument as a value to the `--kube-apiser
Ensure that the `--encryption-provider-config` argument is set as appropriate.
Rationale
-Where `etcd` encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, the aescbc, kms and secretbox are likely to be appropriate options.
+`etcd` is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures.
+
+Detailed steps on how to configure secrets encryption in K3s are available in [Secrets Encryption](../secrets_encryption/).
### Control 1.2.34
Ensure that encryption providers are appropriately configured.
Rationale
-`etcd` is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures.
+Where `etcd` encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, the `aescbc`, `kms` and `secretbox` are likely to be appropriate options.
-This can be remediated by passing a valid configuration to `k3s` as outlined above.
+This can be remediated by passing a valid configuration to `k3s` as outlined above. Detailed steps on how to configure secrets encryption in K3s are available in [Secrets Encryption](../secrets_encryption/).
### Control 1.3.1
@@ -454,7 +518,7 @@ This can be remediated by passing this argument as a value to the `--kube-apiser
### Control 3.2.1
-Ensure that a minimal audit policy is created (Scored)
+Ensure that a minimal audit policy is created.
Rationale
Logging is an important detective control for all systems, to detect potential unauthorized access.
@@ -462,7 +526,6 @@ Logging is an important detective control for all systems, to detect potential u
This can be remediated by passing controls 1.2.22 - 1.2.25 and verifying their efficacy.
-
### Control 4.2.7
Ensure that the `--make-iptables-util-chains` argument is set to true.
@@ -473,24 +536,23 @@ This can be remediated by passing this argument as a value to the `--kube-apiser
### Control 5.1.5
-Ensure that default service accounts are not actively used. (Scored)
+Ensure that default service accounts are not actively used
Rationale
-
-Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
+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.
-
-The remediation for this is to update the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
+This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default`), K3s does not automatically do this. You can manually update this field on these service accounts to pass the control.
+
## Control Plane Execution and Arguments
-Listed below are the K3s control plane components and the arguments they're given at start, by default. Commented to their right is the CIS 1.5 control that they satisfy.
+Listed below are the K3s control plane components and the arguments they are given at start, by default. Commented to their right is the CIS 1.6 control that they satisfy.
```bash
kube-apiserver
@@ -590,13 +652,14 @@ kubelet
--tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key # 4.2.10
```
-The command below is an example of how the outlined remediations can be applied.
+The command below is an example of how the outlined remediations can be applied to harden K3s.
```bash
k3s server \
--protect-kernel-defaults=true \
--secrets-encryption=true \
- --kube-apiserver-arg='audit-log-path=/var/lib/rancher/k3s/server/logs/audit-log' \
+ --kube-apiserver-arg='audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log' \
+ --kube-apiserver-arg='audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml' \
--kube-apiserver-arg='audit-log-maxage=30' \
--kube-apiserver-arg='audit-log-maxbackup=10' \
--kube-apiserver-arg='audit-log-maxsize=100' \
@@ -611,4 +674,4 @@ k3s server \
## Conclusion
-If you have followed this guide, your K3s cluster will be configured to comply with the CIS Kubernetes Benchmark. You can review the [CIS Benchmark Self-Assessment Guide](../self_assessment/) to understand the expectations of each of the benchmarks and how you can do the same on your cluster.
+If you have followed this guide, your K3s cluster will be configured to comply with the CIS Kubernetes Benchmark. You can review the [CIS Benchmark Self-Assessment Guide](../self_assessment/) to understand the expectations of each of the benchmark's checks and how you can do the same on your cluster.
diff --git a/content/k3s/latest/en/security/secrets_encryption/_index.md b/content/k3s/latest/en/security/secrets_encryption/_index.md
new file mode 100644
index 00000000000..a7491e2fb63
--- /dev/null
+++ b/content/k3s/latest/en/security/secrets_encryption/_index.md
@@ -0,0 +1,241 @@
+---
+title: Secrets Encryption
+weight: 26
+---
+
+# Secrets Encryption Config
+_Available as of v1.17.4+k3s1_
+
+K3s supports enabling secrets encryption at rest by passing the flag `--secrets-encryption` on a server; this flag will do the following automatically:
+
+- Generate an AES-CBC key
+- Generate an encryption config file with the generated key
+- Pass the config to the KubeAPI as encryption-provider-config
+
+Example of the encryption config file:
+```
+{
+ "kind": "EncryptionConfiguration",
+ "apiVersion": "apiserver.config.k8s.io/v1",
+ "resources": [
+ {
+ "resources": [
+ "secrets"
+ ],
+ "providers": [
+ {
+ "aescbc": {
+ "keys": [
+ {
+ "name": "aescbckey",
+ "secret": "xxxxxxxxxxxxxxxxxxx"
+ }
+ ]
+ }
+ },
+ {
+ "identity": {}
+ }
+ ]
+ }
+ ]
+}
+```
+
+
+## Secrets Encryption Tool
+_Available as of v1.21.8+k3s1_
+
+K3s contains a utility tool `secrets-encrypt`, which enables automatic control over the following:
+
+- Disabling/Enabling secrets encryption
+- Adding new encryption keys
+- Rotating and deleting encryption keys
+- Reencrypting secrets
+
+>**Warning:** Failure to follow proper procedure for rotating encryption keys can leave your cluster permanently corrupted. Proceed with caution.
+
+### Single-Server Encryption Key Rotation
+To rotate secrets encryption keys on a single-node cluster:
+
+- Start the K3s server with the flag `--secrets-encryption`
+
+>**Note:** Starting K3s without encryption and enabling it at a later time is currently *not* supported.
+
+1. Prepare
+
+ ```
+ k3s secrets-encrypt prepare
+ ```
+
+2. Kill and restart the K3s server with same arguments
+3. Rotate
+
+ ```
+ k3s secrets-encrypt rotate
+ ```
+
+4. Kill and restart the K3s server with same arguments
+5. Reencrypt
+
+ ```
+ k3s secrets-encrypt reencrypt
+ ```
+
+### High-Availability Encryption Key Rotation
+The steps are the same for both embedded DB and external DB clusters.
+
+To rotate secrets encryption keys on HA setups:
+
+>**Notes:**
+>
+> - Starting K3s without encryption and enabling it at a later time is currently *not* supported.
+>
+> - While not required, it is recommended that you pick one server node from which to run the `secrets-encrypt` commands.
+
+- Start up all three K3s servers with the `--secrets-encryption` flag. For brevity, the servers will be referred to as S1, S2, S3.
+
+1. Prepare on S1
+
+ ```
+ k3s secrets-encrypt prepare
+ ```
+
+2. Kill and restart S1 with same arguments
+3. Once S1 is up, kill and restart the S2 and S3
+
+4. Rotate on S1
+
+ ```
+ k3s secrets-encrypt rotate
+ ```
+
+5. Kill and restart S1 with same arguments
+6. Once S1 is up, kill and restart the S2 and S3
+
+7. Reencrypt on S1
+
+ ```
+ k3s secrets-encrypt reencrypt
+ ```
+
+8. Kill and restart S1 with same arguments
+9. Once S1 is up, kill and restart the S2 and S3
+
+### Single-Server Secrets Encryption Disable/Enable
+After launching a server with `--secrets-encryption` flag, secrets encryption can be disabled.
+
+To disable secrets encryption on a single-node cluster:
+
+1. Disable
+
+ ```
+ k3s secrets-encrypt disable
+ ```
+
+2. Kill and restart the K3s server with same arguments
+
+3. Reencrypt with flags
+
+ ```
+ k3s secrets-encrypt reencrypt --force --skip
+ ```
+
+To re-enable secrets encryption on a single node cluster:
+
+1. Enable
+
+ ```
+ k3s secrets-encrypt enable
+ ```
+
+2. Kill and restart the K3s server with same arguments
+
+3. Reencrypt with flags
+
+ ```
+ k3s secrets-encrypt reencrypt --force --skip
+ ```
+
+### High-Availability Secrets Encryption Disable/Enable
+After launching a HA cluster with `--secrets-encryption` flags, secrets encryption can be disabled.
+>**Note:** While not required, it is recommended that you pick one server node from which to run the `secrets-encrypt` commands.
+
+For brevity, the three servers used in this guide will be referred to as S1, S2, S3.
+
+To disable secrets encryption on a HA cluster:
+
+1. Disable on S1
+
+ ```
+ k3s secrets-encrypt disable
+ ```
+
+2. Kill and restart S1 with same arguments
+3. Once S1 is up, kill and restart the S2 and S3
+
+
+4. Reencrypt with flags on S1
+
+ ```
+ k3s secrets-encrypt reencrypt --force --skip
+ ```
+
+To re-enable secrets encryption on a HA cluster:
+
+1. Enable on S1
+
+ ```
+ k3s secrets-encrypt enable
+ ```
+
+2. Kill and restart S1 with same arguments
+3. Once S1 is up, kill and restart the S2 and S3
+
+4. Reencrypt with flags on S1
+
+ ```
+ k3s secrets-encrypt reencrypt --force --skip
+ ```
+
+
+### Secrets Encryption Status
+The secrets-encrypt tool includes a `status` command that displays information about the current status of secrets encryption on the node.
+
+An example of the command on a single-server node:
+```
+$ k3s secrets-encrypt status
+Encryption Status: Enabled
+Current Rotation Stage: start
+Server Encryption Hashes: All hashes match
+
+Active Key Type Name
+------ -------- ----
+ * AES-CBC aescbckey
+
+```
+
+Another example on HA cluster, after rotating the keys, but before restarting the servers:
+```
+$ k3s secrets-encrypt status
+Encryption Status: Enabled
+Current Rotation Stage: rotate
+Server Encryption Hashes: hash does not match between node-1 and node-2
+
+Active Key Type Name
+------ -------- ----
+ * AES-CBC aescbckey-2021-12-10T22:54:38Z
+ AES-CBC aescbckey
+
+```
+
+Details on each section are as follows:
+
+- __Encryption Status__: Displayed whether secrets encryption is disabled or enabled on the node
+- __Current Rotation Stage__: Indicates the current rotation stage on the node.
+ Stages are: `start`, `prepare`, `rotate`, `reencrypt_request`, `reencrypt_active`, `reencrypt_finished`
+- __Server Encryption Hashes__: Useful for HA clusters, this indicates whether all servers are on the same stage with their local files. This can be used to identify whether a restart of servers is required before proceeding to the next stage. In the HA example above, node-1 and node-2 have different hashes, indicating that they currently do not have the same encryption configuration. Restarting the servers will sync up their configuration.
+- __Key Table__: Summarizes information about the secrets encryption keys found on the node.
+ * __Active__: The "*" indicates which, if any, of the keys are currently used for secrets encryption. An active key is used by Kubernetes to encrypt any new secrets.
+ * __Key Type__: All keys using this tool are `AES-CBC` type. See more info [here.](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers)
+ * __Name__: Name of the encryption key.
\ No newline at end of file
diff --git a/content/k3s/latest/en/security/self_assessment/_index.md b/content/k3s/latest/en/security/self_assessment/_index.md
index ff7ba082384..6471a95fb83 100644
--- a/content/k3s/latest/en/security/self_assessment/_index.md
+++ b/content/k3s/latest/en/security/self_assessment/_index.md
@@ -1,18 +1,17 @@
---
-title: "CIS Self Assessment Guide"
+title: CIS Self Assessment Guide
weight: 90
---
-
-### CIS Kubernetes Benchmark v1.5 - K3s v1.17, v1.18, & v1.19
+### CIS Kubernetes Benchmark v1.6 - K3s with Kubernetes v1.17 to v1.21
#### Overview
-This document is a companion to the K3s security hardening guide. The hardening guide provides prescriptive guidance for hardening a production installation of K3s, and this benchmark guide is meant to help you evaluate the level of security of the hardened cluster against each control in the CIS Kubernetes benchmark. It is to be used by K3s operators, security teams, auditors, and decision-makers.
+This document is a companion to the K3s security hardening guide. The hardening guide provides prescriptive guidance for hardening a production installation of K3s, and this benchmark guide is meant to help you evaluate the level of security of the hardened cluster against each control in the CIS Kubernetes Benchmark. It is to be used by K3s operators, security teams, auditors, and decision-makers.
-This guide is specific to the **v1.17**, **v1.18**, and **v1.19** release line of K3s and the **v1.5.1** release of the CIS Kubernetes Benchmark.
+This guide is specific to the **v1.17**, **v1.18**, **v1.19**, **v1.20** and **v1.21** release line of K3s and the **v1.6** release of the CIS Kubernetes Benchmark.
-For more detail about each control, including more detailed descriptions and remediations for failing tests, you can refer to the corresponding section of the CIS Kubernetes Benchmark v1.5. You can download the benchmark after logging in to [CISecurity.org](https://www.cisecurity.org/benchmark/kubernetes/).
+For more information about each control, including detailed descriptions and remediations for failing tests, you can refer to the corresponding section of the CIS Kubernetes Benchmark v1.6. You can download the benchmark, after creating a free account, in [Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/).
#### Testing controls methodology
@@ -24,2474 +23,3056 @@ These are the possible results for each control:
- **Pass** - The K3s cluster under test passed the audit outlined in the benchmark.
- **Not Applicable** - The control is not applicable to K3s because of how it is designed to operate. The remediation section will explain why this is so.
-- **Not Scored - Operator Dependent** - The control is not scored in the CIS benchmark and it depends on the cluster's use case or some other factor that must be determined by the cluster operator. These controls have been evaluated to ensure K3s does not prevent their implementation, but no further configuration or auditing of the cluster under test has been performed.
+- **Warn** - The control is manual in the CIS benchmark and it depends on the cluster's use case or some other factor that must be determined by the cluster operator. These controls have been evaluated to ensure K3s does not prevent their implementation, but no further configuration or auditing of the cluster under test has been performed.
This guide makes the assumption that K3s is running as a Systemd unit. Your installation may vary and will require you to adjust the "audit" commands to fit your scenario.
+> NOTE: Only `automated` tests (previously called `scored`) are covered in this guide.
+
### Controls
---
-## 1 Master Node Security Configuration
-### 1.1 Master Node Configuration Files
-#### 1.1.1
-Ensure that the API server pod specification file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The API server pod specification file controls various parameters that set the behavior of the API server. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
+## 1.1 Master Node Configuration Files
+### 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)
+
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the
+master node.
+For example, chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml
+
+### 1.1.2 Ensure that the API server pod specification file ownership is set to root:root (Automated)
-#### 1.1.2
-Ensure that the API server pod specification file ownership is set to `root:root` (Scored)
-
-Rationale
-The API server pod specification file controls various parameters that set the behavior of the API server. You should set its file ownership to maintain the integrity of the file. The file should be owned by `root:root`.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml
+
+### 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated)
-#### 1.1.3
-Ensure that the controller manager pod specification file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The controller manager pod specification file controls various parameters that set the behavior of the Controller Manager on the master node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod 644 /etc/kubernetes/manifests/kube-controller-manager.yaml
+
+### 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root (Automated)
-#### 1.1.4
-Ensure that the controller manager pod specification file ownership is set to `root:root` (Scored)
-
-Rationale
-The controller manager pod specification file controls various parameters that set the behavior of various components of the master node. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root /etc/kubernetes/manifests/kube-controller-manager.yaml
+
+### 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated)
-#### 1.1.5
-Ensure that the scheduler pod specification file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The scheduler pod specification file controls various parameters that set the behavior of the Scheduler service in the master node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod 644 /etc/kubernetes/manifests/kube-scheduler.yaml
+
+### 1.1.6 Ensure that the scheduler pod specification file ownership is set to root:root (Automated)
-#### 1.1.6
-Ensure that the scheduler pod specification file ownership is set to `root:root` (Scored)
-
-Rationale
-The scheduler pod specification file controls various parameters that set the behavior of the kube-scheduler service in the master node. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root /etc/kubernetes/manifests/kube-scheduler.yaml
+
+### 1.1.7 Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Automated)
-#### 1.1.7
-Ensure that the etcd pod specification file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The etcd pod specification file /var/lib/rancher/k3s/agent/pod-manifests/etcd.yaml controls various parameters that set the behavior of the etcd service in the master node. etcd is a highly- available key-value store which Kubernetes uses for persistent storage of all of its REST API object. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod 644 /etc/kubernetes/manifests/etcd.yaml
+
+### 1.1.8 Ensure that the etcd pod specification file ownership is set to root:root (Automated)
-#### 1.1.8
-Ensure that the etcd pod specification file ownership is set to `root:root` (Scored)
-
-Rationale
-The etcd pod specification file /var/lib/rancher/k3s/agent/pod-manifests/etcd.yaml controls various parameters that set the behavior of the etcd service in the master node. etcd is a highly- available key-value store which Kubernetes uses for persistent storage of all of its REST API object. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root /etc/kubernetes/manifests/etcd.yaml
+
+### 1.1.9 Ensure that the Container Network Interface file permissions are set to 644 or more restrictive (Manual)
-#### 1.1.9
-Ensure that the Container Network Interface file permissions are set to 644 or more restrictive (Not Scored)
-
-Rationale
-Container Network Interface provides various networking options for overlay networking. You should consult their documentation and restrict their respective file permissions to maintain the integrity of those files. Those files should be writable by only the administrators on the system.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod 644
+
+### 1.1.10 Ensure that the Container Network Interface file ownership is set to root:root (Manual)
-#### 1.1.10
-Ensure that the Container Network Interface file ownership is set to root:root (Not Scored)
-
-Rationale
-Container Network Interface provides various networking options for overlay networking. You should consult their documentation and restrict their respective file permissions to maintain the integrity of those files. Those files should be owned by root:root.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root
-#### 1.1.11
-Ensure that the etcd data directory permissions are set to 700 or more restrictive (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. This data directory should be protected from any unauthorized reads or writes. It should not be readable or writable by any group members or the world.
-
+### 1.1.11 Ensure that the etcd data directory permissions are set to 700 or more restrictive (Automated)
-**Result:** Pass
-**Audit:**
+**Result:** pass
+
+**Remediation:**
+On the etcd server node, get the etcd data directory, passed as an argument --data-dir,
+from the below command:
+ps -ef | grep etcd
+Run the below command (based on the etcd data directory found above). For example,
+chmod 700 /var/lib/etcd
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
```bash
-stat -c %a /var/lib/rancher/k3s/server/db/etcd
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 1.1.11
+```
+
+**Expected Result**:
+
+```console
+'700' is equal to '700'
+```
+
+**Returned Value**:
+
+```console
700
```
-**Remediation:**
-K3s manages the etcd data directory and sets its permissions to 700. No manual remediation needed. (only relevant when Etcd is used for the data store)
+### 1.1.12 Ensure that the etcd data directory ownership is set to etcd:etcd (Automated)
-#### 1.1.12
-Ensure that the etcd data directory ownership is set to `etcd:etcd` (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. This data directory should be protected from any unauthorized reads or writes. It should be owned by etcd:etcd.
-
-
**Result:** Not Applicable
+**Remediation:**
+On the etcd server node, get the etcd data directory, passed as an argument --data-dir,
+from the below command:
+ps -ef | grep etcd
+Run the below command (based on the etcd data directory found above).
+For example, chown etcd:etcd /var/lib/etcd
-#### 1.1.13
-Ensure that the `admin.conf` file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The admin.conf is the administrator kubeconfig file defining various settings for the administration of the cluster. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
+### 1.1.13 Ensure that the admin.conf file permissions are set to 644 or more restrictive (Automated)
-In K3s, this file is located at `/var/lib/rancher/k3s/server/cred/admin.kubeconfig`.
-
-**Result:** Pass
+**Result:** Not Applicable
**Remediation:**
-By default, K3s creates the directory and files with the expected permissions of `644`. No manual remediation should be necessary.
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod 644 /var/lib/rancher/k3s/server/cred/admin.kubeconfig
+
+### 1.1.14 Ensure that the admin.conf file ownership is set to root:root (Automated)
-#### 1.1.14
-Ensure that the `admin.conf` file ownership is set to `root:root` (Scored)
-
-Rationale
-The admin.conf file contains the admin credentials for the cluster. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.
-
-In K3s, this file is located at `/var/lib/rancher/k3s/server/cred/admin.kubeconfig`.
-
-
-**Result:** Pass
+**Result:** pass
**Remediation:**
-By default, K3s creates the directory and files with the expected ownership of `root:root`. No manual remediation should be necessary.
-
-
-#### 1.1.15
-Ensure that the `scheduler.conf` file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-
-The scheduler.conf file is the kubeconfig file for the Scheduler. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
-In K3s, this file is located at `/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig`.
-
-
-**Result:** Pass
-
-**Remediation:**
-By default, K3s creates the directory and files with the expected permissions of `644`. No manual remediation should be necessary.
-
-
-#### 1.1.16
-Ensure that the `scheduler.conf` file ownership is set to `root:root` (Scored)
-
-Rationale
-The scheduler.conf file is the kubeconfig file for the Scheduler. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.
-
-In K3s, this file is located at `/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig`.
-
-
-**Result:** Pass
-
-**Remediation:**
-By default, K3s creates the directory and files with the expected ownership of `root:root`. No manual remediation should be necessary.
-
-
-#### 1.1.17
-Ensure that the `controller.kubeconfig` file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The controller.kubeconfig file is the kubeconfig file for the Scheduler. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
-In K3s, this file is located at `/var/lib/rancher/k3s/server/cred/controller.kubeconfig`.
-
-
-**Result:** Pass
-
-**Remediation:**
-By default, K3s creates the directory and files with the expected permissions of `644`. No manual remediation should be necessary.
-
-
-#### 1.1.18
-Ensure that the `controller.kubeconfig` file ownership is set to `root:root` (Scored)
-
-Rationale
-The controller.kubeconfig file is the kubeconfig file for the Scheduler. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.
-
-In K3s, this file is located at `/var/lib/rancher/k3s/server/cred/controller.kubeconfig`.
-
-
-**Result:** Pass
-
-**Remediation:**
-By default, K3s creates the directory and files with the expected ownership of `root:root`. No manual remediation should be necessary.
-
-
-#### 1.1.19
-Ensure that the Kubernetes PKI directory and file ownership is set to `root:root` (Scored)
-
-Rationale
-Kubernetes makes use of a number of certificates as part of its operation. You should set the ownership of the directory containing the PKI information and all files in that directory to maintain their integrity. The directory and files should be owned by root:root.
-
-
-**Result:** Pass
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root /etc/kubernetes/admin.conf
**Audit:**
+
```bash
-stat -c %U:%G /var/lib/rancher/k3s/server/tls
+/bin/sh -c 'if test -e /var/lib/rancher/k3s/server/cred/admin.kubeconfig; then stat -c %U:%G /var/lib/rancher/k3s/server/cred/admin.kubeconfig; fi'
+```
+
+**Expected Result**:
+
+```console
+'root:root' is equal to 'root:root'
+```
+
+**Returned Value**:
+
+```console
root:root
```
+### 1.1.15 Ensure that the scheduler.conf file permissions are set to 644 or more restrictive (Automated)
+
+
+**Result:** pass
+
**Remediation:**
-By default, K3s creates the directory and files with the expected ownership of `root:root`. No manual remediation should be necessary.
-
-
-#### 1.1.20
-Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-Kubernetes makes use of a number of certificate files as part of the operation of its components. The permissions on these files should be set to 644 or more restrictive to protect their integrity.
-
-
-**Result:** Pass
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod 644 scheduler
**Audit:**
-Run the below command on the master node.
```bash
-stat -c %n\ %a /var/lib/rancher/k3s/server/tls/*.crt
+/bin/sh -c 'if test -e scheduler; then stat -c permissions=%a scheduler; fi'
```
-Verify that the permissions are `644` or more restrictive.
+**Expected Result**:
+
+```console
+'permissions' is not present
+```
+
+### 1.1.16 Ensure that the scheduler.conf file ownership is set to root:root (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s creates the files with the expected permissions of `644`. No manual remediation is needed.
-
-
-#### 1.1.21
-Ensure that the Kubernetes PKI key file permissions are set to `600` (Scored)
-
-Rationale
-Kubernetes makes use of a number of key files as part of the operation of its components. The permissions on these files should be set to 600 to protect their integrity and confidentiality.
-
-
-**Result:** Pass
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root scheduler
**Audit:**
-Run the below command on the master node.
```bash
-stat -c %n\ %a /var/lib/rancher/k3s/server/tls/*.key
+/bin/sh -c 'if test -e scheduler; then stat -c %U:%G scheduler; fi'
```
-Verify that the permissions are `600` or more restrictive.
+**Expected Result**:
+
+```console
+'root:root' is not present
+```
+
+### 1.1.17 Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s creates the files with the expected permissions of `600`. No manual remediation is needed.
-
-
-### 1.2 API Server
-This section contains recommendations relating to API server configuration flags
-
-
-#### 1.2.1
-Ensure that the `--anonymous-auth` argument is set to false (Not Scored)
-
-
-Rationale
-When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. You should rely on authentication to authorize access and disallow anonymous requests.
-
-If you are using RBAC authorization, it is generally considered reasonable to allow anonymous access to the API Server for health checks and discovery purposes, and hence this recommendation is not scored. However, you should consider whether anonymous discovery is an acceptable risk for your purposes.
-
-
-**Result:** Pass
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod 644 controllermanager
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "anonymous-auth"
+/bin/sh -c 'if test -e controllermanager; then stat -c permissions=%a controllermanager; fi'
```
-Verify that `--anonymous-auth=false` is present.
+**Expected Result**:
+
+```console
+'permissions' is not present
+```
+
+### 1.1.18 Ensure that the controller-manager.conf file ownership is set to root:root (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s kube-apiserver is configured to run with this flag and value. No manual remediation is needed.
-
-#### 1.2.2
-Ensure that the `--basic-auth-file` argument is not set (Scored)
-
-Rationale
-Basic authentication uses plaintext credentials for authentication. Currently, the basic authentication credentials last indefinitely, and the password cannot be changed without restarting the API server. The basic authentication is currently supported for convenience. Hence, basic authentication should not be used.
-
-
-**Result:** Pass
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown root:root controllermanager
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "basic-auth-file"
+stat -c %U:%G /var/lib/rancher/k3s/server/tls
```
-Verify that the `--basic-auth-file` argument does not exist.
+**Expected Result**:
+
+```console
+'root:root' is equal to 'root:root'
+```
+
+**Returned Value**:
+
+```console
+root:root
+```
+
+### 1.1.19 Ensure that the Kubernetes PKI directory and file ownership is set to root:root (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s does not run with basic authentication enabled. No manual remediation is needed.
-
-
-#### 1.2.3
-Ensure that the `--token-auth-file` parameter is not set (Scored)
-
-
-Rationale
-The token-based authentication utilizes static tokens to authenticate requests to the apiserver. The tokens are stored in clear-text in a file on the apiserver, and cannot be revoked or rotated without restarting the apiserver. Hence, do not use static token-based authentication.
-
-
-**Result:** Pass
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chown -R root:root /etc/kubernetes/pki/
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "token-auth-file"
+find /etc/kubernetes/pki/ | xargs stat -c %U:%G
```
-Verify that the `--token-auth-file` argument does not exist.
+**Expected Result**:
+
+```console
+'root:root' is not present
+```
+
+### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive (Manual)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s does not run with basic authentication enabled. No manual remediation is needed.
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod -R 644 /etc/kubernetes/pki/*.crt
-#### 1.2.4
-Ensure that the `--kubelet-https` argument is set to true (Scored)
+**Audit:**
+
+```bash
+stat -c %n %a /var/lib/rancher/k3s/server/tls/*.crt
+```
+
+**Expected Result**:
+
+```console
+'permissions' is not present
+```
+
+### 1.1.21 Ensure that the Kubernetes PKI key file permissions are set to 600 (Manual)
+
+
+**Result:** pass
+
+**Remediation:**
+Run the below command (based on the file location on your system) on the master node.
+For example,
+chmod -R 600 /etc/kubernetes/pki/*.key
+
+**Audit:**
+
+```bash
+stat -c %n %a /var/lib/rancher/k3s/server/tls/*.key
+```
+
+**Expected Result**:
+
+```console
+'permissions' is not present
+```
+
+## 1.2 API Server
+### 1.2.1 Ensure that the --anonymous-auth argument is set to false (Manual)
+
+
+**Result:** warn
+
+**Remediation:**
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the below parameter.
+--anonymous-auth=false
+
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'anonymous-auth'
+```
+
+### 1.2.2 Ensure that the --basic-auth-file argument is not set (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Follow the documentation and configure alternate mechanisms for authentication. Then,
+edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and remove the --basic-auth-file= parameter.
+
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'basic-auth-file'
+```
+
+**Expected Result**:
+
+```console
+'--basic-auth-file' is not present
+```
+
+### 1.2.3 Ensure that the --token-auth-file parameter is not set (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Follow the documentation and configure alternate mechanisms for authentication. Then,
+edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and remove the --token-auth-file= parameter.
+
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'token-auth-file'
+```
+
+**Expected Result**:
+
+```console
+'--token-auth-file' is not present
+```
+
+### 1.2.4 Ensure that the --kubelet-https argument is set to true (Automated)
-
-Rationale
-Connections from apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets.
-
**Result:** Not Applicable
+**Remediation:**
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and remove the --kubelet-https parameter.
+
+### 1.2.5 Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Follow the Kubernetes documentation and set up the TLS connection between the
+apiserver and kubelets. Then, edit API server pod specification file
+/etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
+kubelet client certificate and key parameters as below.
+--kubelet-client-certificate=
+--kubelet-client-key=
+
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "kubelet-https"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'kubelet-certificate-authority'
```
-Verify that the `--kubelet-https` argument does not exist.
+**Expected Result**:
+
+```console
+'--kubelet-client-certificate' is not present AND '--kubelet-client-key' is not present
+```
+
+### 1.2.6 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s kube-apiserver doesn't run with the `--kubelet-https` parameter as it runs with TLS. No manual remediation is needed.
-
-#### 1.2.5
-Ensure that the `--kubelet-client-certificate` and `--kubelet-client-key` arguments are set as appropriate (Scored)
-
-
-Rationale
-The apiserver, by default, does not authenticate itself to the kubelet's HTTPS endpoints. The requests from the apiserver are treated anonymously. You should set up certificate-based kubelet authentication to ensure that the apiserver authenticates itself to kubelets when submitting requests.
-
-
-**Result:** Pass
+Follow the Kubernetes documentation and setup the TLS connection between
+the apiserver and kubelets. Then, edit the API server pod specification file
+/etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
+--kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
+--kubelet-certificate-authority=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep -E 'kubelet-client-certificate|kubelet-client-key'
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'kubelet-certificate-authority'
```
-Verify that the `--kubelet-client-certificate` and `--kubelet-client-key` arguments exist and they are set as appropriate.
+**Expected Result**:
+
+```console
+'--kubelet-certificate-authority' is not present
+```
+
+### 1.2.7 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s kube-apiserver is ran with these arguments for secure communication with kubelet. No manual remediation is needed.
-
-
-#### 1.2.6
-Ensure that the `--kubelet-certificate-authority` argument is set as appropriate (Scored)
-
-Rationale
-The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --authorization-mode parameter to values other than AlwaysAllow.
+One such example could be as below.
+--authorization-mode=RBAC
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "kubelet-certificate-authority"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'
```
-Verify that the `--kubelet-certificate-authority` argument exists and is set as appropriate.
+**Expected Result**:
+
+```console
+'--authorization-mode' is not present
+```
+
+### 1.2.8 Ensure that the --authorization-mode argument includes Node (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s kube-apiserver is ran with this argument for secure communication with kubelet. No manual remediation is needed.
-
-
-#### 1.2.7
-Ensure that the `--authorization-mode` argument is not set to `AlwaysAllow` (Scored)
-
-Rationale
-The API Server, can be configured to allow all requests. This mode should not be used on any production cluster.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --authorization-mode parameter to a value that includes Node.
+--authorization-mode=Node,RBAC
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "authorization-mode"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'
```
-Verify that the argument value doesn't contain `AlwaysAllow`.
+**Expected Result**:
+
+```console
+'--authorization-mode' is not present
+```
+
+### 1.2.9 Ensure that the --authorization-mode argument includes RBAC (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets `Node,RBAC` as the parameter to the `--authorization-mode` argument. No manual remediation is needed.
-
-
-#### 1.2.8
-Ensure that the `--authorization-mode` argument includes `Node` (Scored)
-
-Rationale
-The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --authorization-mode parameter to a value that includes RBAC,
+for example:
+--authorization-mode=Node,RBAC
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "authorization-mode"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'
```
-Verify `Node` exists as a parameter to the argument.
+**Expected Result**:
+
+```console
+'--authorization-mode' is not present
+```
+
+### 1.2.10 Ensure that the admission control plugin EventRateLimit is set (Manual)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets `Node,RBAC` as the parameter to the `--authorization-mode` argument. No manual remediation is needed.
-
-
-#### 1.2.9
-Ensure that the `--authorization-mode` argument includes `RBAC` (Scored)
-
-Rationale
-Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorization mode.
-
-
-**Result:** Pass
+Follow the Kubernetes documentation and set the desired limits in a configuration file.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+and set the below parameters.
+--enable-admission-plugins=...,EventRateLimit,...
+--admission-control-config-file=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "authorization-mode"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'
```
-Verify `RBAC` exists as a parameter to the argument.
+**Expected Result**:
+
+```console
+'--enable-admission-plugins' is not present
+```
+
+### 1.2.11 Ensure that the admission control plugin AlwaysAdmit is not set (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets `Node,RBAC` as the parameter to the `--authorization-mode` argument. No manual remediation is needed.
-
-
-#### 1.2.10
-Ensure that the admission control plugin EventRateLimit is set (Not Scored)
-
-Rationale
-Using `EventRateLimit` admission control enforces a limit on the number of events that the API Server will accept in a given time slice. A misbehaving workload could overwhelm and DoS the API Server, making it unavailable. This particularly applies to a multi-tenant cluster, where there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. Hence, it is recommended to limit the rate of events that the API server will accept.
-
-Note: This is an Alpha feature in the Kubernetes 1.15 release.
-
-
-**Result:** **Not Scored - Operator Dependent**
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and either remove the --enable-admission-plugins parameter, or set it to a
+value that does not include AlwaysAdmit.
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "enable-admission-plugins"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'
```
-Verify that the `--enable-admission-plugins` argument is set to a value that includes EventRateLimit.
+**Expected Result**:
+
+```console
+'--enable-admission-plugins' is not present OR '--enable-admission-plugins' is not present
+```
+
+### 1.2.12 Ensure that the admission control plugin AlwaysPullImages is set (Manual)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s only sets `NodeRestriction,PodSecurityPolicy` as the parameter to the `--enable-admission-plugins` argument.
-To configure this, follow the Kubernetes documentation and set the desired limits in a configuration file. Then refer to K3s's documentation to see how to supply additional api server configuration via the kube-apiserver-arg parameter.
-
-
-#### 1.2.11
-Ensure that the admission control plugin `AlwaysAdmit` is not set (Scored)
-
-Rationale
-Setting admission control plugin AlwaysAdmit allows all requests and do not filter any requests.
-
-The AlwaysAdmit admission controller was deprecated in Kubernetes v1.13. Its behavior was equivalent to turning off all admission controllers.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --enable-admission-plugins parameter to include
+AlwaysPullImages.
+--enable-admission-plugins=...,AlwaysPullImages,...
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "enable-admission-plugins"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'
```
-Verify that if the `--enable-admission-plugins` argument is set, its value does not include `AlwaysAdmit`.
+**Expected Result**:
+
+```console
+'--enable-admission-plugins' is not present
+```
+
+### 1.2.13 Ensure that the admission control plugin SecurityContextDeny is set if PodSecurityPolicy is not used (Manual)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s only sets `NodeRestriction,PodSecurityPolicy` as the parameter to the `--enable-admission-plugins` argument. No manual remediation needed.
-
-
-#### 1.2.12
-Ensure that the admission control plugin AlwaysPullImages is set (Not Scored)
-
-Rationale
-Setting admission control policy to `AlwaysPullImages` forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required.
-
-
-
-**Result:** **Not Scored - Operator Dependent**
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --enable-admission-plugins parameter to include
+SecurityContextDeny, unless PodSecurityPolicy is already in place.
+--enable-admission-plugins=...,SecurityContextDeny,...
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "enable-admission-plugins"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'
```
-Verify that the `--enable-admission-plugins` argument is set to a value that includes `AlwaysPullImages`.
+**Expected Result**:
+
+```console
+'--enable-admission-plugins' is not present OR '--enable-admission-plugins' is not present
+```
+
+### 1.2.14 Ensure that the admission control plugin ServiceAccount is set (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s only sets `NodeRestriction,PodSecurityPolicy` as the parameter to the `--enable-admission-plugins` argument.
-To configure this, follow the Kubernetes documentation and set the desired limits in a configuration file. Then refer to K3s's documentation to see how to supply additional api server configuration via the kube-apiserver-arg parameter.
-
-#### 1.2.13
-Ensure that the admission control plugin SecurityContextDeny is set if PodSecurityPolicy is not used (Not Scored)
-
-Rationale
-SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled.
-
-
-**Result:** Not Scored
+Follow the documentation and create ServiceAccount objects as per your environment.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and ensure that the --disable-admission-plugins parameter is set to a
+value that does not include ServiceAccount.
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "enable-admission-plugins"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'ServiceAccount'
```
-Verify that the `--enable-admission-plugins` argument is set to a value that includes `SecurityContextDeny`, if `PodSecurityPolicy` is not included.
+**Expected Result**:
+
+```console
+'--disable-admission-plugins' is not present OR '--disable-admission-plugins' is not present
+```
+
+### 1.2.15 Ensure that the admission control plugin NamespaceLifecycle is set (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s would need to have the `SecurityContextDeny` admission plugin enabled by passing it as an argument to K3s. `--kube-apiserver-arg='enable-admission-plugins=SecurityContextDeny`
-
-
-#### 1.2.14
-Ensure that the admission control plugin `ServiceAccount` is set (Scored)
-
-Rationale
-When you create a pod, if you do not specify a service account, it is automatically assigned the `default` service account in the same namespace. You should create your own service account and let the API server manage its security tokens.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --disable-admission-plugins parameter to
+ensure it does not include NamespaceLifecycle.
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "ServiceAccount"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'disable-admission-plugins'
```
-Verify that the `--disable-admission-plugins` argument is set to a value that does not includes `ServiceAccount`.
+**Expected Result**:
+
+```console
+'--disable-admission-plugins' is not present OR '--disable-admission-plugins' is not present
+```
+
+### 1.2.16 Ensure that the admission control plugin PodSecurityPolicy is set (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s does not use this argument. If there's a desire to use this argument, follow the documentation and create ServiceAccount objects as per your environment. Then refer to K3s's documentation to see how to supply additional api server configuration via the kube-apiserver-arg parameter.
-
-
-#### 1.2.15
-Ensure that the admission control plugin `NamespaceLifecycle` is set (Scored)
-
-Rationale
-Setting admission control policy to `NamespaceLifecycle` ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects.
-
-
-**Result:** Pass
+Follow the documentation and create Pod Security Policy objects as per your environment.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --enable-admission-plugins parameter to a
+value that includes PodSecurityPolicy:
+--enable-admission-plugins=...,PodSecurityPolicy,...
+Then restart the API Server.
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "disable-admission-plugins"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'
```
-Verify that the `--disable-admission-plugins` argument is set to a value that does not include `NamespaceLifecycle`.
+**Expected Result**:
+
+```console
+'--enable-admission-plugins' is not present
+```
+
+### 1.2.17 Ensure that the admission control plugin NodeRestriction is set (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s does not use this argument. No manual remediation needed.
-
-
-#### 1.2.16
-Ensure that the admission control plugin `PodSecurityPolicy` is set (Scored)
-
-Rationale
-A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The `PodSecurityPolicy` objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions.
-
-**Note:** When the PodSecurityPolicy admission plugin is in use, there needs to be at least one PodSecurityPolicy in place for ANY pods to be admitted. See section 1.7 for recommendations on PodSecurityPolicy settings.
-
-
-**Result:** Pass
+Follow the Kubernetes documentation and configure NodeRestriction plug-in on kubelets.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --enable-admission-plugins parameter to a
+value that includes NodeRestriction.
+--enable-admission-plugins=...,NodeRestriction,...
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "enable-admission-plugins"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'
```
-Verify that the `--enable-admission-plugins` argument is set to a value that includes `PodSecurityPolicy`.
+**Expected Result**:
+
+```console
+'--enable-admission-plugins' is not present
+```
+
+### 1.2.18 Ensure that the --insecure-bind-address argument is not set (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s would need to have the `PodSecurityPolicy` admission plugin enabled by passing it as an argument to K3s. `--kube-apiserver-arg='enable-admission-plugins=PodSecurityPolicy`.
-
-
-#### 1.2.17
-Ensure that the admission control plugin `NodeRestriction` is set (Scored)
-
-Rationale
-Using the `NodeRestriction` plug-in ensures that the kubelet is restricted to the `Node` and `Pod` objects that it could modify as defined. Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node.
-
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and remove the --insecure-bind-address parameter.
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "enable-admission-plugins"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'insecure-bind-address'
```
-Verify that the `--enable-admission-plugins` argument is set to a value that includes `NodeRestriction`.
+**Expected Result**:
+
+```console
+'--insecure-bind-address' is not present
+```
+
+### 1.2.19 Ensure that the --insecure-port argument is set to 0 (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s would need to have the `NodeRestriction` admission plugin enabled by passing it as an argument to K3s. `--kube-apiserver-arg='enable-admission-plugins=NodeRestriction`.
-
-
-#### 1.2.18
-Ensure that the `--insecure-bind-address` argument is not set (Scored)
-
-Rationale
-If you bind the apiserver to an insecure address, basically anyone who could connect to it over the insecure port, would have unauthenticated and unencrypted access to your master node. The apiserver doesn't do any authentication checking for insecure binds and traffic to the Insecure API port is not encrpyted, allowing attackers to potentially read sensitive data in transit.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the below parameter.
+--insecure-port=0
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "insecure-bind-address"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'insecure-port'
```
-Verify that the `--insecure-bind-address` argument does not exist.
+**Expected Result**:
+
+```console
+'--insecure-port' is not present
+```
+
+### 1.2.20 Ensure that the --secure-port argument is not set to 0 (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s explicitly excludes the use of the `--insecure-bind-address` parameter. No manual remediation is needed.
-
-
-#### 1.2.19
-Ensure that the `--insecure-port` argument is set to `0` (Scored)
-
-Rationale
-Setting up the apiserver to serve on an insecure port would allow unauthenticated and unencrypted access to your master node. This would allow attackers who could access this port, to easily take control of the cluster.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and either remove the --secure-port parameter or
+set it to a different (non-zero) desired port.
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "insecure-port"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'secure-port'
```
-Verify that the `--insecure-port` argument is set to `0`.
+**Expected Result**:
+
+```console
+'--secure-port' is not present OR '--secure-port' is not present
+```
+
+### 1.2.21 Ensure that the --profiling argument is set to false (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s starts the kube-apiserver process with this argument's parameter set to `0`. No manual remediation is needed.
-
-
-#### 1.2.20
-Ensure that the `--secure-port` argument is not set to `0` (Scored)
-
-Rationale
-The secure port is used to serve https with authentication and authorization. If you disable it, no https traffic is served and all traffic is served unencrypted.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the below parameter.
+--profiling=false
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "secure-port"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'profiling'
```
-Verify that the `--secure-port` argument is either not set or is set to an integer value between 1 and 65535.
+**Expected Result**:
+
+```console
+'--profiling' is not present
+```
+
+### 1.2.22 Ensure that the --audit-log-path argument is set (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the parameter of 6444 for the `--secure-port` argument. No manual remediation is needed.
-
-
-#### 1.2.21
-Ensure that the `--profiling` argument is set to `false` (Scored)
-
-Rationale
-Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --audit-log-path parameter to a suitable path and
+file where you would like audit logs to be written, for example:
+--audit-log-path=/var/log/apiserver/audit.log
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "profiling"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'audit-log-path'
```
-Verify that the `--profiling` argument is set to false.
+**Expected Result**:
+
+```console
+'--audit-log-path' is not present
+```
+
+### 1.2.23 Ensure that the --audit-log-maxage argument is set to 30 or as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the `--profiling` flag parameter to false. No manual remediation needed.
-
-
-#### 1.2.22
-Ensure that the `--audit-log-path` argument is set (Scored)
-
-Rationale
-Auditing the Kubernetes API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators or other components of the system. Even though currently, Kubernetes provides only basic audit capabilities, it should be enabled. You can enable it by setting an appropriate audit log path.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --audit-log-maxage parameter to 30 or as an appropriate number of days:
+--audit-log-maxage=30
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "audit-log-path"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'audit-log-maxage'
```
-Verify that the `--audit-log-path` argument is set as appropriate.
+**Expected Result**:
+
+```console
+'--audit-log-maxage' is not present
+```
+
+### 1.2.24 Ensure that the --audit-log-maxbackup argument is set to 10 or as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following argument, `--kube-apiserver-arg='audit-log-path=/path/to/log/file'`.
-
-
-#### 1.2.23
-Ensure that the `--audit-log-maxage` argument is set to `30` or as appropriate (Scored)
-
-Rationale
-Retaining logs for at least 30 days ensures that you can go back in time and investigate or correlate any events. Set your audit log retention period to 30 days or as per your business requirements.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --audit-log-maxbackup parameter to 10 or to an appropriate
+value.
+--audit-log-maxbackup=10
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "audit-log-maxage"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'audit-log-maxbackup'
```
-Verify that the `--audit-log-maxage` argument is set to `30` or as appropriate.
+**Expected Result**:
+
+```console
+'--audit-log-maxbackup' is not present
+```
+
+### 1.2.25 Ensure that the --audit-log-maxsize argument is set to 100 or as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following argument, `--kube-apiserver-arg='audit-log-maxage=30'`.
-
-
-#### 1.2.24
-Ensure that the `--audit-log-maxbackup` argument is set to `10` or as appropriate (Scored)
-
-Rationale
-Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. For example, if you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --audit-log-maxsize parameter to an appropriate size in MB.
+For example, to set it as 100 MB:
+--audit-log-maxsize=100
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "audit-log-maxbackup"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'audit-log-maxsize'
```
-Verify that the `--audit-log-maxbackup` argument is set to `10` or as appropriate.
+**Expected Result**:
+
+```console
+'--audit-log-maxsize' is not present
+```
+
+### 1.2.26 Ensure that the --request-timeout argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following argument, `--kube-apiserver-arg='audit-log-maxbackup=10'`.
-
-
-#### 1.2.25
-Ensure that the `--audit-log-maxsize` argument is set to `100` or as appropriate (Scored)
-
-Rationale
-Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+and set the below parameter as appropriate and if needed.
+For example,
+--request-timeout=300s
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "audit-log-maxsize"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'request-timeout'
```
-Verify that the `--audit-log-maxsize` argument is set to `100` or as appropriate.
+**Expected Result**:
+
+```console
+'--request-timeout' is not present OR '--request-timeout' is not present
+```
+
+### 1.2.27 Ensure that the --service-account-lookup argument is set to true (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following argument, `--kube-apiserver-arg='audit-log-maxsize=100'`.
-
-
-#### 1.2.26
-Ensure that the `--request-timeout` argument is set as appropriate (Scored)
-
-Rationale
-Setting global request timeout allows extending the API server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 60 seconds which might be problematic on slower connections making cluster resources inaccessible once the data volume for requests exceeds what can be transmitted in 60 seconds. But, setting this timeout limit to be too large can exhaust the API server resources making it prone to Denial-of-Service attack. Hence, it is recommended to set this limit as appropriate and change the default limit of 60 seconds only if needed.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the below parameter.
+--service-account-lookup=true
+Alternatively, you can delete the --service-account-lookup parameter from this file so
+that the default takes effect.
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "request-timeout"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'service-account-lookup'
```
-Verify that the `--request-timeout` argument is either not set or set to an appropriate value.
+**Expected Result**:
+
+```console
+'--service-account-lookup' is not present OR '--service-account-lookup' is not present
+```
+
+### 1.2.28 Ensure that the --service-account-key-file argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s does not set the `--request-timeout` argument. No manual remediation needed.
-
-
-#### 1.2.27
-Ensure that the `--service-account-lookup` argument is set to `true` (Scored)
-
-Rationale
-If `--service-account-lookup` is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue.
-
-
-**Result:** Pass
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --service-account-key-file parameter
+to the public key file for service accounts:
+--service-account-key-file=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "service-account-lookup"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'service-account-key-file'
```
-Verify that if the `--service-account-lookup` argument exists it is set to `true`.
+**Expected Result**:
+
+```console
+'--service-account-key-file' is not present
+```
+
+### 1.2.29 Ensure that the --etcd-certfile and --etcd-keyfile arguments are set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following argument, `--kube-apiserver-arg='service-account-lookup=true'`.
+Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the etcd certificate and key file parameters.
+--etcd-certfile=
+--etcd-keyfile=
-
-#### 1.2.28
-Ensure that the `--service-account-key-file` argument is set as appropriate (Scored)
-
-Rationale
-By default, if no `--service-account-key-file` is specified to the apiserver, it uses the private key from the TLS serving certificate to verify service account tokens. To ensure that the keys for service account tokens could be rotated as needed, a separate public/private key pair should be used for signing service account tokens. Hence, the public key should be specified to the apiserver with `--service-account-key-file`.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
+**Audit Script:** `check_for_k3s_etcd.sh`
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "service-account-key-file"
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
```
-Verify that the `--service-account-key-file` argument exists and is set as appropriate.
-
-**Remediation:**
-By default, K3s sets the `--service-account-key-file` explicitly. No manual remediation needed.
-
-
-#### 1.2.29
-Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a client certificate and key.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
+**Audit Execution:**
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep -E 'etcd-certfile|etcd-keyfile'
+./check_for_k3s_etcd.sh 1.2.29
```
-Verify that the `--etcd-certfile` and `--etcd-keyfile` arguments exist and they are set as appropriate.
+**Expected Result**:
+
+```console
+'--etcd-certfile' is present AND '--etcd-keyfile' is present
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:24 k3s[5223]: time="2022-02-21T23:13:24.847339487Z" level=info msg="Running kube-apiserver --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit-log --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --enable-admission-plugins=NodeRestriction,PodSecurityPolicy,NamespaceLifecycle,ServiceAccount --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --insecure-port=0 --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --request-timeout=300s --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-lookup=true --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
+```
+
+### 1.2.30 Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the `--etcd-certfile` and `--etcd-keyfile` arguments explicitly. No manual remediation needed.
-
-
-#### 1.2.30
-Ensure that the `--tls-cert-file` and `--tls-private-key-file` arguments are set as appropriate (Scored)
-
-Rationale
-API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic.
-
-
-**Result:** Pass
+Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the TLS certificate and private key file parameters.
+--tls-cert-file=
+--tls-private-key-file=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep -E 'tls-cert-file|tls-private-key-file'
+journalctl -D /var/log/journal -u k3s | grep -A1 'Running kube-apiserver' | tail -n2
```
-Verify that the `--tls-cert-file` and `--tls-private-key-file` arguments exist and they are set as appropriate.
+**Expected Result**:
+
+```console
+'--tls-cert-file' is present AND '--tls-private-key-file' is present
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:24 k3s[5223]: time="2022-02-21T23:13:24.847339487Z" level=info msg="Running kube-apiserver --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit-log --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --enable-admission-plugins=NodeRestriction,PodSecurityPolicy,NamespaceLifecycle,ServiceAccount --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --insecure-port=0 --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --request-timeout=300s --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-lookup=true --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key" Feb 21 23:13:24 k3s[5223]: {"level":"info","ts":"2022-02-21T23:13:24.848Z","caller":"raft/raft.go:1530","msg":"b3656202b34887ca switched to configuration voters=(12926846069174208458)"}
+```
+
+### 1.2.31 Ensure that the --client-ca-file argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the `--tls-cert-file` and `--tls-private-key-file` arguments explicitly. No manual remediation needed.
-
-
-#### 1.2.31
-Ensure that the `--client-ca-file` argument is set as appropriate (Scored)
-
-Rationale
-API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic. If `--client-ca-file` argument is set, any request presenting a client certificate signed by one of the authorities in the `client-ca-file` is authenticated with an identity corresponding to the CommonName of the client certificate.
-
-
-**Result:** Pass
+Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the client certificate authority file.
+--client-ca-file=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "client-ca-file"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'client-ca-file'
```
-Verify that the `--client-ca-file` argument exists and it is set as appropriate.
+**Expected Result**:
+
+```console
+'--client-ca-file' is not present
+```
+
+### 1.2.32 Ensure that the --etcd-cafile argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the `--client-ca-file` argument explicitly. No manual remediation needed.
-
-
-#### 1.2.32
-Ensure that the `--etcd-cafile` argument is set as appropriate (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a SSL Certificate Authority file.
-
-
-**Result:** Pass
+Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the etcd certificate authority file parameter.
+--etcd-cafile=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "etcd-cafile"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-cafile'
```
-Verify that the `--etcd-cafile` argument exists and it is set as appropriate.
+**Expected Result**:
+
+```console
+'--etcd-cafile' is not present
+```
+
+### 1.2.33 Ensure that the --encryption-provider-config argument is set as appropriate (Manual)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the `--etcd-cafile` argument explicitly. No manual remediation needed.
-
-
-#### 1.2.33
-Ensure that the `--encryption-provider-config` argument is set as appropriate (Scored)
-
-Rationale
-etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures.
-
-
-**Result:** Pass
+Follow the Kubernetes documentation and configure a EncryptionConfig file.
+Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the --encryption-provider-config parameter to the path of that file: --encryption-provider-config=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "encryption-provider-config"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'encryption-provider-config'
```
-Verify that the `--encryption-provider-config` argument is set to a EncryptionConfigfile. Additionally, ensure that the `EncryptionConfigfile` has all the desired resources covered especially any secrets.
+**Expected Result**:
+
+```console
+'--encryption-provider-config' is not present
+```
+
+### 1.2.34 Ensure that encryption providers are appropriately configured (Manual)
+
+
+**Result:** warn
**Remediation:**
-K3s server needs to be ran with the follow, `--kube-apiserver-arg='encryption-provider-config=/path/to/encryption_config'`. This can be done by running k3s with the `--secrets-encryptiuon` argument which will configure the encryption provider.
-
-
-#### 1.2.34
-Ensure that encryption providers are appropriately configured (Scored)
-
-Rationale
-Where `etcd` encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, the `aescbc`, `kms` and `secretbox` are likely to be appropriate options.
-
-
-**Result:** Pass
-
-**Remediation:**
-Follow the Kubernetes documentation and configure a `EncryptionConfig` file.
-In this file, choose **aescbc**, **kms** or **secretbox** as the encryption provider.
+Follow the Kubernetes documentation and configure a EncryptionConfig file.
+In this file, choose aescbc, kms or secretbox as the encryption provider.
**Audit:**
-Run the below command on the master node.
```bash
grep aescbc /path/to/encryption-config.json
```
-Run the below command on the master node.
-
-Verify that aescbc is set as the encryption provider for all the desired resources.
-
-**Remediation**
-K3s server needs to be run with the following, `--secrets-encryption=true`, and verify that one of the allowed encryption providers is present.
+### 1.2.35 Ensure that the API Server only makes use of Strong Cryptographic Ciphers (Manual)
-#### 1.2.35
-Ensure that the API Server only makes use of Strong Cryptographic Ciphers (Not Scored)
+**Result:** pass
-
-Rationale
-TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS cipher suites including some that have security concerns, weakening the protection provided.
-
-
-**Result:** **Not Scored - Operator Dependent**
+**Remediation:**
+Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
+on the master node and set the below parameter.
+--tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM
+_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM
+_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM
+_SHA384
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "tls-cipher-suites"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'tls-cipher-suites'
```
-Verify that the `--tls-cipher-suites` argument is set as outlined in the remediation procedure below.
+**Expected Result**:
+
+```console
+'--tls-cipher-suites' is not present
+```
+
+## 1.3 Controller Manager
+### 1.3.1 Ensure that the --terminated-pod-gc-threshold argument is set as appropriate (Manual)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s explicitly doesn't set this flag. No manual remediation needed.
-
-
-### 1.3 Controller Manager
-
-#### 1.3.1
-Ensure that the `--terminated-pod-gc-threshold` argument is set as appropriate (Not Scored)
-
-Rationale
-Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. The current setting for garbage collection is 12,500 terminated pods which might be too high for your system to sustain. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
-
-
-**Result:** **Not Scored - Operator Dependent**
+Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
+on the master node and set the --terminated-pod-gc-threshold to an appropriate threshold,
+for example:
+--terminated-pod-gc-threshold=10
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-controller-manager" | tail -n1 | grep "terminated-pod-gc-threshold
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'terminated-pod-gc-threshold'
```
-Verify that the `--terminated-pod-gc-threshold` argument is set as appropriate.
+**Expected Result**:
+
+```console
+'--terminated-pod-gc-threshold' is not present
+```
+
+### 1.3.2 Ensure that the --profiling argument is set to false (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following, `--kube-controller-manager-arg='terminated-pod-gc-threshold=10`.
-
-
-#### 1.3.2
-Ensure that the `--profiling` argument is set to false (Scored)
-
-Rationale
-Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface.
-
-
-**Result:** Pass
+Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
+on the master node and set the below parameter.
+--profiling=false
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-controller-manager" | tail -n1 | grep "profiling"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'profiling'
```
-Verify that the `--profiling` argument is set to false.
+**Expected Result**:
+
+```console
+'--profiling' is not present
+```
+
+### 1.3.3 Ensure that the --use-service-account-credentials argument is set to true (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the `--profiling` flag parameter to false. No manual remediation needed.
-
-
-#### 1.3.3
-Ensure that the `--use-service-account-credentials` argument is set to `true` (Scored)
-
-Rationale
-The controller manager creates a service account per controller in the `kube-system` namespace, generates a credential for it, and builds a dedicated API client with that service account credential for each controller loop to use. Setting the `--use-service-account-credentials` to `true` runs each control loop within the controller manager using a separate service account credential. When used in combination with RBAC, this ensures that the control loops run with the minimum permissions required to perform their intended tasks.
-
-
-**Result:** Pass
+Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
+on the master node to set the below parameter.
+--use-service-account-credentials=true
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-controller-manager" | tail -n1 | grep "use-service-account-credentials"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'use-service-account-credentials'
```
-Verify that the `--use-service-account-credentials` argument is set to true.
+**Expected Result**:
+
+```console
+'--use-service-account-credentials' is not present
+```
+
+### 1.3.4 Ensure that the --service-account-private-key-file argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following, `--kube-controller-manager-arg='use-service-account-credentials=true'`
-
-
-#### 1.3.4
-Ensure that the `--service-account-private-key-file` argument is set as appropriate (Scored)
-
-Rationale
-To ensure that keys for service account tokens can be rotated as needed, a separate public/private key pair should be used for signing service account tokens. The private key should be specified to the controller manager with `--service-account-private-key-file` as appropriate.
-
-
-**Result:** Pass
+Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
+on the master node and set the --service-account-private-key-file parameter
+to the private key file for service accounts.
+--service-account-private-key-file=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-controller-manager" | tail -n1 | grep "service-account-private-key-file"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'service-account-private-key-file'
```
-Verify that the `--service-account-private-key-file` argument is set as appropriate.
+**Expected Result**:
+
+```console
+'--service-account-private-key-file' is not present
+```
+
+### 1.3.5 Ensure that the --root-ca-file argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s sets the `--service-account-private-key-file` argument with the service account key file. No manual remediation needed.
-
-
-#### 1.3.5
-Ensure that the `--root-ca-file` argument is set as appropriate (Scored)
-
-Rationale
-Processes running within pods that need to contact the API server must verify the API server's serving certificate. Failing to do so could be a subject to man-in-the-middle attacks.
-
-Providing the root certificate for the API server's serving certificate to the controller manager with the `--root-ca-file` argument allows the controller manager to inject the trusted bundle into pods so that they can verify TLS connections to the API server.
-
-
-**Result:** Pass
+Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
+on the master node and set the --root-ca-file parameter to the certificate bundle file`.
+--root-ca-file=
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-controller-manager" | tail -n1 | grep "root-ca-file"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'root-ca-file'
```
-Verify that the `--root-ca-file` argument exists and is set to a certificate bundle file containing the root certificate for the API server's serving certificate
+**Expected Result**:
-**Remediation:**
-By default, K3s sets the `--root-ca-file` argument with the root ca file. No manual remediation needed.
-
-
-#### 1.3.6
-Ensure that the `RotateKubeletServerCertificate` argument is set to `true` (Scored)
-
-Rationale
-`RotateKubeletServerCertificate` causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad.
-
-Note: This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself.
-
-
-**Result:** Not Applicable
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-journalctl -u k3s | grep "Running kube-controller-manager" | tail -n1 | grep "RotateKubeletServerCertificate"
+```console
+'--root-ca-file' is not present
```
-Verify that RotateKubeletServerCertificateargument exists and is set to true.
+### 1.3.6 Ensure that the RotateKubeletServerCertificate argument is set to true (Automated)
-**Remediation:**
-By default, K3s implements its own logic for certificate generation and rotation.
-
-
-#### 1.3.7
-Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
-
-Rationale
-The Controller Manager API service which runs on port 10252/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-journalctl -u k3s | grep "Running kube-controller-manager" | tail -n1 | grep "bind-address"
-```
-
-Verify that the `--bind-address` argument is set to 127.0.0.1.
-
-**Remediation:**
-By default, K3s sets the `--bind-address` argument to `127.0.0.1`. No manual remediation needed.
-
-
-### 1.4 Scheduler
-This section contains recommendations relating to Scheduler configuration flags
-
-
-#### 1.4.1
-Ensure that the `--profiling` argument is set to `false` (Scored)
-
-Rationale
-Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-journalctl -u k3s | grep "Running kube-scheduler" | tail -n1 | grep "profiling"
-```
-
-Verify that the `--profiling` argument is set to false.
-
-**Remediation:**
-By default, K3s sets the `--profiling` flag parameter to false. No manual remediation needed.
-
-
-#### 1.4.2
-Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
-
-Rationale
-
-The Scheduler API service which runs on port 10251/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-journalctl -u k3s | grep "Running kube-scheduler" | tail -n1 | grep "bind-address"
-```
-
-Verify that the `--bind-address` argument is set to 127.0.0.1.
-
-**Remediation:**
-By default, K3s sets the `--bind-address` argument to `127.0.0.1`. No manual remediation needed.
-
-
-## 2 Etcd Node Configuration
-This section covers recommendations for etcd configuration.
-
-#### 2.1
-Ensure that the `cert-file` and `key-file` fields are set as appropriate (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted in transit.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-grep -E 'cert-file|key-file' /var/lib/rancher/k3s/server/db/etcd/config
-```
-
-Verify that the `cert-file` and the `key-file` fields are set as appropriate.
-
-**Remediation:**
-By default, K3s uses a config file for etcd that can be found at `/var/lib/rancher/k3s/server/db/etcd/config`. Server and peer cert and key files are specified. No manual remediation needed.
-
-
-#### 2.2
-Ensure that the `client-cert-auth` field is set to `true` (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should not be available to unauthenticated clients. You should enable the client authentication via valid certificates to secure the access to the etcd service.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-grep 'client-cert-auth' /var/lib/rancher/k3s/server/db/etcd/config
-```
-
-Verify that the `client-cert-auth` field is set to true.
-
-**Remediation:**
-By default, K3s uses a config file for etcd that can be found at `/var/lib/rancher/k3s/server/db/etcd/config`. `client-cert-auth` is set to true. No manual remediation needed.
-
-
-#### 2.3
-Ensure that the `auto-tls` field is not set to `true` (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should not be available to unauthenticated clients. You should enable the client authentication via valid certificates to secure the access to the etcd service.
-
-
-**Result:** Pass
-
-**Remediation:**
-By default, K3s starts Etcd without this flag. It is set to `false` by default.
-
-
-#### 2.4
-Ensure that the `peer-cert-file` and `peer-key-file` fields are set as appropriate (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted in transit and also amongst peers in the etcd clusters.
-
-
-**Result:** Pass
-
-**Remediation:**
-By default, K3s starts Etcd with a config file found here, `/var/lib/rancher/k3s/server/db/etcd/config`. The config file contains `peer-transport-security:` which has fields that have the peer cert and peer key files.
-
-
-#### 2.5
-Ensure that the `client-cert-auth` field is set to `true` (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be accessible only by authenticated etcd peers in the etcd cluster.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-grep 'client-cert-auth' /var/lib/rancher/k3s/server/db/etcd/config
-```
-
-Verify that the `client-cert-auth` field in the peer section is set to true.
-
-**Remediation:**
-By default, K3s uses a config file for etcd that can be found at `/var/lib/rancher/k3s/server/db/etcd/config`. Within the file, the `client-cert-auth` field is set. No manual remediation needed.
-
-
-#### 2.6
-Ensure that the `peer-auto-tls` field is not set to `true` (Scored)
-
-Rationale
-etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be accessible only by authenticated etcd peers in the etcd cluster. Hence, do not use self- signed certificates for authentication.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config
-```
-
-Verify that if the `peer-auto-tls` field does not exist.
-
-**Remediation:**
-By default, K3s uses a config file for etcd that can be found at `/var/lib/rancher/k3s/server/db/etcd/config`. Within the file, it does not contain the `peer-auto-tls` field. No manual remediation needed.
-
-
-#### 2.7
-Ensure that a unique Certificate Authority is used for etcd (Not Scored)
-
-Rationale
-etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. Its access should be restricted to specifically designated clients and peers only.
-
-Authentication to etcd is based on whether the certificate presented was issued by a trusted certificate authority. There is no checking of certificate attributes such as common name or subject alternative name. As such, if any attackers were able to gain access to any certificate issued by the trusted certificate authority, they would be able to gain full access to the etcd database.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-# To find the ca file used by etcd:
-grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config
-# To find the kube-apiserver process:
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1
-```
-
-Verify that the file referenced by the `client-ca-file` flag in the apiserver process is different from the file referenced by the `trusted-ca-file` parameter in the etcd configuration file.
-
-**Remediation:**
-By default, K3s uses a config file for etcd that can be found at `/var/lib/rancher/k3s/server/db/etcd/config` and the `trusted-ca-file` parameters in it are set to unique values specific to etcd. No manual remediation needed.
-
-
-
-## 3 Control Plane Configuration
-
-
-### 3.1 Authentication and Authorization
-
-
-#### 3.1.1
-Client certificate authentication should not be used for users (Not Scored)
-
-Rationale
-With any authentication mechanism the ability to revoke credentials if they are compromised or no longer required, is a key control. Kubernetes client certificate authentication does not allow for this due to a lack of support for certificate revocation.
-
-
-**Result:** Not Scored - Operator Dependent
-
-**Audit:**
-Review user access to the cluster and ensure that users are not making use of Kubernetes client certificate authentication.
-
-**Remediation:**
-Alternative mechanisms provided by Kubernetes such as the use of OIDC should be implemented in place of client certificates.
-
-### 3.2 Logging
-
-
-#### 3.2.1
-Ensure that a minimal audit policy is created (Scored)
-
-Rationale
-Logging is an important detective control for all systems, to detect potential unauthorized access.
-
-
-**Result:** Does not pass. See the [Hardening Guide](../hardening_guide/) for details.
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "audit-policy-file"
-```
-
-Verify that the `--audit-policy-file` is set. Review the contents of the file specified and ensure that it contains a valid audit policy.
-
-**Remediation:**
-Create an audit policy file for your cluster and pass it to k3s. e.g. `--kube-apiserver-arg='audit-log-path=/var/lib/rancher/k3s/server/logs/audit-log'`
-
-
-#### 3.2.2
-Ensure that the audit policy covers key security concerns (Not Scored)
-
-Rationale
-Security audit logs should cover access and modification of key resources in the cluster, to enable them to form an effective part of a security environment.
-
-
-**Result:** Not Scored - Operator Dependent
-
-**Remediation:**
-
-
-## 4 Worker Node Security Configuration
-
-
-### 4.1 Worker Node Configuration Files
-
-
-#### 4.1.1
-Ensure that the kubelet service file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The `kubelet` service file controls various parameters that set the behavior of the kubelet service in the worker node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
**Result:** Not Applicable
**Remediation:**
-K3s doesn’t launch the kubelet as a service. It is launched and managed by the K3s supervisor process. All configuration is passed to it as command line arguments at run time.
+Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
+on the master node and set the --feature-gates parameter to include RotateKubeletServerCertificate=true.
+--feature-gates=RotateKubeletServerCertificate=true
+
+### 1.3.7 Ensure that the --bind-address argument is set to 127.0.0.1 (Automated)
-#### 4.1.2
-Ensure that the kubelet service file ownership is set to `root:root` (Scored)
-
-Rationale
-The `kubelet` service file controls various parameters that set the behavior of the kubelet service in the worker node. You should set its file ownership to maintain the integrity of the file. The file should be owned by `root:root`.
-
+**Result:** pass
+
+**Remediation:**
+Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
+on the master node and ensure the correct value for the --bind-address parameter
+
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'bind-address'
+```
+
+**Expected Result**:
+
+```console
+'--bind-address' is present OR '--bind-address' is not present
+```
+
+## 1.4 Scheduler
+### 1.4.1 Ensure that the --profiling argument is set to false (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml file
+on the master node and set the below parameter.
+--profiling=false
+
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-scheduler' | tail -n1
+```
+
+**Expected Result**:
+
+```console
+'false' is equal to 'false'
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:24 k3s[5223]: time="2022-02-21T23:13:24.851975832Z" level=info msg="Running kube-scheduler --address=127.0.0.1 --bind-address=127.0.0.1 --kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --port=10251 --profiling=false --secure-port=0"
+```
+
+### 1.4.2 Ensure that the --bind-address argument is set to 127.0.0.1 (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Edit the Scheduler pod specification file /etc/kubernetes/manifests/kube-scheduler.yaml
+on the master node and ensure the correct value for the --bind-address parameter
+
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-scheduler' | tail -n1 | grep 'bind-address'
+```
+
+**Expected Result**:
+
+```console
+'--bind-address' is present OR '--bind-address' is not present
+```
+
+## 2 Etcd Node Configuration Files
+### 2.1 Ensure that the --cert-file and --key-file arguments are set as appropriate (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Follow the etcd service documentation and configure TLS encryption.
+Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
+on the master node and set the below parameters.
+--cert-file=
+--key-file=
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
+```bash
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 2.1
+```
+
+**Expected Result**:
+
+```console
+'cert-file' is present AND 'key-file' is present
+```
+
+**Returned Value**:
+
+```console
+cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
+```
+
+### 2.2 Ensure that the --client-cert-auth argument is set to true (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Edit the etcd pod specification file /var/lib/rancher/k3s/server/db/etcd/config on the master
+node and set the below parameter.
+--client-cert-auth="true"
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
+```bash
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 2.2
+```
+
+**Expected Result**:
+
+```console
+'--client-cert-auth' is not present
+```
+
+**Returned Value**:
+
+```console
+client-cert-auth: true
+```
+
+### 2.3 Ensure that the --auto-tls argument is not set to true (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Edit the etcd pod specification file /var/lib/rancher/k3s/server/db/etcd/config on the master
+node and either remove the --auto-tls parameter or set it to false.
+ --auto-tls=false
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
+```bash
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 2.3
+```
+
+**Expected Result**:
+
+```console
+'--auto-tls' is not present OR '--auto-tls' is not present
+```
+
+**Returned Value**:
+
+```console
+false
+```
+
+### 2.4 Ensure that the --peer-cert-file and --peer-key-file arguments are set as appropriate (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Follow the etcd service documentation and configure peer TLS encryption as appropriate
+for your etcd cluster.
+Then, edit the etcd pod specification file /var/lib/rancher/k3s/server/db/etcd/config on the
+master node and set the below parameters.
+--peer-client-file=
+--peer-key-file=
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
+```bash
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 2.4
+```
+
+**Expected Result**:
+
+```console
+'cert-file' is present AND 'key-file' is present
+```
+
+**Returned Value**:
+
+```console
+cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
+```
+
+### 2.5 Ensure that the --peer-client-cert-auth argument is set to true (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Edit the etcd pod specification file /var/lib/rancher/k3s/server/db/etcd/config on the master
+node and set the below parameter.
+--peer-client-cert-auth=true
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
+```bash
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 2.5
+```
+
+**Expected Result**:
+
+```console
+'--client-cert-auth' is not present
+```
+
+**Returned Value**:
+
+```console
+client-cert-auth: true
+```
+
+### 2.6 Ensure that the --peer-auto-tls argument is not set to true (Automated)
+
+
+**Result:** pass
+
+**Remediation:**
+Edit the etcd pod specification file /var/lib/rancher/k3s/server/db/etcd/config on the master
+node and either remove the --peer-auto-tls parameter or set it to false.
+--peer-auto-tls=false
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
+```bash
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 2.6
+```
+
+**Expected Result**:
+
+```console
+'--peer-auto-tls' is not present OR '--peer-auto-tls' is present
+```
+
+**Returned Value**:
+
+```console
+false
+```
+
+### 2.7 Ensure that a unique Certificate Authority is used for etcd (Manual)
+
+
+**Result:** pass
+
+**Remediation:**
+[Manual test]
+Follow the etcd documentation and create a dedicated certificate authority setup for the
+etcd service.
+Then, edit the etcd pod specification file /var/lib/rancher/k3s/server/db/etcd/config on the
+master node and set the below parameter.
+--trusted-ca-file=
+
+**Audit Script:** `check_for_k3s_etcd.sh`
+
+```bash
+#!/bin/bash
+
+# This script is used to ensure that k3s is actually running etcd (and not other databases like sqlite3)
+# before it checks the requirement
+set -eE
+
+handle_error() {
+ echo "false"
+}
+
+trap 'handle_error' ERR
+
+
+if [[ "$(journalctl -D /var/log/journal -u k3s | grep 'Managed etcd' | grep -v grep | wc -l)" -gt 0 ]]; then
+ case $1 in
+ "1.1.11")
+ echo $(stat -c %a /var/lib/rancher/k3s/server/db/etcd);;
+ "1.2.29")
+ echo $(journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-');;
+ "2.1")
+ echo $(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.2")
+ echo "$(grep -A 5 'client-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.3")
+ echo $(grep 'auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.4")
+ echo $(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep -E 'cert-file|key-file');;
+ "2.5")
+ echo "$(grep -A 5 'peer-transport-security' /var/lib/rancher/k3s/server/db/etcd/config | grep 'client-cert-auth')";;
+ "2.6")
+ echo $(grep 'peer-auto-tls' /var/lib/rancher/k3s/server/db/etcd/config);;
+ "2.7")
+ echo $(grep 'trusted-ca-file' /var/lib/rancher/k3s/server/db/etcd/config);;
+ esac
+else
+# If another database is running, return whatever is required to pass the scan
+ case $1 in
+ "1.1.11")
+ echo "700";;
+ "1.2.29")
+ echo "--etcd-certfile AND --etcd-keyfile";;
+ "2.1")
+ echo "cert-file AND key-file";;
+ "2.2")
+ echo "true";;
+ "2.3")
+ echo "false";;
+ "2.4")
+ echo "peer-cert-file AND peer-key-file";;
+ "2.5")
+ echo "true";;
+ "2.6")
+ echo "--peer-auto-tls=false";;
+ "2.7")
+ echo "--trusted-ca-file";;
+ esac
+fi
+
+```
+
+**Audit Execution:**
+
+```bash
+./check_for_k3s_etcd.sh 2.7
+```
+
+**Expected Result**:
+
+```console
+'trusted-ca-file' is present
+```
+
+**Returned Value**:
+
+```console
+trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
+```
+
+## 3.1 Authentication and Authorization
+### 3.1.1 Client certificate authentication should not be used for users (Manual)
+
+
+**Result:** warn
+
+**Remediation:**
+Alternative mechanisms provided by Kubernetes such as the use of OIDC should be
+implemented in place of client certificates.
+
+## 3.2 Logging
+### 3.2.1 Ensure that a minimal audit policy is created (Manual)
+
+
+**Result:** warn
+
+**Remediation:**
+Create an audit policy file for your cluster.
+
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'audit-policy-file'
+```
+
+### 3.2.2 Ensure that the audit policy covers key security concerns (Manual)
+
+
+**Result:** warn
+
+**Remediation:**
+Consider modification of the audit policy in use on the cluster to include these items, at a
+minimum.
+
+## 4.1 Worker Node Configuration Files
+### 4.1.1 Ensure that the kubelet service file permissions are set to 644 or more restrictive (Automated)
+
**Result:** Not Applicable
**Remediation:**
-K3s doesn’t launch the kubelet as a service. It is launched and managed by the K3s supervisor process. All configuration is passed to it as command line arguments at run time.
+Run the below command (based on the file location on your system) on the each worker node.
+For example,
+chmod 644 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+### 4.1.2 Ensure that the kubelet service file ownership is set to root:root (Automated)
-#### 4.1.3
-Ensure that the proxy kubeconfig file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The `kube-proxy` kubeconfig file controls various parameters of the `kube-proxy` service in the worker node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
-It is possible to run `kube-proxy` with the kubeconfig parameters configured as a Kubernetes ConfigMap instead of a file. In this case, there is no proxy kubeconfig file.
-
**Result:** Not Applicable
+**Remediation:**
+Run the below command (based on the file location on your system) on the each worker node.
+For example,
+chown root:root /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+
+### 4.1.3 If proxy kubeconfig file exists ensure permissions are set to 644 or more restrictive (Manual)
+
+
+**Result:** pass
+
+**Remediation:**
+Run the below command (based on the file location on your system) on the each worker node.
+For example,
+chmod 644 /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig
+
**Audit:**
-Run the below command on the worker node.
```bash
stat -c %a /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig
+```
+
+**Expected Result**:
+
+```console
+'permissions' is present OR '/var/lib/rancher/k3s/agent/kubeproxy.kubeconfig' is not present
+```
+
+**Returned Value**:
+
+```console
644
```
-Verify that if a file is specified and it exists, the permissions are 644 or more restrictive.
+### 4.1.4 Ensure that the proxy kubeconfig file ownership is set to root:root (Manual)
+
+
+**Result:** pass
**Remediation:**
-K3s runs `kube-proxy` in process and does not use a config file.
-
-
-#### 4.1.4
-Ensure that the proxy kubeconfig file ownership is set to `root:root` (Scored)
-
-Rationale
-The kubeconfig file for `kube-proxy` controls various parameters for the `kube-proxy` service in the worker node. You should set its file ownership to maintain the integrity of the file. The file should be owned by `root:root`.
-
-
-**Result:** Not Applicable
+Run the below command (based on the file location on your system) on the each worker node.
+For example, chown root:root /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig
**Audit:**
-Run the below command on the master node.
```bash
stat -c %U:%G /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig
+```
+
+**Expected Result**:
+
+```console
+'root:root' is not present OR '/var/lib/rancher/k3s/agent/kubeproxy.kubeconfig' is not present
+```
+
+**Returned Value**:
+
+```console
root:root
```
-Verify that if a file is specified and it exists, the permissions are 644 or more restrictive.
+### 4.1.5 Ensure that the --kubeconfig kubelet.conf file permissions are set to 644 or more restrictive (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s runs `kube-proxy` in process and does not use a config file.
-
-
-#### 4.1.5
-Ensure that the kubelet.conf file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The `kubelet.conf` file is the kubeconfig file for the node, and controls various parameters that set the behavior and identity of the worker node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
-
-**Result:** Pass
+Run the below command (based on the file location on your system) on the each worker node.
+For example,
+chmod 644 /var/lib/rancher/k3s/server/cred/admin.kubeconfig
**Audit:**
-Run the below command on the worker node.
```bash
stat -c %a /var/lib/rancher/k3s/agent/kubelet.kubeconfig
+```
+
+**Expected Result**:
+
+```console
+'644' is equal to '644'
+```
+
+**Returned Value**:
+
+```console
644
```
+### 4.1.6 Ensure that the --kubeconfig kubelet.conf file ownership is set to root:root (Manual)
+
+
+**Result:** warn
+
**Remediation:**
-By default, K3s creates `kubelet.kubeconfig` with `644` permissions. No manual remediation needed.
-
-#### 4.1.6
-Ensure that the kubelet.conf file ownership is set to `root:root` (Scored)
-
-Rationale
-The `kubelet.conf` file is the kubeconfig file for the node, and controls various parameters that set the behavior and identity of the worker node. You should set its file ownership to maintain the integrity of the file. The file should be owned by `root:root`.
-
-
-**Result:** Not Applicable
+Run the below command (based on the file location on your system) on the each worker node.
+For example,
+chown root:root /var/lib/rancher/k3s/server/cred/admin.kubeconfig
**Audit:**
-Run the below command on the master node.
```bash
stat -c %U:%G /var/lib/rancher/k3s/agent/kubelet.kubeconfig
-root:root
```
+### 4.1.7 Ensure that the certificate authorities file permissions are set to 644 or more restrictive (Manual)
+
+
+**Result:** pass
+
**Remediation:**
-By default, K3s creates `kubelet.kubeconfig` with `root:root` ownership. No manual remediation needed.
-
-
-#### 4.1.7
-Ensure that the certificate authorities file permissions are set to `644` or more restrictive (Scored)
-
-Rationale
-The certificate authorities file controls the authorities used to validate API requests. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
-
-**Result:** Pass
+Run the following command to modify the file permissions of the
+--client-ca-file chmod 644
**Audit:**
-Run the below command on the master node.
```bash
stat -c %a /var/lib/rancher/k3s/server/tls/server-ca.crt
+```
+
+**Expected Result**:
+
+```console
+'644' is equal to '644' OR '640' is present OR '600' is present OR '444' is present OR '440' is present OR '400' is present OR '000' is present
+```
+
+**Returned Value**:
+
+```console
644
```
-Verify that the permissions are 644.
+### 4.1.8 Ensure that the client certificate authorities file ownership is set to root:root (Manual)
+
+
+**Result:** warn
**Remediation:**
-By default, K3s creates `/var/lib/rancher/k3s/server/tls/server-ca.crt` with `644` permissions.
-
-
-#### 4.1.8
-Ensure that the client certificate authorities file ownership is set to `root:root` (Scored)
-
-Rationale
-The certificate authorities file controls the authorities used to validate API requests. You should set its file ownership to maintain the integrity of the file. The file should be owned by `root:root`.
-
-
-**Result:** Pass
+Run the following command to modify the ownership of the --client-ca-file.
+chown root:root
**Audit:**
-Run the below command on the master node.
```bash
stat -c %U:%G /var/lib/rancher/k3s/server/tls/client-ca.crt
-root:root
```
-**Remediation:**
-By default, K3s creates `/var/lib/rancher/k3s/server/tls/client-ca.crt` with `root:root` ownership.
+### 4.1.9 Ensure that the kubelet --config configuration file has permissions set to 644 or more restrictive (Automated)
-#### 4.1.9
-Ensure that the kubelet configuration file has permissions set to `644` or more restrictive (Scored)
-
-Rationale
-The kubelet reads various parameters, including security settings, from a config file specified by the `--config` argument. If this file is specified you should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
-
-
**Result:** Not Applicable
**Remediation:**
-K3s doesn’t require or maintain a configuration file for the kubelet process. All configuration is passed to it as command line arguments at run time.
+Run the following command (using the config file location identified in the Audit step)
+chmod 644 /var/lib/kubelet/config.yaml
+### 4.1.10 Ensure that the kubelet --config configuration file ownership is set to root:root (Automated)
-#### 4.1.10
-Ensure that the kubelet configuration file ownership is set to `root:root` (Scored)
-
-Rationale
-The kubelet reads various parameters, including security settings, from a config file specified by the `--config` argument. If this file is specified you should restrict its file permissions to maintain the integrity of the file. The file should be owned by `root:root`.
-
**Result:** Not Applicable
**Remediation:**
-K3s doesn’t require or maintain a configuration file for the kubelet process. All configuration is passed to it as command line arguments at run time.
+Run the following command (using the config file location identified in the Audit step)
+chown root:root /var/lib/kubelet/config.yaml
+
+## 4.2 Kubelet
+### 4.2.1 Ensure that the anonymous-auth argument is set to false (Automated)
-### 4.2 Kubelet
-This section contains recommendations for kubelet configuration.
-
-
-#### 4.2.1
-Ensure that the `--anonymous-auth` argument is set to false (Scored)
-
-Rationale
-When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "anonymous-auth"
-```
-
-Verify that the value for `--anonymous-auth` is false.
+**Result:** pass
**Remediation:**
-By default, K3s starts kubelet with `--anonymous-auth` set to false. No manual remediation needed.
-
-#### 4.2.2
-Ensure that the `--authorization-mode` argument is not set to `AlwaysAllow` (Scored)
-
-Rationale
-Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests.
-
-
-**Result:** Pass
+If using a Kubelet config file, edit the file to set authentication: anonymous: enabled to
+false.
+If using executable arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
+--anonymous-auth=false
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "authorization-mode"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'anonymous-auth' | grep -v grep
```
-Verify that `AlwaysAllow` is not present.
+**Expected Result**:
+
+```console
+'false' is equal to 'false'
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:24 k3s[5223]: time="2022-02-21T23:13:24.847339487Z" level=info msg="Running kube-apiserver --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit-log --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --enable-admission-plugins=NodeRestriction,PodSecurityPolicy,NamespaceLifecycle,ServiceAccount --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --insecure-port=0 --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --request-timeout=300s --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-lookup=true --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
+```
+
+### 4.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s starts kubelet with `Webhook` as the value for the `--authorization-mode` argument. No manual remediation needed.
-
-
-#### 4.2.3
-Ensure that the `--client-ca-file` argument is set as appropriate (Scored)
-
-Rationale
-The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests.
-
-
-**Result:** Pass
+If using a Kubelet config file, edit the file to set authorization: mode to Webhook. If
+using executable arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameter in KUBELET_AUTHZ_ARGS variable.
+--authorization-mode=Webhook
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "client-ca-file"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode' | grep -v grep
```
-Verify that the `--client-ca-file` argument has a ca file associated.
+**Expected Result**:
+
+```console
+'Node,RBAC' not have 'AlwaysAllow'
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:24 k3s[5223]: time="2022-02-21T23:13:24.847339487Z" level=info msg="Running kube-apiserver --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit-log --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --enable-admission-plugins=NodeRestriction,PodSecurityPolicy,NamespaceLifecycle,ServiceAccount --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --insecure-port=0 --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --request-timeout=300s --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-lookup=true --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
+```
+
+### 4.2.3 Ensure that the --client-ca-file argument is set as appropriate (Automated)
+
+
+**Result:** pass
**Remediation:**
-By default, K3s starts the kubelet process with the `--client-ca-file`. No manual remediation needed.
-
-
-#### 4.2.4
-Ensure that the `--read-only-port` argument is set to `0` (Scored)
-
-Rationale
-The Kubelet process provides a read-only API in addition to the main Kubelet API. Unauthenticated access is provided to this read-only API which could possibly retrieve potentially sensitive information about the cluster.
-
-
-**Result:** Pass
+If using a Kubelet config file, edit the file to set authentication: x509: clientCAFile to
+the location of the client CA file.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameter in KUBELET_AUTHZ_ARGS variable.
+--client-ca-file=
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kubelet" | tail -n1 | grep "read-only-port"
+journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver'| tail -n1 | grep 'client-ca-file' | grep -v grep
```
-Verify that the `--read-only-port` argument is set to 0.
+
+**Expected Result**:
+
+```console
+'--client-ca-file' is present
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:24 k3s[5223]: time="2022-02-21T23:13:24.847339487Z" level=info msg="Running kube-apiserver --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit-log --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --enable-admission-plugins=NodeRestriction,PodSecurityPolicy,NamespaceLifecycle,ServiceAccount --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --insecure-port=0 --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --request-timeout=300s --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-lookup=true --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
+```
+
+### 4.2.4 Ensure that the --read-only-port argument is set to 0 (Manual)
+
+
+**Result:** warn
**Remediation:**
-By default, K3s starts the kubelet process with the `--read-only-port` argument set to `0`.
-
-
-#### 4.2.5
-Ensure that the `--streaming-connection-idle-timeout` argument is not set to `0` (Scored)
-
-Rationale
-Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports.
-
-**Note:** By default, `--streaming-connection-idle-timeout` is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases.
-
-
-**Result:** Pass
+If using a Kubelet config file, edit the file to set readOnlyPort to 0.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
+--read-only-port=0
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kubelet" | tail -n1 | grep "streaming-connection-idle-timeout"
+journalctl -D /var/log/journal -u k3s | grep 'Running kubelet' | tail -n1 | grep 'read-only-port'
```
-Verify that there's nothing returned.
+### 4.2.5 Ensure that the --streaming-connection-idle-timeout argument is not set to 0 (Manual)
+
+
+**Result:** warn
**Remediation:**
-By default, K3s does not set `--streaming-connection-idle-timeout` when starting kubelet.
-
-
-#### 4.2.6
-Ensure that the `--protect-kernel-defaults` argument is set to `true` (Scored)
-
-Rationale
-Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior.
-
-
-**Result:** Pass
+If using a Kubelet config file, edit the file to set streamingConnectionIdleTimeout to a
+value other than 0.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
+--streaming-connection-idle-timeout=5m
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kubelet" | tail -n1 | grep "protect-kernel-defaults"
+journalctl -D /var/log/journal -u k3s | grep 'Running kubelet' | tail -n1 | grep 'streaming-connection-idle-timeout'
```
+### 4.2.6 Ensure that the --protect-kernel-defaults argument is set to true (Automated)
+
+
+**Result:** pass
+
**Remediation:**
-K3s server needs to be started with the following, `--protect-kernel-defaults=true`.
-
-
-#### 4.2.7
-Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored)
-
-Rationale
-Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open.
-
-
-**Result:** Pass
+If using a Kubelet config file, edit the file to set protectKernelDefaults: true.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
+--protect-kernel-defaults=true
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kubelet" | tail -n1 | grep "make-iptables-util-chains"
+journalctl -D /var/log/journal -u k3s | grep 'Running kubelet' | tail -n1 | grep 'protect-kernel-defaults'
```
-Verify there are no results returned.
+**Expected Result**:
+
+```console
+'true' is equal to 'true'
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:32 k3s[5223]: time="2022-02-21T23:13:32.581127632Z" level=info msg="Running kubelet --address=0.0.0.0 --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=cgroupfs --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --cni-bin-dir=/var/lib/rancher/k3s/data/9de9bfcf367b723ef0ac73dd91761165a4a8ad11ad16a758d3a996264e60c612/bin --cni-conf-dir=/var/lib/rancher/k3s/agent/etc/cni/net.d --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --container-runtime=remote --containerd=/run/k3s/containerd/containerd.sock --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override= --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-labels= --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
+```
+
+### 4.2.7 Ensure that the --make-iptables-util-chains argument is set to true (Automated)
+
+
+**Result:** pass
**Remediation:**
-K3s server needs to be run with the following, `--kube-apiserver-arg='make-iptables-util-chains=true'`.
+If using a Kubelet config file, edit the file to set makeIPTablesUtilChains: true.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+remove the --make-iptables-util-chains argument from the
+KUBELET_SYSTEM_PODS_ARGS variable.
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
+**Audit:**
+
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kubelet' | tail -n1 | grep 'make-iptables-util-chains'
+```
+
+**Expected Result**:
+
+```console
+'true' is equal to 'true' OR '--make-iptables-util-chains' is not present
+```
+
+**Returned Value**:
+
+```console
+Feb 21 23:13:32 k3s[5223]: time="2022-02-21T23:13:32.581127632Z" level=info msg="Running kubelet --address=0.0.0.0 --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=cgroupfs --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --cni-bin-dir=/var/lib/rancher/k3s/data/9de9bfcf367b723ef0ac73dd91761165a4a8ad11ad16a758d3a996264e60c612/bin --cni-conf-dir=/var/lib/rancher/k3s/agent/etc/cni/net.d --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --container-runtime=remote --containerd=/run/k3s/containerd/containerd.sock --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override= --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-labels= --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
+```
+
+### 4.2.8 Ensure that the --hostname-override argument is not set (Manual)
-#### 4.2.8
-Ensure that the `--hostname-override` argument is not set (Not Scored)
-
-Rationale
-Overriding hostnames could potentially break TLS setup between the kubelet and the apiserver. Additionally, with overridden hostnames, it becomes increasingly difficult to associate logs with a particular node and process them for security analytics. Hence, you should setup your kubelet nodes with resolvable FQDNs and avoid overriding the hostnames with IPs.
-
**Result:** Not Applicable
**Remediation:**
-K3s does set this parameter for each host, but K3s also manages all certificates in the cluster. It ensures the hostname-override is included as a subject alternative name (SAN) in the kubelet's certificate.
+Edit the kubelet service file /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+on each worker node and remove the --hostname-override argument from the
+KUBELET_SYSTEM_PODS_ARGS variable.
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
+
+### 4.2.9 Ensure that the --event-qps argument is set to 0 or a level which ensures appropriate event capture (Manual)
-#### 4.2.9
-Ensure that the `--event-qps` argument is set to 0 or a level which ensures appropriate event capture (Not Scored)
-
-Rationale
-It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data.
-
-
-**Result:** Not Scored - Operator Dependent
+**Result:** warn
**Remediation:**
-See CIS Benchmark guide for further details on configuring this.
-
-#### 4.2.10
-Ensure that the `--tls-cert-file` and `--tls-private-key-file` arguments are set as appropriate (Scored)
-
-Rationale
-Kubelet communication contains sensitive parameters that should remain encrypted in transit. Configure the Kubelets to serve only HTTPS traffic.
-
-
-**Result:** Pass
+If using a Kubelet config file, edit the file to set eventRecordQPS: to an appropriate level.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-journalctl -u k3s | grep "Running kubelet" | tail -n1 | grep -E 'tls-cert-file|tls-private-key-file'
+/bin/ps -fC containerd
```
-Verify the `--tls-cert-file` and `--tls-private-key-file` arguments are present and set appropriately.
+### 4.2.10 Ensure that the --tls-cert-file and --tls-private-key-file arguments are set as appropriate (Manual)
+
+
+**Result:** warn
**Remediation:**
-By default, K3s sets the `--tls-cert-file` and `--tls-private-key-file` arguments when executing the kubelet process.
+If using a Kubelet config file, edit the file to set tlsCertFile to the location
+of the certificate file to use to identify this Kubelet, and tlsPrivateKeyFile
+to the location of the corresponding private key file.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
+--tls-cert-file=
+--tls-private-key-file=
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
+**Audit:**
-#### 4.2.11
-Ensure that the `--rotate-certificates` argument is not set to `false` (Scored)
-
-Rationale
+```bash
+journalctl -D /var/log/journal -u k3s | grep 'Running kubelet' | tail -n1
+```
-The `--rotate-certificates` setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire. This automated periodic rotation ensures that there is no downtime due to expired certificates and thus addressing availability in the CIA security triad.
+### 4.2.11 Ensure that the --rotate-certificates argument is not set to false (Manual)
-**Note:** This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself.
-
-**Note:**This feature also requires the `RotateKubeletClientCertificate` feature gate to be enabled (which is the default since Kubernetes v1.7)
-
**Result:** Not Applicable
**Remediation:**
-By default, K3s implements its own logic for certificate generation and rotation.
+If using a Kubelet config file, edit the file to add the line rotateCertificates: true or
+remove it altogether to use the default value.
+If using command line arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+remove --rotate-certificates=false argument from the KUBELET_CERTIFICATE_ARGS
+variable.
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
+### 4.2.12 Verify that the RotateKubeletServerCertificate argument is set to true (Manual)
-#### 4.2.12
-Ensure that the `RotateKubeletServerCertificate` argument is set to `true` (Scored)
-
-Rationale
-`RotateKubeletServerCertificate` causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad.
-
-Note: This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself.
-
**Result:** Not Applicable
**Remediation:**
-By default, K3s implements its own logic for certificate generation and rotation.
+Edit the kubelet service file /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
+on each worker node and set the below parameter in KUBELET_CERTIFICATE_ARGS variable.
+--feature-gates=RotateKubeletServerCertificate=true
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
+
+### 4.2.13 Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers (Manual)
-#### 4.2.13
-Ensure that the Kubelet only makes use of Strong Cryptographic Ciphers (Not Scored)
-
-Rationale
-TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided.
-
-
-**Result:** Not Scored - Operator Dependent
+**Result:** warn
**Remediation:**
-Configuration of the parameter is dependent on your use case. Please see the CIS Kubernetes Benchmark for suggestions on configuring this for your use-case.
-
-
-## 5 Kubernetes Policies
-
-
-### 5.1 RBAC and Service Accounts
-
-
-#### 5.1.1
-Ensure that the cluster-admin role is only used where required (Not Scored)
-
-Rationale
-Kubernetes provides a set of default roles where RBAC is used. Some of these roles such as `cluster-admin` provide wide-ranging privileges which should only be applied where absolutely necessary. Roles such as `cluster-admin` allow super-user access to perform any action on any resource. When used in a `ClusterRoleBinding`, it gives full control over every resource in the cluster and in all namespaces. When used in a `RoleBinding`, it gives full control over every resource in the rolebinding's namespace, including the namespace itself.
-
-
-**Result:** Pass
-
-**Remediation:**
-K3s does not make inappropriate use of the cluster-admin role. Operators must audit their workloads of additional usage. See the CIS Benchmark guide for more details.
-
-#### 5.1.2
-Minimize access to secrets (Not Scored)
-
-Rationale
-Inappropriate access to secrets stored within the Kubernetes cluster can allow for an attacker to gain additional access to the Kubernetes cluster or external resources whose credentials are stored as secrets.
-
-
-**Result:** Not Scored - Operator Dependent
-
-**Remediation:**
-K3s limits its use of secrets for the system components appropriately, but operators must audit the use of secrets by their workloads. See the CIS Benchmark guide for more details.
-
-#### 5.1.3
-Minimize wildcard use in Roles and ClusterRoles (Not Scored)
-
-Rationale
-The principle of least privilege recommends that users are provided only the access required for their role and nothing more. The use of wildcard rights grants is likely to provide excessive rights to the Kubernetes API.
-
-
-**Result:** Not Scored - Operator Dependent
+If using a Kubelet config file, edit the file to set TLSCipherSuites: to
+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+or to a subset of these values.
+If using executable arguments, edit the kubelet service file
+/etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
+set the --tls-cipher-suites parameter as follows, or to a subset of these values.
+--tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
+Based on your system, restart the kubelet service. For example:
+systemctl daemon-reload
+systemctl restart kubelet.service
**Audit:**
-Run the below command on the master node.
```bash
-# Retrieve the roles defined across each namespaces in the cluster and review for wildcards
-kubectl get roles --all-namespaces -o yaml
-
-# Retrieve the cluster roles defined in the cluster and review for wildcards
-kubectl get clusterroles -o yaml
+/bin/ps -fC containerd
```
-Verify that there are not wildcards in use.
+## 5.1 RBAC and Service Accounts
+### 5.1.1 Ensure that the cluster-admin role is only used where required (Manual)
+
+
+**Result:** warn
**Remediation:**
-Operators should review their workloads for proper role usage. See the CIS Benchmark guide for more details.
+Identify all clusterrolebindings to the cluster-admin role. Check if they are used and
+if they need this role or if they could use a role with fewer privileges.
+Where possible, first bind users to a lower privileged role and then remove the
+clusterrolebinding to the cluster-admin role :
+kubectl delete clusterrolebinding [name]
-#### 5.1.4
-Minimize access to create pods (Not Scored)
-
-Rationale
-The ability to create pods in a cluster opens up possibilities for privilege escalation and should be restricted, where possible.
-
+### 5.1.2 Minimize access to secrets (Manual)
-**Result:** Not Scored - Operator Dependent
+
+**Result:** warn
**Remediation:**
-Operators should review who has access to create pods in their cluster. See the CIS Benchmark guide for more details.
+Where possible, remove get, list and watch access to secret objects in the cluster.
-#### 5.1.5
-Ensure that default service accounts are not actively used. (Scored)
-
-Rationale
-Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
+### 5.1.3 Minimize wildcard use in Roles and ClusterRoles (Manual)
-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.
-
+**Result:** warn
-**Result:** Fail. Currently requires operator intervention See the [Hardening Guide]({{}}/k3s/latest/en/security/hardening_guide) for details.
+**Remediation:**
+Where possible replace any use of wildcards in clusterroles and roles with specific
+objects or actions.
-**Audit:**
-For each namespace in the cluster, review the rights assigned to the default service account and ensure that it has no roles or cluster roles bound to it apart from the defaults. Additionally ensure that the automountServiceAccountToken: false setting is in place for each default service account.
+### 5.1.4 Minimize access to create pods (Manual)
+
+
+**Result:** warn
+
+**Remediation:**
+Where possible, remove create access to pod objects in the cluster.
+
+### 5.1.5 Ensure that default service accounts are not actively used. (Manual)
+
+
+**Result:** warn
**Remediation:**
Create explicit service accounts wherever a Kubernetes workload requires specific access
to the Kubernetes API server.
Modify the configuration of each default service account to include this value
-
-``` bash
automountServiceAccountToken: false
-```
+
+### 5.1.6 Ensure that Service Account Tokens are only mounted where necessary (Manual)
-#### 5.1.6
-Ensure that Service Account Tokens are only mounted where necessary (Not Scored)
-
-Rationale
-Mounting service account tokens inside pods can provide an avenue for privilege escalation attacks where an attacker is able to compromise a single pod in the cluster.
-
-Avoiding mounting these tokens removes this attack avenue.
-
-
-**Result:** Not Scored - Operator Dependent
+**Result:** warn
**Remediation:**
-The pods launched by K3s are part of the control plane and generally need access to communicate with the API server, thus this control does not apply to them. Operators should review their workloads and take steps to modify the definition of pods and service accounts which do not need to mount service account tokens to disable it.
+Modify the definition of pods and service accounts which do not need to mount service
+account tokens to disable it.
-### 5.2 Pod Security Policies
+## 5.2 Pod Security Policies
+### 5.2.1 Minimize the admission of privileged containers (Manual)
-#### 5.2.1
-Minimize the admission of containers wishing to share the host process ID namespace (Scored)
-
-Rationale
-Privileged containers have access to all Linux Kernel capabilities and devices. A container running with full privileges can do almost everything that the host can do. This flag exists to allow special use-cases, like manipulating the network stack and accessing devices.
+**Result:** warn
-There should be at least one PodSecurityPolicy (PSP) defined which does not permit privileged containers.
-
-If you need to run privileged containers, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Pass
+**Remediation:**
+Create a PSP as described in the Kubernetes documentation, ensuring that
+the .spec.privileged field is omitted or set to false.
**Audit:**
-Run the below command on the master node.
```bash
-kubectl describe psp | grep MustRunAsNonRoot
+kubectl describe psp global-restricted-psp | grep MustRunAsNonRoot
```
-Verify that the result is `Rule: MustRunAsNonRoot`.
+### 5.2.2 Minimize the admission of containers wishing to share the host process ID namespace (Manual)
+
+
+**Result:** pass
**Remediation:**
-An operator should apply a PodSecurityPolicy that sets the `Rule` value to `MustRunAsNonRoot`. An example of this can be found in the [Hardening Guide](../hardening_guide/).
-
-
-#### 5.2.2
-Minimize the admission of containers wishing to share the host process ID namespace (Scored)
-
-Rationale
-A container running in the host's PID namespace can inspect processes running outside the container. If the container also has access to ptrace capabilities this can be used to escalate privileges outside of the container.
-
-There should be at least one PodSecurityPolicy (PSP) defined which does not permit containers to share the host PID namespace.
-
-If you need to run containers which require hostPID, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Pass
+Create a PSP as described in the Kubernetes documentation, ensuring that the
+.spec.hostPID field is omitted or set to false.
**Audit:**
-Run the below command on the master node.
```bash
kubectl get psp -o json | jq .items[] | jq -r 'select((.spec.hostPID == null) or (.spec.hostPID == false))' | jq .metadata.name | wc -l | xargs -I {} echo '--count={}'
```
-Verify that the returned count is 1.
+**Expected Result**:
+
+```console
+1 is greater than 0
+```
+
+**Returned Value**:
+
+```console
+--count=1
+```
+
+### 5.2.3 Minimize the admission of containers wishing to share the host IPC namespace (Manual)
+
+
+**Result:** pass
**Remediation:**
-An operator should apply a PodSecurityPolicy that sets the `hostPID` value to false explicitly for the PSP it creates. An example of this can be found in the [Hardening Guide](../hardening_guide/).
-
-
-#### 5.2.3
-Minimize the admission of containers wishing to share the host IPC namespace (Scored)
-
-Rationale
-
-A container running in the host's IPC namespace can use IPC to interact with processes outside the container.
-
-There should be at least one PodSecurityPolicy (PSP) defined which does not permit containers to share the host IPC namespace.
-
-If you have a requirement to containers which require hostIPC, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Pass
+Create a PSP as described in the Kubernetes documentation, ensuring that the
+.spec.hostIPC field is omitted or set to false.
**Audit:**
-Run the below command on the master node.
```bash
kubectl get psp -o json | jq .items[] | jq -r 'select((.spec.hostIPC == null) or (.spec.hostIPC == false))' | jq .metadata.name | wc -l | xargs -I {} echo '--count={}'
```
-Verify that the returned count is 1.
+**Expected Result**:
+
+```console
+1 is greater than 0
+```
+
+**Returned Value**:
+
+```console
+--count=1
+```
+
+### 5.2.4 Minimize the admission of containers wishing to share the host network namespace (Manual)
+
+
+**Result:** pass
**Remediation:**
-An operator should apply a PodSecurityPolicy that sets the `HostIPC` value to false explicitly for the PSP it creates. An example of this can be found in the [Hardening Guide](../hardening_guide/).
-
-
-#### 5.2.4
-Minimize the admission of containers wishing to share the host network namespace (Scored)
-
-Rationale
-A container running in the host's network namespace could access the local loopback device, and could access network traffic to and from other pods.
-
-There should be at least one PodSecurityPolicy (PSP) defined which does not permit containers to share the host network namespace.
-
-If you have need to run containers which require hostNetwork, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Pass
+Create a PSP as described in the Kubernetes documentation, ensuring that the
+.spec.hostNetwork field is omitted or set to false.
**Audit:**
-Run the below command on the master node.
```bash
kubectl get psp -o json | jq .items[] | jq -r 'select((.spec.hostNetwork == null) or (.spec.hostNetwork == false))' | jq .metadata.name | wc -l | xargs -I {} echo '--count={}'
```
-Verify that the returned count is 1.
+**Expected Result**:
+
+```console
+1 is greater than 0
+```
+
+**Returned Value**:
+
+```console
+--count=1
+```
+
+### 5.2.5 Minimize the admission of containers with allowPrivilegeEscalation (Manual)
+
+
+**Result:** pass
**Remediation:**
-An operator should apply a PodSecurityPolicy that sets the `HostNetwork` value to false explicitly for the PSP it creates. An example of this can be found in the [Hardening Guide](../hardening_guide/).
-
-
-#### 5.2.5
-Minimize the admission of containers with `allowPrivilegeEscalation` (Scored)
-
-Rationale
-A container running with the `allowPrivilegeEscalation` flag set to true may have processes that can gain more privileges than their parent.
-
-There should be at least one PodSecurityPolicy (PSP) defined which does not permit containers to allow privilege escalation. The option exists (and is defaulted to true) to permit setuid binaries to run.
-
-If you have need to run containers which use setuid binaries or require privilege escalation, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Pass
+Create a PSP as described in the Kubernetes documentation, ensuring that the
+.spec.allowPrivilegeEscalation field is omitted or set to false.
**Audit:**
-Run the below command on the master node.
```bash
kubectl get psp -o json | jq .items[] | jq -r 'select((.spec.allowPrivilegeEscalation == null) or (.spec.allowPrivilegeEscalation == false))' | jq .metadata.name | wc -l | xargs -I {} echo '--count={}'
```
-Verify that the returned count is 1.
+**Expected Result**:
+
+```console
+1 is greater than 0
+```
+
+**Returned Value**:
+
+```console
+--count=1
+```
+
+### 5.2.6 Minimize the admission of root containers (Manual)
+
+
+**Result:** pass
**Remediation:**
-An operator should apply a PodSecurityPolicy that sets the `allowPrivilegeEscalation` value to false explicitly for the PSP it creates. An example of this can be found in the [Hardening Guide](../hardening_guide/).
-
-
-#### 5.2.6
-Minimize the admission of root containers (Not Scored)
-
-Rationale
-Containers may run as any Linux user. Containers which run as the root user, whilst constrained by Container Runtime security features still have an escalated likelihood of container breakout.
-
-Ideally, all containers should run as a defined non-UID 0 user.
-
-There should be at least one PodSecurityPolicy (PSP) defined which does not permit root users in a container.
-
-If you need to run root containers, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Not Scored
+Create a PSP as described in the Kubernetes documentation, ensuring that the
+.spec.runAsUser.rule is set to either MustRunAsNonRoot or MustRunAs with the range of
+UIDs not including 0.
**Audit:**
-Run the below command on the master node.
```bash
kubectl get psp -o json | jq .items[] | jq -r 'select((.spec.allowPrivilegeEscalation == null) or (.spec.allowPrivilegeEscalation == false))' | jq .metadata.name | wc -l | xargs -I {} echo '--count={}'
```
-Verify that the returned count is 1.
+**Expected Result**:
-**Remediation:**
-An operator should apply a PodSecurityPolicy that sets the `runAsUser.Rule` value to `MustRunAsNonRoot`. An example of this can be found in the [Hardening Guide](../hardening_guide/).
-
-
-#### 5.2.7
-Minimize the admission of containers with the NET_RAW capability (Not Scored)
-
-Rationale
-Containers run with a default set of capabilities as assigned by the Container Runtime. By default this can include potentially dangerous capabilities. With Docker as the container runtime the NET_RAW capability is enabled which may be misused by malicious containers.
-
-Ideally, all containers should drop this capability.
-
-There should be at least one PodSecurityPolicy (PSP) defined which prevents containers with the NET_RAW capability from launching.
-
-If you need to run containers with this capability, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Not Scored
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-kubectl get psp -o json | jq .spec.requiredDropCapabilities[]
+```console
+1 is greater than 0
```
-Verify the value is `"ALL"`.
+**Returned Value**:
+
+```console
+--count=1
+```
+
+### 5.2.7 Minimize the admission of containers with the NET_RAW capability (Manual)
+
+
+**Result:** warn
**Remediation:**
-An operator should apply a PodSecurityPolicy that sets `.spec.requiredDropCapabilities[]` to a value of `All`. An example of this can be found in the [Hardening Guide](../hardening_guide/).
-
-
-#### 5.2.8
-Minimize the admission of containers with added capabilities (Not Scored)
-
-Rationale
-Containers run with a default set of capabilities as assigned by the Container Runtime. Capabilities outside this set can be added to containers which could expose them to risks of container breakout attacks.
-
-There should be at least one PodSecurityPolicy (PSP) defined which prevents containers with capabilities beyond the default set from launching.
-
-If you need to run containers with additional capabilities, this should be defined in a separate PSP and you should carefully check RBAC controls to ensure that only limited service accounts and users are given permission to access that PSP.
-
-
-**Result:** Not Scored
+Create a PSP as described in the Kubernetes documentation, ensuring that the
+.spec.requiredDropCapabilities is set to include either NET_RAW or ALL.
**Audit:**
-Run the below command on the master node.
```bash
kubectl get psp
```
-Verify that there are no PSPs present which have `allowedCapabilities` set to anything other than an empty array.
+### 5.2.8 Minimize the admission of containers with added capabilities (Manual)
+
+
+**Result:** warn
**Remediation:**
-An operator should apply a PodSecurityPolicy that sets `allowedCapabilities` to anything other than an empty array. An example of this can be found in the [Hardening Guide](../hardening_guide/).
+Ensure that allowedCapabilities is not present in PSPs for the cluster unless
+it is set to an empty array.
+
+### 5.2.9 Minimize the admission of containers with capabilities assigned (Manual)
-#### 5.2.9
-Minimize the admission of containers with capabilities assigned (Not Scored)
-
-Rationale
-Containers run with a default set of capabilities as assigned by the Container Runtime. Capabilities are parts of the rights generally granted on a Linux system to the root user.
+**Result:** warn
-In many cases applications running in containers do not require any capabilities to operate, so from the perspective of the principle of least privilege use of capabilities should be minimized.
-
+**Remediation:**
+Review the use of capabilites in applications runnning on your cluster. Where a namespace
+contains applicaions which do not require any Linux capabities to operate consider adding
+a PSP which forbids the admission of containers which do not drop all capabilities.
-**Result:** Not Scored
+## 5.3 Network Policies and CNI
+### 5.3.1 Ensure that the CNI in use supports Network Policies (Manual)
-**Audit:**
-Run the below command on the master node.
+
+**Result:** warn
+
+**Remediation:**
+If the CNI plugin in use does not support network policies, consideration should be given to
+making use of a different plugin, or finding an alternate mechanism for restricting traffic
+in the Kubernetes cluster.
+
+### 5.3.2 Ensure that all Namespaces have Network Policies defined (Manual)
+
+
+**Result:** pass
+
+**Remediation:**
+Follow the documentation and create NetworkPolicy objects as you need them.
+
+**Audit Script:** `check_for_rke2_network_policies.sh`
```bash
-kubectl get psp
-```
+#!/bin/bash
-**Remediation:**
-An operator should apply a PodSecurityPolicy that sets `requiredDropCapabilities` to `ALL`. An example of this can be found in the [Hardening Guide](../hardening_guide/).
+set -eE
+handle_error() {
+ echo "false"
+}
-### 5.3 Network Policies and CNI
+trap 'handle_error' ERR
-
-#### 5.3.1
-Ensure that the CNI in use supports Network Policies (Not Scored)
-
-Rationale
-Kubernetes network policies are enforced by the CNI plugin in use. As such it is important to ensure that the CNI plugin supports both Ingress and Egress network policies.
-
-
-**Result:** Pass
-
-**Audit:**
-Review the documentation of CNI plugin in use by the cluster, and confirm that it supports Ingress and Egress network policies.
-
-**Remediation:**
-By default, K3s use Canal (Calico and Flannel) and fully supports network policies.
-
-
-#### 5.3.2
-Ensure that all Namespaces have Network Policies defined (Scored)
-
-Rationale
-Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints.
-
-Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-for i in kube-system kube-public default; do
- kubectl get networkpolicies -n $i;
+for namespace in kube-system kube-public default; do
+ policy_count=$(/var/lib/rancher/rke2/bin/kubectl get networkpolicy -n ${namespace} -o json | jq -r '.items | length')
+ if [ ${policy_count} -eq 0 ]; then
+ echo "false"
+ exit
+ fi
done
+
+echo "true"
+
```
-Verify that there are network policies applied to each of the namespaces.
-
-**Remediation:**
-An operator should apply NetworkPolcyies that prevent unneeded traffic from traversing networks unnecessarily. An example of applying a NetworkPolcy can be found in the [Hardening Guide](../hardening_guide/).
-
-### 5.4 Secrets Management
-
-
-#### 5.4.1
-Prefer using secrets as files over secrets as environment variables (Not Scored)
-
-Rationale
-It is reasonably common for application code to log out its environment (particularly in the event of an error). This will include any secret values passed in as environment variables, so secrets can easily be exposed to any user or entity who has access to the logs.
-
-
-**Result:** Not Scored
-
-**Audit:**
-Run the following command to find references to objects which use environment variables defined from secrets.
+**Audit Execution:**
```bash
-kubectl get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.name} {"\n"}{end}' -A
+./check_for_rke2_network_policies.sh
```
-**Remediation:**
-If possible, rewrite application code to read secrets from mounted secret files, rather than from environment variables.
+**Expected Result**:
+
+```console
+'true' is equal to 'true'
+```
+
+**Returned Value**:
+
+```console
+true
+```
+
+## 5.4 Secrets Management
+### 5.4.1 Prefer using secrets as files over secrets as environment variables (Manual)
-#### 5.4.2
-Consider external secret storage (Not Scored)
-
-Rationale
-Kubernetes supports secrets as first-class objects, but care needs to be taken to ensure that access to secrets is carefully limited. Using an external secrets provider can ease the management of access to secrets, especially where secrets are used across both Kubernetes and non-Kubernetes environments.
-
-
-**Result:** Not Scored
-
-**Audit:**
-Review your secrets management implementation.
+**Result:** warn
**Remediation:**
-Refer to the secrets management options offered by your cloud provider or a third-party secrets management solution.
-
-
-### 5.5 Extensible Admission Control
-
-
-#### 5.5.1
-Configure Image Provenance using ImagePolicyWebhook admission controller (Not Scored)
-
-Rationale
-Kubernetes supports plugging in provenance rules to accept or reject the images in your deployments. You could configure such rules to ensure that only approved images are deployed in the cluster.
-
-
-**Result:** Not Scored
+if possible, rewrite application code to read secrets from mounted secret files, rather than
+from environment variables.
**Audit:**
-Review the pod definitions in your cluster and verify that image _provenance_ is configured as appropriate.
+
+```bash
+kubectl get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.name} {' '}{end}' -A
+```
+
+### 5.4.2 Consider external secret storage (Manual)
+
+
+**Result:** warn
+
+**Remediation:**
+Refer to the secrets management options offered by your cloud provider or a third-party
+secrets management solution.
+
+## 5.5 Extensible Admission Control
+### 5.5.1 Configure Image Provenance using ImagePolicyWebhook admission controller (Manual)
+
+
+**Result:** warn
**Remediation:**
Follow the Kubernetes documentation and setup image provenance.
-
-### 5.6 Omitted
-The v1.5.1 Benchmark skips 5.6 and goes from 5.5 to 5.7. We are including it here merely for explanation.
+## 5.7 General Policies
+### 5.7.1 Create administrative boundaries between resources using namespaces (Manual)
-### 5.7 General Policies
-These policies relate to general cluster management topics, like namespace best practices and policies applied to pod objects in the cluster.
+**Result:** warn
+
+**Remediation:**
+Follow the documentation and create namespaces for objects in your deployment as you need
+them.
+
+### 5.7.2 Ensure that the seccomp profile is set to docker/default in your pod definitions (Manual)
-#### 5.7.1
-Create administrative boundaries between resources using namespaces (Not Scored)
-
-Rationale
-Limiting the scope of user permissions can reduce the impact of mistakes or malicious activities. A Kubernetes namespace allows you to partition created resources into logically named groups. Resources created in one namespace can be hidden from other namespaces. By default, each resource created by a user in Kubernetes cluster runs in a default namespace, called default. You can create additional namespaces and attach resources and users to them. You can use Kubernetes Authorization plugins to create policies that segregate access to namespace resources between different users.
-
+**Result:** warn
-**Result:** Not Scored
+**Remediation:**
+Seccomp is an alpha feature currently. By default, all alpha features are disabled. So, you
+would need to enable alpha features in the apiserver by passing "--feature-
+gates=AllAlpha=true" argument.
+Edit the /etc/kubernetes/apiserver file on the master node and set the KUBE_API_ARGS
+parameter to "--feature-gates=AllAlpha=true"
+KUBE_API_ARGS="--feature-gates=AllAlpha=true"
+Based on your system, restart the kube-apiserver service. For example:
+systemctl restart kube-apiserver.service
+Use annotations to enable the docker/default seccomp profile in your pod definitions. An
+example is as below:
+apiVersion: v1
+kind: Pod
+metadata:
+ name: trustworthy-pod
+ annotations:
+ seccomp.security.alpha.kubernetes.io/pod: docker/default
+spec:
+ containers:
+ - name: trustworthy-container
+ image: sotrustworthy:latest
+
+### 5.7.3 Apply Security Context to Your Pods and Containers (Manual)
+
+
+**Result:** warn
+
+**Remediation:**
+Follow the Kubernetes documentation and apply security contexts to your pods. For a
+suggested list of security contexts, you may refer to the CIS Security Benchmark for Docker
+Containers.
+
+### 5.7.4 The default namespace should not be used (Manual)
+
+
+**Result:** pass
+
+**Remediation:**
+Ensure that namespaces are created to allow for appropriate segregation of Kubernetes
+resources and that all new resources are created in a specific namespace.
**Audit:**
-Run the below command and review the namespaces created in the cluster.
```bash
-kubectl get namespaces
+kubectl get all --no-headers -n default | grep -v service | wc -l | xargs -I {} echo '--count={}'
```
-Ensure that these namespaces are the ones you need and are adequately administered as per your requirements.
+**Expected Result**:
-**Remediation:**
-Follow the documentation and create namespaces for objects in your deployment as you need them.
-
-
-#### 5.7.2
-Ensure that the seccomp profile is set to `docker/default` in your pod definitions (Not Scored)
-
-Rationale
-Seccomp (secure computing mode) is used to restrict the set of system calls applications can make, allowing cluster administrators greater control over the security of workloads running in the cluster. Kubernetes disables seccomp profiles by default for historical reasons. You should enable it to ensure that the workloads have restricted actions available within the container.
-
-
-**Result:** Not Scored
-
-**Audit:**
-Review the pod definitions in your cluster. It should create a line as below:
-
-```yaml
-annotations:
- seccomp.security.alpha.kubernetes.io/pod: docker/default
+```console
+'0' is equal to '0'
```
-**Remediation:**
-Review the Kubernetes documentation and if needed, apply a relevant PodSecurityPolicy.
+**Returned Value**:
-#### 5.7.3
-Apply Security Context to Your Pods and Containers (Not Scored)
-
-Rationale
-A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. When designing your containers and pods, make sure that you configure the security context for your pods, containers, and volumes. A security context is a property defined in the deployment yaml. It controls the security parameters that will be assigned to the pod/container/volume. There are two levels of security context: pod level security context, and container-level security context.
-
-
-**Result:** Not Scored
-
-**Audit:**
-Review the pod definitions in your cluster and verify that you have security contexts defined as appropriate.
-
-**Remediation:**
-Follow the Kubernetes documentation and apply security contexts to your pods. For a suggested list of security contexts, you may refer to the CIS Security Benchmark.
-
-
-#### 5.7.4
-The default namespace should not be used (Scored)
-
-Rationale
-Resources in a Kubernetes cluster should be segregated by namespace, to allow for security controls to be applied at that level and to make it easier to manage resources.
-
-
-**Result:** Pass
-
-**Audit:**
-Run the below command on the master node.
-
-```bash
-kubectl get all -n default
+```console
+--count=0
```
-
-The only entries there should be system-managed resources such as the kubernetes service.
-
-**Remediation:**
-By default, K3s does not utilize the default namespace.
diff --git a/content/k3s/latest/en/storage/_index.md b/content/k3s/latest/en/storage/_index.md
index fd0dcba1168..883128ee118 100644
--- a/content/k3s/latest/en/storage/_index.md
+++ b/content/k3s/latest/en/storage/_index.md
@@ -9,6 +9,26 @@ A persistent volume (PV) is a piece of storage in the Kubernetes cluster, while
This page describes how to set up persistent storage with a local storage provider, or with [Longhorn.](#setting-up-longhorn)
+# What's changed in K3s storage?
+
+K3s removes several optional volume plugins and all built-in (sometimes referred to as "in-tree") cloud providers. We do this in order to achieve a smaller binary size and to avoid dependence on third-party cloud or data center technologies and services, which may not be available in many K3s use cases. We are able to do this because their removal affects neither core Kubernetes functionality nor conformance.
+
+The following volume plugins have been removed from K3s:
+
+* cephfs
+* fc
+* flocker
+* git_repo
+* glusterfs
+* portworx
+* quobyte
+* rbd
+* storageos
+
+Both components have out-of-tree alternatives that can be used with K3s: The Kubernetes [Container Storage Interface (CSI)](https://github.com/container-storage-interface/spec/blob/master/spec.md) and [Cloud Provider Interface (CPI)](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/).
+
+Kubernetes maintainers are actively migrating in-tree volume plugins to CSI drivers. For more information on this migration, please refer [here](https://kubernetes.io/blog/2021/12/10/storage-in-tree-to-csi-migration-status-update/).
+
# Setting up the Local Storage Provider
K3s comes with Rancher's Local Path Provisioner and this enables the ability to create persistent volume claims out of the box using local storage on the respective node. Below we cover a simple example. For more information please reference the official documentation [here](https://github.com/rancher/local-path-provisioner/blob/master/README.md#usage).
diff --git a/content/k3s/latest/en/upgrades/_index.md b/content/k3s/latest/en/upgrades/_index.md
index 1b9c86805ad..fad09759854 100644
--- a/content/k3s/latest/en/upgrades/_index.md
+++ b/content/k3s/latest/en/upgrades/_index.md
@@ -3,12 +3,22 @@ title: "Upgrades"
weight: 25
---
-This section describes how to upgrade your K3s cluster.
+### Upgrading your K3s cluster
[Upgrade basics]({{< baseurl >}}/k3s/latest/en/upgrades/basic/) describes several techniques for upgrading your cluster manually. It can also be used as a basis for upgrading through third-party Infrastructure-as-Code tools like [Terraform](https://www.terraform.io/).
[Automated upgrades]({{< baseurl >}}/k3s/latest/en/upgrades/automated/) describes how to perform Kubernetes-native automated upgrades using Rancher's [system-upgrade-controller](https://github.com/rancher/system-upgrade-controller).
-> If Traefik is not disabled K3s versions 1.20 and earlier will have installed Traefik v1, while K3s versions 1.21 and later will install Traefik v2 if v1 is not already present. To upgrade Traefik, please refer to the [Traefik documentation](https://doc.traefik.io/traefik/migration/v1-to-v2/) and use the [migration tool](https://github.com/traefik/traefik-migration-tool) to migrate from the older Traefik v1 to Traefik v2.
+### Version-specific caveats
-> The experimental embedded Dqlite data store was deprecated in K3s v1.19.1. Please note that upgrades from experimental Dqlite to experimental embedded etcd are not supported. If you attempt an upgrade it will not succeed and data will be lost.
+- **Traefik:** If Traefik is not disabled, K3s versions 1.20 and earlier will install Traefik v1, while K3s versions 1.21 and later will install Traefik v2, if v1 is not already present. To upgrade from the older Traefik v1 to Traefik v2, please refer to the [Traefik documentation](https://doc.traefik.io/traefik/migration/v1-to-v2/) and use the [migration tool](https://github.com/traefik/traefik-migration-tool).
+
+- **K3s bootstrap data:** If you are using K3s in an HA configuration with an external SQL datastore, and your server (control-plane) nodes were not started with the `--token` CLI flag, you will no longer be able to add additional K3s servers to the cluster without specifying the token. Ensure that you retain a copy of this token, as it is required when restoring from backup. Previously, K3s did not enforce the use of a token when using external SQL datastores.
+ - The affected versions are <= v1.19.12+k3s1, v1.20.8+k3s1, v1.21.2+k3s1; the patched versions are v1.19.13+k3s1, v1.20.9+k3s1, v1.21.3+k3s1.
+
+ - You may retrieve the token value from any server already joined to the cluster as follows:
+```
+cat /var/lib/rancher/k3s/server/token
+```
+
+- **Experimental Dqlite:** The experimental embedded Dqlite data store was deprecated in K3s v1.19.1. Please note that upgrades from experimental Dqlite to experimental embedded etcd are not supported. If you attempt an upgrade, it will not succeed, and data will be lost.
diff --git a/content/rancher/v2.0-v2.4/_index.md b/content/rancher/v2.0-v2.4/_index.md
index 25b54e1aff6..4d23120e33c 100644
--- a/content/rancher/v2.0-v2.4/_index.md
+++ b/content/rancher/v2.0-v2.4/_index.md
@@ -1,5 +1,5 @@
---
-title: v2.0-v2.4.x
+title: Rancher 2.0-2.4
weight: 3
showBreadcrumb: false
---
diff --git a/content/rancher/v2.0-v2.4/en/_index.md b/content/rancher/v2.0-v2.4/en/_index.md
index 153f22c3b87..6720ef85a73 100644
--- a/content/rancher/v2.0-v2.4/en/_index.md
+++ b/content/rancher/v2.0-v2.4/en/_index.md
@@ -1,8 +1,8 @@
---
-title: "Rancher v2.0-v2.4"
+title: "Rancher 2.0-2.4"
shortTitle: "Rancher 2.0-2.4"
description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
-metaTitle: "Rancher 2.x Docs: What is New?"
+metaTitle: "Rancher 2.0-2.4 Docs: What is New?"
metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
insertOneSix: true
weight: 1
@@ -18,4 +18,4 @@ Rancher adds significant value on top of Kubernetes, first by centralizing authe
It then enables detailed monitoring and alerting for clusters and their resources, ships logs to external providers, and integrates directly with Helm via the Application Catalog. If you have an external CI/CD system, you can plug it into Rancher, but if you don't, Rancher even includes a pipeline engine to help you automatically deploy and upgrade workloads.
-Rancher is a _complete_ container management platform for Kubernetes, giving you the tools to successfully run Kubernetes anywhere.
\ No newline at end of file
+Rancher is a _complete_ container management platform for Kubernetes, giving you the tools to successfully run Kubernetes anywhere.
diff --git a/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md
index e9a43d062f2..987ab8e966a 100644
--- a/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md
+++ b/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md
@@ -29,6 +29,8 @@ Note that these URLs will not return valid data until the authentication configu
1. **Groups Field**: Make entries for managing group memberships (example: `memberOf`).
+ 1. **Entity ID Field** (optional): The published, protocol-dependent, unique identifier of your partner. This ID defines your organization as the entity operating the server for SAML 2.0 transactions. This ID may have been obtained out-of-band or via a SAML metadata file.
+
1. **Rancher API Host**: Enter the URL for your Rancher Server.
1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your IdP.
diff --git a/content/rancher/v2.0-v2.4/en/admin-settings/config-private-registry/_index.md b/content/rancher/v2.0-v2.4/en/admin-settings/config-private-registry/_index.md
index d258e527c23..09779408bb8 100644
--- a/content/rancher/v2.0-v2.4/en/admin-settings/config-private-registry/_index.md
+++ b/content/rancher/v2.0-v2.4/en/admin-settings/config-private-registry/_index.md
@@ -4,7 +4,7 @@ weight: 400
aliases:
---
-You might want to use a private Docker registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the Docker images that are used in your clusters.
+You might want to use a private container registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.
There are two main ways to set up private registries in Rancher: by setting up the global default registry through the **Settings** tab in the global view, and by setting up a private registry in the advanced options in the cluster-level settings. The global default registry is intended to be used for air-gapped setups, for registries that do not require credentials. The cluster-level private registry is intended to be used in all setups in which the private registry requires credentials.
diff --git a/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md
index 6185daa0bee..6e155df7033 100644
--- a/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md
+++ b/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md
@@ -84,6 +84,10 @@ _Project roles_ are roles that can be used to grant users access to a project. T
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
+ >**Note:**
+ >
+ >By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+
- **Read Only:**
These users can view everything in the project but cannot create, update, or delete anything.
diff --git a/content/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/_index.md
index 0f5e5f00c9d..125c2cbe699 100644
--- a/content/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/_index.md
+++ b/content/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/_index.md
@@ -27,25 +27,6 @@ This section covers the following topics:
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups)
- [Refreshing group memberships](#refreshing-group-memberships)
-### List of `restricted-admin` Permissions
-
-The `restricted-admin` permissions are as follows:
-
-- Has full admin access to all downstream clusters managed by Rancher.
-- Has very limited access to the local Kubernetes cluster. Can access Rancher custom resource definitions, but has no access to any Kubernetes native types.
-- Can add other users and assign them to clusters outside of the local cluster.
-- Can create other restricted admins.
-- Cannot grant any permissions in the local cluster they don't currently have. (This is how Kubernetes normally operates)
-
-
-### Changing Global Administrators to Restricted Admins
-
-If Rancher already has a global administrator, they should change all global administrators over to the new `restricted-admin` role.
-
-This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
-
-Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
-
# Global Permission Assignment
Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.
diff --git a/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md b/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md
index b7026acc4a4..bfc20ae2b48 100644
--- a/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md
+++ b/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md
@@ -28,7 +28,7 @@ Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.o
2. After executing the command a `tokens.json` file will be created. Important! Back up this file in a safe place.** You will need it to restore functionality to your clusters after rolling back Rancher. **If you lose this file, you may lose access to your clusters.**
-3. Rollback Rancher following the [normal instructions]({{}}/rancher/v2.x/en/upgrades/rollbacks/).
+3. Rollback Rancher following the [normal instructions]({{}}/rancher/v2.0-v2.4/en/upgrades/rollbacks/).
4. Once Rancher comes back up, every cluster managed by Rancher (except for Imported clusters) will be in an `Unavailable` state.
diff --git a/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md b/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md
index d85e5a22cbf..5e23755f729 100644
--- a/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md
+++ b/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md
@@ -4,6 +4,7 @@ weight: 101
aliases:
- /rancher/v2.0-v2.4/en/best-practices/management
- /rancher/v2.0-v2.4/en/best-practices/v2.0-v2.4/management
+ - /rancher/v2.x/en/best-practices/management/
- /rancher/v2.x/en/best-practices/v2.0-v2.4/management/
---
@@ -86,8 +87,8 @@ Run your etcd and control plane nodes on virtual machines where you can scale vC
### Use at Least Three etcd Nodes
Provision 3 or 5 etcd nodes. Etcd requires a quorum to determine a leader by the majority of nodes, therefore it is not recommended to have clusters of even numbers. Three etcd nodes is generally sufficient for smaller clusters and five etcd nodes for large clusters.
-### Use at Least Two Control Plane Nodes
-Provision two 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.
+### Use at Least Three Control Plane Nodes
+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]({{}}/rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/) and use the Prometheus metrics and Grafana visualization options as a starting point.
diff --git a/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md
index 9774a89c470..545de58bf84 100644
--- a/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md
+++ b/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md
@@ -162,6 +162,9 @@ By default, your user is added as the project `Owner`.
>**Notes on Permissions:**
>
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
+>
+>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+>
>- Choose `Custom` to create a custom role on the fly: [Custom Project Roles]({{}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles).
To add members:
diff --git a/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md b/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md
index a0928f9373a..73d1f6efe48 100644
--- a/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md
+++ b/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md
@@ -128,4 +128,4 @@ This reference contains variables that you can use in `questions.yml` nested und
# Tutorial: Example Custom Chart Creation
-For a tutorial on adding a custom Helm chart to a custom catalog, refer to [this page.]({{}}/rancher/v2.x/en/catalog/tutorial)
+For a tutorial on adding a custom Helm chart to a custom catalog, refer to [this page.]({{}}/rancher/v2.0-v2.4/en/catalog/tutorial)
diff --git a/content/rancher/v2.0-v2.4/en/helm-charts/tutorial/_index.md b/content/rancher/v2.0-v2.4/en/helm-charts/tutorial/_index.md
index 5a23d0b7092..09b5c493fc1 100644
--- a/content/rancher/v2.0-v2.4/en/helm-charts/tutorial/_index.md
+++ b/content/rancher/v2.0-v2.4/en/helm-charts/tutorial/_index.md
@@ -50,20 +50,20 @@ You can fill your custom catalogs with either Helm Charts or Rancher Charts, alt
- CMS
questions:
- variable: persistence.enabled
- default: "false"
- description: "Enable persistent volume for WordPress"
- type: boolean
- required: true
- label: WordPress Persistent Volume Enabled
- show_subquestion_if: true
- group: "WordPress Settings"
- subquestions:
- - variable: persistence.size
+ default: "false"
+ description: "Enable persistent volume for WordPress"
+ type: boolean
+ required: true
+ label: WordPress Persistent Volume Enabled
+ show_subquestion_if: true
+ group: "WordPress Settings"
+ subquestions:
+ - variable: persistence.size
default: "10Gi"
description: "WordPress Persistent Volume Size"
type: string
label: WordPress Volume Size
- - variable: persistence.storageClass
+ - variable: persistence.storageClass
default: ""
description: "If undefined or null, uses the default StorageClass. Default to null"
type: storageclass
diff --git a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/_index.md b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/_index.md
index 98c8db4a6e8..0e79ce86a0d 100644
--- a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/_index.md
@@ -196,7 +196,7 @@ helm install rancher rancher-/rancher \
--namespace cattle-system \
--set hostname=rancher.my.org \
--set ingress.tls.source=letsEncrypt \
- --set letsEncrypt.email=me@example.org
+ --set letsEncrypt.email=me@example.org \
```
Wait for Rancher to be rolled out:
@@ -231,7 +231,7 @@ helm install rancher rancher-/rancher \
If you are using a Private CA signed certificate , add `--set privateCA=true` to the command:
```
-helm install rancher rancher-latest/rancher \
+helm install rancher rancher-/rancher \
--namespace cattle-system \
--set hostname=rancher.my.org \
--set ingress.tls.source=secret \
diff --git a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/_index.md b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/_index.md
index ff6631bef9a..f027000a6cb 100644
--- a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/chart-options/_index.md
@@ -126,7 +126,7 @@ To customize or use a different ingress with Rancher server you can set your own
Example on setting a custom certificate issuer:
```plain
---set ingress.extraAnnotations.'certmanager\.k8s\.io/cluster-issuer'=ca-key-pair
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
```
Example on setting a static proxy header with `ingress.configurationSnippet`. This value is parsed like a template so variables can be used.
diff --git a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/_index.md b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/_index.md
index e49c62f7d23..cb3cf8b9655 100644
--- a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/_index.md
@@ -168,7 +168,7 @@ helm upgrade rancher rancher-/rancher \
### Option B: Reinstalling Rancher and cert-manager
-If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manger due to the API change in cert-manger v0.11.
+If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
1. Uninstall Rancher
diff --git a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/_index.md b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/_index.md
index 7895c69d7af..e0f9ac2787c 100644
--- a/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/_index.md
@@ -114,7 +114,7 @@ helm upgrade --install rancher rancher-/rancher \
{{% accordion label="Option B: Reinstalling Rancher chart" %}}
-If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manger due to the API change in cert-manger v0.11.
+If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
1. Uninstall Rancher
diff --git a/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md b/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md
index d3a7a28d33d..efd93d093c7 100644
--- a/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md
@@ -142,7 +142,7 @@ For a how-to guide for setting up a DNS record to route domain traffic to an Ama
Rancher supports air gap installs using a secure Docker private registry. You must have your own private registry or other means of distributing Docker images to your machines.
-In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file]({{}}/k3s/latest/en/installation/private-registry/) with details from this registry.
+In a later step, when you set up your RKE Kubernetes cluster, you will create a [private registries configuration file]({{}}/rke/latest/en/config-options/private-registries/) with details from this registry.
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
@@ -164,8 +164,6 @@ For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/k3s/latest/en/installation/private-registry/) with details from this registry.
-
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/)
{{% /tab %}}
diff --git a/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md b/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md
index be69fcd235e..7e7e935097c 100644
--- a/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md
@@ -86,7 +86,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
```
- docker run --volumes-from rancher-data -v $PWD:/backup busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher
+ docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher
```
**Step Result:** When you enter this command, a series of commands should run.
diff --git a/content/rancher/v2.0-v2.4/en/installation/requirements/_index.md b/content/rancher/v2.0-v2.4/en/installation/requirements/_index.md
index ef77bd8dd89..fbf442d663e 100644
--- a/content/rancher/v2.0-v2.4/en/installation/requirements/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/requirements/_index.md
@@ -78,7 +78,8 @@ Performance increased in Rancher v2.4.0. For the requirements of Rancher before
| X-Large | Up to 1000 | Up to 10,000 | 16 | 64 GB |
| XX-Large | Up to 2000 | Up to 20,000 | 32 | 128 GB |
-[Contact Rancher](https://rancher.com/contact/) for more than 2000 clusters and/or 20,000 nodes.
+Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
+
{{% /tab %}}
{{% tab "K3s" %}}
@@ -93,7 +94,7 @@ These requirements apply to each host in a [K3s Kubernetes cluster where the Ran
| X-Large | Up to 1000 | Up to 10,000 | 16 | 64 GB | 2 cores, 4 GB + 1000 IOPS |
| XX-Large | Up to 2000 | Up to 20,000 | 32 | 128 GB | 2 cores, 4 GB + 1000 IOPS |
-[Contact Rancher](https://rancher.com/contact/) for more than 2000 clusters and/or 20,000 nodes.
+Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
{{% /tab %}}
diff --git a/content/rancher/v2.0-v2.4/en/installation/requirements/installing-docker/_index.md b/content/rancher/v2.0-v2.4/en/installation/requirements/installing-docker/_index.md
index 4414cb08794..9fdeb407a47 100644
--- a/content/rancher/v2.0-v2.4/en/installation/requirements/installing-docker/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/requirements/installing-docker/_index.md
@@ -3,7 +3,7 @@ title: Installing Docker
weight: 1
---
-For Helm CLI installs, Docker is required to be installed on any node that runs the Rancher server.
+Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/advanced/firewall/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/advanced/firewall/_index.md
index f3ee9defadd..67c6f880325 100644
--- a/content/rancher/v2.0-v2.4/en/installation/resources/advanced/firewall/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/resources/advanced/firewall/_index.md
@@ -3,7 +3,7 @@ title: Opening Ports with firewalld
weight: 1
---
-> We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off.
+> We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/advanced/helm2/helm-rancher/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/advanced/helm2/helm-rancher/_index.md
index 985141b076a..dc96db26d41 100644
--- a/content/rancher/v2.0-v2.4/en/installation/resources/advanced/helm2/helm-rancher/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/resources/advanced/helm2/helm-rancher/_index.md
@@ -131,7 +131,12 @@ deployment "rancher" successfully rolled out
This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA. This configuration uses HTTP validation (`HTTP-01`) so the load balancer must have a public DNS record and be accessible from the internet.
-- Set `hostname` to the public DNS record, set `ingress.tls.source` to `letsEncrypt` and `letsEncrypt.email` to the email address used for communication about your certificate (for example, expiry notices)
+In the following command,
+
+- Set `hostname` to the public DNS record that resolves to your load balancer.
+- Set `ingress.tls.source` to `letsEncrypt`.
+- Set `letsEncrypt.email` to the email address used for communication about your certificate (for example, expiry notices).
+- Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
```
@@ -140,7 +145,8 @@ helm install rancher-/rancher \
--namespace cattle-system \
--set hostname=rancher.my.org \
--set ingress.tls.source=letsEncrypt \
- --set letsEncrypt.email=me@example.org
+ --set letsEncrypt.email=me@example.org \
+ --set letsEncrypt.ingress.class=nginx
```
Wait for Rancher to be rolled out:
diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/feature-flags/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/feature-flags/_index.md
index c235116ee24..3c0c500c5aa 100644
--- a/content/rancher/v2.0-v2.4/en/installation/resources/feature-flags/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/resources/feature-flags/_index.md
@@ -107,7 +107,7 @@ When installing Rancher with Docker, use the `--features` option. In the below e
docker run -d -p 80:80 -p 443:443 \
--restart=unless-stopped \
rancher/rancher:rancher-latest \
- --features==true,=true # Available as of v2.3.0
+ --features==true,=true # Available as of v2.3.0
```
{{% /tab %}}
diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/installing-docker/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/installing-docker/_index.md
deleted file mode 100644
index faec8aed59c..00000000000
--- a/content/rancher/v2.0-v2.4/en/installation/resources/installing-docker/_index.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Installing Docker
-weight: 1
-aliases:
- - /rancher/v2.0-v2.4/en/installation/requirements/installing-docker
----
-
-Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
-
-There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
-
-Another option is to use one of Rancher's Docker installation scripts, which are available for most recent versions of Docker.
-
-For example, this command could be used to install Docker 19.03 on Ubuntu:
-
-```
-curl https://releases.rancher.com/install-docker/19.03.sh | sh
-```
-
-Rancher has installation scripts for every version of upstream Docker that Kubernetes supports. To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher's Docker installation scripts.
\ No newline at end of file
diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md
index 40f9c5294d2..3c32084c5e6 100644
--- a/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md
@@ -35,4 +35,4 @@ kubectl -n cattle-system create secret generic tls-ca \
# Updating a Private CA Certificate
-Follow the steps on [this page]({{}}/rancher/v2.x/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate.
\ No newline at end of file
+Follow the steps on [this page]({{}}/rancher/v2.0-v2.4/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate.
\ No newline at end of file
diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/_index.md
index 4d8266873c8..29d2e411443 100644
--- a/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/_index.md
@@ -19,7 +19,7 @@ To address these changes, this guide will do two things:
1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data
> **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md
index aba42eb1959..968cd6d6666 100644
--- a/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md
+++ b/content/rancher/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md
@@ -19,7 +19,7 @@ To address these changes, this guide will do two things:
1. Explain the cert-manager API changes and link to cert-manager's offficial documentation for migrating your data
> **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
diff --git a/content/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/deploy-workloads/_index.md b/content/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
index 95a39db870d..249bd6e59d9 100644
--- a/content/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
+++ b/content/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
@@ -15,7 +15,7 @@ Deploy a workload to run an application in one or more containers.
1. Enter a **Name** for the workload.
-1. Select a [workload type]({{}}/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/). The workload defaults to a scalable deployment, by can change the workload type by clicking **More options.**
+1. Select a [workload type]({{}}/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/). The workload defaults to a scalable deployment, but you can change the workload type by clicking **More options.**
1. From the **Docker Image** field, enter the name of the Docker image that you want to deploy to the project, optionally prefacing it with the registry host (e.g. `quay.io`, `registry.gitlab.com`, etc.). During deployment, Rancher pulls this image from the specified public or private registry. If no registry host is provided, Rancher will pull the image from [Docker Hub](https://hub.docker.com/explore/). Enter the name exactly as it appears in the registry server, including any required path, and optionally including the desired tag (e.g. `registry.gitlab.com/user/path/image:tag`). If no tag is provided, the `latest` tag will be automatically used.
diff --git a/content/rancher/v2.0-v2.4/en/overview/_index.md b/content/rancher/v2.0-v2.4/en/overview/_index.md
index b572069fbbb..16d8a5d0590 100644
--- a/content/rancher/v2.0-v2.4/en/overview/_index.md
+++ b/content/rancher/v2.0-v2.4/en/overview/_index.md
@@ -37,7 +37,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
- **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{}}/rancher/v2.0-v2.4/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{}}/rancher/v2.0-v2.4/en/cluster-admin/upgrading-kubernetes)
- **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{}}/rancher/v2.0-v2.4/en/catalog/) that make it easy to repeatedly deploy applications.
-- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.0-v2.4/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.0-v2.4/en/k8s-in-rancher/)
+- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.0-v2.4/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.0-v2.4/en/k8s-in-rancher/)
- **Pipelines:** Setting up a [pipeline]({{}}/rancher/v2.0-v2.4/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
- **Istio:** Our [integration with Istio]({{}}/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.
diff --git a/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md b/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md
index afac8412a3f..c637928995d 100644
--- a/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md
+++ b/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md
@@ -52,7 +52,7 @@ Three etcd nodes is generally sufficient for smaller clusters and five etcd node
### Controlplane Nodes
-Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles.
+Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although three or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles.
### Worker Nodes
@@ -69,4 +69,4 @@ For high-availability installations of Rancher, Helm is the tool used to install
Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh).
-For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
\ No newline at end of file
+For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
diff --git a/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md b/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md
index 47f4c7eddfe..a0a4a0922d7 100644
--- a/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md
+++ b/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md
@@ -42,6 +42,8 @@ Following project creation, you can add users as project members so that they ca
>
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
>
+ >- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+ >
>- For `Custom` roles, you can modify the list of individual roles available for assignment.
>
> - To add roles to the list, [Add a Custom Role]({{}}/rancher/v2.0-v2.4/en/admin-settings/rbac/default-custom-roles).
diff --git a/content/rancher/v2.0-v2.4/en/project-admin/resource-quotas/_index.md b/content/rancher/v2.0-v2.4/en/project-admin/resource-quotas/_index.md
index 6cac538d8f9..af27d4b3457 100644
--- a/content/rancher/v2.0-v2.4/en/project-admin/resource-quotas/_index.md
+++ b/content/rancher/v2.0-v2.4/en/project-admin/resource-quotas/_index.md
@@ -45,4 +45,4 @@ Edit [resource quotas]({{}}/rancher/v2.0-v2.4/en/k8s-in-rancher/project
1. Click **Create**.
-**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, Rancher won't let you save your changes.
+**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, you may still create namespaces, but they will be given a resource quota of 0. Subsequently, Rancher will not allow you to create any resources restricted by this quota.
diff --git a/content/rancher/v2.0-v2.4/en/project-admin/tools/_index.md b/content/rancher/v2.0-v2.4/en/project-admin/tools/_index.md
index bdd701e0d31..c1adfb7bc85 100644
--- a/content/rancher/v2.0-v2.4/en/project-admin/tools/_index.md
+++ b/content/rancher/v2.0-v2.4/en/project-admin/tools/_index.md
@@ -43,4 +43,4 @@ For details on project-level logging, see [this section.](./project-logging)
_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.]({{}}/rancher/v2.0-v2.4/en/cluster-admin/tools/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 the [monitoring section.]({{}}/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring)
diff --git a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/amazon-aws-qs/_index.md b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/amazon-aws-qs/_index.md
index 9c45743601b..92e07f38fc3 100644
--- a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/amazon-aws-qs/_index.md
+++ b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/amazon-aws-qs/_index.md
@@ -5,6 +5,8 @@ weight: 100
---
The following steps will quickly deploy a Rancher Server on AWS with a single node cluster attached.
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.0-v2.4/en/installation/).
+
## Prerequisites
>**Note**
diff --git a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/digital-ocean-qs/_index.md b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/digital-ocean-qs/_index.md
index 0f11b237ccf..06f557f5c88 100644
--- a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/digital-ocean-qs/_index.md
+++ b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/digital-ocean-qs/_index.md
@@ -5,6 +5,8 @@ weight: 100
---
The following steps will quickly deploy a Rancher Server on DigitalOcean with a single node cluster attached.
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.0-v2.4/en/installation/).
+
## Prerequisites
>**Note**
diff --git a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/google-gcp-qs/_index.md b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/google-gcp-qs/_index.md
index 0eeb4a5624d..31911cc0af8 100644
--- a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/google-gcp-qs/_index.md
+++ b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/google-gcp-qs/_index.md
@@ -5,6 +5,8 @@ weight: 100
---
The following steps will quickly deploy a Rancher server on GCP in a single-node RKE Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.0-v2.4/en/installation/).
+
## Prerequisites
>**Note**
diff --git a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md
index 663c03edc1b..448549c6778 100644
--- a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md
+++ b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md
@@ -6,6 +6,8 @@ weight: 100
The following steps will quickly deploy a Rancher server on Azure in a single-node RKE Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.0-v2.4/en/installation/).
+
## Prerequisites
>**Note**
diff --git a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
index 33d31c1b52c..753006eb6b6 100644
--- a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
+++ b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
@@ -8,6 +8,8 @@ Howdy Partner! This tutorial walks you through:
- Creation of your first cluster
- Deployment of an application, Nginx
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.0-v2.4/en/installation/).
+
## Quick Start Outline
This Quick Start Guide is divided into different tasks for easier consumption.
@@ -96,13 +98,13 @@ In this task, you can use the versatile **Custom** option. This option lets you
11. When you finish running the command on your Linux host, 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
diff --git a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-vagrant/_index.md b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-vagrant/_index.md
index 933a94ce66b..a996135f282 100644
--- a/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-vagrant/_index.md
+++ b/content/rancher/v2.0-v2.4/en/quick-start-guide/deployment/quickstart-vagrant/_index.md
@@ -4,6 +4,8 @@ weight: 200
---
The following steps quickly deploy a Rancher Server with a single node cluster attached.
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.0-v2.4/en/installation/).
+
## Prerequisites
- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
@@ -14,7 +16,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
`vagrant plugin install vagrant-vboxmanage`
-
+
`vagrant plugin install vagrant-vbguest`
## Getting Started
diff --git a/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md b/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md
index 48a98a37919..169b5d84104 100644
--- a/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md
+++ b/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md
@@ -158,7 +158,7 @@ kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{
Enabling query logging can be done by enabling the [log plugin](https://coredns.io/plugins/log/) in the Corefile configuration in the configmap `coredns`. You can do so by using `kubectl -n kube-system edit configmap coredns` or use the command below to replace the configuration in place:
```
-kubectl get configmap -n kube-system coredns -o json | kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f -
+kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f -
```
All queries will now be logged and can be checked using the command in [Check CoreDNS logging](#check-coredns-logging).
diff --git a/content/rancher/v2.5/_index.md b/content/rancher/v2.5/_index.md
index 89c7c0d8e09..61f266de705 100644
--- a/content/rancher/v2.5/_index.md
+++ b/content/rancher/v2.5/_index.md
@@ -1,5 +1,5 @@
---
-title: Rancher 2.5.7-2.5.9
+title: Rancher 2.5
weight: 2
showBreadcrumb: false
---
diff --git a/content/rancher/v2.5/en/_index.md b/content/rancher/v2.5/en/_index.md
index 513fb4d9836..95a369285c1 100644
--- a/content/rancher/v2.5/en/_index.md
+++ b/content/rancher/v2.5/en/_index.md
@@ -2,7 +2,7 @@
title: "Rancher 2.5"
shortTitle: "Rancher 2.5"
description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
-metaTitle: "Rancher 2.5.7-2.5.9 Docs: What is New?"
+metaTitle: "Rancher 2.5 Docs: What is New?"
metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
insertOneSix: false
weight: 2
diff --git a/content/rancher/v2.5/en/admin-settings/authentication/ad/_index.md b/content/rancher/v2.5/en/admin-settings/authentication/ad/_index.md
index 0cce01d449d..2c9c82a4374 100644
--- a/content/rancher/v2.5/en/admin-settings/authentication/ad/_index.md
+++ b/content/rancher/v2.5/en/admin-settings/authentication/ad/_index.md
@@ -101,7 +101,7 @@ The table below details the parameters for the group schema configuration.
| Search Attribute | Attribute used to construct search filters when adding groups to clusters or projects. See description of user schema `Search Attribute`. |
| Search Filter | This filter gets applied to the list of groups that is searched when Rancher attempts to add groups to a site access list or tries to add groups to clusters or projects. For example, a group search filter could be (|(cn=group1)(cn=group2)). Note: If the search filter does not use [valid AD search syntax,](https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax) the list of groups will be empty. |
| Group DN Attribute | The name of the group attribute whose format matches the values in the user attribute describing a the user's memberships. See `User Member Attribute`. |
-| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organisation makes use of these nested memberships (ie. you have groups that contain other groups as members. We advise avoiding nested groups when possible). |
+| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organization makes use of these nested memberships (i.e., you have groups that contain other groups as members. We advise avoiding nested groups when possible). |
---
@@ -153,7 +153,7 @@ This command performs an LDAP search with the search base set to the domain root
Since in this case the user's DN is `CN=John Doe,CN=Users,DC=acme,DC=com` [5], we should configure the **User Search Base** with the parent node DN `CN=Users,DC=acme,DC=com`.
-Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, ie. `OU=Groups,DC=acme,DC=com`.
+Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, i.e., `OU=Groups,DC=acme,DC=com`.
### Identify User Schema
@@ -166,7 +166,7 @@ The output of the above `ldapsearch` query also allows to determine the correct
> **Note:**
>
-> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
+> If the AD users in our organization were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name.
diff --git a/content/rancher/v2.5/en/admin-settings/authentication/keycloak/_index.md b/content/rancher/v2.5/en/admin-settings/authentication/keycloak/_index.md
index 95a37c00e2f..e4e75f36477 100644
--- a/content/rancher/v2.5/en/admin-settings/authentication/keycloak/_index.md
+++ b/content/rancher/v2.5/en/admin-settings/authentication/keycloak/_index.md
@@ -25,36 +25,87 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
>1: Optionally, you can enable either one or both of these settings.
>2: Rancher SAML metadata won't be generated until a SAML provider is configured and saved.
-
+
{{< img "/img/rancher/keycloak/keycloak-saml-client-configuration.png" "">}}
-
+
- In the new SAML client, create Mappers to expose the users fields
- Add all "Builtin Protocol Mappers"
{{< img "/img/rancher/keycloak/keycloak-saml-client-builtin-mappers.png" "">}}
- Create a new "Group list" mapper to map the member attribute to a user's groups
- {{< img "/img/rancher/keycloak/keycloak-saml-client-group-mapper.png" "">}}
-- Export a `metadata.xml` file from your Keycloak client:
- From the `Installation` tab, choose the `SAML Metadata IDPSSODescriptor` format option and download your file.
-
- >**Note**
- > Keycloak versions 6.0.0 and up no longer provide the IDP metadata under the `Installation` tab.
- > You can still get the XML from the following url:
- >
- > `https://{KEYCLOAK-URL}/auth/realms/{REALM-NAME}/protocol/saml/descriptor`
- >
- > The XML obtained from this URL contains `EntitiesDescriptor` as the root element. Rancher expects the root element to be `EntityDescriptor` rather than `EntitiesDescriptor`. So before passing this XML to Rancher, follow these steps to adjust it:
- >
- > * Copy all the attributes from `EntitiesDescriptor` to the `EntityDescriptor` that are not present.
- > * Remove the `` tag from the beginning.
- > * Remove the `` from the end of the xml.
- >
- > You are left with something similar as the example below:
- >
- > ```
- >
- > ....
- >
- > ```
+ {{< img "/img/rancher/keycloak/keycloak-saml-client-group-mapper.png" "">}}
+
+## Getting the IDP Metadata
+
+{{% tabs %}}
+{{% tab "Keycloak 5 and earlier" %}}
+To get the IDP metadata, export a `metadata.xml` file from your Keycloak client.
+From the **Installation** tab, choose the **SAML Metadata IDPSSODescriptor** format option and download your file.
+{{% /tab %}}
+{{% tab "Keycloak 6-13" %}}
+
+1. From the **Configure** section, click the **Realm Settings** tab.
+1. Click the **General** tab.
+1. From the **Endpoints** field, click **SAML 2.0 Identity Provider Metadata**.
+
+Verify the IDP metadata contains the following attributes:
+
+```
+xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
+xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
+xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+```
+
+Some browsers, such as Firefox, may render/process the document such that the contents appear to have been modified, and some attributes appear to be missing. In this situation, use the raw response data that can be found using your browser.
+
+The following is an example process for Firefox, but will vary slightly for other browsers:
+
+1. Press **F12** to access the developer console.
+1. Click the **Network** tab.
+1. From the table, click the row containing `descriptor`.
+1. From the details pane, click the **Response** tab.
+1. Copy the raw response data.
+
+The XML obtained contains `EntitiesDescriptor` as the root element. Rancher expects the root element to be `EntityDescriptor` rather than `EntitiesDescriptor`. So before passing this XML to Rancher, follow these steps to adjust it:
+
+1. Copy all the attributes from `EntitiesDescriptor` to the `EntityDescriptor` that are not present.
+1. Remove the `` tag from the beginning.
+1. Remove the `` from the end of the xml.
+
+You are left with something similar as the example below:
+
+```
+
+....
+
+```
+
+{{% /tab %}}
+{{% tab "Keycloak 14+" %}}
+
+1. From the **Configure** section, click the **Realm Settings** tab.
+1. Click the **General** tab.
+1. From the **Endpoints** field, click **SAML 2.0 Identity Provider Metadata**.
+
+Verify the IDP metadata contains the following attributes:
+
+```
+xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
+xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
+xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+```
+
+Some browsers, such as Firefox, may render/process the document such that the contents appear to have been modified, and some attributes appear to be missing. In this situation, use the raw response data that can be found using your browser.
+
+The following is an example process for Firefox, but will vary slightly for other browsers:
+
+1. Press **F12** to access the developer console.
+1. Click the **Network** tab.
+1. From the table, click the row containing `descriptor`.
+1. From the details pane, click the **Response** tab.
+1. Copy the raw response data.
+
+{{% /tab %}}
+{{% /tabs %}}
## Configuring Keycloak in Rancher
diff --git a/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md
index 87abce2b877..525717bb7b9 100644
--- a/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md
+++ b/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md
@@ -30,6 +30,8 @@ Note that these URLs will not return valid data until the authentication configu
1. **Groups Field**: Make entries for managing group memberships (example: `memberOf`).
+ 1. **Entity ID Field** (optional): The published, protocol-dependent, unique identifier of your partner. This ID defines your organization as the entity operating the server for SAML 2.0 transactions. This ID may have been obtained out-of-band or via a SAML metadata file.
+
1. **Rancher API Host**: Enter the URL for your Rancher Server.
1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your IdP.
diff --git a/content/rancher/v2.5/en/admin-settings/config-private-registry/_index.md b/content/rancher/v2.5/en/admin-settings/config-private-registry/_index.md
index 378d84aea5f..d9b05763201 100644
--- a/content/rancher/v2.5/en/admin-settings/config-private-registry/_index.md
+++ b/content/rancher/v2.5/en/admin-settings/config-private-registry/_index.md
@@ -5,7 +5,7 @@ aliases:
- /rancher/v2.x/en/admin-settings/config-private-registry/
---
-You might want to use a private Docker registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the Docker images that are used in your clusters.
+You might want to use a private container registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.
There are two main ways to set up private registries in Rancher: by setting up the global default registry through the **Settings** tab in the global view, and by setting up a private registry in the advanced options in the cluster-level settings. The global default registry is intended to be used for air-gapped setups, for registries that do not require credentials. The cluster-level private registry is intended to be used in all setups in which the private registry requires credentials.
diff --git a/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md
index 6c82e42e726..4996f82ab54 100644
--- a/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md
+++ b/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md
@@ -86,6 +86,10 @@ _Project roles_ are roles that can be used to grant users access to a project. T
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
+ >**Note:**
+ >
+ >By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+
- **Read Only:**
These users can view everything in the project but cannot create, update, or delete anything.
@@ -94,7 +98,6 @@ _Project roles_ are roles that can be used to grant users access to a project. T
>
>Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
-
#### Custom Project Roles
Rancher lets you assign _custom project roles_ to a standard user instead of the typical `Owner`, `Member`, or `Read Only` roles. These roles can be either a built-in custom project role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a standard user within a project. See the table below for a list of built-in custom project roles.
diff --git a/content/rancher/v2.5/en/api/_index.md b/content/rancher/v2.5/en/api/_index.md
index c6c3fdb63e3..a36f5f9fea2 100644
--- a/content/rancher/v2.5/en/api/_index.md
+++ b/content/rancher/v2.5/en/api/_index.md
@@ -52,3 +52,17 @@ Most collections can be sorted on the server-side by common fields using HTTP qu
## 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.
+
+## Capturing Rancher API Calls
+
+You can use browser developer tools to capture how the Rancher API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning an RKE cluster:
+
+1. In the Rancher UI, go to **Cluster Management** and click **Create.**
+1. Click one of the cluster types. This example uses Digital Ocean.
+1. Fill out the form with a cluster name and node template, but don't click **Create**.
+1. You will need to open the developer tools before the cluster creation to see the API call being recorded. To open the tools, right-click on the Rancher UI and click **Inspect.**
+1. In the developer tools, click the **Network** tab.
+1. On the **Network** tab, make sure **Fetch/XHR** is selected.
+1. In the Rancher UI, click **Create**. In the developer tools, you should see a new network request with the name `cluster?_replace=true`.
+1. Right-click `cluster?_replace=true` and click **Copy > Copy as cURL.**
+1. Paste the result into any text editor. You will be able to see the POST request, including the URL it was sent to, all of the headers, and the full body of the request. This command can be used to create a cluster from the command line. Note: The request should be stored in a safe place because it contains credentials.
\ No newline at end of file
diff --git a/content/rancher/v2.5/en/backups/_index.md b/content/rancher/v2.5/en/backups/_index.md
index 0f765d2d84d..01b07a0db84 100644
--- a/content/rancher/v2.5/en/backups/_index.md
+++ b/content/rancher/v2.5/en/backups/_index.md
@@ -63,6 +63,8 @@ The Backup and Restore custom resources can be created in the Rancher UI, or by
The `rancher-backup` operator can be installed from the Rancher UI, or with the Helm CLI. In both cases, the `rancher-backup` Helm chart is installed on the Kubernetes cluster running the Rancher server. It is a cluster-admin only feature and available only for the **local** cluster. (*If you do not see `rancher-backup` in the Rancher UI, you may have selected the wrong cluster.*)
+>**NOTE:** There are two known issues in Fleet that occur after performing a restoration using the backup-restore-operator: Fleet agents are inoperable and clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}rancher/v2.5/en/deploy-across-clusters/fleet/#troubleshooting) for workarounds.
+
### Installing rancher-backup with the Rancher UI
1. In the Rancher UI's Cluster Manager, choose the cluster named **local**
diff --git a/content/rancher/v2.5/en/backups/back-up-rancher/_index.md b/content/rancher/v2.5/en/backups/back-up-rancher/_index.md
index 51cdf22dfc1..47f57c96e26 100644
--- a/content/rancher/v2.5/en/backups/back-up-rancher/_index.md
+++ b/content/rancher/v2.5/en/backups/back-up-rancher/_index.md
@@ -7,11 +7,13 @@ aliases:
- /rancher/v2.x/en/backups/v2.5/back-up-rancher/
---
-In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer the instructions for [single node backups]({{}}/rancher/v2.5/en/backups/v2.5/docker-installs/docker-backups)
+In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer to the instructions for [single node backups]({{}}/rancher/v2.5/en/backups/v2.5/docker-installs/docker-backups).
The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster.
-> When restoring a backup into a new Rancher setup, the version of the new setup should be the same as the one where the backup is made.
+Note that the rancher-backup operator version 1.x.x is for Rancher v2.5.x.
+
+> When restoring a backup into a new Rancher setup, the version of the new setup should be the same as the one where the backup is made. The Kubernetes version should also be considered when restoring a backup, since the supported apiVersion in the cluster and in the backup file could be different.
### Prerequisites
@@ -28,6 +30,8 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio,
1. Click **Rancher Backups.**
1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config)
+>**NOTE:** There are two known issues in Fleet that occur after performing a restoration using the backup-restore-operator: Fleet agents are inoperable and clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}/rancher/v2.5/en/deploy-across-clusters/fleet/#troubleshooting) for workarounds.
+
### 2. Perform a Backup
To perform a backup, a custom resource of type Backup must be created.
diff --git a/content/rancher/v2.5/en/backups/migrating-rancher/_index.md b/content/rancher/v2.5/en/backups/migrating-rancher/_index.md
index 1fc70aee590..e84fe21de1b 100644
--- a/content/rancher/v2.5/en/backups/migrating-rancher/_index.md
+++ b/content/rancher/v2.5/en/backups/migrating-rancher/_index.md
@@ -21,13 +21,19 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
- [K3s Kubernetes installation docs]({{}}/k3s/latest/en/installation/)
### 1. Install the rancher-backup Helm chart
-Install version 1.x.x of the rancher-backup chart.
+Install version 1.x.x of the rancher-backup chart. The following assumes a connected environment with access to DockerHub:
+
```
helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
```
+
+For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
+```
+--set image.repository $REGISTRY/rancher/backup-restore-operator
+```
### 2. Restore from backup using a Restore custom resource
@@ -70,20 +76,19 @@ spec:
endpoint: s3.us-west-2.amazonaws.com
```
-> **Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
-1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
+>**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
-```
-kubectl create secret generic encryptionconfig \
- --from-file=./encryption-provider-config.yaml \
- -n cattle-resources-system
-```
-
-Then apply the resource:
-
-```
-kubectl apply -f migrationResource.yaml
-```
+1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
+ ```
+ kubectl create secret generic encryptionconfig \
+ --from-file=./encryption-provider-config.yaml \
+ -n cattle-resources-system
+ ```
+
+1. Then apply the resource:
+ ```
+ kubectl apply -f migrationResource.yaml
+ ```
### 3. Install cert-manager
diff --git a/content/rancher/v2.5/en/best-practices/rancher-server/deployment-types/_index.md b/content/rancher/v2.5/en/best-practices/rancher-server/deployment-types/_index.md
index f32518a92f7..f7ba5e5f02e 100644
--- a/content/rancher/v2.5/en/best-practices/rancher-server/deployment-types/_index.md
+++ b/content/rancher/v2.5/en/best-practices/rancher-server/deployment-types/_index.md
@@ -19,7 +19,7 @@ When you set up your high-availability Rancher installation, consider the follow
Don't run other workloads or microservices in the Kubernetes cluster that Rancher is installed on.
### 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)
+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/).
### When using RKE: Back up 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.
diff --git a/content/rancher/v2.5/en/best-practices/rancher-server/rancher-in-vsphere/_index.md b/content/rancher/v2.5/en/best-practices/rancher-server/rancher-in-vsphere/_index.md
index 9b987726412..d3db6045085 100644
--- a/content/rancher/v2.5/en/best-practices/rancher-server/rancher-in-vsphere/_index.md
+++ b/content/rancher/v2.5/en/best-practices/rancher-server/rancher-in-vsphere/_index.md
@@ -53,7 +53,7 @@ https://rancher.com/docs/rancher/v2.5/en/installation/requirements/
### Leverage VM Templates to Construct the Environment
-To facilitate consistency across the deployed Virtual Machines across the environment, consider the use of "Golden Images" in the form of VM templates. Packer can be used to accomplish this, adding greater customisation options.
+To facilitate the consistency of Virtual Machines deployed across the environment, consider the use of "Golden Images" in the form of VM templates. Packer can be used to accomplish this, adding greater customization options.
### Leverage DRS Anti-Affinity Rules (Where Possible) to Separate Rancher Cluster Nodes Across ESXi Hosts
diff --git a/content/rancher/v2.5/en/cli/_index.md b/content/rancher/v2.5/en/cli/_index.md
index 0413cdde5ed..6996b6bdf3d 100644
--- a/content/rancher/v2.5/en/cli/_index.md
+++ b/content/rancher/v2.5/en/cli/_index.md
@@ -1,13 +1,23 @@
---
-title: Using the Rancher Command Line Interface
-description: The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI
-metaTitle: "Using the Rancher Command Line Interface "
-metaDescription: "The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI"
+title: CLI with Rancher
+description: Interact with Rancher using command line interface (CLI) tools from your workstation.
weight: 21
-aliases:
- - /rancher/v2.5/en/cluster-admin/cluster-access/cli
---
+- [Rancher CLI](#rancher-cli)
+ - [Download Rancher CLI](#download-rancher-cli)
+ - [Requirements](#requirements)
+ - [CLI Authentication](#cli-authentication)
+ - [Project Selection](#project-selection)
+ - [Commands](#commands)
+ - [Rancher CLI Help](#rancher-cli-help)
+ - [Limitations](#limitations)
+- [kubectl](#kubectl)
+ - [kubectl Utility](#kubectl-utility)
+ - [Authentication with kubectl and kubeconfig Tokens with TTL](#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl)
+
+# Rancher CLI
+
The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
### Download Rancher CLI
@@ -38,11 +48,11 @@ Before you can perform any commands, you must select a Rancher project to perfor
**Example: `./rancher context switch` Output**
```
User:rancher-cli-directory user$ ./rancher context switch
-NUMBER CLUSTER NAME PROJECT ID PROJECT NAME
-1 cluster-2 c-7q96s:p-h4tmb project-2
-2 cluster-2 c-7q96s:project-j6z6d Default
-3 cluster-1 c-lchzv:p-xbpdt project-1
-4 cluster-1 c-lchzv:project-s2mch Default
+NUMBER CLUSTER NAME PROJECT ID PROJECT NAME
+1 cluster-2 c-7q96s:p-h4tmb project-2
+2 cluster-2 c-7q96s:project-j6z6d Default
+3 cluster-1 c-lchzv:p-xbpdt project-1
+4 cluster-1 c-lchzv:project-s2mch Default
Select a Project:
```
@@ -53,14 +63,16 @@ INFO[0005] Setting new context to project project-1
INFO[0005] Saving config to /Users/markbishop/.rancher/cli2.json
```
+Ensure you can run `rancher kubectl get pods` successfully.
+
### Commands
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]({{}}/rancher/v2.5/en/catalog/). |
+| `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]({{}}/rancher/v2.5/en/helm-charts/). |
| `clusters, [cluster]` | Performs operations on your [clusters]({{}}/rancher/v2.5/en/cluster-provisioning/). |
| `context` | Switches between Rancher [projects]({{}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/). 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]({{}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/) and [workloads]({{}}/rancher/v2.5/en/k8s-in-rancher/workloads/)). Specify resources by name or ID. |
@@ -80,3 +92,38 @@ The following commands are available for use in Rancher CLI.
Once logged into Rancher Server using the CLI, enter `./rancher --help` for a list of commands.
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](../helm-charts/).
+
+# kubectl
+
+Interact with Rancher using kubectl.
+
+### kubectl Utility
+
+Install the `kubectl` utility. See [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
+
+Configure kubectl by visiting your cluster in the Rancher Web UI, clicking on `Kubeconfig`, copying contents, and putting them into your `~/.kube/config` file.
+
+Run `kubectl cluster-info` or `kubectl get pods` successfully.
+
+### Authentication with kubectl and kubeconfig Tokens with TTL
+
+_Requirements_
+
+If admins have [enforced TTL on kubeconfig tokens]({{}}/rancher/v2.5/en/api/api-tokens/#setting-ttl-on-kubeconfig-tokens), the kubeconfig file requires the [Rancher CLI](../cli) to be present in your PATH when you run `kubectl`. Otherwise, you’ll see an error like:
+`Unable to connect to the server: getting credentials: exec: exec: "rancher": executable file not found in $PATH`.
+
+This feature enables kubectl to authenticate with the Rancher server and get a new kubeconfig token when required. The following auth providers are currently supported:
+
+1. Local
+2. Active Directory (LDAP only)
+3. FreeIPA
+4. OpenLDAP
+5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth
+
+When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server.
+The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../api/api-tokens/#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../../api/api-tokens/#deleting-tokens).
+Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
diff --git a/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md b/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md
index b3f52ad2d3f..168a7e4094b 100644
--- a/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md
+++ b/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md
@@ -12,9 +12,29 @@ By default, Kubernetes clusters require certificates and Rancher launched Kubern
Certificates can be rotated for the following services:
- etcd
-- kubelet
+- kubelet (node certificate)
+- kubelet (serving certificate, if [enabled]({{}}/rke/latest/en/config-options/services/#kubelet-options))
- kube-apiserver
- kube-proxy
- kube-scheduler
- kube-controller-manager
+
+### Certificate Rotation
+
+Rancher launched Kubernetes clusters have the ability to rotate the auto-generated certificates through the UI.
+
+1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
+
+2. Select **â‹® > Rotate Certificates**.
+
+3. Select which certificates that you want to rotate.
+
+ * Rotate all Service certificates (keep the same CA)
+ * Rotate an individual service and choose one of the services from the drop-down menu
+
+4. Click **Save**.
+
+**Results:** The selected certificates will be rotated and the related services will be restarted to start using the new certificate.
+
+> **Note:** Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher launched Kubernetes clusters.
diff --git a/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md b/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md
index bb4e31086c1..0ea3ab8ad80 100644
--- a/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md
+++ b/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md
@@ -16,7 +16,7 @@ Complete each drop-down and field using the information obtained for your IAM po
| Setting | Description |
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
| Region | From the drop-down choose the geographical region in which to build your cluster. |
-| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.x/en/user-settings/cloud-credentials/) |
+| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.5/en/user-settings/cloud-credentials/) |
### Service Role
@@ -186,7 +186,7 @@ Complete each drop-down and field using the information obtained for your IAM po
| Setting | Description |
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
| Region | From the drop-down choose the geographical region in which to build your cluster. |
-| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.x/en/user-settings/cloud-credentials/) |
+| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.5/en/user-settings/cloud-credentials/) |
### Service Role
diff --git a/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md b/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md
index d66fdb087bd..9de7dbf3c1d 100644
--- a/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md
+++ b/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md
@@ -25,7 +25,7 @@ If restricting outgoing internet access is not a concern for your organization,
>**Note**
>This scenario is not officially supported, but is described for cases in which using the Cloud NAT service is not sufficient.
-If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.x/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.
+If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.5/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.
### Private Control Plane Endpoint
diff --git a/content/rancher/v2.5/en/cluster-admin/nodes/_index.md b/content/rancher/v2.5/en/cluster-admin/nodes/_index.md
index 514ebc67a18..af48e6fa950 100644
--- a/content/rancher/v2.5/en/cluster-admin/nodes/_index.md
+++ b/content/rancher/v2.5/en/cluster-admin/nodes/_index.md
@@ -42,11 +42,11 @@ The following table lists which node options are available for each type of clus
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | | Download SSH key in order to SSH into the node. |
| [Node Scaling](#scaling-nodes) | ✓ | | | ✓ | | Scale the number of nodes in the node pool up or down. |
-[1]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
-[2]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/
-[3]: {{}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
-[4]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
-[5]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
+[1]: {{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/
+[2]: {{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/custom-nodes/
+[3]: {{}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/
+[4]: {{}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/
+[5]: {{}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/
\* Delete option accessible via View API
diff --git a/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md
index 86c6574c224..493331bc93c 100644
--- a/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md
+++ b/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md
@@ -156,6 +156,9 @@ By default, your user is added as the project `Owner`.
>**Notes on Permissions:**
>
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
+>
+>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+>
>- Choose `Custom` to create a custom role on the fly: [Custom Project Roles]({{}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles).
To add members:
diff --git a/content/rancher/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/_index.md b/content/rancher/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/_index.md
index 1a30d52540d..deaaaac4fc5 100644
--- a/content/rancher/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/_index.md
+++ b/content/rancher/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/_index.md
@@ -19,9 +19,12 @@ If you encounter this issue, you can work around it by installing the initiator
After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.
->**Note:**
+>**Notes:**
+>
+>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
+>
>
->Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.
+>- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.
```
services:
diff --git a/content/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/eks/permissions/_index.md b/content/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/eks/permissions/_index.md
index 0567e110d02..8f4539e1c6f 100644
--- a/content/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/eks/permissions/_index.md
+++ b/content/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/eks/permissions/_index.md
@@ -24,6 +24,7 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
"ec2:RunInstances",
"ec2:RevokeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
+ "ec2:DescribeRegions",
"ec2:DescribeVpcs",
"ec2:DescribeTags",
"ec2:DescribeSubnets",
@@ -123,31 +124,6 @@ Resource targeting uses `*` as the ARN of many of the resources created cannot b
### Service Role Permissions
-Rancher will create a service role with the following trust policy:
-
-```json
-{
- "Version": "2012-10-17",
- "Statement": [
- {
- "Action": "sts:AssumeRole",
- "Principal": {
- "Service": "eks.amazonaws.com"
- },
- "Effect": "Allow",
- "Sid": ""
- }
- ]
-}
-```
-
-This role will also have two role policy attachments with the following policies ARNs:
-
-```
-arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
-arn:aws:iam::aws:policy/AmazonEKSServicePolicy
-```
-
Permissions required for Rancher to create service role on users behalf during the EKS cluster creation process.
```json
@@ -182,36 +158,66 @@ Permissions required for Rancher to create service role on users behalf during t
}
```
+When an EKS cluster is created, Rancher will create a service role with the following trust policy:
+
+```json
+{
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Action": "sts:AssumeRole",
+ "Principal": {
+ "Service": "eks.amazonaws.com"
+ },
+ "Effect": "Allow",
+ "Sid": ""
+ }
+ ]
+}
+```
+
+This role will also have two role policy attachments with the following policies ARNs:
+
+```
+arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
+arn:aws:iam::aws:policy/AmazonEKSServicePolicy
+```
+
### VPC Permissions
Permissions required for Rancher to create VPC and associated resources.
```json
{
- "Sid": "VPCPermissions",
- "Effect": "Allow",
- "Action": [
- "ec2:ReplaceRoute",
- "ec2:ModifyVpcAttribute",
- "ec2:ModifySubnetAttribute",
- "ec2:DisassociateRouteTable",
- "ec2:DetachInternetGateway",
- "ec2:DescribeVpcs",
- "ec2:DeleteVpc",
- "ec2:DeleteTags",
- "ec2:DeleteSubnet",
- "ec2:DeleteRouteTable",
- "ec2:DeleteRoute",
- "ec2:DeleteInternetGateway",
- "ec2:CreateVpc",
- "ec2:CreateSubnet",
- "ec2:CreateSecurityGroup",
- "ec2:CreateRouteTable",
- "ec2:CreateRoute",
- "ec2:CreateInternetGateway",
- "ec2:AttachInternetGateway",
- "ec2:AssociateRouteTable"
- ],
- "Resource": "*"
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Sid": "VPCPermissions",
+ "Effect": "Allow",
+ "Action": [
+ "ec2:ReplaceRoute",
+ "ec2:ModifyVpcAttribute",
+ "ec2:ModifySubnetAttribute",
+ "ec2:DisassociateRouteTable",
+ "ec2:DetachInternetGateway",
+ "ec2:DescribeVpcs",
+ "ec2:DeleteVpc",
+ "ec2:DeleteTags",
+ "ec2:DeleteSubnet",
+ "ec2:DeleteRouteTable",
+ "ec2:DeleteRoute",
+ "ec2:DeleteInternetGateway",
+ "ec2:CreateVpc",
+ "ec2:CreateSubnet",
+ "ec2:CreateSecurityGroup",
+ "ec2:CreateRouteTable",
+ "ec2:CreateRoute",
+ "ec2:CreateInternetGateway",
+ "ec2:AttachInternetGateway",
+ "ec2:AssociateRouteTable"
+ ],
+ "Resource": "*"
+ }
+ ]
}
-```
\ No newline at end of file
+```
diff --git a/content/rancher/v2.5/en/cluster-provisioning/node-requirements/_index.md b/content/rancher/v2.5/en/cluster-provisioning/node-requirements/_index.md
index 54e83ca885d..3daf9c0cb8f 100644
--- a/content/rancher/v2.5/en/cluster-provisioning/node-requirements/_index.md
+++ b/content/rancher/v2.5/en/cluster-provisioning/node-requirements/_index.md
@@ -32,6 +32,13 @@ For information on how to install Docker, refer to the official [Docker document
Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off.
+>**Note:** In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity:
+>
+> ```
+ systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
+ reboot
+ ```
+
### SUSE Linux Nodes
SUSE Linux may have a firewall that blocks all ports by default. In that situation, follow [these steps]({{}}/rancher/v2.5/en/installation/requirements/ports/#opening-suse-linux-ports) to open the ports needed for adding a host to a custom cluster.
diff --git a/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md b/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md
index 8791b91df96..0e1ee65c004 100644
--- a/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md
+++ b/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md
@@ -20,6 +20,17 @@ The control that Rancher has to manage a registered cluster depends on the type
# Prerequisites
+{{% tabs %}}
+{{% tab "v2.5.9+" %}}
+
+### Kubernetes Node Roles
+
+Registered RKE Kubernetes clusters must have all three node roles - etcd, controlplane and worker. A cluster with only controlplane components cannot be registered in Rancher.
+
+For more information on RKE node roles, see the [best practices.]({{}}/rancher/v2.5/en/cluster-provisioning/production/#cluster-architecture)
+
+### Permissions
+
If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.
In order to apply the privilege, you need to run:
@@ -36,6 +47,38 @@ By default, GKE users are not given this privilege, so you will need to run the
If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher)
+### EKS Clusters
+
+EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
+
+{{% /tab %}}
+{{% tab "Rancher before v2.5.9" %}}
+
+### Permissions
+
+If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher.
+
+In order to apply the privilege, you need to run:
+
+```plain
+kubectl create clusterrolebinding cluster-admin-binding \
+ --clusterrole cluster-admin \
+ --user [USER_ACCOUNT]
+```
+
+before running the `kubectl` command to register the cluster.
+
+By default, GKE users are not given this privilege, so you will need to run the command before registering GKE clusters. To learn more about role-based access control for GKE, please click [here](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control).
+
+If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher)
+
+### EKS Clusters
+
+EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully.
+
+{{% /tab %}}
+{{% /tabs %}}
+
# Registering a Cluster
1. From the **Clusters** page, click **Add Cluster**.
@@ -76,6 +119,34 @@ The option can also be specified using the environment variable `K3S_KUBECONFIG_
$ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -
```
+### Configuring an Imported EKS Cluster with Terraform
+
+You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.
+
+>**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.
+
+The minimum config fields required by Rancher to import EKS clusters with Terraform using `eks_config_v2` are as follows:
+
+- cloud_credential_id
+- name
+- region
+- imported (this field should always be set to `true` for imported clusters)
+
+Example YAML configuration for imported EKS clusters:
+
+```
+resource "rancher2_cluster" "my-eks-to-import" {
+ name = "my-eks-to-import"
+ description = "Terraform EKS Cluster"
+ eks_config_v2 {
+ cloud_credential_id = rancher2_cloud_credential.aws.id
+ name = var.aws_eks_name
+ region = var.aws_region
+ imported = true
+ }
+}
+```
+
# Management Capabilities for Registered Clusters
The control that Rancher has to manage a registered cluster depends on the type of cluster.
diff --git a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md
index 82f660865e9..2679bbe634b 100644
--- a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md
+++ b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md
@@ -6,7 +6,7 @@ aliases:
- /rancher/v2.5/en/cluster-provisioning/rke-clusters/options/cloud-providers
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/cloud-providers/
---
-A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes. For more information, refer to the [official Kubernetes documentation on cloud providers.](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
+A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes.
When a cloud provider is set up in Rancher, the Rancher server can automatically provision new nodes, load balancers or persistent storage devices when launching Kubernetes definitions, if the cloud provider you're using supports such automation.
@@ -39,9 +39,9 @@ For details on enabling the vSphere cloud provider, refer to [this page.](./vsph
### Setting up a Custom Cloud Provider
-The `Custom` cloud provider is available if you want to configure any [Kubernetes cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/).
+The `Custom` cloud provider is available if you want to configure any Kubernetes cloud provider.
-For the custom cloud provider option, you can refer to the [RKE docs]({{}}/rke/latest/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
+For the custom cloud provider option, you can refer to the [RKE docs]({{}}/rke/latest/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration:
* [vSphere]({{}}/rke/latest/en/config-options/cloud-providers/vsphere/)
* [OpenStack]({{}}/rke/latest/en/config-options/cloud-providers/openstack/)
diff --git a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere/out-of-tree/_index.md b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere/out-of-tree/_index.md
index 33c3a39e9d8..545d87e0f49 100644
--- a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere/out-of-tree/_index.md
+++ b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere/out-of-tree/_index.md
@@ -13,7 +13,10 @@ This page covers how to install the Cloud Provider Interface (CPI) and Cloud Sto
# Prerequisites
-The vSphere version must be 7.0u1 or higher.
+The vSphere versions supported:
+
+* 6.7u3
+* 7.0u1 or higher.
The Kubernetes version must be 1.19 or higher.
diff --git a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md
index 662af99a33d..63b3bfddcbd 100644
--- a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md
+++ b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md
@@ -158,7 +158,7 @@ Option to enable or disable [recurring etcd snapshots]({{}}/rke/latest/
_Available as of v2.5.6_
-Option to set environment variables for [rancher agents]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
+Option to set environment variables for [rancher agents]({{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
# Cluster Config File
diff --git a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md
index 37ff393eded..16bf34656c1 100644
--- a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md
+++ b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md
@@ -85,7 +85,7 @@ If you are configuring DHCP options sets for an AWS virtual private cloud, note
> Some Linux operating systems accept multiple domain names separated by spaces. However, other Linux operating systems and Windows treat the value as a single domain, which results in unexpected behavior. If your DHCP options set is associated with a VPC that has instances with multiple operating systems, specify only one domain name.
-#### Rancher on vSphere with ESXi 6.7u2 and above
+### Rancher on vSphere with ESXi 6.7u2 and above
If you are using Rancher on VMware vSphere with ESXi 6.7u2 or later with Red Hat Enterprise Linux 8.3, CentOS 8.3, or SUSE Enterprise Linux 15 SP2 or later, it is necessary to disable the `vmxnet3` virtual network adapter hardware offloading feature. Failure to do so will result in all network connections between pods on different cluster nodes to fail with timeout errors. All connections from Windows pods to critical services running on Linux nodes, such as CoreDNS, will fail as well. It is also possible that external connections may fail. This issue is the result of Linux distributions enabling the hardware offloading feature in `vmxnet3` and a bug in the `vmxnet3` hardware offloading feature that results in the discarding of packets for guest overlay traffic. To address this issue, it is necessary disable the `vmxnet3` hardware offloading feature. This setting does not survive reboot, so it is necessary to disable on every boot. The recommended course of action is to create a systemd unit file at `/etc/systemd/system/disable_hw_offloading.service`, which disables the `vmxnet3` hardware offloading feature on boot. A sample systemd unit file which disables the `vmxnet3` hardware offloading feature is as follows. Note that `` must be customized to the host `vmxnet3` network interface, e.g., `ens192`:
diff --git a/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md b/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md
index abea9bad31e..9774589340a 100644
--- a/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md
+++ b/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md
@@ -16,6 +16,8 @@ Fleet is a separate project from Rancher, and can be installed on any Kubernetes
- [Windows Support](#windows-support)
- [GitHub Repository](#github-repository)
- [Using Fleet Behind a Proxy](#using-fleet-behind-a-proxy)
+- [Helm Chart Dependencies](#helm-chart-dependencies)
+- [Troubleshooting](#troubleshooting)
- [Documentation](#documentation)
# Architecture
@@ -24,7 +26,24 @@ For information about how Fleet works, see [this page.](./architecture)
# Accessing Fleet in the Rancher UI
-Fleet comes preinstalled in Rancher v2.5. To access it, go to the **Cluster Explorer** in the Rancher UI. In the top left dropdown menu, click **Cluster Explorer > Continuous Delivery.** On this page, you can edit Kubernetes resources and cluster groups managed by Fleet.
+Fleet comes preinstalled in Rancher v2.5. Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).
+
+Follow the steps below to access Continuous Delivery in the Rancher UI:
+
+1. Click **Cluster Explorer** in the Rancher UI.
+
+1. In the top left dropdown menu, click **Cluster Explorer > Continuous Delivery.**
+
+1. Select your namespace at the top of the menu, noting the following:
+ - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
+ - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
+ - You can then manage clusters by clicking on **Clusters** on the left navigation bar.
+
+1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
+
+1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
+
+1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
# Windows Support
@@ -44,6 +63,31 @@ _Available as of v2.5.8_
For details on using Fleet behind a proxy, see [this page.](./proxy)
+# Helm Chart Dependencies
+
+In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing.
+
+The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` OR run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters.
+
+# Troubleshooting
+---
+* **Known Issue:** Fleet becomes inoperable after a restore using the [backup-restore-operator]({{}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
+
+* **Temporary Workaround:**
+ 1. Find the two service account tokens listed in the fleet-controller and the fleet-controller-bootstrap service accounts. These are under the fleet-system namespace of the local cluster.
+ 2. Remove the non-existent token secret. Doing so allows for only one entry to be present for the service account token secret that actually exists.
+ 3. Delete the fleet-controller Pod in the fleet-system namespace to reschedule.
+ 4. After the service account token issue is resolved, you can force redeployment of the fleet-agents. In the Rancher UI, go to **☰ > Cluster Management**, click on **Clusters** page, then click **Force Update**.
+ 5. If the fleet-agent bundles remain in a `Modified` state after Step 4, update the field `spec.forceSyncGeneration` for the fleet-agent bundle to force re-creation.
+
+---
+* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
+
+* **Temporary Workaround:**
+By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
+
+---
+
# Documentation
The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/)
diff --git a/content/rancher/v2.5/en/faq/removing-rancher/_index.md b/content/rancher/v2.5/en/faq/removing-rancher/_index.md
index 49c1acde9bc..e05744e7400 100644
--- a/content/rancher/v2.5/en/faq/removing-rancher/_index.md
+++ b/content/rancher/v2.5/en/faq/removing-rancher/_index.md
@@ -27,7 +27,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
- **Registered clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
- **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
-- **RKE clusters:** To access an [RKE cluster,]({{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) the cluster must have the [authorized cluster endpoint]({{}}/rancher/v2.5/en/overview/architecture/#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.]({{}}/rancher/v2.5/en/overview/architecture/#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.]({{}}/rancher/v2.5/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
+- **RKE clusters:** Please note that you will no longer be able to manage the individual Kubernetes components or perform any upgrades on them after the deletion of the Rancher server. However, you can still access the cluster to manage your workloads. To access an [RKE cluster,]({{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) the cluster must have the [authorized cluster endpoint]({{}}/rancher/v2.5/en/overview/architecture/#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.]({{}}/rancher/v2.5/en/overview/architecture/#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.]({{}}/rancher/v2.5/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
### What if I don't want Rancher anymore?
diff --git a/content/rancher/v2.5/en/faq/technical/_index.md b/content/rancher/v2.5/en/faq/technical/_index.md
index f338f2a0180..9ea91ea6d92 100644
--- a/content/rancher/v2.5/en/faq/technical/_index.md
+++ b/content/rancher/v2.5/en/faq/technical/_index.md
@@ -173,3 +173,8 @@ In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. Se
### Can I use keyboard shortcuts in the UI?
Yes, most parts of the UI can be reached using keyboard shortcuts. For an overview of the available shortcuts, press `?` anywhere in the UI.
+
+
+### What does `Unknown schema for type:` errors followed by something like `catalog.cattle.io.operation` mean when trying to modify an App?
+
+This error occurs when Kubernetes can not find the CRD mentioned. The vast majority of the time these are a result of missing RBAC permissions. Try with an admin user and if this works, add permissions for the resource mentioned by the error (ie. `Get`, `List`, `Patch` as needed).
diff --git a/content/rancher/v2.5/en/helm-charts/_index.md b/content/rancher/v2.5/en/helm-charts/_index.md
index e5e6ba7853e..b74682a0c62 100644
--- a/content/rancher/v2.5/en/helm-charts/_index.md
+++ b/content/rancher/v2.5/en/helm-charts/_index.md
@@ -50,6 +50,39 @@ From the left sidebar select _"Repositories"_.
These items represent helm repositories, and can be either traditional helm endpoints which have an index.yaml, or git repositories which will be cloned and can point to a specific branch. In order to use custom charts, simply add your repository here and they will become available in the Charts tab under the name of the repository.
+To add a private CA for Helm Chart repositories:
+
+- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:
+ ```
+ [...]
+ spec:
+ caBundle:
+ MIIFXzCCA0egAwIBAgIUWNy8WrvSkgNzV0zdWRP79j9cVcEwDQYJKoZIhvcNAQELBQAwPzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtNeU9yZywgSW5jLjENMAsGA1UEAwwEcm9vdDAeFw0yMTEyMTQwODMyMTdaFw0yNDEwMDMwODMyMT
+ ...
+ nDxZ/tNXt/WPJr/PgEB3hQdInDWYMg7vGO0Oz00G5kWg0sJ0ZTSoA10ZwdjIdGEeKlj1NlPyAqpQ+uDnmx6DW+zqfYtLnc/g6GuLLVPamraqN+gyU8CHwAWPNjZonFN9Vpg0PIk1I2zuOc4EHifoTAXSpnjfzfyAxCaZsnTptimlPFJJqAMj+FfDArGmr4=
+ [...]
+ ```
+
+- **Git-based chart repositories**: It is not currently possible to add a private CA. For git-based chart repositories with a certificate signed by a private CA, you must disable TLS verification. Click **Edit YAML** for the chart repo, and add the key/value pair as follows:
+ ```
+ [...]
+ spec:
+ insecureSkipTLSVerify: true
+ [...]
+ ```
+
+> **Note:** Helm chart repositories with authentication
+>
+> As of Rancher v2.5.12, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
+>
+> To use this feature for an existing Helm chart repository, click â‹® > Edit YAML. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
+>
+> ```yaml
+[...]
+spec:
+ disableSameOriginCheck: true
+[...]
+```
### Helm Compatibility
diff --git a/content/rancher/v2.5/en/installation/_index.md b/content/rancher/v2.5/en/installation/_index.md
index 409e36d4d8e..9f49f7a1b73 100644
--- a/content/rancher/v2.5/en/installation/_index.md
+++ b/content/rancher/v2.5/en/installation/_index.md
@@ -17,7 +17,7 @@ In this section,
- **RKE (Rancher Kubernetes Engine)** is a certified Kubernetes distribution and CLI/library which creates and manages a Kubernetes cluster.
- **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB.
- **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
-- **RancherD** is a new tool for installing Rancher, which is available as of Rancher v2.5.4. It is an experimental feature. RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then installs the Rancher server Helm chart on the cluster.
+- **RancherD** was an experimental tool for installing Rancher; a single binary that first launched an RKE2 Kubernetes cluster, then installed the Rancher server Helm chart on the cluster. It was available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
# Changes to Installation in Rancher v2.5
@@ -37,9 +37,7 @@ We recommend using Helm, a Kubernetes package manager, to install Rancher on mul
### High-availability Kubernetes Install with RancherD
-_Available as of v2.5.4_
-
-> This is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then installs the Rancher server Helm chart on the cluster.
diff --git a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md
index 94497592e86..b0e02303a79 100644
--- a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md
+++ b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md
@@ -6,7 +6,7 @@ aliases:
- /rancher/v2.5/en/installation/k8s-install/
- /rancher/v2.5/en/installation/k8s-install/helm-rancher
- /rancher/v2.5/en/installation/k8s-install/kubernetes-rke
- - /rancher/v2.5/en/installation/ha-server-install
+ - /rancher/v2.5/en/installation/ha-server-install
- /rancher/v2.5/en/installation/install-rancher-on-k8s/install
- /rancher/v2.x/en/installation/install-rancher-on-k8s/
---
@@ -24,7 +24,7 @@ In this section, you'll learn how to deploy Rancher on a Kubernetes cluster usin
### Kubernetes Cluster
-Set up the Rancher server's local Kubernetes cluster.
+Set up the Rancher server's local Kubernetes cluster.
Rancher can be installed on any Kubernetes cluster. This cluster can use upstream Kubernetes, or it can use one of Rancher's Kubernetes distributions, or it can be a managed Kubernetes cluster from a provider such as Amazon EKS.
@@ -113,7 +113,7 @@ There are three recommended options for the source of the certificate used for T
### 4. Install cert-manager
-> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{}}/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
+> You should skip this step if you are bringing your own certificate files (option `ingress.tls.source=secret`), or if you use [TLS termination on an external load balancer]({{}}/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/#external-tls-termination).
This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
@@ -157,6 +157,8 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
The exact command to install Rancher differs depending on the certificate configuration.
+However, irrespective of the certificate configuration, the name of the Rancher installation in the `cattle-system` namespace should always be `rancher`.
+
{{% tabs %}}
{{% tab "Rancher-generated Certificates" %}}
@@ -168,7 +170,7 @@ Because `rancher` is the default option for `ingress.tls.source`, we are not spe
- Set `hostname` to the DNS record that resolves to your load balancer.
- Set `replicas` to the number of replicas to use for the Rancher Deployment. This defaults to 3; if you have less than 3 nodes in your cluster you should reduce it accordingly.
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`.
-- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
```
helm install rancher rancher-/rancher \
@@ -190,7 +192,7 @@ deployment "rancher" successfully rolled out
This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA.
->**Note:**: You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
+>**Note:** You need to have port 80 open as the HTTP-01 challenge can only be done on port 80.
In the following command,
@@ -198,8 +200,9 @@ In the following command,
- Set `replicas` to the number of replicas to use for the Rancher Deployment. This defaults to 3; if you have less than 3 nodes in your cluster you should reduce it accordingly.
- Set `ingress.tls.source` to `letsEncrypt`.
- Set `letsEncrypt.email` to the email address used for communication about your certificate (for example, expiry notices).
+- Set `letsEncrypt.ingress.class` to whatever your ingress controller is, e.g., `traefik`, `nginx`, `haproxy`, etc.
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`.
-- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
```
helm install rancher rancher-/rancher \
@@ -207,7 +210,8 @@ helm install rancher rancher-/rancher \
--set hostname=rancher.my.org \
--set replicas=3 \
--set ingress.tls.source=letsEncrypt \
- --set letsEncrypt.email=me@example.org
+ --set letsEncrypt.email=me@example.org \
+ --set letsEncrypt.ingress.class=nginx
```
Wait for Rancher to be rolled out:
@@ -232,7 +236,7 @@ Although an entry in the `Subject Alternative Names` is technically required, ha
- Set `replicas` to the number of replicas to use for the Rancher Deployment. This defaults to 3; if you have less than 3 nodes in your cluster you should reduce it accordingly.
- Set `ingress.tls.source` to `secret`.
- To install a specific Rancher version, use the `--version` flag, example: `--version 2.3.6`.
-- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
+- If you are installing an alpha version, Helm requires adding the `--devel` option to the command.
```
helm install rancher rancher-/rancher \
@@ -245,7 +249,7 @@ helm install rancher rancher-/rancher \
If you are using a Private CA signed certificate , add `--set privateCA=true` to the command:
```
-helm install rancher rancher-latest/rancher \
+helm install rancher rancher-/rancher \
--namespace cattle-system \
--set hostname=rancher.my.org \
--set ingress.tls.source=secret \
diff --git a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/_index.md b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/_index.md
index 5f922b37e88..e1572af146b 100644
--- a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/_index.md
+++ b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/_index.md
@@ -124,7 +124,7 @@ To customize or use a different ingress with Rancher server you can set your own
Example on setting a custom certificate issuer:
```plain
---set ingress.extraAnnotations.'certmanager\.k8s\.io/cluster-issuer'=ca-key-pair
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
```
Example on setting a static proxy header with `ingress.configurationSnippet`. This value is parsed like a template so variables can be used.
diff --git a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/_index.md b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/_index.md
index 49ce4d505fc..8e1acae6ce0 100644
--- a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/_index.md
+++ b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/_index.md
@@ -165,7 +165,7 @@ helm upgrade rancher rancher-/rancher \
### Option B: Reinstalling Rancher and cert-manager
-If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manger due to the API change in cert-manger v0.11.
+If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
1. Uninstall Rancher
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md
index d97e2266801..78daa4f58a0 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md
@@ -115,7 +115,8 @@ helm template cert-manager ./cert-manager-v1.5.1.tgz --output-dir . \
--namespace cert-manager \
--set image.repository=/quay.io/jetstack/cert-manager-controller \
--set webhook.image.repository=/quay.io/jetstack/cert-manager-webhook \
- --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector
+ --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector \
+ --set startupapicheck.image.repository=/quay.io/jetstack/cert-manager-ctl
```
### 4. Download the cert-manager CRD
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md
index d42ee6f04e8..5c152feb541 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md
@@ -66,7 +66,7 @@ In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm fetch jetstack/cert-manager --version v1.5.1
- helm template ./cert-manager-.tgz | grep -oP '(?<=image: ").*(?=")' >> ./rancher-images.txt
+ helm template ./cert-manager-.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
```
2. Sort and unique the images list to remove any overlap between the sources:
@@ -237,7 +237,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm fetch jetstack/cert-manager --version v0.12.0
- helm template ./cert-manager-.tgz | grep -oP '(?<=image: ").*(?=")' >> ./rancher-images.txt
+ helm template ./cert-manager-.tgz | | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt
```
2. Sort and unique the images list to remove any overlap between the sources:
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md
index 4879223c572..84bff627287 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md
@@ -145,7 +145,7 @@ For a how-to guide for setting up a DNS record to route domain traffic to an Ama
Rancher supports air gap installs using a secure Docker private registry. You must have your own private registry or other means of distributing Docker images to your machines.
-In a later step, when you set up your K3s Kubernetes cluster, you will create a [private registries configuration file]({{}}/k3s/latest/en/installation/private-registry/) with details from this registry.
+In a later step, when you set up your RKE Kubernetes cluster, you will create a [private registries configuration file]({{}}/rke/latest/en/config-options/private-registries/) with details from this registry.
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry)
@@ -167,8 +167,6 @@ For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/k3s/latest/en/installation/private-registry/) with details from this registry.
-
If you need help with creating a private registry, please refer to the [official Docker documentation.](https://docs.docker.com/registry/)
{{% /tab %}}
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md
index fac08ab40c9..dfc9854ee4d 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md
@@ -26,14 +26,14 @@ kubectl create namespace cert-manager
Install the CustomResourceDefinitions of cert-manager:
```
-kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.2/cert-manager.crds.yaml
+kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.5.1/cert-manager.crds.yaml
```
And install it with Helm. Note that cert-manager also needs your proxy configured in case it needs to communicate with Let's Encrypt or other external certificate issuers:
```
helm upgrade --install cert-manager jetstack/cert-manager \
- --namespace cert-manager --version v0.15.2 \
+ --namespace cert-manager --version v1.5.1 \
--set http_proxy=http://${proxy_host} \
--set https_proxy=http://${proxy_host} \
--set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
@@ -60,14 +60,16 @@ Create a namespace:
kubectl create namespace cattle-system
```
-And install Rancher with Helm. Rancher also needs a proxy configuration so that it can communicate with external application catalogs or retrieve Kubernetes version update metadata:
+And install Rancher with Helm. Rancher also needs a proxy configuration so that it can communicate with external application catalogs or retrieve Kubernetes version update metadata.
+
+Note that `rancher.cattle-system` must be added to the noProxy list (as shown below) so that Fleet can communicate directly to Rancher with Kubernetes service DNS using service discovery.
```
helm upgrade --install rancher rancher-latest/rancher \
--namespace cattle-system \
--set hostname=rancher.example.com \
--set proxy=http://${proxy_host}
- --set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local
+ --set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local,rancher.cattle-system
```
After waiting for the deployment to finish:
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/_index.md
index 8b3d6e7b472..19c6afd9c62 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/_index.md
@@ -6,9 +6,7 @@ aliases:
- /rancher/v2.x/en/installation/install-rancher-on-linux/
---
-_Available as of Rancher v2.5.4_
-
-> This is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
We are excited to introduce a new, simpler way to install Rancher called RancherD.
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rancherd-configuration/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rancherd-configuration/_index.md
index 770326f9bd7..01986082057 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rancherd-configuration/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rancherd-configuration/_index.md
@@ -6,7 +6,7 @@ aliases:
- /rancher/v2.x/en/installation/install-rancher-on-linux/rancherd-configuration/
---
-> RancherD is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
In RancherD, a server node is defined as a machine (bare-metal or virtual) running the `rancherd server` command. The server runs the Kubernetes API as well as Kubernetes workloads.
@@ -22,7 +22,7 @@ In the RancherD installation instructions, we recommend running three server nod
# Certificates for the Rancher Server
-Rancherd does not use cert-manger to provision certs. Instead RancherD allows you to bring your own self-signed or trusted certs by storing the .pem files in `/etc/rancher/ssl/`. When doing this you should also set the `publicCA` parameter to `true` in your HelmChartConfig. For more information on the HelmChartConfig, refer to the section about [customizing the RancherD Helm chart.](#customizing-the-rancherd-helm-chart)
+Rancherd does not use cert-manager to provision certs. Instead RancherD allows you to bring your own self-signed or trusted certs by storing the .pem files in `/etc/rancher/ssl/`. When doing this you should also set the `publicCA` parameter to `true` in your HelmChartConfig. For more information on the HelmChartConfig, refer to the section about [customizing the RancherD Helm chart.](#customizing-the-rancherd-helm-chart)
Private key: `/etc/rancher/ssl/key.pem`
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rollbacks/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rollbacks/_index.md
index d9144867731..01ade576014 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rollbacks/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/rollbacks/_index.md
@@ -6,6 +6,6 @@ aliases:
- /rancher/v2.x/en/installation/install-rancher-on-linux/rollbacks/
---
-> RancherD is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
To roll back Rancher to a previous version, re-run the installation script with the previous version specified in the `INSTALL_RANCHERD_VERSION` environment variable.
\ No newline at end of file
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/upgrades/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/upgrades/_index.md
index 66f41139153..3f63915f6f5 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/upgrades/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/install-rancher-on-linux/upgrades/_index.md
@@ -6,7 +6,7 @@ aliases:
- /rancher/v2.x/en/installation/install-rancher-on-linux/upgrades/
---
-> RancherD is an experimental feature.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
When RancherD is upgraded, the Rancher Helm controller and the Fleet pods are upgraded.
diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md
index ce5f6c3f6c2..6c55386d77d 100644
--- a/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md
+++ b/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md
@@ -87,7 +87,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
```
- docker run --volumes-from rancher-data -v $PWD:/backup busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher
+ docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher
```
**Step Result:** When you enter this command, a series of commands should run.
diff --git a/content/rancher/v2.5/en/installation/requirements/_index.md b/content/rancher/v2.5/en/installation/requirements/_index.md
index 77d8abc2244..41eda67564e 100644
--- a/content/rancher/v2.5/en/installation/requirements/_index.md
+++ b/content/rancher/v2.5/en/installation/requirements/_index.md
@@ -80,7 +80,7 @@ If you are installing Rancher on a K3s cluster with Alpine Linux, follow [these
### RancherD Specific Requirements
-_The RancherD install is available as of v2.5.4. It is an experimental feature._
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
At this time, only Linux OSes that leverage systemd are supported.
@@ -103,6 +103,7 @@ The Ingress should be deployed as DaemonSet to ensure your load balancer can suc
Docker is required for Helm chart installs, and it can be installed by following the steps in the official [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{}}/rancher/v2.5/en/installation/requirements/installing-docker) to install Docker with one command.
Docker is not required for RancherD installs.
+
# Hardware Requirements
The following sections describe the CPU, memory, and disk requirements for the nodes where the Rancher server is installed.
@@ -125,7 +126,7 @@ These requirements apply to RKE Kubernetes clusters, as well as to hosted Kubern
| X-Large | Up to 1000 | Up to 10,000 | 16 | 64 GB |
| XX-Large | Up to 2000 | Up to 20,000 | 32 | 128 GB |
-[Contact Rancher](https://rancher.com/contact/) for more than 2000 clusters and/or 20,000 nodes.
+Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
### K3s Kubernetes
@@ -139,11 +140,11 @@ These CPU and memory requirements apply to each host in a [K3s Kubernetes cluste
| X-Large | Up to 1000 | Up to 10,000 | 16 | 64 GB | 2 cores, 4 GB + 1000 IOPS |
| XX-Large | Up to 2000 | Up to 20,000 | 32 | 128 GB | 2 cores, 4 GB + 1000 IOPS |
-[Contact Rancher](https://rancher.com/contact/) for more than 2000 clusters and/or 20,000 nodes.
+Every use case and environment is different. Please [contact Rancher](https://rancher.com/contact/) to review yours.
### RancherD
-_RancherD is available as of v2.5.4. It is an experimental feature._
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
These CPU and memory requirements apply to each instance with RancherD installed. Minimum recommendations are outlined here.
@@ -176,7 +177,7 @@ Each node in the Kubernetes cluster that Rancher is installed on should run an I
The Ingress should be deployed as DaemonSet to ensure your load balancer can successfully route traffic to all nodes.
-For RKE, K3s and RancherD installations, you don't have to install the Ingress manually because is is installed by default.
+For RKE, K3s and RancherD installations, you don't have to install the Ingress manually because it is installed by default.
For hosted Kubernetes clusters (EKS, GKE, AKS) and RKE2 Kubernetes installations, you will need to set up the ingress.
diff --git a/content/rancher/v2.5/en/installation/requirements/installing-docker/_index.md b/content/rancher/v2.5/en/installation/requirements/installing-docker/_index.md
index 02a005d245f..8b16d157505 100644
--- a/content/rancher/v2.5/en/installation/requirements/installing-docker/_index.md
+++ b/content/rancher/v2.5/en/installation/requirements/installing-docker/_index.md
@@ -3,7 +3,7 @@ title: Installing Docker
weight: 1
---
-For Helm CLI installs, Docker is required to be installed on any node that runs the Rancher server.
+Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
diff --git a/content/rancher/v2.5/en/installation/requirements/ports/_index.md b/content/rancher/v2.5/en/installation/requirements/ports/_index.md
index fb88592b0ca..af7f109a891 100644
--- a/content/rancher/v2.5/en/installation/requirements/ports/_index.md
+++ b/content/rancher/v2.5/en/installation/requirements/ports/_index.md
@@ -119,6 +119,8 @@ The following tables break down the port requirements for inbound and outbound t
### Ports for Rancher Server Nodes on RancherD or RKE2
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
+
{{% accordion label="Click to expand" %}}
The RancherD (or RKE2) server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
diff --git a/content/rancher/v2.5/en/installation/resources/advanced/firewall/_index.md b/content/rancher/v2.5/en/installation/resources/advanced/firewall/_index.md
index b779951aa7b..2ff27022f24 100644
--- a/content/rancher/v2.5/en/installation/resources/advanced/firewall/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/advanced/firewall/_index.md
@@ -5,7 +5,7 @@ aliases:
- /rancher/v2.x/en/installation/resources/advanced/firewall/
---
-> We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off.
+> We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
diff --git a/content/rancher/v2.5/en/installation/resources/choosing-version/_index.md b/content/rancher/v2.5/en/installation/resources/choosing-version/_index.md
index 9d7ec763c11..618e8e36c33 100644
--- a/content/rancher/v2.5/en/installation/resources/choosing-version/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/choosing-version/_index.md
@@ -14,6 +14,8 @@ For Docker installations of Rancher, which is used for development and testing,
The Helm chart version also applies to RancherD installs because RancherD installs the Rancher Helm chart on a Kubernetes cluster.
+> **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
+
{{% tabs %}}
{{% tab "Helm Charts" %}}
diff --git a/content/rancher/v2.5/en/installation/resources/feature-flags/_index.md b/content/rancher/v2.5/en/installation/resources/feature-flags/_index.md
index d134423b4cb..b06257e74e4 100644
--- a/content/rancher/v2.5/en/installation/resources/feature-flags/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/feature-flags/_index.md
@@ -56,7 +56,7 @@ When you install Rancher, enable the feature you want with a feature flag. The c
> **Note:** Values set from the Rancher API will override the value passed in through the command line.
-When installing Rancher with a Helm chart, use the `--features` option. In the below example, two features are enabled by passing the feature flag names names in a comma separated list:
+When installing Rancher with a Helm chart, use the `--set` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:
```
helm install rancher-latest/rancher \
@@ -131,7 +131,7 @@ When installing Rancher with Docker, use the `--features` option. In the below e
docker run -d -p 80:80 -p 443:443 \
--restart=unless-stopped \
rancher/rancher:rancher-latest \
- --features==true,=true
+ --features==true,=true
```
diff --git a/content/rancher/v2.5/en/installation/resources/installing-docker/_index.md b/content/rancher/v2.5/en/installation/resources/installing-docker/_index.md
deleted file mode 100644
index ceb75b12645..00000000000
--- a/content/rancher/v2.5/en/installation/resources/installing-docker/_index.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Installing Docker
-weight: 1
-aliases:
- - /rancher/v2.5/en/installation/requirements/installing-docker
----
-
-Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker. Docker is not required for RancherD installs.
-
-There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution.
-
-Another option is to use one of Rancher's Docker installation scripts, which are available for most recent versions of Docker.
-
-For example, this command could be used to install Docker 19.03 on Ubuntu:
-
-```
-curl https://releases.rancher.com/install-docker/19.03.sh | sh
-```
-
-Rancher has installation scripts for every version of upstream Docker that Kubernetes supports. To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher's Docker installation scripts.
\ No newline at end of file
diff --git a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md
index 64d7472dbdd..788a80c1e4a 100644
--- a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md
@@ -8,7 +8,7 @@ aliases:
---
_Tested on v2.5.6_
-This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/#environment-for-kubernetes-installations)
+This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.]({{}}/rancher/v2.5/en/overview/architecture-recommendations/#environment-for-kubernetes-installations)
# Prerequisites
diff --git a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md
index ac26cf28e2a..0f4d80d55c1 100644
--- a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md
@@ -19,9 +19,9 @@ To install the Rancher management server on a high-availability RKE2 cluster, we
### 1. Set up Linux Nodes
-Make sure that your nodes fulfill the general installation requirements for [OS, container runtime, hardware, and networking.]({{}}/rancher/v2.x/en/installation/requirements/)
+Make sure that your nodes fulfill the general installation requirements for [OS, container runtime, hardware, and networking.]({{}}/rancher/v2.5/en/installation/requirements/)
-For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/rancher/v2.x/en/installation/options/ec2-node) for setting up nodes as instances in Amazon EC2.
+For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/rancher/v2.5/en/installation/options/ec2-node) for setting up nodes as instances in Amazon EC2.
### 2. Set up the Load Balancer
@@ -34,11 +34,11 @@ When Rancher is installed (also in a later step), the Rancher system creates an
For your implementation, consider if you want or need to use a Layer-4 or Layer-7 load balancer:
- **A layer-4 load balancer** is the simpler of the two choices, in which you are forwarding TCP traffic to your nodes. We recommend configuring your load balancer as a Layer 4 balancer, forwarding traffic to ports TCP/80 and TCP/443 to the Rancher management cluster nodes. The Ingress controller on the cluster will redirect HTTP traffic to HTTPS and terminate SSL/TLS on port TCP/443. The Ingress controller will forward traffic to port TCP/80 to the Ingress pod in the Rancher deployment.
-- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.]({{}}/rancher/v2.x/en/installation/options/chart-options/#external-tls-termination)
+- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.]({{}}/rancher/v2.5/en/installation/options/chart-options/#external-tls-termination)
-For an example showing how to set up an NGINX load balancer, refer to [this page.]({{}}/rancher/v2.x/en/installation/options/nginx/)
+For an example showing how to set up an NGINX load balancer, refer to [this page.]({{}}/rancher/v2.5/en/installation/options/nginx/)
-For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{}}/rancher/v2.x/en/installation/options/nlb/)
+For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{}}/rancher/v2.5/en/installation/options/nlb/)
> **Important:**
> Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
diff --git a/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md b/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md
index 850856ff865..9878109b8b6 100644
--- a/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md
@@ -38,4 +38,4 @@ kubectl -n cattle-system create secret generic tls-ca \
# Updating a Private CA Certificate
-Follow the steps on [this page]({{}}/rancher/v2.x/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.5/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate.
\ No newline at end of file
+Follow the steps on [this page]({{}}/rancher/v2.5/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.5/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate.
\ No newline at end of file
diff --git a/content/rancher/v2.5/en/installation/resources/update-ca-cert/_index.md b/content/rancher/v2.5/en/installation/resources/update-ca-cert/_index.md
index c256f9f5905..751feae2d8c 100644
--- a/content/rancher/v2.5/en/installation/resources/update-ca-cert/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/update-ca-cert/_index.md
@@ -13,6 +13,7 @@ A summary of the steps is as follows:
2. Create or update the `tls-ca` Kubernetes secret resource with the root CA certificate (only required when using a private CA).
3. Update the Rancher installation using the Helm CLI.
4. Reconfigure the Rancher agents to trust the new CA certificate.
+5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher.
The details of these instructions are below.
@@ -145,3 +146,12 @@ First, generate the agent definitions as described here: https://gist.github.com
Then, connect to a controlplane node of the downstream cluster via SSH, create a Kubeconfig and apply the definitions:
https://gist.github.com/superseb/b14ed3b5535f621ad3d2aa6a4cd6443b
+
+
+# 5. Select Force Update of Fleet clusters to connect fleet-agent to Rancher
+
+Select 'Force Update' for the clusters within the [Continuous Delivery]({{}}/rancher/v2.5/en/deploy-across-clusters/fleet/#accessing-fleet-in-the-rancher-ui) view under Cluster Explorer in the Rancher UI to allow the fleet-agent in downstream clusters to successfully connect to Rancher.
+
+### Why is this step required?
+
+Fleet agents in Rancher managed clusters store kubeconfig that is used to connect to the Rancher proxied kube-api in the fleet-agent secret of the fleet-system namespace. The kubeconfig contains a certificate-authority-data block containing the Rancher CA. When changing the Rancher CA, this block needs to be updated for a successful connection of the fleet-agent to Rancher.
diff --git a/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/_index.md b/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/_index.md
index a3be656b66a..9b557f0ccc7 100644
--- a/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/_index.md
@@ -20,7 +20,7 @@ To address these changes, this guide will do two things:
1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data
> **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
diff --git a/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md b/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md
index 761a2487d26..070dff28f02 100644
--- a/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md
+++ b/content/rancher/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/_index.md
@@ -18,7 +18,7 @@ To address these changes, this guide will do two things:
1. Explain the cert-manager API changes and link to cert-manager's offficial documentation for migrating your data
> **Important:**
-> If you are currently running the cert-manger whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
+> If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, you need to reinstall both of them:
> 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
> 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
diff --git a/content/rancher/v2.5/en/k8s-in-rancher/workloads/deploy-workloads/_index.md b/content/rancher/v2.5/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
index c27ebdcc9e6..4d90d3f5db1 100644
--- a/content/rancher/v2.5/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
+++ b/content/rancher/v2.5/en/k8s-in-rancher/workloads/deploy-workloads/_index.md
@@ -16,7 +16,7 @@ Deploy a workload to run an application in one or more containers.
1. Enter a **Name** for the workload.
-1. Select a [workload type]({{}}/rancher/v2.5/en/k8s-in-rancher/workloads/). The workload defaults to a scalable deployment, by can change the workload type by clicking **More options.**
+1. Select a [workload type]({{}}/rancher/v2.5/en/k8s-in-rancher/workloads/). The workload defaults to a scalable deployment, but you can change the workload type by clicking **More options.**
1. From the **Docker Image** field, enter the name of the Docker image that you want to deploy to the project, optionally prefacing it with the registry host (e.g. `quay.io`, `registry.gitlab.com`, etc.). During deployment, Rancher pulls this image from the specified public or private registry. If no registry host is provided, Rancher will pull the image from [Docker Hub](https://hub.docker.com/explore/). Enter the name exactly as it appears in the registry server, including any required path, and optionally including the desired tag (e.g. `registry.gitlab.com/user/path/image:tag`). If no tag is provided, the `latest` tag will be automatically used.
diff --git a/content/rancher/v2.5/en/monitoring-alerting/configuration/_index.md b/content/rancher/v2.5/en/monitoring-alerting/configuration/_index.md
index e56978fbb98..2d7867cbc4c 100644
--- a/content/rancher/v2.5/en/monitoring-alerting/configuration/_index.md
+++ b/content/rancher/v2.5/en/monitoring-alerting/configuration/_index.md
@@ -15,6 +15,8 @@ For information on configuring custom scrape targets and rules for Prometheus, p
The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](./helm-chart-options/#configuring-resource-limits-and-requests)
+>**Note:** On an idle cluster, Monitoring V2 has significantly higher CPU usage (up to 70%) as compared to Monitoring V1. To improve performance and achieve similar results as in Monitoring V1, turn off the Prometheus adapter.
+
# Prometheus Configuration
It is usually not necessary to directly edit the Prometheus custom resource.
diff --git a/content/rancher/v2.5/en/monitoring-alerting/configuration/servicemonitor-podmonitor/_index.md b/content/rancher/v2.5/en/monitoring-alerting/configuration/servicemonitor-podmonitor/_index.md
index 79f3da27930..39ddfd2b5a0 100644
--- a/content/rancher/v2.5/en/monitoring-alerting/configuration/servicemonitor-podmonitor/_index.md
+++ b/content/rancher/v2.5/en/monitoring-alerting/configuration/servicemonitor-podmonitor/_index.md
@@ -26,6 +26,6 @@ For more information about how ServiceMonitors work, refer to the [Prometheus Op
This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how group of pods should be monitored.
-When a PodMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the PodMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the ServiceMonitor.
+When a PodMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the PodMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the PodMonitor.
Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#podmonitorspec) provided by Prometheus Operator.
diff --git a/content/rancher/v2.5/en/monitoring-alerting/how-monitoring-works/_index.md b/content/rancher/v2.5/en/monitoring-alerting/how-monitoring-works/_index.md
index 6445df9e75a..30b19cdbc66 100644
--- a/content/rancher/v2.5/en/monitoring-alerting/how-monitoring-works/_index.md
+++ b/content/rancher/v2.5/en/monitoring-alerting/how-monitoring-works/_index.md
@@ -11,52 +11,78 @@ weight: 1
# 1. Architecture Overview
-This diagram shows how data flows through the Monitoring V2 application:
+_**The following sections describe how data flows through the Monitoring V2 application:**_
-{{% row %}}
-{{% column %}}
+### Prometheus Operator
-
+Prometheus Operator observes ServiceMonitors, PodMonitors, and PrometheusRules being created. When the Prometheus configuration resources are created, Prometheus Operator calls the Prometheus API to sync the new configuration. As the diagram at the end of this section shows, the Prometheus Operator acts as the intermediary between Prometheus and Kubernetes, calling the Prometheus API to synchronize Prometheus with the monitoring-related resources in Kubernetes.
-{{% /column %}}
-{{% column %}}
+### ServiceMonitors and PodMonitors
+ServiceMonitors and PodMonitors declaratively specify targets, such as Services and Pods, that need to be monitored.
-1. Rules define what Prometheus metrics or time series database queries should result in alerts being fired.
-2. ServiceMonitors and PodMonitors declaratively specify how services and pods should be monitored. They use labels to scrape metrics from pods.
-3. Prometheus Operator observes ServiceMonitors, PodMonitors and PrometheusRules being created.
-4. When the Prometheus configuration resources are created, Prometheus Operator calls the Prometheus API to sync the new configuration.
-5. Recording Rules are not directly used for alerting. They create new time series of precomputed queries. These new time series data can then be queried to generate alerts.
-6. Prometheus scrapes all targets in the scrape configuration on a recurring schedule based on the scrape interval, storing the results in its time series database.Depending on the Kubernetes master component and Kubernetes distribution, the metrics from a certain Kubernetes component could be directly exposed to Prometheus, proxied through PushProx, or not available. For details, see Scraping and Exposing Metrics.
-7. Prometheus evaluates the alerting rules against the time series database. It fires alerts to Alertmanager whenever an alerting rule evaluates to a positive number.
-8. Alertmanager uses routes to group, label and filter the fired alerts to translate them into useful notifications.
-9. Alertmanager uses the Receiver configuration to send notifications to Slack, PagerDuty, SMS, or other types of receivers.
+- Targets are scraped on a recurring schedule based on the configured Prometheus scrape interval, and the metrics that are scraped are stored into the Prometheus Time Series Database (TSDB).
-{{% /column %}}
-{{% /row %}}
+- In order to perform the scrape, ServiceMonitors and PodMonitors are defined with label selectors that determine which Services or Pods should be scraped and endpoints that determine how the scrape should happen on the given target, e.g., scrape/metrics in TCP 10252, proxying through IP addr x.x.x.x.
+- Out of the box, Monitoring V2 comes with certain pre-configured exporters that are deployed based on the type of Kubernetes cluster that it is deployed on. For more information, see [Scraping and Exposing Metrics](#5-scraping-and-exposing-metrics).
+### How PushProx Works
+
+- Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called **PushProx**. The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
+`kube-controller-manager`, `kube-scheduler`, `etcd`, and `kube-proxy`.
+
+- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
+
+- We deploy exactly one PushProx proxy per exporter. The process for exporting metrics is as follows:
+
+1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
+1. The client then polls the proxy for scrape requests that have come into the proxy.
+1. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
+1. The client scrapes the internal component.
+1. The internal component responds by pushing metrics back to the proxy.
+
+
+
Process for Exporting Metrics with PushProx:
+
+
+
+### PrometheusRules
+
+PrometheusRules allow users to define rules for what metrics or time series database queries should result in alerts being fired. Rules are evaluated on an interval.
+
+- **Recording rules** create a new time series based on existing series that have been collected. They are frequently used to precompute complex queries.
+- **Alerting rules** run a particular query and fire an alert from Prometheus if the query evaluates to a non-zero value.
+
+### Alert Routing
+
+Once Prometheus determines that an alert needs to be fired, alerts are forwarded to **Alertmanager**.
+
+- Alerts contain labels that come from the PromQL query itself and additional labels and annotations that can be provided as part of specifying the initial PrometheusRule.
+
+- Before receiving any alerts, Alertmanager will use the **routes** and **receivers** specified in its configuration to form a routing tree on which all incoming alerts are evaluated. Each node of the routing tree can specify additional grouping, labeling, and filtering that needs to happen based on the labels attached to the Prometheus alert. A node on the routing tree (usually a leaf node) can also specify that an alert that reaches it needs to be sent out to a configured Receiver, e.g., Slack, PagerDuty, SMS, etc. Note that Alertmanager will send an alert first to **alertingDriver**, then alertingDriver will send or forward alert to the proper destination.
+
+- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
+
+How data flows through the monitoring application:
# 2. How Prometheus Works
-### 2.1. Storing Time Series Data
+### Storing Time Series Data
After collecting metrics from exporters, Prometheus stores the time series in a local on-disk time series database. Prometheus optionally integrates with remote systems, but `rancher-monitoring` uses local storage for the time series database.
-The database can then be queried using PromQL, the query language for Prometheus. Grafana dashboards use PromQL queries to generate data visualizations.
+Once stored, users can query this TSDB using PromQL, the query language for Prometheus.
-### 2.2. Querying the Time Series Database
+PromQL queries can be visualized in one of two ways:
-The PromQL query language is the primary tool to query Prometheus for time series data.
+1. By supplying the query in Prometheus's Graph UI, which will show a simple graphical view of the data.
+1. By creating a Grafana Dashboard that contains the PromQL query and additional formatting directives that label axes, add units, change colors, use alternative visualizations, etc.
-In Grafana, you can right-click a CPU utilization and click Inspect. This opens a panel that shows the [raw query results.](https://grafana.com/docs/grafana/latest/panels/inspect-panel/#inspect-raw-query-results)The raw results demonstrate how each dashboard is powered by PromQL queries.
+### Defining Rules for Prometheus
-### 2.3. Defining Rules for when Alerts Should be Fired
-
-Rules define the conditions for Prometheus to fire alerts. When PrometheusRule custom resources are created or updated, the Prometheus Operator observes the change and calls the Prometheus API to synchronize the rule configuration with the Alerting Rules and Recording Rules in Prometheus.
-
-When you define a Rule (which is declared within a RuleGroup in a PrometheusRule resource), the [spec of the Rule itself](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#rule) contains labels that are used by Alertmanager to figure out which Route should receive this Alert. For example, an Alert with the label `team: front-end` will be sent to all Routes that match on that label.
+Rules define queries that Prometheus needs to execute on a regular `evaluationInterval` to perform certain actions, such as firing an alert (alerting rules) or precomputing a query based on others existing in its TSDB (recording rules). These rules are encoded in PrometheusRules custom resources. When PrometheusRule custom resources are created or updated, the Prometheus Operator observes the change and calls the Prometheus API to synchronize the set of rules that Prometheus is currently evaluating on a regular interval.
A PrometheusRule allows you to define one or more RuleGroups. Each RuleGroup consists of a set of Rule objects that can each represent either an alerting or a recording rule with the following fields:
@@ -65,7 +91,9 @@ A PrometheusRule allows you to define one or more RuleGroups. Each RuleGroup con
- Labels that should be attached to the alert or record that identify it (e.g. cluster name or severity)
- Annotations that encode any additional important pieces of information that need to be displayed on the notification for an alert (e.g. summary, description, message, runbook URL, etc.). This field is not required for recording rules.
-### 2.4. Firing Alerts
+On evaluating a [rule](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#rule), Prometheus will execute the provided PromQL query, add additional provided labels (or annotations - only for alerting rules), and execute the appropriate action for the rule. For example, an Alerting Rule that adds `team: front-end` as a label to the provided PromQL query will append that label to the fired alert, which will allow Alertmanager to forward the alert to the correct Receiver.
+
+### Alerting and Recording Rules
Prometheus doesn't maintain the state of whether alerts are active. It fires alerts repetitively at every evaluation interval, relying on Alertmanager to group and filter the alerts into meaningful notifications.
@@ -80,6 +108,7 @@ Alerting rules are more commonly used. Whenever an alerting rule evaluates to a
The Rule file adds labels and annotations to alerts before firing them, depending on the use case:
- Labels indicate information that identifies the alert and could affect the routing of the alert. For example, if when sending an alert about a certain container, the container ID could be used as a label.
+
- Annotations denote information that doesn't affect where an alert is routed, for example, a runbook or an error message.
# 3. How Alertmanager Works
@@ -87,17 +116,24 @@ The Rule file adds labels and annotations to alerts before firing them, dependin
The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of the following tasks:
- Deduplicating, grouping, and routing alerts to the correct receiver integration such as email, PagerDuty, or OpsGenie
+
- Silencing and inhibition of alerts
+
- Tracking alerts that fire over time
+
- Sending out the status of whether an alert is currently firing, or if it is resolved
+
+### Alerts Forwarded by alertingDrivers
+
+When alertingDrivers are installed, this creates a `Service` that can be used as the receiver's URL for Teams or SMS, based on the alertingDriver's configuration. The URL in the Receiver points to the alertingDrivers; so the Alertmanager sends alert first to alertingDriver, then alertingDriver forwards or sends alert to the proper destination.
-### 3.1. Routing Alerts to Receivers
+### Routing Alerts to Receivers
Alertmanager coordinates where alerts are sent. It allows you to group alerts based on labels and fire them based on whether certain labels are matched. One top-level route accepts all alerts. From there, Alertmanager continues routing alerts to receivers based on whether they match the conditions of the next route.
-While the Rancher UI forms only allow editing a routing tree that is two levels deep, you can configure more deeply nested routing structures by editing the Alertmanager custom resource YAML.
+While the Rancher UI forms only allow editing a routing tree that is two levels deep, you can configure more deeply nested routing structures by editing the Alertmanager Secret.
-### 3.2. Configuring Multiple Receivers
+### Configuring Multiple Receivers
By editing the forms in the Rancher UI, you can set up a Receiver resource with all the information Alertmanager needs to send alerts to your notification system.
@@ -109,120 +145,89 @@ Prometheus Operator introduces a set of [Custom Resource Definitions](https://gi
Prometheus Operator will automatically update your Prometheus configuration based on the live state of the resources and configuration options that are edited in the Rancher UI.
-### 4.1. Resources Deployed by Default
+### Resources Deployed by Default
By default, a set of resources curated by the [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) project are deployed onto your cluster as part of installing the Rancher Monitoring Application to set up a basic Monitoring/Alerting stack.
The resources that get deployed onto your cluster to support this solution can be found in the [`rancher-monitoring`](https://github.com/rancher/charts/tree/main/charts/rancher-monitoring) Helm chart, which closely tracks the upstream [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) Helm chart maintained by the Prometheus community with certain changes tracked in the [CHANGELOG.md](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring/CHANGELOG.md).
-There are also certain special types of ConfigMaps and Secrets such as those corresponding to Grafana Dashboards, Grafana Datasources, and Alertmanager Configs that will automatically update your Prometheus configuration via sidecar proxies that observe the live state of those resources within your cluster.
+### Default Exporters
-### 4.2. PushProx
+Monitoring V2 deploys three default exporters that provide additional metrics for Prometheus to store:
-PushProx enhances the security of the monitoring application, allowing it to be installed on hardened Kubernetes clusters.
+1. `node-exporter`: exposes hardware and OS metrics for Linux hosts. For more information on `node-exporter`, refer to the [upstream documentation](https://prometheus.io/docs/guides/node-exporter/).
-To expose Kubernetes metrics, PushProxes use a client proxy model to expose specific ports within default Kubernetes components. Node exporters expose metrics to PushProx through an outbound connection.
+1. `windows-exporter`: exposes hardware and OS metrics for Windows hosts (only deployed on Windows clusters). For more information on `windows-exporter`, refer to the [upstream documentation](https://github.com/prometheus-community/windows_exporter).
-The proxy allows `rancher-monitoring` to scrape metrics from processes on the hostNetwork, such as the `kube-api-server`, without opening up node ports to inbound connections.
+1. `kube-state-metrics`: expose additional metrics that track the state of resources contained in the Kubernetes API (e.g., pods, workloads, etc.). For more information on `kube-state-metrics`, refer to the [upstream documentation](https://github.com/kubernetes/kube-state-metrics/tree/master/docs).
-PushProx is a DaemonSet that listens for clients that seek to register. Once registered, it proxies scrape requests through the established connection. Then the client executes the request to etcd.
+ServiceMonitors and PodMonitors will scrape these exporters, as defined [here](#defining-what-metrics-are-scraped). Prometheus stores these metrics, and you can query the results via either Prometheus's UI or Grafana.
-All of the default ServiceMonitors, such as `rancher-monitoring-kube-controller-manager`, are configured to hit the metrics endpoint of the client using this proxy.
+See the [architecture](#1-architecture-overview) section for more information on recording rules, alerting rules, and Alertmanager.
-For more details about how PushProx works, refer to [Scraping Metrics with PushProx.](#5-5-scraping-metrics-with-pushprox)
-
-
-### 4.3. Default Exporters
-
-`rancher-monitoring` deploys two exporters to expose metrics to prometheus: `node-exporter` and `windows-exporter`. Both are deployed as DaemonSets.
-
-`node-exporter` exports container, pod and node metrics for CPU and memory from each Linux node. `windows-exporter` does the same, but for Windows nodes.
-
-For more information on `node-exporter`, refer to the [upstream documentation.](https://prometheus.io/docs/guides/node-exporter/)
-
-[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) is also useful because it exports metrics for Kubernetes components.
-
-### 4.4. Components Exposed in the Rancher UI
+### Components Exposed in the Rancher UI
When the monitoring application is installed, you will be able to edit the following components in the Rancher UI:
| Component | Type of Component | Purpose and Common Use Cases for Editing |
|--------------|------------------------|---------------------------|
-| ServiceMonitor | Custom resource | Set up targets to scrape custom metrics from. Automatically updates the scrape configuration in the Prometheus custom resource. |
-| PodMonitor | Custom resource | Set up targets to scrape custom metrics from. Automatically updates the scrape configuration in the Prometheus custom resource. |
-| Receiver | Configuration block (part of Alertmanager) | Set up a notification system to receive alerts. Automatically updates the Alertmanager custom resource. |
-| Route | Configuration block (part of Alertmanager) | Add identifying information to make alerts more meaningful and direct them to individual teams. Automatically updates the Alertmanager custom resource. |
-| PrometheusRule | Custom resource | For more advanced use cases, you may want to define what Prometheus metrics or time series database queries should result in alerts being fired. Automatically updates the Prometheus custom resource. |
-| Alertmanager | Custom resource | Edit this custom resource only if you need more advanced configuration options beyond what the Rancher UI exposes in the Routes and Receivers sections. For example, you might want to edit this resource to add a routing tree with more than two levels. |
-| Prometheus | Custom resource | Edit this custom resource only if you need more advanced configuration beyond what can be configured using ServiceMonitors, PodMonitors, or [Rancher monitoring Helm chart options.](../configuration/helm-chart-options) |
+| ServiceMonitor | Custom resource | Sets up Kubernetes Services to scrape custom metrics from. Automatically updates the scrape configuration in the Prometheus custom resource. |
+| PodMonitor | Custom resource | Sets up Kubernetes Pods to scrape custom metrics from. Automatically updates the scrape configuration in the Prometheus custom resource. |
+| Receiver | Configuration block (part of Alertmanager) | Modifies information on where to send an alert (e.g., Slack, PagerDuty, etc.) and any necessary information to send the alert (e.g., TLS certs, proxy URLs, etc.). Automatically updates the Alertmanager custom resource. |
+| Route | Configuration block (part of Alertmanager) | Modifies the routing tree that is used to filter, label, and group alerts based on labels and send them to the appropriate Receiver. Automatically updates the Alertmanager custom resource. |
+| PrometheusRule | Custom resource | Defines additional queries that need to trigger alerts or define materialized views of existing series that are within Prometheus's TSDB. Automatically updates the Prometheus custom resource. |
+
+### PushProx
+
+PushProx allows Prometheus to scrape metrics across a network boundary, which prevents users from having to expose metrics ports for internal Kubernetes components on each node in a Kubernetes cluster.
+
+Since the metrics for Kubernetes components are generally exposed on the host network of nodes in the cluster, PushProx deploys a DaemonSet of clients that sit on the hostNetwork of each node and make an outbound connection to a single proxy that is sitting on the Kubernetes API. Prometheus can then be configured to proxy scrape requests through the proxy to each client, which allows it to scrape metrics from the internal Kubernetes components without requiring any inbound node ports to be open.
+
+Refer to [Scraping Metrics with PushProx](#scraping-metrics-with-pushprox) for more.
# 5. Scraping and Exposing Metrics
-### 5.1. Defining what Metrics are Scraped
+### Defining what Metrics are Scraped
-ServiceMonitors define targets that are intended for Prometheus to scrape. The [Prometheus custom resource tells](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md#prometheus) Prometheus which ServiceMonitors it should use to find out where to scrape metrics from.
+ServiceMonitors and PodMonitors define targets that are intended for Prometheus to scrape. The [Prometheus custom resource](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md#prometheus) tells Prometheus which ServiceMonitors or PodMonitors it should use to find out where to scrape metrics from.
-The Prometheus Operator observes the ServiceMonitors. When it observes that ServiceMonitors are created or updated, it calls the Prometheus API to update the scrape configuration in the Prometheus custom resource and keep it in sync with the scrape configuration in the ServiceMonitors. This scrape configuration tells Prometheus which endpoints to scrape metrics from and how it will label the metrics from those endpoints.
+The Prometheus Operator observes the ServiceMonitors and PodMonitors. When it observes that they are created or updated, it calls the Prometheus API to update the scrape configuration in the Prometheus custom resource and keep it in sync with the scrape configuration in the ServiceMonitors or PodMonitors. This scrape configuration tells Prometheus which endpoints to scrape metrics from and how it will label the metrics from those endpoints.
Prometheus scrapes all of the metrics defined in its scrape configuration at every `scrape_interval`, which is one minute by default.
The scrape configuration can be viewed as part of the Prometheus custom resource that is exposed in the Rancher UI.
-### 5.2. How the Prometheus Operator Sets up Metrics Scraping
+### How the Prometheus Operator Sets up Metrics Scraping
The Prometheus Deployment or StatefulSet scrapes metrics, and the configuration of Prometheus is controlled by the Prometheus custom resources. The Prometheus Operator watches for Prometheus and Alertmanager resources, and when they are created, the Prometheus Operator creates a Deployment or StatefulSet for Prometheus or Alertmanager with the user-defined configuration.
-How the Prometheus Operator Sets up Metrics Scraping
+When the Prometheus Operator observes ServiceMonitors, PodMonitors, and PrometheusRules being created, it knows that the scrape configuration needs to be updated in Prometheus. It updates Prometheus by first updating the configuration and rules files in the volumes of Prometheus's Deployment or StatefulSet. Then it calls the Prometheus API to sync the new configuration, resulting in the Prometheus Deployment or StatefulSet to be modified in place.
-
-
-When the Prometheus Operator observes ServiceMonitors, PodMonitors and PrometheusRules being created, it knows that the scrape configuration needs to be updated in Prometheus. It updates Prometheus by first updating the configuration and rules files in the volumes of Prometheus's Deployment or StatefulSet. Then it calls the Prometheus API to sync the new configuration, resulting in the Prometheus Deployment or StatefulSet to be modified in place.
-
-
-
-### 5.3. How Kubernetes Component Metrics are Exposed
+### How Kubernetes Component Metrics are Exposed
Prometheus scrapes metrics from deployments known as [exporters,](https://prometheus.io/docs/instrumenting/exporters/) which export the time series data in a format that Prometheus can ingest. In Prometheus, time series consist of streams of timestamped values belonging to the same metric and the same set of labeled dimensions.
-To allow monitoring to be installed on hardened Kubernetes clusters, `rancher-monitoring` application proxies the communication between Prometheus and the exporter through PushProx for some Kubernetes master components.
+### Scraping Metrics with PushProx
-### 5.4. Scraping Metrics without PushProx
+Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called PushProx. For detailed information on PushProx, refer [here](#how-pushprox-works) and to the above [architecture](#1-architecture-overview) section.
-The Kubernetes components that directly expose metrics to Prometheus are the following:
+### Scraping Metrics
-- kubelet
-- ingress-nginx*
+The following Kubernetes components are directly scraped by Prometheus:
+
+- kubelet*
+- ingress-nginx**
- coreDns/kubeDns
- kube-api-server
-\* For RKE and RKE2 clusters, ingress-nginx is deployed by default and treated as an internal Kubernetes component.
+\* You can optionally use `hardenedKubelet.enabled` to use a PushProx, but that is not the default.
-### 5.5. Scraping Metrics with PushProx
+** For RKE and RKE2 clusters, ingress-nginx is deployed by default and treated as an internal Kubernetes component.
-The purpose of this architecture is to allow us to scrape internal Kubernetes components without exposing those ports to inbound requests. As a result, Prometheus can scrape metrics across a network boundary.
-The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
+### Scraping Metrics Based on Kubernetes Distribution
-- kube-controller-manager
-- kube-scheduler
-- etcd
-- kube-proxy
-
-For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet. We deploy exactly one PushProx proxy per exporter.
-
-The process for exporting metrics is as follows:
-
-1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
-2. The client then polls the proxy for scrape requests that have come into the proxy.
-3. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
-4. The client scrapes the internal component.
-5. The internal component responds by pushing metrics back to the proxy.
-
-Process for Exporting Metrics with PushProx
-
-
-
-Metrics are scraped differently based on the Kubernetes distribution. For help with terminology, see Terminology(#terminology). For details, see the table below:
+Metrics are scraped differently based on the Kubernetes distribution. For help with terminology, refer [here](#terminology). For details, see the table below:
How Metrics are Exposed to Prometheus
@@ -239,7 +244,7 @@ Metrics are scraped differently based on the Kubernetes distribution. For help w
\* For RKE and RKE2 clusters, ingress-nginx is deployed by default and treated as an internal Kubernetes component.
-### 5.6. Terminology
+### Terminology
- **kube-scheduler:** The internal Kubernetes component that uses information in the pod spec to decide on which node to run a pod.
- **kube-controller-manager:** The internal Kubernetes component that is responsible for node management (detecting if a node fails), pod replication and endpoint creation.
diff --git a/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md b/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md
index 4bc0e009c2a..3260cf8cf95 100644
--- a/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md
+++ b/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md
@@ -128,8 +128,8 @@ The relationship between the default roles deployed by Rancher Cluster Manager (
| --------- | --------- | --------- | --------- |
| cluster-owner | cluster-admin | N/A | ClusterRoleBinding |
| cluster-member | admin | monitoring-admin | ClusterRoleBinding |
-| project-owner | edit | monitoring-admin | RoleBinding within Project namespace |
-| project-member | view | monitoring-edit | RoleBinding within Project namespace |
+| project-owner | admin | monitoring-admin | RoleBinding within Project namespace |
+| project-member | edit | monitoring-edit | RoleBinding within Project namespace |
In addition to these default Roles, the following additional Rancher project roles can be applied to members of your Cluster to provide additional access to Monitoring. These Rancher Roles will be tied to ClusterRoles deployed by the Monitoring chart:
diff --git a/content/rancher/v2.5/en/overview/_index.md b/content/rancher/v2.5/en/overview/_index.md
index dea44182edd..0bfde58d339 100644
--- a/content/rancher/v2.5/en/overview/_index.md
+++ b/content/rancher/v2.5/en/overview/_index.md
@@ -39,7 +39,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
- **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{}}/rancher/v2.5/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{}}/rancher/v2.5/en/cluster-admin/upgrading-kubernetes)
- **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{}}/rancher/v2.5/en/catalog/) that make it easy to repeatedly deploy applications.
-- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.5/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.5/en/k8s-in-rancher/)
+- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.5/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.5/en/k8s-in-rancher/)
- **Pipelines:** Setting up a [pipeline]({{}}/rancher/v2.5/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
- **Istio:** Our [integration with Istio]({{}}/rancher/v2.5/en/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.
diff --git a/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md b/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md
index a2aa6faf9f5..25029e83663 100644
--- a/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md
+++ b/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md
@@ -34,7 +34,7 @@ We don't recommend installing Rancher in a single Docker container, because if t
### K3s Kubernetes Cluster Installations
-One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s Rancher's CNCF certified Kubernetes distribution. It is easy to install, with half the memory of Kubernetes, all in a binary less than 100 MB. One main advantage of this K3s architecture is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
+One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s is Rancher's CNCF certified Kubernetes distribution. It is easy to install and uses half the memory of Kubernetes, all in a binary of less than 100 MB. Another advantage of K3s is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server

@@ -110,4 +110,4 @@ For more best practices for downstream clusters, refer to the [production checkl
If you are using an [authorized cluster endpoint,]({{}}/rancher/v2.5/en/overview/architecture/#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]({{}}/rancher/v2.5/en/k8s-in-rancher/kubeconfig/) and [API keys]({{}}/rancher/v2.5/en/user-settings/api-keys/#creating-an-api-key) for more information.
\ No newline at end of file
+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]({{}}/rancher/v2.5/en/k8s-in-rancher/kubeconfig/) and [API keys]({{}}/rancher/v2.5/en/user-settings/api-keys/#creating-an-api-key) for more information.
diff --git a/content/rancher/v2.5/en/overview/concepts/_index.md b/content/rancher/v2.5/en/overview/concepts/_index.md
index 4e9d2d89e0d..30d5374875b 100644
--- a/content/rancher/v2.5/en/overview/concepts/_index.md
+++ b/content/rancher/v2.5/en/overview/concepts/_index.md
@@ -54,7 +54,7 @@ Three etcd nodes is generally sufficient for smaller clusters and five etcd node
### Controlplane Nodes
-Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles.
+Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although three or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles.
### Worker Nodes
@@ -71,4 +71,4 @@ For high-availability installations of Rancher, Helm is the tool used to install
Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh).
-For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
\ No newline at end of file
+For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
diff --git a/content/rancher/v2.5/en/pipelines/_index.md b/content/rancher/v2.5/en/pipelines/_index.md
index a47fdaf7577..8c7ac545a87 100644
--- a/content/rancher/v2.5/en/pipelines/_index.md
+++ b/content/rancher/v2.5/en/pipelines/_index.md
@@ -6,7 +6,9 @@ aliases:
- /rancher/v2.x/en/pipelines/
---
-> As of Rancher v2.5, Git-based deployment pipelines are now recommended to be handled with Rancher Continuous Delivery powered by [Fleet,]({{}}/rancher/v2.5/en/deploy-across-clusters/fleet) available in Cluster Explorer.
+> As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{}}/rancher/v2.5/en/deploy-across-clusters/fleet), available in Cluster Explorer.
+>
+>**Notice:** Fleet does not replace Rancher pipelines; the distinction is that Rancher pipelines are now powered by Fleet.
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.
diff --git a/content/rancher/v2.5/en/project-admin/project-members/_index.md b/content/rancher/v2.5/en/project-admin/project-members/_index.md
index a8476db8ec8..45a149e90ea 100644
--- a/content/rancher/v2.5/en/project-admin/project-members/_index.md
+++ b/content/rancher/v2.5/en/project-admin/project-members/_index.md
@@ -43,6 +43,8 @@ Following project creation, you can add users as project members so that they ca
>
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
>
+ >- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+ >
>- For `Custom` roles, you can modify the list of individual roles available for assignment.
>
> - To add roles to the list, [Add a Custom Role]({{}}/rancher/v2.5/en/admin-settings/rbac/default-custom-roles).
diff --git a/content/rancher/v2.5/en/project-admin/resource-quotas/_index.md b/content/rancher/v2.5/en/project-admin/resource-quotas/_index.md
index 77f54f689cc..5bd7f0ae075 100644
--- a/content/rancher/v2.5/en/project-admin/resource-quotas/_index.md
+++ b/content/rancher/v2.5/en/project-admin/resource-quotas/_index.md
@@ -42,4 +42,4 @@ Edit [resource quotas]({{}}/rancher/v2.5/en/cluster-admin/projects-and-
1. Click **Create**.
-**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, Rancher won't let you save your changes.
+**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, you may still create namespaces, but they will be given a resource quota of 0. Subsequently, Rancher will not allow you to create any resources restricted by this quota.
diff --git a/content/rancher/v2.5/en/quick-start-guide/_index.md b/content/rancher/v2.5/en/quick-start-guide/_index.md
index 13ea050b05e..6e8bb1f38ee 100644
--- a/content/rancher/v2.5/en/quick-start-guide/_index.md
+++ b/content/rancher/v2.5/en/quick-start-guide/_index.md
@@ -1,10 +1,8 @@
---
title: Rancher Deployment Quick Start Guides
metaDescription: Use this section to jump start your Rancher deployment and testing. It contains instructions for a simple Rancher setup and some common use cases.
-short title: Use this section to jump start your Rancher deployment and testing. It contains instructions for a simple Rancher setup and some common use cases.
+short title: Use this section to jump start your Rancher deployment and testing. It contains instructions for a simple Rancher setup and some common use cases.
weight: 2
-aliases:
- - /rancher/v2.x/en/quick-start-guide/
---
>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.5/en/installation/).
@@ -15,5 +13,3 @@ We have Quick Start Guides for:
- [Deploying Rancher Server]({{}}/rancher/v2.5/en/quick-start-guide/deployment/): Get started running Rancher using the method most convenient for you.
- [Deploying Workloads]({{}}/rancher/v2.5/en/quick-start-guide/workload/): Deploy a simple [workload](https://kubernetes.io/docs/concepts/workloads/) and expose it, letting you access it from outside the cluster.
-
-- [Using the CLI]({{}}/rancher/v2.5/en/quick-start-guide/cli/): Use `kubectl` or Rancher command line interface (CLI) to interact with your Rancher instance.
diff --git a/content/rancher/v2.5/en/quick-start-guide/cli/_index.md b/content/rancher/v2.5/en/quick-start-guide/cli/_index.md
deleted file mode 100644
index 954e27f6a70..00000000000
--- a/content/rancher/v2.5/en/quick-start-guide/cli/_index.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: CLI with Rancher
-weight: 100
-aliases:
- - /rancher/v2.x/en/quick-start-guide/cli/
----
-
-Interact with Rancher using command line interface (CLI) tools from your workstation.
-
-## Rancher CLI
-
-Follow the steps in [rancher cli](../../cli).
-
-Ensure you can run `rancher kubectl get pods` successfully.
-
-
-## kubectl
-Install the `kubectl` utility. See [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
-
-
-Configure kubectl by visiting your cluster in the Rancher Web UI then clicking on `Kubeconfig`, copying contents and putting into your `~/.kube/config` file.
-
-Run `kubectl cluster-info` or `kubectl get pods` successfully.
-
-## Authentication with kubectl and kubeconfig Tokens with TTL
-
-_Requirements_
-
-If admins have [enforced TTL on kubeconfig tokens]({{}}/rancher/v2.5/en/api/api-tokens/#setting-ttl-on-kubeconfig-tokens), the kubeconfig file requires the [Rancher cli](../cli) to be present in your PATH when you run `kubectl`. Otherwise, you’ll see error like:
-`Unable to connect to the server: getting credentials: exec: exec: "rancher": executable file not found in $PATH`.
-
-This feature enables kubectl to authenticate with the Rancher server and get a new kubeconfig token when required. The following auth providers are currently supported:
-
-1. Local
-2. Active Directory
-3. FreeIpa, OpenLdap
-4. SAML providers - Ping, Okta, ADFS, Keycloak, Shibboleth
-
-When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server.
-The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid till [it expires](../../api/api-tokens/#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../../api/api-tokens/#deleting-tokens)
-Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/amazon-aws-qs/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/amazon-aws-qs/_index.md
index c5f189a9542..146b7151ad4 100644
--- a/content/rancher/v2.5/en/quick-start-guide/deployment/amazon-aws-qs/_index.md
+++ b/content/rancher/v2.5/en/quick-start-guide/deployment/amazon-aws-qs/_index.md
@@ -1,11 +1,11 @@
---
title: Rancher AWS Quick Start Guide
-description: Read this step by step Rancher AWS guide to quickly deploy a Rancher Server with a single node cluster attached.
+description: Read this step by step Rancher AWS guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
weight: 100
-aliases:
- - /rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/
---
-The following steps will quickly deploy a Rancher Server on AWS with a single node cluster attached.
+The following steps will quickly deploy a Rancher server on AWS in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.5/en/installation/).
## Prerequisites
@@ -21,25 +21,26 @@ The following steps will quickly deploy a Rancher Server on AWS with a single no
1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
-1. Go into the AWS folder containing the terraform files by executing `cd quickstart/aws`.
+2. Go into the AWS folder containing the terraform files by executing `cd quickstart/aws`.
-1. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
-1. Edit `terraform.tfvars` and customize the following variables:
+4. Edit `terraform.tfvars` and customize the following variables:
- `aws_access_key` - Amazon AWS Access Key
- `aws_secret_key` - Amazon AWS Secret Key
- `rancher_server_admin_password` - Admin password for created Rancher server
-1. **Optional:** Modify optional variables within `terraform.tfvars`.
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/aws) for more information.
Suggestions include:
- - `aws_region` - Amazon AWS region, choose the closest instead of the default
+ - `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`)
- `prefix` - Prefix for all created resources
- `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget
+ - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
-1. Run `terraform init`.
+6. Run `terraform init`.
-1. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
```
Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
@@ -51,11 +52,12 @@ Suggestions include:
workload_node_ip = yy.yy.yy.yy
```
-1. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher server using the `id_rsa` key generated in `quickstart/aws`.
#### Result
-Two Kubernetes clusters are deployed into your AWS account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines.
+Two Kubernetes clusters are deployed into your AWS account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
### What's Next?
diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/digital-ocean-qs/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/digital-ocean-qs/_index.md
index 2e3e94777df..168b580dbdf 100644
--- a/content/rancher/v2.5/en/quick-start-guide/deployment/digital-ocean-qs/_index.md
+++ b/content/rancher/v2.5/en/quick-start-guide/deployment/digital-ocean-qs/_index.md
@@ -1,11 +1,11 @@
---
title: Rancher DigitalOcean Quick Start Guide
-description: Read this step by step Rancher DigitalOcean guide to quickly deploy a Rancher Server with a single node cluster attached.
+description: Read this step by step Rancher DigitalOcean guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
weight: 100
-aliases:
- - /rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/
---
-The following steps will quickly deploy a Rancher Server on DigitalOcean with a single node cluster attached.
+The following steps will quickly deploy a Rancher server on DigitalOcean in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.5/en/installation/).
## Prerequisites
@@ -21,25 +21,24 @@ The following steps will quickly deploy a Rancher Server on DigitalOcean with a
1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
-1. Go into the DigitalOcean folder containing the terraform files by executing `cd quickstart/do`.
+2. Go into the DigitalOcean folder containing the terraform files by executing `cd quickstart/do`.
-1. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
-1. Edit `terraform.tfvars` and customize the following variables:
+4. Edit `terraform.tfvars` and customize the following variables:
- `do_token` - DigitalOcean access key
- `rancher_server_admin_password` - Admin password for created Rancher server
-1. **Optional:** Modify optional variables within `terraform.tfvars`.
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/do) for more information.
Suggestions include:
- - `do_region` - DigitalOcean region, choose the closest instead of the default
+ - `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`)
- `prefix` - Prefix for all created resources
- `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget
- - `ssh_key_file_name` - Use a specific SSH key instead of `~/.ssh/id_rsa` (public key is assumed to be `${ssh_key_file_name}.pub`)
-1. Run `terraform init`.
+6. Run `terraform init`.
-1. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
```
Apply complete! Resources: 15 added, 0 changed, 0 destroyed.
@@ -51,11 +50,12 @@ Suggestions include:
workload_node_ip = yy.yy.yy.yy
```
-1. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/do`.
#### Result
-Two Kubernetes clusters are deployed into your DigitalOcean account, one running Rancher Server and the other ready for experimentation deployments.
+Two Kubernetes clusters are deployed into your DigitalOcean account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
### What's Next?
diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/google-gcp-qs/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/google-gcp-qs/_index.md
index 48eaec3b4ba..35839e68f87 100644
--- a/content/rancher/v2.5/en/quick-start-guide/deployment/google-gcp-qs/_index.md
+++ b/content/rancher/v2.5/en/quick-start-guide/deployment/google-gcp-qs/_index.md
@@ -1,69 +1,70 @@
----
-title: Rancher GCP Quick Start Guide
-description: Read this step by step Rancher GCP guide to quickly deploy a Rancher Server with a single node cluster attached.
-weight: 100
-aliases:
- - /rancher/v2.x/en/quick-start-guide/deployment/google-gcp-qs/
----
-The following steps will quickly deploy a Rancher server on GCP in a single-node RKE Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
-
-## Prerequisites
-
->**Note**
->Deploying to Google GCP will incur charges.
-
-- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
-- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
-- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
-- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
-
-
-## Getting Started
-
-1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
-
-1. Go into the GCP folder containing the terraform files by executing `cd quickstart/gcp`.
-
-1. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
-
-1. Edit `terraform.tfvars` and customize the following variables:
- - `gcp_account_json` - GCP service account file path and file name
- - `rancher_server_admin_password` - Admin password for created Rancher server
-
-1. **Optional:** Modify optional variables within `terraform.tfvars`.
-See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/gcp) for more information.
-Suggestions include:
- - `gcp_region` - Google GCP region, choose the closest instead of the default
- - `prefix` - Prefix for all created resources
- - `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget
- - `ssh_key_file_name` - Use a specific SSH key instead of `~/.ssh/id_rsa` (public key is assumed to be `${ssh_key_file_name}.pub`)
-
-1. Run `terraform init`.
-
-1. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
-
- ```
- Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
-
- Outputs:
-
- rancher_node_ip = xx.xx.xx.xx
- rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
- workload_node_ip = yy.yy.yy.yy
- ```
-
-1. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
-
-#### Result
-
-Two Kubernetes clusters are deployed into your GCP account, one running Rancher Server and the other ready for experimentation deployments.
-
-### What's Next?
-
-Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.5/en/quick-start-guide/workload).
-
-## Destroying the Environment
-
-1. From the `quickstart/gcp` folder, execute `terraform destroy --auto-approve`.
-
-2. Wait for confirmation that all resources have been destroyed.
+---
+title: Rancher GCP Quick Start Guide
+description: Read this step by step Rancher GCP guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+weight: 100
+---
+The following steps will quickly deploy a Rancher server on GCP in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.5/en/installation/).
+
+## Prerequisites
+
+>**Note**
+>Deploying to Google GCP will incur charges.
+
+- [Google GCP Account](https://console.cloud.google.com/): A Google GCP Account is required to create resources for deploying Rancher and Kubernetes.
+- [Google GCP Project](https://cloud.google.com/appengine/docs/standard/nodejs/building-app/creating-project): Use this link to follow a tutorial to create a GCP Project if you don't have one yet.
+- [Google GCP Service Account](https://cloud.google.com/iam/docs/creating-managing-service-account-keys): Use this link and follow instructions to create a GCP service account and token file.
+- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Google GCP.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the GCP folder containing the terraform files by executing `cd quickstart/gcp`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+ - `gcp_account_json` - GCP service account file path and file name
+ - `rancher_server_admin_password` - Admin password for created Rancher server
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/gcp) for more information.
+Suggestions include:
+ - `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`)
+ - `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`)
+ - `prefix` - Prefix for all created resources
+ - `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+ ```
+ Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
+
+ Outputs:
+
+ rancher_node_ip = xx.xx.xx.xx
+ rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+ workload_node_ip = yy.yy.yy.yy
+ ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/gcp`.
+
+#### Result
+
+Two Kubernetes clusters are deployed into your GCP account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.5/en/quick-start-guide/workload).
+
+## Destroying the Environment
+
+1. From the `quickstart/gcp` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md
index a77fede6147..72c5d43096e 100644
--- a/content/rancher/v2.5/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md
+++ b/content/rancher/v2.5/en/quick-start-guide/deployment/microsoft-azure-qs/_index.md
@@ -1,73 +1,76 @@
----
-title: Rancher Azure Quick Start Guide
-description: Read this step by step Rancher Azure guide to quickly deploy a Rancher Server with a single node cluster attached.
-weight: 100
-aliases:
- - /rancher/v2.x/en/quick-start-guide/deployment/microsoft-azure-qs/
----
-
-The following steps will quickly deploy a Rancher server on Azure in a single-node RKE Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
-
-## Prerequisites
-
->**Note**
->Deploying to Microsoft Azure will incur charges.
-
-- [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
-- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
-- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
-- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
-- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
-
-
-## Getting Started
-
-1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
-
-1. Go into the Azure folder containing the terraform files by executing `cd quickstart/azure`.
-
-1. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
-
-1. Edit `terraform.tfvars` and customize the following variables:
- - `azure_subscription_id` - Microsoft Azure Subscription ID
- - `azure_client_id` - Microsoft Azure Client ID
- - `azure_client_secret` - Microsoft Azure Client Secret
- - `azure_tenant_id` - Microsoft Azure Tenant ID
- - `rancher_server_admin_password` - Admin password for created Rancher server
-
-2. **Optional:** Modify optional variables within `terraform.tfvars`.
-See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/azure) for more information.
-Suggestions include:
- - `azure_location` - Microsoft Azure region, choose the closest instead of the default
- - `prefix` - Prefix for all created resources
- - `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
-
-1. Run `terraform init`.
-
-1. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
-
- ```
- Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
-
- Outputs:
-
- rancher_node_ip = xx.xx.xx.xx
- rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
- workload_node_ip = yy.yy.yy.yy
- ```
-
-1. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
-2. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/azure`.
-#### Result
-
-Two Kubernetes clusters are deployed into your Azure account, one running Rancher Server and the other ready for experimentation deployments.
-
-### What's Next?
-
-Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.5/en/quick-start-guide/workload).
-
-## Destroying the Environment
-
-1. From the `quickstart/azure` folder, execute `terraform destroy --auto-approve`.
-
-2. Wait for confirmation that all resources have been destroyed.
+---
+title: Rancher Azure Quick Start Guide
+description: Read this step by step Rancher Azure guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
+weight: 100
+---
+
+The following steps will quickly deploy a Rancher server on Azure in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
+
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.5/en/installation/).
+
+## Prerequisites
+
+>**Note**
+>Deploying to Microsoft Azure will incur charges.
+
+- [Microsoft Azure Account](https://azure.microsoft.com/en-us/free/): A Microsoft Azure Account is required to create resources for deploying Rancher and Kubernetes.
+- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
+- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
+- [Microsoft Azure Client ID/Secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal): Use this link and follow instructions to create a Microsoft Azure client and secret.
+- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Microsoft Azure.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the Azure folder containing the terraform files by executing `cd quickstart/azure`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables:
+ - `azure_subscription_id` - Microsoft Azure Subscription ID
+ - `azure_client_id` - Microsoft Azure Client ID
+ - `azure_client_secret` - Microsoft Azure Client Secret
+ - `azure_tenant_id` - Microsoft Azure Tenant ID
+ - `rancher_server_admin_password` - Admin password for created Rancher server
+
+5. **Optional:** Modify optional variables within `terraform.tfvars`.
+See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/azure) for more information.
+Suggestions include:
+ - `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`)
+ - `prefix` - Prefix for all created resources
+ - `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget
+ - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster
+ - `windows_admin_password` - The admin password of the windows worker node
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following:
+
+ ```
+ Apply complete! Resources: 16 added, 0 changed, 0 destroyed.
+
+ Outputs:
+
+ rancher_node_ip = xx.xx.xx.xx
+ rancher_server_url = https://rancher.xx.xx.xx.xx.sslip.io
+ workload_node_ip = yy.yy.yy.yy
+ ```
+
+8. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`).
+9. ssh to the Rancher Server using the `id_rsa` key generated in `quickstart/azure`.
+
+#### Result
+
+Two Kubernetes clusters are deployed into your Azure account, one running Rancher Server and the other ready for experimentation deployments. Please note that while this setup is a great way to explore Rancher functionality, a production setup should follow our high availability setup guidelines. SSH keys for the VMs are auto-generated and stored in the module directory.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.5/en/quick-start-guide/workload).
+
+## Destroying the Environment
+
+1. From the `quickstart/azure` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
index 770940ff92f..e9051c73081 100644
--- a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
+++ b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
@@ -10,6 +10,8 @@ Howdy Partner! This tutorial walks you through:
- Creation of your first cluster
- Deployment of an application, Nginx
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.5/en/installation/).
+
## Quick Start Outline
This Quick Start Guide is divided into different tasks for easier consumption.
@@ -48,7 +50,7 @@ To install Rancher on your host, connect to it and then use a shell to install.
1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection.
-2. From your shell, enter the following command:
+1. From your shell, enter the following command:
```
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher
@@ -60,13 +62,17 @@ To install Rancher on your host, connect to it and then use a shell to install.
Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations.
-1. Open a web browser and enter the IP address of your host: `https://`.
+1. Open a web browser and enter the IP address of your host: `https://`.
Replace `` with your host IP address.
-2. When prompted, create a password for the default `admin` account there cowpoke!
+1. When prompted, create a password for the default `admin` account there cowpoke!
-3. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.
If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
+1. Set the **Default View**.
+ - If `I want to create or manage multiple clusters` is selected, the Cluster Manager UI is used as the default view.
+ - If `I'm only going to use the cluster Rancher was installed on` is selected, the Cluster Explorer UI is used as the default view.
+
+1. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.
If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
@@ -76,35 +82,37 @@ Welcome to Rancher! You are now able to create your first Kubernetes cluster.
In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-prem VM, or bare-metal) to be used in a cluster.
+1. If you chose `I'm only going to use the cluster Rancher was installed on` when setting the default view, click the **Cluster Manager** button in the upper-right of the UI to access the **Clusters** page.
+
1. From the **Clusters** page, click **Add Cluster**.
-2. Choose **Existing Nodes**.
+1. Choose **Existing Nodes**.
-3. Enter a **Cluster Name**.
+1. Enter a **Cluster Name**.
-4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
+1. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
-5. Click **Next**.
+1. Click **Next**.
-6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
+1. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
-7. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
+1. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
-8. Skip the **Labels** stuff. It's not important for now.
+1. Skip the **Labels** stuff. It's not important for now.
-9. Copy the command displayed on screen to your clipboard.
+1. 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.
+1. 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.
-11. When you finish running the command on your Linux host, click **Done**.
+1. When you finish running the command on your Linux host, 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
diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md
index b175645408d..43102865117 100644
--- a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md
+++ b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md
@@ -6,6 +6,8 @@ aliases:
---
The following steps quickly deploy a Rancher Server with a single node cluster attached.
+>**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{}}/rancher/v2.5/en/installation/).
+
## Prerequisites
- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
@@ -16,7 +18,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
`vagrant plugin install vagrant-vboxmanage`
-
+
`vagrant plugin install vagrant-vbguest`
## Getting Started
@@ -32,7 +34,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`.
-5. Once provisioning finishes, go to `https://172.22.101.101` in the browser. The default user/password is `admin/admin`.
+5. Once provisioning finishes, go to `https://192.168.56.101` in the browser. The default user/password is `admin/admin`.
**Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox.
diff --git a/content/rancher/v2.5/en/security/_index.md b/content/rancher/v2.5/en/security/_index.md
index c52daf4bde1..531c7d2ca33 100644
--- a/content/rancher/v2.5/en/security/_index.md
+++ b/content/rancher/v2.5/en/security/_index.md
@@ -33,6 +33,7 @@ On this page, we provide security-related documentation along with resources to
- [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)
+- [Kubernetes Security Best Practices](#kubernetes-security-best-practices)
### Running a CIS Security Scan on a Kubernetes Cluster
@@ -86,3 +87,7 @@ Results:
### 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.](./cve)
+
+### Kubernetes Security Best Practices
+
+For recommendations on securing your Kubernetes cluster, refer to the [Best Practices](./best-practices) guide.
diff --git a/content/rancher/v2.5/en/security/best-practices/_index.md b/content/rancher/v2.5/en/security/best-practices/_index.md
new file mode 100644
index 00000000000..1b207551e35
--- /dev/null
+++ b/content/rancher/v2.5/en/security/best-practices/_index.md
@@ -0,0 +1,8 @@
+---
+title: Kubernetes Security Best Practices
+weight: 5
+---
+
+# Restricting cloud metadata API access
+
+Cloud providers such as AWS, Azure, or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.
diff --git a/content/rancher/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/_index.md b/content/rancher/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/_index.md
index 02b34e42fdb..4fed8f40550 100644
--- a/content/rancher/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/_index.md
+++ b/content/rancher/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/_index.md
@@ -1281,7 +1281,7 @@ on the master node and ensure the correct value for the `--bind-address` paramet
**Expected result**:
```
-'--bind-address' is present OR '--bind-address' is not present
+'--bind-address' argument is set to 127.0.0.1
```
### 1.4 Scheduler
@@ -1327,7 +1327,7 @@ on the master node and ensure the correct value for the `--bind-address` paramet
**Expected result**:
```
-'--bind-address' is present OR '--bind-address' is not present
+'--bind-address' argument is set to 127.0.0.1
```
## 2 Etcd Node Configuration
diff --git a/content/rancher/v2.5/en/security/rancher-2.5/1.5-hardening-2.5/_index.md b/content/rancher/v2.5/en/security/rancher-2.5/1.5-hardening-2.5/_index.md
index 26907ab28b6..491aec9c080 100644
--- a/content/rancher/v2.5/en/security/rancher-2.5/1.5-hardening-2.5/_index.md
+++ b/content/rancher/v2.5/en/security/rancher-2.5/1.5-hardening-2.5/_index.md
@@ -667,6 +667,7 @@ rancher_kubernetes_engine_config:
service_node_port_range: 30000-32767
kube_controller:
extra_args:
+ bind-address: 127.0.0.1
address: 127.0.0.1
feature-gates: RotateKubeletServerCertificate=true
profiling: 'false'
@@ -685,6 +686,7 @@ rancher_kubernetes_engine_config:
generate_serving_certificate: true
scheduler:
extra_args:
+ bind-address: 127.0.0.1
address: 127.0.0.1
profiling: 'false'
ssh_agent_auth: false
diff --git a/content/rancher/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/_index.md b/content/rancher/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/_index.md
index 57b65e5b004..e0dc1e45c5d 100644
--- a/content/rancher/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/_index.md
+++ b/content/rancher/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/_index.md
@@ -1803,13 +1803,13 @@ on the master node and ensure the correct value for the --bind-address parameter
**Expected Result**:
```console
-'--bind-address' is not present OR '--bind-address' is not present
+'--bind-address' argument is set to 127.0.0.1
```
**Returned Value**:
```console
-root 4788 4773 4 16:16 ? 00:00:09 kube-controller-manager --configure-cloud-routes=false --cloud-provider= --service-cluster-ip-range=10.43.0.0/16 --v=2 --pod-eviction-timeout=5m0s --leader-elect=true --cluster-cidr=10.42.0.0/16 --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-controller-manager.yaml --profiling=false --node-monitor-grace-period=40s --service-account-private-key-file=/etc/kubernetes/ssl/kube-service-account-token-key.pem --address=0.0.0.0 --allow-untagged-cloud=true --root-ca-file=/etc/kubernetes/ssl/kube-ca.pem --allocate-node-cidrs=true --enable-hostpath-provisioner=false --terminated-pod-gc-threshold=1000 --feature-gates=RotateKubeletServerCertificate=true --use-service-account-credentials=true
+root 4788 4773 4 16:16 ? 00:00:09 kube-controller-manager --configure-cloud-routes=false --cloud-provider= --service-cluster-ip-range=10.43.0.0/16 --v=2 --bind-address=127.0.0.1 --pod-eviction-timeout=5m0s --leader-elect=true --cluster-cidr=10.42.0.0/16 --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-controller-manager.yaml --profiling=false --node-monitor-grace-period=40s --service-account-private-key-file=/etc/kubernetes/ssl/kube-service-account-token-key.pem --address=127.0.0.1 --allow-untagged-cloud=true --root-ca-file=/etc/kubernetes/ssl/kube-ca.pem --allocate-node-cidrs=true --enable-hostpath-provisioner=false --terminated-pod-gc-threshold=1000 --feature-gates=RotateKubeletServerCertificate=true --use-service-account-credentials=true
```
## 1.4 Scheduler
@@ -1859,13 +1859,13 @@ on the master node and ensure the correct value for the --bind-address parameter
**Expected Result**:
```console
-'--bind-address' is not present OR '--bind-address' is not present
+'--bind-address' argument is set to 127.0.0.1
```
**Returned Value**:
```console
-root 4947 4930 1 16:16 ? 00:00:02 kube-scheduler --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-scheduler.yaml --leader-elect=true --profiling=false --v=2 --address=0.0.0.0
+root 4947 4930 1 16:16 ? 00:00:02 kube-scheduler --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-scheduler.yaml --leader-elect=true --profiling=false --v=2 --address=127.0.0.1 --bind-address=127.0.0.1
```
## 2 Etcd Node Configuration Files
diff --git a/content/rancher/v2.5/en/security/rancher-2.5/1.6-hardening-2.5/_index.md b/content/rancher/v2.5/en/security/rancher-2.5/1.6-hardening-2.5/_index.md
index 0b6497f2e1f..d628bfd8c5a 100644
--- a/content/rancher/v2.5/en/security/rancher-2.5/1.6-hardening-2.5/_index.md
+++ b/content/rancher/v2.5/en/security/rancher-2.5/1.6-hardening-2.5/_index.md
@@ -511,6 +511,8 @@ rancher_kubernetes_engine_config:
kube_controller:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
+ bind-address: 127.0.0.1
+ address: 127.0.0.1
kubelet:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
@@ -519,6 +521,10 @@ rancher_kubernetes_engine_config:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
fail_swap_on: false
generate_serving_certificate: true
+ scheduler:
+ extra_args:
+ bind-address: 127.0.0.1
+ address: 127.0.0.1
ssh_agent_auth: false
upgrade_strategy:
max_unavailable_controlplane: '1'
diff --git a/content/rancher/v2.5/en/troubleshooting/dns/_index.md b/content/rancher/v2.5/en/troubleshooting/dns/_index.md
index 99274794206..3822399c32f 100644
--- a/content/rancher/v2.5/en/troubleshooting/dns/_index.md
+++ b/content/rancher/v2.5/en/troubleshooting/dns/_index.md
@@ -160,7 +160,7 @@ kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{
Enabling query logging can be done by enabling the [log plugin](https://coredns.io/plugins/log/) in the Corefile configuration in the configmap `coredns`. You can do so by using `kubectl -n kube-system edit configmap coredns` or use the command below to replace the configuration in place:
```
-kubectl get configmap -n kube-system coredns -o json | kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f -
+kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f -
```
All queries will now be logged and can be checked using the command in [Check CoreDNS logging](#check-coredns-logging).
diff --git a/content/rancher/v2.6/_index.md b/content/rancher/v2.6/_index.md
index a1ea29d36e4..5060194d87d 100644
--- a/content/rancher/v2.6/_index.md
+++ b/content/rancher/v2.6/_index.md
@@ -1,5 +1,5 @@
---
-title: v2.6.x
+title: Rancher 2.6
weight: 1
showBreadcrumb: false
---
diff --git a/content/rancher/v2.6/en/_index.md b/content/rancher/v2.6/en/_index.md
index d8bfd4a20c3..98bdedcac77 100644
--- a/content/rancher/v2.6/en/_index.md
+++ b/content/rancher/v2.6/en/_index.md
@@ -2,7 +2,7 @@
title: "Rancher 2.6"
shortTitle: "Rancher 2.6 (Latest)"
description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
-metaTitle: "Rancher 2.x Docs: What is New?"
+metaTitle: "Rancher 2.6 Docs: What is New?"
metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more."
insertOneSix: false
weight: 1
diff --git a/content/rancher/v2.6/en/admin-settings/authentication/ad/_index.md b/content/rancher/v2.6/en/admin-settings/authentication/ad/_index.md
index a919075bdaa..251039f2c97 100644
--- a/content/rancher/v2.6/en/admin-settings/authentication/ad/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/authentication/ad/_index.md
@@ -101,7 +101,7 @@ The table below details the parameters for the group schema configuration.
| Search Attribute | Attribute used to construct search filters when adding groups to clusters or projects. See description of user schema `Search Attribute`. |
| Search Filter | This filter gets applied to the list of groups that is searched when Rancher attempts to add groups to a site access list or tries to add groups to clusters or projects. For example, a group search filter could be (|(cn=group1)(cn=group2)). Note: If the search filter does not use [valid AD search syntax,](https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax) the list of groups will be empty. |
| Group DN Attribute | The name of the group attribute whose format matches the values in the user attribute describing a the user's memberships. See `User Member Attribute`. |
-| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organisation makes use of these nested memberships (ie. you have groups that contain other groups as members. We advise avoiding nested groups when possible). |
+| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organization makes use of these nested memberships (i.e., you have groups that contain other groups as members. We advise avoiding nested groups when possible to avoid potential performance issues when there is a large amount of nested memberships). |
---
@@ -153,7 +153,7 @@ This command performs an LDAP search with the search base set to the domain root
Since in this case the user's DN is `CN=John Doe,CN=Users,DC=acme,DC=com` [5], we should configure the **User Search Base** with the parent node DN `CN=Users,DC=acme,DC=com`.
-Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, ie. `OU=Groups,DC=acme,DC=com`.
+Similarly, based on the DN of the group referenced in the **memberOf** attribute [4], the correct value for the **Group Search Base** would be the parent node of that value, i.e., `OU=Groups,DC=acme,DC=com`.
### Identify User Schema
@@ -166,7 +166,7 @@ The output of the above `ldapsearch` query also allows to determine the correct
> **Note:**
>
-> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
+> If the AD users in our organization were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead.
We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name.
diff --git a/content/rancher/v2.6/en/admin-settings/authentication/keycloak-saml/_index.md b/content/rancher/v2.6/en/admin-settings/authentication/keycloak-saml/_index.md
index bd94b700d23..ca2952111fb 100644
--- a/content/rancher/v2.6/en/admin-settings/authentication/keycloak-saml/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/authentication/keycloak-saml/_index.md
@@ -23,36 +23,87 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati
>1: Optionally, you can enable either one or both of these settings.
>2: Rancher SAML metadata won't be generated until a SAML provider is configured and saved.
-
+
{{< img "/img/rancher/keycloak/keycloak-saml-client-configuration.png" "">}}
-
+
- In the new SAML client, create Mappers to expose the users fields
- Add all "Builtin Protocol Mappers"
{{< img "/img/rancher/keycloak/keycloak-saml-client-builtin-mappers.png" "">}}
- Create a new "Group list" mapper to map the member attribute to a user's groups
- {{< img "/img/rancher/keycloak/keycloak-saml-client-group-mapper.png" "">}}
-- Export a `metadata.xml` file from your Keycloak client:
- From the `Installation` tab, choose the `SAML Metadata IDPSSODescriptor` format option and download your file.
-
- >**Note**
- > Keycloak versions 6.0.0 and up no longer provide the IDP metadata under the `Installation` tab.
- > You can still get the XML from the following url:
- >
- > `https://{KEYCLOAK-URL}/auth/realms/{REALM-NAME}/protocol/saml/descriptor`
- >
- > The XML obtained from this URL contains `EntitiesDescriptor` as the root element. Rancher expects the root element to be `EntityDescriptor` rather than `EntitiesDescriptor`. So before passing this XML to Rancher, follow these steps to adjust it:
- >
- > * Copy all the attributes from `EntitiesDescriptor` to the `EntityDescriptor` that are not present.
- > * Remove the `` tag from the beginning.
- > * Remove the `` from the end of the xml.
- >
- > You are left with something similar as the example below:
- >
- > ```
- >
- > ....
- >
- > ```
+ {{< img "/img/rancher/keycloak/keycloak-saml-client-group-mapper.png" "">}}
+
+## Getting the IDP Metadata
+
+{{% tabs %}}
+{{% tab "Keycloak 5 and earlier" %}}
+To get the IDP metadata, export a `metadata.xml` file from your Keycloak client.
+From the **Installation** tab, choose the **SAML Metadata IDPSSODescriptor** format option and download your file.
+{{% /tab %}}
+{{% tab "Keycloak 6-13" %}}
+
+1. From the **Configure** section, click the **Realm Settings** tab.
+1. Click the **General** tab.
+1. From the **Endpoints** field, click **SAML 2.0 Identity Provider Metadata**.
+
+Verify the IDP metadata contains the following attributes:
+
+```
+xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
+xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
+xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+```
+
+Some browsers, such as Firefox, may render/process the document such that the contents appear to have been modified, and some attributes appear to be missing. In this situation, use the raw response data that can be found using your browser.
+
+The following is an example process for Firefox, but will vary slightly for other browsers:
+
+1. Press **F12** to access the developer console.
+1. Click the **Network** tab.
+1. From the table, click the row containing `descriptor`.
+1. From the details pane, click the **Response** tab.
+1. Copy the raw response data.
+
+The XML obtained contains `EntitiesDescriptor` as the root element. Rancher expects the root element to be `EntityDescriptor` rather than `EntitiesDescriptor`. So before passing this XML to Rancher, follow these steps to adjust it:
+
+1. Copy all the attributes from `EntitiesDescriptor` to the `EntityDescriptor` that are not present.
+1. Remove the `` tag from the beginning.
+1. Remove the `` from the end of the xml.
+
+You are left with something similar as the example below:
+
+```
+
+....
+
+```
+
+{{% /tab %}}
+{{% tab "Keycloak 14+" %}}
+
+1. From the **Configure** section, click the **Realm Settings** tab.
+1. Click the **General** tab.
+1. From the **Endpoints** field, click **SAML 2.0 Identity Provider Metadata**.
+
+Verify the IDP metadata contains the following attributes:
+
+```
+xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
+xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
+xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
+```
+
+Some browsers, such as Firefox, may render/process the document such that the contents appear to have been modified, and some attributes appear to be missing. In this situation, use the raw response data that can be found using your browser.
+
+The following is an example process for Firefox, but will vary slightly for other browsers:
+
+1. Press **F12** to access the developer console.
+1. Click the **Network** tab.
+1. From the table, click the row containing `descriptor`.
+1. From the details pane, click the **Response** tab.
+1. Copy the raw response data.
+
+{{% /tab %}}
+{{% /tabs %}}
## Configuring Keycloak in Rancher
diff --git a/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md
index 5040d63561b..484b0a1610c 100644
--- a/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md
@@ -27,6 +27,8 @@ Note that these URLs will not return valid data until the authentication configu
1. **Groups Field**: Make entries for managing group memberships (example: `memberOf`).
+ 1. **Entity ID Field** (optional): The published, protocol-dependent, unique identifier of your partner. This ID defines your organization as the entity operating the server for SAML 2.0 transactions. This ID may have been obtained out-of-band or via a SAML metadata file.
+
1. **Rancher API Host**: Enter the URL for your Rancher Server.
1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your IdP.
diff --git a/content/rancher/v2.6/en/admin-settings/branding/_index.md b/content/rancher/v2.6/en/admin-settings/branding/_index.md
index 1fbe6d9f78b..4e5cff17e20 100644
--- a/content/rancher/v2.6/en/admin-settings/branding/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/branding/_index.md
@@ -40,7 +40,21 @@ You can override the primary color used throughout the UI with a custom color of
### Fixed Banners
+{{% tabs %}}
+{{% tab "Rancher before v2.6.4" %}}
Display a custom fixed banner in the header, footer, or both.
+{{% /tab %}}
+{{% tab "Rancher v2.6.4+" %}}
+Display a custom fixed banner in the header, footer, or both.
+
+As of Rancher v2.6.4, configuration of fixed banners has moved from the **Branding** tab to the **Banners** tab.
+
+To configure banner settings,
+
+1. Click **☰ > Global settings**.
+2. Click **Banners**.
+{{% /tab %}}
+{{% /tabs %}}
# Custom Navigation Links
diff --git a/content/rancher/v2.6/en/admin-settings/config-private-registry/_index.md b/content/rancher/v2.6/en/admin-settings/config-private-registry/_index.md
index 16690af8bd3..cd36201d114 100644
--- a/content/rancher/v2.6/en/admin-settings/config-private-registry/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/config-private-registry/_index.md
@@ -3,7 +3,7 @@ title: Configuring a Global Default Private Registry
weight: 40
---
-You might want to use a private Docker registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.
+You might want to use a private container registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.
There are two main ways to set up private registries in Rancher: by setting up the global default registry through the **Settings** tab in the global view, and by setting up a private registry in the advanced options in the cluster-level settings. The global default registry is intended to be used for air-gapped setups, for registries that do not require credentials. The cluster-level private registry is intended to be used in all setups in which the private registry requires credentials.
@@ -35,4 +35,4 @@ You can follow these steps to configure a private registry when you create a clu
**Result:** The new cluster will be able to pull images from the private registry.
-The private registry cannot be configured after the cluster is created.
\ No newline at end of file
+The private registry cannot be configured after the cluster is created.
diff --git a/content/rancher/v2.6/en/admin-settings/pod-security-policies/_index.md b/content/rancher/v2.6/en/admin-settings/pod-security-policies/_index.md
index 2e0d6d70fc3..9244102623d 100644
--- a/content/rancher/v2.6/en/admin-settings/pod-security-policies/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/pod-security-policies/_index.md
@@ -9,6 +9,7 @@ If a pod does not meet the conditions specified in the PSP, Kubernetes will not
- [How PSPs Work](#how-psps-work)
- [Default PSPs](#default-psps)
+ - [Restricted-NoRoot](#restricted-noroot)
- [Restricted](#restricted)
- [Unrestricted](#unrestricted)
- [Creating PSPs](#creating-psps)
@@ -28,18 +29,22 @@ PSPs work through inheritance:
Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
-Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
+Read more about Pod Security Policies in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
# Default PSPs
-Rancher ships with two default Pod Security Policies (PSPs): the `restricted` and `unrestricted` policies.
+Rancher ships with three default Pod Security Policies (PSPs): the `restricted-noroot`, `restricted` and `unrestricted` policies.
-### Restricted
+### Restricted-NoRoot
This policy is based on the Kubernetes [example restricted policy](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml). It significantly restricts what types of pods can be deployed to a cluster or project. This policy:
- Prevents pods from running as a privileged user and prevents escalation of privileges.
-- Validates that server-required security mechanisms are in place (such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added.
+- Validates that server-required security mechanisms are in place, such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added.
+
+### Restricted
+
+This policy is a relaxed version of the `restricted-noroot` policy, with almost all the restrictions in place, except for the fact that it allows running containers as a privileged user.
### Unrestricted
@@ -51,9 +56,9 @@ Using Rancher, you can create a Pod Security Policy using our GUI rather than cr
### Requirements
-Rancher can only assign PSPs for clusters that are [launched using RKE.]({{< baseurl >}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/)
+Rancher can only assign PSPs for clusters that are [launched using RKE]({{< baseurl >}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/).
-You must enable PSPs at the cluster level before you can assign them to a project. This can be configured by [editing the cluster.]({{}}/rancher/v2.6/en/cluster-admin/editing-clusters/)
+You must enable PSPs at the cluster level before you can assign them to a project. This can be configured by [editing the cluster]({{}}/rancher/v2.6/en/cluster-admin/editing-clusters/).
It is a best practice to set PSP at the cluster level.
@@ -63,19 +68,11 @@ We recommend adding PSPs during cluster and project creation instead of adding i
1. In the upper left corner, click **☰ > Cluster Management**.
1. In the left navigation bar, click **Pod Security Policies**.
-1. Click **Add policy**.
+1. Click **Add Policy**.
1. Name the policy.
1. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does.
1. Click **Create**.
# Configuration
-The Kubernetes documentation on PSPs is [here.](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
-
-
-
-
-
-[1]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems
-[2]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces
-[3]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups
+The Kubernetes documentation on PSPs is [here](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
diff --git a/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md
index c966d787383..c2767b8a66f 100644
--- a/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md
@@ -5,7 +5,7 @@ weight: 1127
Cluster and project roles define user authorization inside a cluster or project.
-To manage these roles,
+To manage these roles,
1. Click **☰ > Users & Authentication**.
1. In the left navigation bar, click **Roles** and go to the **Cluster** or **Project/Namespaces** tab.
@@ -60,8 +60,8 @@ The following table lists the permissions available for the `Manage Nodes` role
| SSH Access | ✓ | ✓ |
| Delete Nodes | ✓ | ✓ |
| Scale Clusters Up and Down | ✓ | * |
-***In RKE2, you must have permission to edit a cluster to be able to scale clusters up and down.**
-
+***In RKE2, you must have permission to edit a cluster to be able to scale clusters up and down.**
+
For details on how each cluster role can access Kubernetes resources, you can look them up in the Rancher UI:
@@ -81,12 +81,24 @@ To assign a custom role to a new cluster member, you can use the Rancher UI. To
To assign the role to a new cluster member,
+{{% tabs %}}
+{{% tab "Rancher before v2.6.4" %}}
1. Click **☰ > Cluster Management**.
1. Go to the cluster where you want to assign a role to a member and click **Explore**.
1. Click **RBAC > Cluster Members**.
1. Click **Add**.
1. In the **Cluster Permissions** section, choose the custom cluster role that should be assigned to the member.
1. Click **Create**.
+{{% /tab %}}
+{{% tab "Rancher v2.6.4+" %}}
+1. Click **☰ > Cluster Management**.
+1. Go to the cluster where you want to assign a role to a member and click **Explore**.
+1. Click **Cluster > Cluster Members**.
+1. Click **Add**.
+1. In the **Cluster Permissions** section, choose the custom cluster role that should be assigned to the member.
+1. Click **Create**.
+{{% /tab %}}
+{{% /tabs %}}
**Result:** The member has the assigned role.
@@ -111,6 +123,10 @@ _Project roles_ are roles that can be used to grant users access to a project. T
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
+ >**Note:**
+ >
+ >By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
+
- **Read Only:**
These users can view everything in the project but cannot create, update, or delete anything.
@@ -119,7 +135,6 @@ _Project roles_ are roles that can be used to grant users access to a project. T
>
>Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
-
#### Custom Project Roles
Rancher lets you assign _custom project roles_ to a standard user instead of the typical `Owner`, `Member`, or `Read Only` roles. These roles can be either a built-in custom project role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a standard user within a project. See the table below for a list of built-in custom project roles.
diff --git a/content/rancher/v2.6/en/admin-settings/rke-templates/enforcement/_index.md b/content/rancher/v2.6/en/admin-settings/rke-templates/enforcement/_index.md
index 9125f7ff342..cd51f196341 100644
--- a/content/rancher/v2.6/en/admin-settings/rke-templates/enforcement/_index.md
+++ b/content/rancher/v2.6/en/admin-settings/rke-templates/enforcement/_index.md
@@ -25,6 +25,8 @@ To require new clusters to use an RKE template, administrators can turn on RKE t
1. Go to the `cluster-template-enforcement` setting. Click **â‹® > Edit Setting**.
1. Set the value to **True** and click **Save**.
+ >**Important:** When the admin sets the `cluster-template-enforcement` to True, they also need to share the `clusterTemplates` with users so that users can select one of these templates to create the cluster.
+
**Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator.
# Disabling RKE Template Enforcement
diff --git a/content/rancher/v2.6/en/api/_index.md b/content/rancher/v2.6/en/api/_index.md
index 60cf9320914..d1cc9cc4454 100644
--- a/content/rancher/v2.6/en/api/_index.md
+++ b/content/rancher/v2.6/en/api/_index.md
@@ -5,7 +5,22 @@ weight: 24
## 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]({{}}/rancher/v2.6/en/user-settings/api-keys/).
+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:
+
+{{% tabs %}}
+{{% tab "Rancher v2.6.4+" %}}
+
+1. Click on your user avatar in the upper right corner.
+1. Click **Account & API Keys**.
+1. Under the **API Keys** section, find the **API Endpoint** field and click the link. The link will look something like `https:///v3`, where `` is the fully qualified domain name of your Rancher deployment.
+
+{{% /tab %}}
+{{% tab "Rancher before v2.6.4" %}}
+
+Go to the URL endpoint at `https:///v3`, where `` is the fully qualified domain name of your Rancher deployment.
+
+{{% /tab %}}
+{{% /tabs %}}
## Authentication
@@ -50,3 +65,17 @@ Most collections can be sorted on the server-side by common fields using HTTP qu
## 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.
+
+## Capturing Rancher API Calls
+
+You can use browser developer tools to capture how the Rancher API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning an RKE cluster:
+
+1. In the Rancher UI, go to **Cluster Management** and click **Create.**
+1. Click one of the cluster types. This example uses Digital Ocean.
+1. Fill out the form with a cluster name and node template, but don't click **Create**.
+1. You will need to open the developer tools before the cluster creation to see the API call being recorded. To open the tools, right-click on the Rancher UI and click **Inspect.**
+1. In the developer tools, click the **Network** tab.
+1. On the **Network** tab, make sure **Fetch/XHR** is selected.
+1. In the Rancher UI, click **Create**. In the developer tools, you should see a new network request with the name `cluster?_replace=true`.
+1. Right-click `cluster?_replace=true` and click **Copy > Copy as cURL.**
+1. Paste the result into any text editor. You will be able to see the POST request, including the URL it was sent to, all of the headers, and the full body of the request. This command can be used to create a cluster from the command line. Note: The request should be stored in a safe place because it contains credentials.
diff --git a/content/rancher/v2.6/en/backups/_index.md b/content/rancher/v2.6/en/backups/_index.md
index b090f2972b2..d9e4dd96065 100644
--- a/content/rancher/v2.6/en/backups/_index.md
+++ b/content/rancher/v2.6/en/backups/_index.md
@@ -43,10 +43,14 @@ When a Restore custom resource is created, the operator accesses the backup .tar
The Backup and Restore custom resources can be created in the Rancher UI, or by using `kubectl apply`.
+>**Note:** Refer [here]({{}}/rancher/v2.6/en/backups/migrating-rancher/#2-restore-from-backup-using-a-restore-custom-resource) for help on restoring an existing backup file into a v1.22 cluster in Rancher v2.6.3.
+
# Installing the rancher-backup Operator
The `rancher-backup` operator can be installed from the Rancher UI, or with the Helm CLI. In both cases, the `rancher-backup` Helm chart is installed on the Kubernetes cluster running the Rancher server. It is a cluster-admin only feature and available only for the **local** cluster. (*If you do not see `rancher-backup` in the Rancher UI, you may have selected the wrong cluster.*)
+>**NOTE:** There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround.
+
### Installing rancher-backup with the Rancher UI
1. In the upper left corner, click **☰ > Cluster Management**.
diff --git a/content/rancher/v2.6/en/backups/back-up-rancher/_index.md b/content/rancher/v2.6/en/backups/back-up-rancher/_index.md
index acfe23fc3fb..629a7ad2c64 100644
--- a/content/rancher/v2.6/en/backups/back-up-rancher/_index.md
+++ b/content/rancher/v2.6/en/backups/back-up-rancher/_index.md
@@ -5,12 +5,18 @@ weight: 1
In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer the instructions for [single node backups]({{}}/rancher/v2.6/en/backups/docker-installs/docker-backups)
-The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster.
+The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster.
+
+Note that the rancher-backup operator version 2.x.x is for Rancher v2.6.x.
+
+> When restoring a backup into a new Rancher setup, the version of the new setup should be the same as the one where the backup is made. The Kubernetes version should also be considered when restoring a backup, since the supported apiVersion in the cluster and in the backup file could be different.
### Prerequisites
The Rancher version must be v2.5.0 and up.
+Refer [here]({{}}/rancher/v2.6/en/backups/migrating-rancher/#2-restore-from-backup-using-a-restore-custom-resource) for help on restoring an existing backup file into a v1.22 cluster in Rancher v2.6.3.
+
### 1. Install the Rancher Backups operator
The backup storage location is an operator-level setting, so it needs to be configured when the Rancher Backups application is installed or upgraded.
@@ -25,6 +31,8 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio,
1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config)
1. Click **Install**.
+>**NOTE:** There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround.
+
### 2. Perform a Backup
To perform a backup, a custom resource of type Backup must be created.
diff --git a/content/rancher/v2.6/en/backups/examples/_index.md b/content/rancher/v2.6/en/backups/examples/_index.md
index 87c607b7780..b1282f9c3ca 100644
--- a/content/rancher/v2.6/en/backups/examples/_index.md
+++ b/content/rancher/v2.6/en/backups/examples/_index.md
@@ -272,6 +272,13 @@ data:
# Example EncryptionConfiguration
+The snippet below demonstrates two different types of secrets and their relevance with respect to Backup and Restore of custom resources.
+
+The first example is that of a secret that is used to encrypt the backup files. The backup operator, in this case, will not be able to read the secrets encryption file. It only uses the contents of the secret.
+
+The second example is that of a Kubernetes secrets encryption config file that is used to encrypt secrets when stored in etcd. **When backing up the etcd datastore, be sure to also back up the EncryptionConfiguration.** Failure to do so will result in an inability to use the restored data if secrets encryption was in use at the time the data was backed up.
+
+
```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
diff --git a/content/rancher/v2.6/en/backups/migrating-rancher/_index.md b/content/rancher/v2.6/en/backups/migrating-rancher/_index.md
index 0154b6b1bd7..5b5e4f3acdd 100644
--- a/content/rancher/v2.6/en/backups/migrating-rancher/_index.md
+++ b/content/rancher/v2.6/en/backups/migrating-rancher/_index.md
@@ -9,7 +9,7 @@ If you are migrating Rancher to a new Kubernetes cluster, you don't need to inst
These instructions assume you have [created a backup](../back-up-rancher) and you have already installed a new Kubernetes cluster where Rancher will be deployed.
-It is required to use the same hostname that was set as the server URL in the first cluster.
+>**Warning:** It is required to use the same hostname that was set as the server URL in the first cluster. If not done, downstream clusters will show as unavailable in the cluster management page of the UI, and you won't be able to click inside the cluster or on the cluster's Explore button.
Rancher version must be v2.5.0 and up
@@ -19,17 +19,31 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
- [K3s Kubernetes installation docs]({{}}/k3s/latest/en/installation/)
### 1. Install the rancher-backup Helm chart
-Install version 2.x.x of the rancher-backup chart.
+Install version 2.x.x of the rancher-backup chart. The following assumes a connected environment with access to DockerHub:
```
helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
```
+
+For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
+```
+--set image.repository $REGISTRY/rancher/backup-restore-operator
+```
### 2. Restore from backup using a Restore custom resource
-If you are using an S3 store as the backup source, and need to use your S3 credentials for restore, create a secret in this cluster using your S3 credentials. The Secret data must have two keys, `accessKey` and `secretKey` containing the s3 credentials like this:
+>**Important:** Kubernetes v1.22, available as an experimental feature of v2.6.3, does not support restoring from backup files containing CRDs with the apiVersion `apiextensions.k8s.io/v1beta1`. In v1.22, the default `resourceSet` in the rancher-backup app is updated to collect only CRDs that use `apiextensions.k8s.io/v1`. There are currently two ways to work around this issue:
+>
+1. Update the default `resourceSet` to collect the CRDs with the apiVersion v1.
+1. Update the default `resourceSet` and the client to use the new APIs internally, with `apiextensions.k8s.io/v1` as the replacement.
+>
+> - Note that when making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.
+
+If you are using an S3 store as the backup source and need to use your S3 credentials for restore, create a secret in this cluster using your S3 credentials. The Secret data must have two keys - `accessKey` and `secretKey` - that contain the S3 credentials.
+
+**Warning:** The values `accessKey` and `secretKey` in the example below must be base64-encoded first when creating the object directly. If not encoded first, the pasted values will cause errors when you are attempting to backup or restore.
```yaml
apiVersion: v1
@@ -42,7 +56,7 @@ stringData:
secretKey:
```
-This secret can be created in any namespace, with the above example it will get created in the default namespace
+This secret can be created in any namespace; with the above example, it will get created in the default namespace.
In the Restore custom resource, `prune` must be set to false.
@@ -68,21 +82,34 @@ spec:
endpoint: s3.us-west-2.amazonaws.com
```
-> **Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
-1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
+>**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
+1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
```
kubectl create secret generic encryptionconfig \
--from-file=./encryption-provider-config.yaml \
-n cattle-resources-system
```
-Then apply the resource:
+1. Apply the manifest, and watch for the Restore resources status:
+ Apply the resource:
```
-kubectl apply -f migrationResource.yaml
+kubectl apply -f migrationResource.yaml
```
+ Watch the Restore status:
+```
+kubectl get restore
+```
+
+ Watch the restoration logs:
+```
+kubectl logs -n cattle-resources-system --tail 100 -f rancher-backup-xxx-xxx
+```
+
+Once the Restore resource has the status `Completed`, you can continue the Rancher installation.
+
### 3. Install cert-manager
Follow the steps to [install cert-manager]({{}}/rancher/v2.6/en/installation/install-rancher-on-k8s/#5-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
diff --git a/content/rancher/v2.6/en/backups/restoring-rancher/_index.md b/content/rancher/v2.6/en/backups/restoring-rancher/_index.md
index 0d9925329a1..2ec7691aa79 100644
--- a/content/rancher/v2.6/en/backups/restoring-rancher/_index.md
+++ b/content/rancher/v2.6/en/backups/restoring-rancher/_index.md
@@ -3,15 +3,33 @@ title: Restoring Rancher
weight: 2
---
-A restore is performed by creating a Restore custom resource.
+This page outlines how to perform a restore with Rancher.
> **Important**
>
> * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{}}/rancher/v2.6/en/backups/migrating-rancher)
> * While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore.
+> * If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation.]({{}}/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/)
+
+### Additional Steps for Rollbacks with Rancher v2.6.4+
+
+In Rancher v2.6.4, the cluster-api module has been upgraded from v0.4.4 to v1.0.2 in which the apiVersion of CAPI CRDs are upgraded from `cluster.x-k8s.io/v1alpha4` to `cluster.x-k8s.io/v1beta1`. This has the effect of causing rollbacks from Rancher v2.6.4 to any previous version of Rancher v2.6.x to fail because the previous version the CRDs needed to roll back are no longer available in v1beta1.
+
+To avoid this, the Rancher resource cleanup scripts should be run **before** the restore or rollback is attempted. Specifically, two scripts have been created to assist you: one to clean up the cluster (`cleanup.sh`), and one to check for any Rancher-related resources in the cluster (`verify.sh`). Details on the cleanup script can be found in the [rancherlabs/support-tools repo](https://github.com/rancherlabs/support-tools/tree/master/rancher-cleanup).
+
+> **Caution** Rancher will be down as the `cleanup` script runs as it deletes the resources created by rancher.
+
+The additional preparations:
+
+1. Follow these [instructions](https://github.com/rancherlabs/support-tools/blob/master/rancher-cleanup/README.md) to run the scripts.
+1. Follow these [instructions](https://rancher.com/docs/rancher/v2.6/en/backups/migrating-rancher/) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
+ 1. Omit Step 3.
+ 1. When Step 4 is reached, install the required Rancher v2.6.x version on the local cluster you intend to roll back to.
### Create the Restore Custom Resource
+A restore is performed by creating a Restore custom resource.
+
1. In the upper left corner, click **☰ > Cluster Management**.
1. On the **Clusters** page, go to the `local` cluster and click **Explore**. The `local` cluster runs the Rancher server.
1. In the left navigation bar, click **Rancher Backups > Restores**.
@@ -64,6 +82,6 @@ In some cases, after restoring the backup, Rancher logs will show errors similar
```
2021/10/05 21:30:45 [ERROR] error syncing 'c-89d82/m-4067aa68dd78': handler rke-worker-upgrader: clusters.management.cattle.io "c-89d82" not found, requeuing
```
-This happens because one of the resources that was just restored has finalizers but the related resources have been deleted so the handler cannot find it.
+This happens because one of the resources that was just restored has finalizers, but the related resources have been deleted so the handler cannot find it.
To eliminate the errors, we need to find and delete the resource that causes the error. See more information [here](https://github.com/rancher/rancher/issues/35050#issuecomment-937968556)
diff --git a/content/rancher/v2.6/en/best-practices/_index.md b/content/rancher/v2.6/en/best-practices/_index.md
index 4a9912da47b..37310b8fdd9 100644
--- a/content/rancher/v2.6/en/best-practices/_index.md
+++ b/content/rancher/v2.6/en/best-practices/_index.md
@@ -12,9 +12,7 @@ Use the navigation bar on the left to find the current best practices for managi
For more guidance on best practices, you can consult these resources:
- [Security]({{}}/rancher/v2.6/en/security/)
-- [Rancher Blog](https://rancher.com/blog/)
- - [Articles about best practices on the Rancher blog](https://rancher.com/tags/best-practices/)
- - [101 More Security Best Practices for Kubernetes](https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/)
+- [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)
diff --git a/content/rancher/v2.6/en/best-practices/rancher-server/deployment-types/_index.md b/content/rancher/v2.6/en/best-practices/rancher-server/deployment-types/_index.md
index 2c9d5a218b1..35e0fcaf41a 100644
--- a/content/rancher/v2.6/en/best-practices/rancher-server/deployment-types/_index.md
+++ b/content/rancher/v2.6/en/best-practices/rancher-server/deployment-types/_index.md
@@ -15,7 +15,7 @@ When you set up your high-availability Rancher installation, consider the follow
Don't run other workloads or microservices in the Kubernetes cluster that Rancher is installed on.
### 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)
+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/).
### When using RKE: Back up 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.
diff --git a/content/rancher/v2.6/en/best-practices/rancher-server/rancher-in-vsphere/_index.md b/content/rancher/v2.6/en/best-practices/rancher-server/rancher-in-vsphere/_index.md
index 48d5459b691..207ab8accb2 100644
--- a/content/rancher/v2.6/en/best-practices/rancher-server/rancher-in-vsphere/_index.md
+++ b/content/rancher/v2.6/en/best-practices/rancher-server/rancher-in-vsphere/_index.md
@@ -50,7 +50,7 @@ https://rancher.com/docs/rancher/v2.6/en/installation/requirements/
### Leverage VM Templates to Construct the Environment
-To facilitate consistency across the deployed Virtual Machines across the environment, consider the use of "Golden Images" in the form of VM templates. Packer can be used to accomplish this, adding greater customisation options.
+To facilitate the consistency of Virtual Machines deployed across the environment, consider the use of "Golden Images" in the form of VM templates. Packer can be used to accomplish this, adding greater customization options.
### Leverage DRS Anti-Affinity Rules (Where Possible) to Separate Rancher Cluster Nodes Across ESXi Hosts
diff --git a/content/rancher/v2.6/en/cli/_index.md b/content/rancher/v2.6/en/cli/_index.md
index 89928a7dc9b..553cb44c5c2 100644
--- a/content/rancher/v2.6/en/cli/_index.md
+++ b/content/rancher/v2.6/en/cli/_index.md
@@ -1,17 +1,33 @@
---
-title: Using the Rancher Command Line Interface
-description: The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI
-metaTitle: "Using the Rancher Command Line Interface "
-metaDescription: "The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI"
+title: CLI with Rancher
+description: Interact with Rancher using command line interface (CLI) tools from your workstation.
weight: 21
---
+- [Rancher CLI](#rancher-cli)
+ - [Download Rancher CLI](#download-rancher-cli)
+ - [Requirements](#requirements)
+ - [CLI Authentication](#cli-authentication)
+ - [Project Selection](#project-selection)
+ - [Commands](#commands)
+ - [Rancher CLI Help](#rancher-cli-help)
+ - [Limitations](#limitations)
+- [kubectl](#kubectl)
+ - [kubectl Utility](#kubectl-utility)
+ - [Authentication with kubectl and kubeconfig Tokens with TTL](#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl)
+
+# Rancher CLI
+
The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
### Download Rancher CLI
The binary can be downloaded directly from the UI. The link can be found in the right hand side of the footer in the UI. We have binaries for Windows, Mac, and Linux. You can also check the [releases page for our CLI](https://github.com/rancher/cli/releases) for direct downloads of the binary.
+1. In the upper left corner, click **☰**.
+1. At the bottom, click **v2.6.x**, where **v2.6.x** is a hyperlinked text indicating the installed Rancher version.
+1. Under the **CLI Downloads section**, there are links to download the binaries for Windows, Mac, and Linux. You can also check the [releases page for our CLI](https://github.com/rancher/cli/releases) for direct downloads of the binary.
+
### Requirements
After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires:
@@ -36,11 +52,11 @@ Before you can perform any commands, you must select a Rancher project to perfor
**Example: `./rancher context switch` Output**
```
User:rancher-cli-directory user$ ./rancher context switch
-NUMBER CLUSTER NAME PROJECT ID PROJECT NAME
-1 cluster-2 c-7q96s:p-h4tmb project-2
-2 cluster-2 c-7q96s:project-j6z6d Default
-3 cluster-1 c-lchzv:p-xbpdt project-1
-4 cluster-1 c-lchzv:project-s2mch Default
+NUMBER CLUSTER NAME PROJECT ID PROJECT NAME
+1 cluster-2 c-7q96s:p-h4tmb project-2
+2 cluster-2 c-7q96s:project-j6z6d Default
+3 cluster-1 c-lchzv:p-xbpdt project-1
+4 cluster-1 c-lchzv:project-s2mch Default
Select a Project:
```
@@ -51,13 +67,15 @@ INFO[0005] Setting new context to project project-1
INFO[0005] Saving config to /Users/markbishop/.rancher/cli2.json
```
+Ensure you can run `rancher kubectl get pods` successfully.
+
### Commands
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. |
+| `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]({{}}/rancher/v2.6/en/helm-charts/). |
| `clusters, [cluster]` | Performs operations on your [clusters]({{}}/rancher/v2.6/en/cluster-provisioning/). |
| `context` | Switches between Rancher [projects]({{}}/rancher/v2.6/en/cluster-admin/projects-and-namespaces/). For an example, see [Project Selection](#project-selection). |
@@ -78,3 +96,38 @@ The following commands are available for use in Rancher CLI.
Once logged into Rancher Server using the CLI, enter `./rancher --help` for a list of commands.
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](../helm-charts/).
+
+# kubectl
+
+Interact with Rancher using kubectl.
+
+### kubectl Utility
+
+Install the `kubectl` utility. See [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
+
+Configure kubectl by visiting your cluster in the Rancher Web UI, clicking on `Kubeconfig`, copying contents, and putting them into your `~/.kube/config` file.
+
+Run `kubectl cluster-info` or `kubectl get pods` successfully.
+
+### Authentication with kubectl and kubeconfig Tokens with TTL
+
+_Requirements_
+
+If admins have [enforced TTL on kubeconfig tokens]({{}}/rancher/v2.6/en/api/api-tokens/#setting-ttl-on-kubeconfig-tokens), the kubeconfig file requires the [Rancher CLI](../cli) to be present in your PATH when you run `kubectl`. Otherwise, you’ll see an error like:
+`Unable to connect to the server: getting credentials: exec: exec: "rancher": executable file not found in $PATH`.
+
+This feature enables kubectl to authenticate with the Rancher server and get a new kubeconfig token when required. The following auth providers are currently supported:
+
+1. Local
+2. Active Directory (LDAP only)
+3. FreeIPA
+4. OpenLDAP
+5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth
+
+When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server.
+The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../api/api-tokens/#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../../api/api-tokens/#deleting-tokens).
+Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
diff --git a/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md b/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md
index 38eb69b8cb1..c38a4dd0d5b 100644
--- a/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md
@@ -9,12 +9,64 @@ By default, Kubernetes clusters require certificates and Rancher launched Kubern
Certificates can be rotated for the following services:
+{{% tabs %}}
+{{% tab "RKE" %}}
+
- etcd
-- kubelet
+- kubelet (node certificate)
+- kubelet (serving certificate, if [enabled]({{}}/rke/latest/en/config-options/services/#kubelet-options))
- kube-apiserver
- kube-proxy
- kube-scheduler
- kube-controller-manager
+{{% /tab %}}
+{{% tab "RKE2" %}}
+
+- admin
+- api-server
+- controller-manager
+- scheduler
+- rke2-controller
+- rke2-server
+- cloud-controller
+- etcd
+- auth-proxy
+- kubelet
+- kube-proxy
+
+{{% /tab %}}
+{{% /tabs %}}
+
> **Note:** For users who didn't rotate their webhook certificates, and they have expired after one year, please see this [page]({{}}/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/) for help.
+
+### Certificate Rotation
+
+Rancher launched Kubernetes clusters have the ability to rotate the auto-generated certificates through the UI.
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. On the **Clusters** page, go to the cluster you want to rotate certificates for amd click **â‹® > Rotate Certificates**.
+1. Select which certificates that you want to rotate.
+
+ * Rotate all Service certificates (keep the same CA)
+ * Rotate an individual service and choose one of the services from the drop-down menu
+
+1. Click **Save**.
+
+**Results:** The selected certificates will be rotated and the related services will be restarted to start using the new certificate.
+
+### Additional Notes
+
+{{% tabs %}}
+{{% tab "RKE" %}}
+
+Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher launched Kubernetes clusters.
+
+{{% /tab %}}
+{{% tab "RKE2" %}}
+
+In RKE2, both etcd and control plane nodes are treated as the same `server` concept. As such, when rotating certificates of services specific to either of these components will result in certificates being rotated on both. The certificates will only change for the specified service, but you will see nodes for both components go into an updating state. You may also see worker only nodes go into an updating state. This is to restart the workers after a certificate change to ensure they get the latest client certs.
+
+{{% /tab %}}
+{{% /tabs %}}
diff --git a/content/rancher/v2.6/en/cluster-admin/cluster-access/_index.md b/content/rancher/v2.6/en/cluster-admin/cluster-access/_index.md
index 9d092a24550..291423864fc 100644
--- a/content/rancher/v2.6/en/cluster-admin/cluster-access/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/cluster-access/_index.md
@@ -20,7 +20,7 @@ Rancher provides an intuitive user interface for interacting with your clusters.
You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to manage your clusters. You have two options for using kubectl:
-- **Rancher kubectl shell:** Interact with your clusters by launching a kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. For more information, see [Accessing Clusters with kubectl Shell]({{}}/rancher/v2.6/en/cluster-access/kubectl/).
+- **Rancher kubectl shell:** Interact with your clusters by launching a kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. For more information, see [Accessing Clusters with kubectl Shell]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/).
- **Terminal remote connection:** You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local desktop and then copying the cluster's kubeconfig file to your local `~/.kube/config` directory. For more information, see [Accessing Clusters with kubectl and a kubeconfig File](./kubectl/).
### Rancher CLI
diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/_index.md
index c9e257784be..cab7cdd0d06 100644
--- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/_index.md
@@ -12,8 +12,8 @@ For information on editing cluster membership, go to [this page.]({{}}/
The cluster configuration options depend on the type of Kubernetes cluster:
- [RKE Cluster Configuration](./rke-config-reference)
-- [RKE2 Cluster Configuration](./rke2-config-reference) (Tech Preview)
-- [K3s Cluster Configuration](./k3s-config-reference) (Tech Preview)
+- [RKE2 Cluster Configuration](./rke2-config-reference)
+- [K3s Cluster Configuration](./k3s-config-reference)
- [EKS Cluster Configuration](./eks-config-reference)
- [GKE Cluster Configuration](./gke-config-reference)
- [AKS Cluster Configuration](./aks-config-reference)
diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md
index 67d3e46d94f..4eec75f21f7 100644
--- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md
@@ -11,7 +11,7 @@ Complete each drop-down and field using the information obtained for your IAM po
| Setting | Description |
| ---------- | -------------------------------------------------------------------------------------------------------------------- |
| Region | From the drop-down choose the geographical region in which to build your cluster. |
-| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.x/en/user-settings/cloud-credentials/) |
+| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.6/en/user-settings/cloud-credentials/) |
### Service Role
diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/_index.md
index 30b22867584..b87543a3157 100644
--- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/_index.md
@@ -103,13 +103,13 @@ The address range assigned to the services in the cluster. Must be a valid CIDR
_Mutable: no_
-> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/gke/private-clusters/).
+> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).
Assign nodes only internal IP addresses. Private cluster nodes cannot access the public internet unless additional networking steps are taken in GCP.
### Enable Private Endpoint
-> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/gke/#private-clusters).
+> Warning: private clusters require additional planning and configuration outside of Rancher. Refer to the [private cluster guide]({{< baseurl >}}/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/).
_Mutable: no_
diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md
index cf3b3963f05..95d9bd39bcc 100644
--- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md
@@ -21,7 +21,7 @@ If restricting outgoing internet access is not a concern for your organization,
>**Note**
>This scenario is not officially supported, but is described for cases in which using the Cloud NAT service is not sufficient.
-If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.x/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.
+If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.6/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it.
### Private Control Plane Endpoint
diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/k3s-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/k3s-config-reference/_index.md
index 47ee18b44e2..00d784cfa0c 100644
--- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/k3s-config-reference/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/k3s-config-reference/_index.md
@@ -1,5 +1,5 @@
---
-title: K3s Cluster Configuration Reference (Tech Preview)
+title: K3s Cluster Configuration Reference
shortTitle: K3s Cluster Configuration
weight: 6
---
diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md
index 2b530a8db5e..27e73a4c408 100644
--- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md
@@ -189,7 +189,7 @@ Option to enable or disable [recurring etcd snapshots]({{}}/rke/latest/
### Agent Environment Variables
-Option to set environment variables for [rancher agents]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
+Option to set environment variables for [rancher agents]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
### Updating ingress-nginx
@@ -341,7 +341,10 @@ Example:
local_cluster_auth_endpoint:
enabled: true
fqdn: "FQDN"
- ca_certs: "BASE64_CACERT"
+ ca_certs: |-
+ -----BEGIN CERTIFICATE-----
+ ...
+ -----END CERTIFICATE-----
```
### Custom Network Plug-in
diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md
index 907fbfb3aea..3e1ee54d5db 100644
--- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke2-config-reference/_index.md
@@ -1,5 +1,5 @@
---
-title: RKE2 Cluster Configuration Reference (Tech Preview)
+title: RKE2 Cluster Configuration Reference
shortTitle: RKE2 Cluster Configuration
weight: 5
---
@@ -8,7 +8,7 @@ This section covers the configuration options that are available in Rancher for
# Overview
-You can configure the Kubernetes options one of two ways:
+You can configure the Kubernetes options in one of the two following ways:
- [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
- [Cluster Config File](#cluster-config-file): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE2 config file. Using a config file allows you to set any of the [options](https://docs.rke2.io/install/install_options/install_options) available in an RKE2 installation.
@@ -28,17 +28,27 @@ For more detail, see [Upgrading Kubernetes]({{}}/rancher/v2.6/en/cluste
The [Network Provider](https://kubernetes.io/docs/concepts/cluster-administration/networking/) that the cluster uses.
-> After you launch the cluster, you cannot change your network provider. Therefore, choose which network provider you want to use carefully, as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, changing network providers would require you tear down the entire cluster and all its applications.
+> After you launch the cluster, you cannot change your network provider. Therefore, choose which network provider you want to use carefully, as Kubernetes doesn't allow switching between network providers. Once a cluster is created with a network provider, changing network providers would require you to tear down the entire cluster and all its applications.
Out of the box, Rancher is compatible with the following network providers:
- [Canal](https://github.com/projectcalico/canal)
-- [Cilium](https://cilium.io/)
+- [Cilium](https://cilium.io/)*
- [Calico](https://docs.projectcalico.org/v3.11/introduction/)
- [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)
+\* When using [project network isolation](#project-network-isolation) in the [Cilium CNI]({{}}/rancher/v2.6/en/faq/networking/cni-providers/#cilium), it is possible to enable cross-node ingress routing. Click the [CNI provider docs]({{}}/rancher/v2.6/en/faq/networking/cni-providers/#ingress-routing-across-nodes-in-cilium) to learn more.
+
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options/).
+##### Dual-stack Networking
+
+[Dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
+
+###### Additional Configuration {#dual-stack-additional-config}
+
+When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
+
#### Cloud Provider
You can configure a [Kubernetes cloud provider]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers). If you want to use dynamically provisioned [volumes and storage]({{}}/rancher/v2.6/en/cluster-admin/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.
@@ -81,7 +91,7 @@ Each cloud provider capable of launching a cluster using RKE2 can collect metric
### Add-On Config
-Additional Kubernetes manifests, managed as a [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts) for details.
+Additional Kubernetes manifests, managed as an [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts) for details.
### Agent Environment Vars
@@ -101,12 +111,24 @@ Option to choose whether to expose etcd metrics to the public or only within the
#### Cluster CIDR
-IPv4/IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
+IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
+
+##### Dual-stack Networking
+
+To configure [dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
+
+[Additional configuration](#dual-stack-additional-config) is required when using `cilium` or `multus,cilium` as your [container network](#container-network) interface provider.
#### Service CIDR
IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
+##### Dual-stack Networking
+
+To configure [dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
+
+[Additional configuration](#dual-stack-additional-config) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network) interface provider.
+
#### Cluster DNS
IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
@@ -139,7 +161,7 @@ Select the image repository to pull Rancher images from. For more details and co
### Upgrade Strategy
-#### Controle Plane Concurrency
+#### Control Plane Concurrency
Select how many nodes can be upgraded at the same time. Can be a fixed number or percentage.
@@ -164,5 +186,3 @@ Option to set kubelet options for different nodes. For available options, refer
Instead of using the Rancher UI forms to choose Kubernetes options for the cluster, advanced users can create an RKE2 config file. Using a config file allows you to set any of the [options](https://docs.rke2.io/install/install_options/install_options) available in an RKE2 installation.
To edit an RKE2 config file directly from the Rancher UI, click **Edit as YAML**.
-
-
diff --git a/content/rancher/v2.6/en/cluster-admin/nodes/_index.md b/content/rancher/v2.6/en/cluster-admin/nodes/_index.md
index a60fb2d562a..9f2243cceab 100644
--- a/content/rancher/v2.6/en/cluster-admin/nodes/_index.md
+++ b/content/rancher/v2.6/en/cluster-admin/nodes/_index.md
@@ -40,11 +40,11 @@ The following table lists which node options are available for each type of clus
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | | Download SSH key in order to SSH into the node. |
| [Node Scaling](#scaling-nodes) | ✓ | | | ✓ | | Scale the number of nodes in the node pool up or down. |
-[1]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
-[2]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/
-[3]: {{}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
-[4]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
-[5]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
+[1]: {{