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 a4e250cdb7a..554a0e5469a 100644 --- a/content/k3s/latest/en/advanced/_index.md +++ b/content/k3s/latest/en/advanced/_index.md @@ -17,11 +17,11 @@ This section contains advanced information describing the different ways you can - [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) @@ -143,7 +143,7 @@ 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. # Running K3s with Rootless mode (Experimental) @@ -256,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 @@ -293,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 @@ -365,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? 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 d7392feba23..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 @@ -46,5 +46,4 @@ 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 -disable-network-policy: true ``` diff --git a/content/k3s/latest/en/installation/installation-requirements/_index.md b/content/k3s/latest/en/installation/installation-requirements/_index.md index 3daee8b3ccc..f4fd336d7f7 100644 --- a/content/k3s/latest/en/installation/installation-requirements/_index.md +++ b/content/k3s/latest/en/installation/installation-requirements/_index.md @@ -44,7 +44,7 @@ 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. @@ -59,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 0889039827e..c667a7cef73 100644 --- a/content/k3s/latest/en/installation/network-options/_index.md +++ b/content/k3s/latest/en/installation/network-options/_index.md @@ -19,6 +19,7 @@ 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 @@ -76,10 +77,10 @@ Dual-stack networking must be configured when the cluster is first created. It c 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`, 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: +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: ``` -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 --disable-network-policy +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. @@ -91,7 +92,7 @@ If you are using a custom cni plugin, i.e. a cni plugin different from flannel, IPv6 only setup is supported on k3s v1.22 or above. As in dual-stack operation, IPv6 node addresses cannot be auto-detected; all nodes must have an explicitly configured IPv6 `node-ip`. This is an example of a valid configuration: ``` -k3s server --node-ip 2a05:d012:c6f:4611:5c2:5602:eed2:898c --cluster-cidr 2001:cafe:42:0::/56 --service-cidr 2001:cafe:42:1::/112 --disable-network-policy +k3s server --node-ip 2a05:d012:c6f:4611:5c2:5602:eed2:898c --cluster-cidr 2001:cafe:42:0::/56 --service-cidr 2001:cafe:42:1::/112 ``` Note that you can specify only one IPv6 `cluster-cidr` value. diff --git a/content/k3s/latest/en/installation/private-registry/_index.md b/content/k3s/latest/en/installation/private-registry/_index.md index c87ee3df0cb..1abbc473cd1 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: 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.6/en/cluster-admin/volumes-and-storage/_index.md b/content/rancher/v2.6/en/cluster-admin/volumes-and-storage/_index.md index 9467dfa660f..745fbce0131 100644 --- a/content/rancher/v2.6/en/cluster-admin/volumes-and-storage/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/volumes-and-storage/_index.md @@ -44,7 +44,7 @@ For details and prerequisites, refer to [this page.](./provisioning-new-storage) Longhorn is free, open source software. Originally developed by Rancher Labs, it is now being developed as a sandbox project of the Cloud Native Computing Foundation. It can be installed on any Kubernetes cluster with Helm, with kubectl, or with the Rancher UI. -If you have a pool of block storage, Longhorn can help you provide persistent storage to your Kubernetes cluster without relying on cloud providers. For more information about Longhorn features, refer to the [documentation.](https://longhorn.io/docs/1.0.2/what-is-longhorn/) +If you have a pool of block storage, Longhorn can help you provide persistent storage to your Kubernetes cluster without relying on cloud providers. For more information about Longhorn features, refer to the [documentation.](https://longhorn.io/docs/latest/what-is-longhorn/) Rancher v2.5 simplified the process of installing Longhorn on a Rancher-managed cluster. For more information, see [this page.]({{}}/rancher/v2.6/en/longhorn) diff --git a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md index 0d82a9a6e0b..bcb6f1d2089 100644 --- a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md +++ b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/_index.md @@ -2,7 +2,7 @@ title: Setting up Cloud Providers weight: 2300 --- -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. @@ -35,9 +35,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.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/_index.md b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/_index.md new file mode 100644 index 00000000000..f009dc078f8 --- /dev/null +++ b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/_index.md @@ -0,0 +1,20 @@ +--- +title: Creating a Nutanix AOS Cluster +shortTitle: Nutanix +description: Use Rancher to create a Nutanix AOS (AHV) cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes. +metaDescription: Use Rancher to create a Nutanix AOS (AHV) cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes. +weight: 2225 +--- + +[Nutanix Acropolis Operating System](https://www.nutanix.com/products/acropolis) (Nutanix AOS) is an operating system for the Nutanix hyper-converged infrastructure platform. AOS comes with a built-in hypervisor called [Acropolis Hypervisor](https://www.nutanix.com/products/ahv), or AHV. By using Rancher with Nutanix AOS (AHV), you can bring cloud operations on-premises. + +Rancher can provision nodes in AOS (AHV) and install Kubernetes on them. When creating a Kubernetes cluster in AOS, Rancher first provisions the specified number of virtual machines by communicating with the Prism Central API. Then it installs Kubernetes on top of the VMs. + +A Nutanix cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role. + +- [Creating a Nutanix Cluster]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/provisioning-nutanix-clusters/#creating-a-nutanix-aos-cluster) +- [Provisioning Storage]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/provisioning-nutanix-clusters) + +# Creating a Nutanix Cluster + +In [this section,](./provisioning-nutanix-clusters) you'll learn how to use Rancher to install an [RKE]({{}}/rke/latest/en/) Kubernetes cluster in Nutanix AOS. \ No newline at end of file diff --git a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/nutanix-node-template-config/_index.md b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/nutanix-node-template-config/_index.md new file mode 100644 index 00000000000..a4ae10d8ece --- /dev/null +++ b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/nutanix-node-template-config/_index.md @@ -0,0 +1,64 @@ +--- +title: Nutanix Node Template Configuration +weight: 2 +--- + +- [Account Access](#account-access) +- [Scheduling](#scheduling) +- [Instance Options](#instance-options) +- [Networks](#networks) +- [VM Categories](#vm-categories) +- [cloud-init](#cloud-init) + +# Account Access + +| Parameter | Required | Description | Default +|:-----------------------------|:--------:|:-----------------------------------------------------------------|:----- +| Management Endpoint | ✓ | Hostname/IP address of Prism Central | +| Username | ✓ | Username of the Prism Central user | +| Password | ✓ | Password of the Prism Central user | +| Allow insecure communication | | Set to true to allow insecure SSL communication to Prism Central | False + +# Scheduling + +Choose what Nutanix cluster the virtual machine will be scheduled to. + +| Parameter | Required | Description +|:----------|:--------:|:---------------------------------------------------------------------------- +| Cluster | ✓ | Name of the Nutanix cluster where the VM should be deployed (case sensitive) + +# Instance Options + +In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. + +| Parameter | Required | Description | Default +|:---------------------|:--------:|:--------------------------------------------------------------------------------------------|:------- +| CPUs | | Number of vCPUs allocated to the VM (cores) | 2 +| Memory | | Amount of RAM allocated to the VM (MB) | 2 GB +| Template Image | ✓ | Name of the Disk Image template to clone as the VM's primary disk (must support cloud-init) | +| VM Disk Size | | New size of the VM's primary disk (in GiB) | +| Additional Disk Size | | Size of an additional disk to add to the VM (in GiB) | +| Storage Container | | Storage container _UUID_ in which to provision an additional disk | +| Cloud Config YAML | | Cloud-init to provide to the VM (will be patched with Rancher root user) | +| Network | ✓ | Name(s) of the network(s) to attach to the VM | +| VM Categories | | Name(s) of any categories to be applied to the VM | + +The VM may use any modern Linux operating system that is configured with support for [cloud-init](https://cloudinit.readthedocs.io/en/latest/) using the [Config Drive v2 datasource](https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html). + +# Networks + +The node template allows a VM to be provisioned with multiple networks. In the **Network** field, you can click **Add** to add any networks available to you in AOS. + +# VM Categories + +A category is a grouping of entities into a key value pair. Typically, VMs are assigned to a category based on some criteria. Policies can then be tied to those entities that are assigned (grouped by) a specific category value. + +# cloud-init + +[Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users or authorizing SSH keys. + +To make use of cloud-init initialization, paste a cloud config using valid YAML syntax into the **Cloud Config YAML** field. Refer to the [cloud-init documentation](https://cloudinit.readthedocs.io/en/latest/topics/examples.html) for a commented set of examples of supported cloud config directives. + +Note that cloud-init based network configuration is not recommended and only supported via user data `runcmd` rather than by NoCloud or other network configuration datasources. + +Nutanix IP Address Management (IPAM) or another DHCP service is recommended. diff --git a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/provisioning-nutanix-clusters/_index.md b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/provisioning-nutanix-clusters/_index.md new file mode 100644 index 00000000000..de2647ddced --- /dev/null +++ b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/provisioning-nutanix-clusters/_index.md @@ -0,0 +1,90 @@ +--- +title: Provisioning Kubernetes Clusters in Nutanix AOS +weight: 1 +--- + +To use Rancher to install an [RKE]({{}}/rke/latest/en/) Kubernetes cluster in Nutanix AOS (AHV): + +1. Locate Rancher's built-in Nutanix [node driver and activate it]({{}}/rancher/v2.6/en/admin-settings/drivers/node-drivers/#activating-deactivating-node-drivers). + +1. Create a node template, which Rancher will use to provision nodes in Nutanix AOS. + +1. Create a Nutanix AOS cluster in Rancher. When configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool. + +For details on configuring the Nutanix AOS node template, refer to the [Nutanix AOS node template configuration reference.]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/nutanix-node-template-config/) + +For details on configuring RKE Kubernetes clusters in Rancher, refer to the [cluster configuration reference.]({{}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/) + +- [Preparation in Nutanix AOS](#preparation-in-nutanix-aos) +- [Creating a Nutanix AOS Cluster](#creating-a-nutanix-aos-cluster) + +# Preparation in Nutanix AOS + +The following sections describe the requirements for setting up Nutanix AOS so that Rancher can provision VMs and clusters. + +**Note:** The node templates are documented and tested with Nutanix AOS version 5.20.2 and 6.0.1. + +### Create Credentials in Nutanix AOS + +Before proceeding to create a cluster, you must ensure that you have a [Nutanix Prism Central user account](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_0:wc-user-create-wc-t.html) with admin permissions. When you set up a node template, the template will need to use these credentials. + +### Network Permissions + +You must ensure that the hosts running the Rancher server are able to establish the following network connections: + +- To the Nutanix Prism Central API (usually port 9440/TCP). +- To port 22/TCP and 2376/TCP on the created VMs + +See [Node Networking Requirements]({{}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements) for a detailed list of port requirements applicable for creating nodes on an infrastructure provider. + +### VM-VM Anti-Affinity Policies + +Setting up [VM-VM Anti-Affinity Policies](https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v6_1:ahv-vm-anti-affinity-t.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate AHV hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes. + +# Creating a Nutanix AOS Cluster + +1. [Create a node template ](#1-create-a-node-template) +2. [Create a cluster with node pools using the node template](#2-create-a-cluster-with-node-pools-using-the-node-template) + +### 1. Create a node template + +Creating a [node template]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-templates) for Nutanix AOS will allow Rancher to provision new nodes in Nutanix AOS. Node templates can be reused for other clusters. + +1. Click **☰ > Cluster Management**. +1. Click **RKE1 Configuration > Node Templates**. +1. Click **Create**. +1. Click **Add Template**. +1. Click **Nutanix**. +1. Fill out a node template for Nutanix AOS. For help filling out the form, refer to the Nutanix AOS node template [configuration reference.]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/nutanix/nutanix-node-template-config/). +1. Click **Create**. + +### 2. Create a cluster with node pools using the node template + +Use Rancher to create a Kubernetes cluster in Nutanix AOS. + +1. Click **☰ > Cluster Management**. +1. On the **Clusters** page, click **Create**. +1. Click **Nutanix**. +1. Enter a **Cluster Name**, then click **Continue**. +1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users who can access the cluster. Use the **Role** drop-down to set permissions for each user. +1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used, and whether you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the [RKE cluster configuration reference.]({{}}/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/) +1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to the nodes, see [this section.]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) +1. Review your options to confirm they're correct. Then click **Create**. + +**Result:** Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster. + +You can access your cluster after its state is updated to **Active**. + +**Active** clusters are assigned two Projects: + +- `Default`, containing the `default` namespace +- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces + + +# Optional Next Steps + +After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster: + +- **Access your cluster with the kubectl CLI:** Follow [these steps]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI. + +- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster. \ No newline at end of file diff --git a/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md b/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md index a5a57c7b6ae..c147692a558 100644 --- a/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md +++ b/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md @@ -66,7 +66,7 @@ And install Rancher with Helm. Rancher also needs a proxy configuration so that helm upgrade --install rancher rancher-latest/rancher \ --namespace cattle-system \ --set hostname=rancher.example.com \ - --set proxy=http://${proxy_host} + --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 ``` diff --git a/content/rancher/v2.6/en/installation/requirements/_index.md b/content/rancher/v2.6/en/installation/requirements/_index.md index 3c089d6023c..c60d529b881 100644 --- a/content/rancher/v2.6/en/installation/requirements/_index.md +++ b/content/rancher/v2.6/en/installation/requirements/_index.md @@ -170,6 +170,8 @@ Rancher performance depends on etcd in the cluster performance. To ensure optima This section describes the networking requirements for the node(s) where the Rancher server is installed. +> If a server containing Rancher has the `X-Frame-Options=DENY` header, some pages in the new Rancher UI will not be able to render after upgrading from the legacy UI. This is because some legacy pages are embedded as iFrames in the new UI. + ### Node IP Addresses Each node used should have a static IP configured, regardless of whether you are installing Rancher on a single node or on an HA cluster. In case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated. diff --git a/content/rancher/v2.6/en/logging/custom-resource-config/flows/_index.md b/content/rancher/v2.6/en/logging/custom-resource-config/flows/_index.md index f4ffeb05cfb..2ad4991dc8f 100644 --- a/content/rancher/v2.6/en/logging/custom-resource-config/flows/_index.md +++ b/content/rancher/v2.6/en/logging/custom-resource-config/flows/_index.md @@ -3,7 +3,7 @@ title: Flows and ClusterFlows weight: 1 --- -For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/) +For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/) - [Configuration](#configuration) - [YAML Example](#yaml-example) diff --git a/content/rancher/v2.6/en/longhorn/_index.md b/content/rancher/v2.6/en/longhorn/_index.md index ad14ffbb067..fc3d2e2ac91 100644 --- a/content/rancher/v2.6/en/longhorn/_index.md +++ b/content/rancher/v2.6/en/longhorn/_index.md @@ -6,7 +6,7 @@ weight: 19 [Longhorn](https://longhorn.io/) is a lightweight, reliable and easy-to-use distributed block storage system for Kubernetes. -Longhorn is free, open source software. Originally developed by Rancher Labs, it is now being developed as a sandbox project of the Cloud Native Computing Foundation. It can be installed on any Kubernetes cluster with Helm, with kubectl, or with the Rancher UI. You can learn more about its architecture [here.](https://longhorn.io/docs/1.0.2/concepts/) +Longhorn is free, open source software. Originally developed by Rancher Labs, it is now being developed as a sandbox project of the Cloud Native Computing Foundation. It can be installed on any Kubernetes cluster with Helm, with kubectl, or with the Rancher UI. You can learn more about its architecture [here.](https://longhorn.io/docs/latest/concepts/) With Longhorn, you can: @@ -24,12 +24,12 @@ With Longhorn, you can: ### Installing Longhorn with Rancher -1. Fulfill all [Installation Requirements.](https://longhorn.io/docs/1.1.0/deploy/install/#installation-requirements) +1. Fulfill all [Installation Requirements.](https://longhorn.io/docs/latest/deploy/install/#installation-requirements) 1. Go to the cluster where you want to install Longhorn. 1. Click **Apps & Marketplace**. 1. Click **Charts**. 1. Click **Longhorn**. -1. Optional: To customize the initial settings, click **Longhorn Default Settings** and edit the configuration. For help customizing the settings, refer to the [Longhorn documentation.](https://longhorn.io/docs/1.0.2/references/settings/) +1. Optional: To customize the initial settings, click **Longhorn Default Settings** and edit the configuration. For help customizing the settings, refer to the [Longhorn documentation.](https://longhorn.io/docs/latest/references/settings/) 1. Click **Install**. **Result:** Longhorn is deployed in the Kubernetes cluster. @@ -64,7 +64,7 @@ Longhorn creates a dedicated storage controller for each volume and synchronousl The storage controller and replicas are themselves orchestrated using Kubernetes. -You can learn more about its architecture [here.](https://longhorn.io/docs/1.0.2/concepts/) +You can learn more about its architecture [here.](https://longhorn.io/docs/latest/concepts/)
Longhorn Architecture
![Longhorn Architecture]({{}}/img/rancher/longhorn-architecture.svg) diff --git a/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md b/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md index 12bec549c0d..b24baf5a47e 100644 --- a/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md +++ b/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md @@ -49,8 +49,9 @@ Install-Module Posh-SSH ## Get the remote kubeconfig file scp root@:/etc/rancher/k3s/k3s.yaml $env:USERPROFILE\.kube\config ``` -{{% /tab %}} -{{% tabs %}} + +{{% /tab %}} +{{% /tabs %}} ## Edit the Rancher server URL in the kubeconfig @@ -80,7 +81,7 @@ Once edited, either press `ctrl+s` or go to `File > Save` to save your work. {{% /tab %}} -{{% tabs %}} +{{% /tabs %}} ## Install Rancher with Helm @@ -91,7 +92,7 @@ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest kubectl create namespace cattle-system -kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.5.1/cert-manager.crds.yaml +kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml helm repo add jetstack https://charts.jetstack.io @@ -100,13 +101,13 @@ helm repo update helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ - --version v1.5.1 + --version v1.7.1 # Windows Powershell -helm install cert-manager jetstack/cert-manager \` - --namespace cert-manager \` - --create-namespace \` - --version v1.5.1 +helm install cert-manager jetstack/cert-manager ` + --namespace cert-manager ` + --create-namespace ` + --version v1.7.1 ``` The final command to install Rancher is below. The command requires a domain name that forwards traffic to the Linux machine. For the sake of simplicity in this tutorial, you can use a fake domain name to create your proof-of-concept. An example of a fake domain name would be `.sslip.io`. @@ -129,8 +130,8 @@ helm install rancher rancher-latest/rancher ` Now if you navigate to `.sslip.io` in a web browser, you should see the Rancher UI. -To make these instructions simple, we used a fake domain name and self-signed certificates to do this installation. For production installs, you would need a high-availability setup with a load balancer, a real domain name and real certificates. +To make these instructions simple, we used a fake domain name and self-signed certificates to do this installation. Therefore, you will probably need to add a security exception to your web browser to see the Rancher UI. Note that for production installs, you would need a high-availability setup with a load balancer, a real domain name and real certificates. These instructions also left out the full installation requirements and other installation options. If you have any issues with these steps, refer to the full [Helm CLI installation docs.]({{}}/rancher/v2.6/en/installation/install-rancher-on-k8s/) -To launch new Kubernetes clusters with your new Rancher server, you may need to set up cloud credentials in Rancher. For more information, see [Launching Kubernetes clusters with Rancher.]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) \ No newline at end of file +To launch new Kubernetes clusters with your new Rancher server, you may need to set up cloud credentials in Rancher. For more information, see [Launching Kubernetes clusters with Rancher.]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) diff --git a/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md b/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md index 5be4b866fb9..004950b7fe2 100644 --- a/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md +++ b/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md @@ -54,6 +54,7 @@ Now that the application is up and running, it needs to be exposed so that other **Result:** The application is assigned a `sslip.io` address and exposed. It may take a minute or two to populate. + ### View Your Application From the **Deployments** page, find the **Endpoints** column for your deployment and click on an endpoint. The endpoints available will depend on how you configured the port you added to your deployment. For endpoints where you do not see a randomly assigned port, append the path you specified when creating the ingress to the IP address. For example, if your endpoint looks like `xxx.xxx.xxx.xxx` or `https://xxx.xxx.xxx.xxx` change it to `xxx.xxx.xxx.xxx/hello` or `https://xxx.xxx.xxx.xxx/hello`. diff --git a/content/rancher/v2.6/en/security/cve/_index.md b/content/rancher/v2.6/en/security/cve/_index.md index 628473bb891..b353c508096 100644 --- a/content/rancher/v2.6/en/security/cve/_index.md +++ b/content/rancher/v2.6/en/security/cve/_index.md @@ -7,6 +7,10 @@ Rancher is committed to informing the community of security issues in our produc | ID | Description | Date | Resolution | |----|-------------|------|------------| +| [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 which allows users who have create or update permissions on [Global Roles](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rbac/) to escalate their permissions, or those of another user, to admin-level permissions. Global Roles grant users Rancher-wide permissions, such as the ability to create clusters. In the identified versions of Rancher, when users are given permission to edit or create Global Roles, they are not restricted to only granting permissions which they already posses. This vulnerability affects customers who utilize non-admin users that are able to create or edit Global Roles. The most common use case for this scenario is the `restricted-admin` role. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) | +| [CVE-2021-4200](https://github.com/rancher/rancher/security/advisories/GHSA-hx8w-ghh8-r4xf) | This vulnerability only affects customers using the `restricted-admin` role in Rancher. A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 where the `global-data` role in `cattle-global-data` namespace grants write access to the Catalogs. Since each user with any level of catalog access was bound to the `global-data` role, this grants write access to templates (`CatalogTemplates`) and template versions (`CatalogTemplateVersions`) for any user with any level of catalog access. New users created in Rancher are by default assigned to the `user` role (standard user), which is not designed to grant write catalog access. This vulnerability effectively elevates the privilege of any user to write access for the catalog template and catalog template version resources. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) | +| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | This vulnerability only affects customers using [Fleet](https://rancher.com/docs/rancher/v2.6/en/deploy-across-clusters/fleet/) for continuous delivery with authenticated Git and/or Helm repositories. An issue was discovered in `go-getter` library in versions prior to [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) that exposes SSH private keys in base64 format due to a failure in redacting such information from error messages. The vulnerable version of this library is used in Rancher through Fleet in versions of Fleet prior to [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9). This issue affects Rancher versions 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3. The issue was found and reported by Dagan Henderson from Raft Engineering. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) | +| [CVE-2021-36778](https://github.com/rancher/rancher/security/advisories/GHSA-4fc7-hc63-7fjg) | A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.11 and from 2.6.0 up to and including 2.6.2, where an insufficient check of the same-origin policy when downloading Helm charts from a configured private repository can lead to exposure of the repository credentials to a third-party provider. This issue only happens when the user configures access credentials to a private repository in Rancher inside `Apps & Marketplace > Repositories`. The issue was found and reported by Martin Andreas Ullrich. | 14 Apr 2022 | [Rancher v2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) and [Rancher v2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) | | [GHSA-hwm2-4ph6-w6m5](https://github.com/rancher/rancher/security/advisories/GHSA-hwm2-4ph6-w6m5) | A vulnerability was discovered in versions of Rancher starting 2.0 up to and including 2.6.3. The `restricted` pod security policy (PSP) provided in Rancher deviated from the upstream `restricted` policy provided in Kubernetes on account of which Rancher's PSP had `runAsUser` set to `runAsAny`, while upstream had `runAsUser` set to `MustRunAsNonRoot`. This allowed containers to run as any user, including a privileged user (`root`), even when Rancher's `restricted` policy was enforced on a project or at the cluster level. | 31 Mar 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | | [CVE-2021-36775](https://github.com/rancher/rancher/security/advisories/GHSA-28g7-896h-695v) | A vulnerability was discovered in Rancher versions up to and including 2.4.17, 2.5.11 and 2.6.2. After removing a `Project Role` associated with a group from the project, the bindings that granted access to cluster-scoped resources for those subjects were not deleted. This was due to an incomplete authorization logic check. A user who was a member of the affected group with authenticated access to Rancher could exploit this vulnerability to access resources they shouldn't have had access to. The exposure level would depend on the original permission level granted to the affected project role. This vulnerability only affected customers using group based authentication in Rancher. | 31 Mar 2022 | [Rancher v2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3), [Rancher v2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) and [Rancher v2.4.18](https://github.com/rancher/rancher/releases/tag/v2.4.18) | | [CVE-2021-36776](https://github.com/rancher/rancher/security/advisories/GHSA-gvh9-xgrq-r8hw) | A vulnerability was discovered in Rancher versions starting 2.5.0 up to and including 2.5.9, that allowed an authenticated user to impersonate any user on a cluster through an API proxy, without requiring knowledge of the impersonated user's credentials. This was due to the API proxy not dropping the impersonation header before sending the request to the Kubernetes API. A malicious user with authenticated access to Rancher could use this to impersonate another user with administrator access in Rancher, thereby gaining administrator level access to the cluster. | 31 Mar 2022 | [Rancher v2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) and [Rancher v2.5.10](https://github.com/rancher/rancher/releases/tag/v2.5.10) | diff --git a/content/rke/latest/en/config-options/_index.md b/content/rke/latest/en/config-options/_index.md index 30b0383d445..3fe0a5ab2eb 100644 --- a/content/rke/latest/en/config-options/_index.md +++ b/content/rke/latest/en/config-options/_index.md @@ -50,7 +50,10 @@ cluster_name: mycluster ### Supported Docker Versions -By default, RKE will check the installed Docker version on all hosts and fail with an error if the version is not supported by Kubernetes. The list of [supported Docker versions](https://github.com/rancher/rke/blob/master/docker/docker.go#L37-L41) are set specifically for each Kubernetes version. To override this behavior, set this option to `true`. +By default, RKE will check the installed Docker version on all hosts and fail with an error if the version is not supported by Kubernetes. The list of supported Docker versions is set specifically for each Kubernetes version in kontainer-driver-metadata depending on the RKE version used, as shown below. To override this behavior, set this option to `true`. Refer to the following: + +- For RKE v1.3.x, see this [link](https://github.com/rancher/kontainer-driver-metadata/blob/release-v2.6/rke/k8s_docker_info.go). +- For RKE v1.2.x, see this [link](https://github.com/rancher/kontainer-driver-metadata/blob/release-v2.5/rke/k8s_docker_info.go). The default value is `false`. diff --git a/content/rke/latest/en/config-options/cloud-providers/_index.md b/content/rke/latest/en/config-options/cloud-providers/_index.md index 45501bcf784..f9a58253e15 100644 --- a/content/rke/latest/en/config-options/cloud-providers/_index.md +++ b/content/rke/latest/en/config-options/cloud-providers/_index.md @@ -3,7 +3,7 @@ title: Cloud Providers weight: 250 --- -RKE supports the ability to set your specific [cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) for your Kubernetes cluster. There are specific cloud configurations for these cloud providers. +RKE supports the ability to set your specific cloud provider for your Kubernetes cluster. There are specific cloud configurations for these cloud providers. To enable a cloud provider its name as well as any required configuration options must be provided under the `cloud_provider` directive in the cluster YML. * [AWS]({{}}/rke/latest/en/config-options/cloud-providers/aws) diff --git a/content/rke/latest/en/config-options/secrets-encryption/_index.md b/content/rke/latest/en/config-options/secrets-encryption/_index.md index ff8bab209a6..f2539991d7f 100644 --- a/content/rke/latest/en/config-options/secrets-encryption/_index.md +++ b/content/rke/latest/en/config-options/secrets-encryption/_index.md @@ -139,7 +139,7 @@ kube-api: secrets_encryption_config: enabled: true custom_config: - api_version: apiserver.config.k8s.io/v1 + apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - Providers: @@ -147,7 +147,7 @@ kube-api: Keys: - Name: key1 Secret: - Resources: + resources: - secrets - identity: {} ```