mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Sync content from rancher/docs
Start: cb708da8d Jul 7 2022 End: 09d646cfc Sep 2 2022
This commit is contained in:
+1
-1
@@ -24,7 +24,7 @@ services:
|
||||
|
||||
You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.4.0/tuning/#disk) on how to tune the disk priority on the host.
|
||||
|
||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS.
|
||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use striping RAID configurations to increase available IOPS.
|
||||
|
||||
To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etcd/wal` directories will need to have disks mounted and formatted on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions.
|
||||
|
||||
|
||||
+1
-1
@@ -80,7 +80,7 @@ sudo mv ./kubectl /usr/local/bin/kubectl
|
||||
* [helm](https://helm.sh/docs/intro/install/)
|
||||
|
||||
```
|
||||
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
|
||||
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
|
||||
chmod +x get_helm.sh
|
||||
sudo ./get_helm.sh
|
||||
```
|
||||
|
||||
+1
-1
@@ -28,7 +28,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
|
||||
3. **Optional:** Edit `config.yaml` to:
|
||||
|
||||
- Change the number of nodes and the memory allocations, if required. (`node.count`, `node.cpus`, `node.memory`)
|
||||
- Change the password of the `admin` user for logging into Rancher. (`default_password`)
|
||||
- Change the password of the `admin` user for logging into Rancher. (`admin_password`)
|
||||
|
||||
4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`.
|
||||
|
||||
|
||||
@@ -13,8 +13,6 @@ Rancher was originally built to work with multiple orchestrators, and it include
|
||||
|
||||
Rancher can provision Kubernetes from a hosted provider, provision compute nodes and then install Kubernetes onto them, or import existing Kubernetes clusters running anywhere.
|
||||
|
||||
One Rancher server installation can manage thousands of Kubernetes clusters and thousands of nodes from the same user interface.
|
||||
|
||||
Rancher adds significant value on top of Kubernetes, first by centralizing authentication and role-based access control (RBAC) for all of the clusters, giving global admins the ability to control cluster access from one location.
|
||||
|
||||
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.
|
||||
|
||||
@@ -37,7 +37,7 @@ _**Available as of v2.4.6**_
|
||||
|
||||
Starting Rancher v2.4.6, admins can set a global TTL on Kubeconfig tokens. Once the token expires the kubectl command will require the user to authenticate to Rancher.
|
||||
|
||||
_**Note:**_:
|
||||
_**Note:**_
|
||||
|
||||
Existing kubeconfig tokens won't be updated with the new TTL. Admins can [delete old kubeconfig tokens](#deleting-tokens).
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ CNI network providers using this network model include Calico and Romana.
|
||||
|
||||
### What CNI Providers are Provided by Rancher?
|
||||
|
||||
Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave. You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
|
||||
Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico, and Weave. You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
|
||||
|
||||
#### Canal
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ services:
|
||||
|
||||
You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.4.0/tuning/#disk) on how to tune the disk priority on the host.
|
||||
|
||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS.
|
||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use striping RAID configurations to increase available IOPS.
|
||||
|
||||
To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etcd/wal` directories will need to have disks mounted and formatted on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions.
|
||||
|
||||
|
||||
+1
-1
@@ -82,7 +82,7 @@ sudo mv ./kubectl /usr/local/bin/kubectl
|
||||
* [helm](https://helm.sh/docs/intro/install/)
|
||||
|
||||
```
|
||||
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
|
||||
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
|
||||
chmod +x get_helm.sh
|
||||
sudo ./get_helm.sh
|
||||
```
|
||||
|
||||
+1
-1
@@ -30,7 +30,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
|
||||
3. **Optional:** Edit `config.yaml` to:
|
||||
|
||||
- Change the number of nodes and the memory allocations, if required. (`node.count`, `node.cpus`, `node.memory`)
|
||||
- Change the password of the `admin` user for logging into Rancher. (`default_password`)
|
||||
- Change the password of the `admin` user for logging into Rancher. (`admin_password`)
|
||||
|
||||
4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`.
|
||||
|
||||
|
||||
+203
-98
@@ -1,23 +1,29 @@
|
||||
---
|
||||
title: Configuring Azure AD
|
||||
weight: 1115
|
||||
aliases:
|
||||
- /rancher/v2.5/en/tasks/global-configuration/authentication/azure-ad/
|
||||
- /rancher/v2.x/en/admin-settings/authentication/azure-ad/
|
||||
---
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.16+" %}}
|
||||
|
||||
## Microsoft Graph API
|
||||
|
||||
Microsoft Graph API is now the flow through which you will set up Azure AD. The below sections will assist [new users](#new-user-setup) in configuring Azure AD with a new instance as well as assist existing Azure app owners in [migrating to the new flow](#migrating-from-azure-ad-graph-api-to-microsoft-graph-api).
|
||||
|
||||
### New User Setup
|
||||
|
||||
If you have an instance of Active Directory (AD) hosted in Azure, you can configure Rancher to allow your users to log in using their AD accounts. Configuration of Azure AD external authentication requires you to make configurations in both Azure and Rancher.
|
||||
|
||||
>**Note:** Azure AD integration only supports Service Provider initiated logins.
|
||||
|
||||
>**Prerequisite:** Have an instance of Azure AD configured.
|
||||
|
||||
>**Note:** Most of this procedure takes place from the [Microsoft Azure Portal](https://portal.azure.com/).
|
||||
>**Notes:**
|
||||
>
|
||||
>- Azure AD integration only supports Service Provider initiated logins.
|
||||
>- Most of this procedure takes place from the [Microsoft Azure Portal](https://portal.azure.com/).
|
||||
|
||||
## Azure Active Directory Configuration Outline
|
||||
#### Azure Active Directory Configuration Outline
|
||||
|
||||
Configuring Rancher to allow your users to authenticate with their Azure AD accounts involves multiple procedures. Review the outline below before getting started.
|
||||
|
||||
<a id="tip"></a>
|
||||
|
||||
>**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later.
|
||||
@@ -27,13 +33,12 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco
|
||||
- [1. Register Rancher with Azure](#1-register-rancher-with-azure)
|
||||
- [2. Create a new client secret](#2-create-a-new-client-secret)
|
||||
- [3. Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher)
|
||||
- [4. Add a Reply URL](#4-add-a-reply-url)
|
||||
- [5. Copy Azure Application Data](#5-copy-azure-application-data)
|
||||
- [6. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher)
|
||||
- [4. Copy Azure Application Data](#5-copy-azure-application-data)
|
||||
- [5. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
### 1. Register Rancher with Azure
|
||||
#### 1. Register Rancher with Azure
|
||||
|
||||
Before enabling Azure AD within Rancher, you must register Rancher with Azure.
|
||||
|
||||
@@ -47,37 +52,40 @@ Before enabling Azure AD within Rancher, you must register Rancher with Azure.
|
||||
|
||||

|
||||
|
||||
1. Enter a **Name** (something like `Rancher`).
|
||||
3.1. Enter a **Name** (something like `Rancher`).
|
||||
<a id="3.2"></a>
|
||||
|
||||
1. From **Supported account types**, select "Accounts in this organizational directory only (AzureADTest only - Single tenant)" This corresponds to the legacy app registration options.
|
||||
3.2. From **Supported account types**, select "Accounts in this organizational directory only (AzureADTest only - Single tenant)" This corresponds to the legacy app registration options.
|
||||
|
||||
1. In the **Redirect URI** section, make sure **Web** is selected from the dropdown and enter the URL of your Rancher Server in the text box next to the dropdown. This Rancher server URL should be appended with the verification path: `<MY_RANCHER_URL>/verify-auth-azure`.
|
||||
>**Important:** In the updated Azure portal, Redirect URIs are synonymous with Reply URLs. In order to use Azure AD with Rancher, you must whitelist Rancher with Azure (previously done through Reply URLs). Therefore, you must ensure to fill in the Redirect URI with your Rancher server URL, to include the verification path as listed below.
|
||||
|
||||
>**Tip:** You can find your personalized Azure reply URL in Rancher on the Azure AD Authentication page (Global View > Security Authentication > Azure AD).
|
||||
3.3. In the [**Redirect URI**](https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url) section, make sure **Web** is selected from the dropdown and enter the URL of your Rancher Server in the text box next to the dropdown. This Rancher server URL should be appended with the verification path: `<MY_RANCHER_URL>/verify-auth-azure`.
|
||||
|
||||
1. Click **Register**.
|
||||
>**Tip:** You can find your personalized Azure Redirect URI (reply URL) in Rancher on the Azure AD Authentication page (Global View > Authentication > Web).
|
||||
|
||||
>**Note:** It can take up to five minutes for this change to take affect, so don't be alarmed if you can't authenticate immediately after Azure AD configuration.
|
||||
3.4. Click **Register**.
|
||||
|
||||
### 2. Create a new client secret
|
||||
>**Important:** It can take up to five minutes for this change to take affect, so don't be alarmed if you can't authenticate immediately after Azure AD configuration.
|
||||
|
||||
#### 2. Create a new client secret
|
||||
|
||||
From the Azure portal, create a client secret. Rancher will use this key to authenticate with Azure AD.
|
||||
|
||||
1. Use search to open **App registrations** services. Then open the entry for Rancher that you created in the last procedure.
|
||||
|
||||

|
||||

|
||||
|
||||
1. From the navigation pane on left, click **Certificates and Secrets**.
|
||||
|
||||
1. Click **New client secret**.
|
||||
|
||||

|
||||

|
||||
|
||||
1. Enter a **Description** (something like `Rancher`).
|
||||
3.1. Enter a **Description** (something like `Rancher`).
|
||||
|
||||
1. Select duration for the key from the options under **Expires**. This drop-down sets the expiration date for the key. Shorter durations are more secure, but require you to create a new key after expiration.
|
||||
3.2. Select duration for the key from the options under **Expires**. This drop-down sets the expiration date for the key. Shorter durations are more secure, but require you to create a new key after expiration.
|
||||
|
||||
1. Click **Add** (you don't need to enter a value—it will automatically populate after you save).
|
||||
3.3. Click **Add** (you don't need to enter a value—it will automatically populate after you save).
|
||||
<a id="secret"></a>
|
||||
|
||||
1. Copy the key value and save it to an [empty text file](#tip).
|
||||
@@ -86,110 +94,95 @@ From the Azure portal, create a client secret. Rancher will use this key to auth
|
||||
|
||||
You won't be able to access the key value again within the Azure UI.
|
||||
|
||||
### 3. Set Required Permissions for Rancher
|
||||
#### 3. Set Required Permissions for Rancher
|
||||
|
||||
Next, set API permissions for Rancher within Azure.
|
||||
|
||||
:::caution
|
||||
|
||||
Ensure that you set the permissions of type Application and NOT Delegated. Otherwise, you may not be able to login to Azure AD. This issue will persist even after you disable/re-enable Azure AD and will require an hour wait, or manual deletion of a cache value to resolve.
|
||||
|
||||
:::
|
||||
|
||||
1. From the navigation pane on left, select **API permissions**.
|
||||
|
||||

|
||||

|
||||
|
||||
1. Click **Add a permission**.
|
||||
|
||||
1. From the **Azure Active Directory Graph**, select the following **Delegated Permissions**:
|
||||
1. From the **Microsoft Graph**, select the following **Application Permissions**:
|
||||
- `Group.Read.All`
|
||||
- `User.Read.All`
|
||||
|
||||

|
||||
![Select API Permissions]/img/api-permissions.png)
|
||||
|
||||
<br/>
|
||||
<br/>
|
||||
- **Access the directory as the signed-in user**
|
||||
- **Read directory data**
|
||||
- **Read all groups**
|
||||
- **Read all users' full profiles**
|
||||
- **Read all users' basic profiles**
|
||||
- **Sign in and read user profile**
|
||||
|
||||
1. Click **Add permissions**.
|
||||
|
||||
1. From **API permissions**, click **Grant admin consent**. Then click **Yes**.
|
||||
1. Return to **API permissions** in the left nav bar. From there, click **Grant admin consent**. Then click **Yes**.
|
||||
|
||||
>**Note:** You must be signed in as an Azure administrator to successfully save your permission settings.
|
||||
|
||||
|
||||
### 4. Add a Reply URL
|
||||
|
||||
To use Azure AD with Rancher you must whitelist Rancher with Azure. You can complete this whitelisting by providing Azure with a reply URL for Rancher, which is your Rancher Server URL followed with a verification path.
|
||||
|
||||
|
||||
1. From the **Setting** blade, select **Reply URLs**.
|
||||
|
||||

|
||||
|
||||
1. From the **Reply URLs** blade, enter the URL of your Rancher Server, appended with the verification path: `<MY_RANCHER_URL>/verify-auth-azure`.
|
||||
|
||||
>**Tip:** You can find your personalized Azure reply URL in Rancher on the Azure AD Authentication page (Global View > Security Authentication > Azure AD).
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Your reply URL is saved.
|
||||
|
||||
>**Note:** It can take up to five minutes for this change to take affect, so don't be alarmed if you can't authenticate immediately after Azure AD configuration.
|
||||
|
||||
### 5. Copy Azure Application Data
|
||||
#### 4. Copy Azure Application Data
|
||||
|
||||
As your final step in Azure, copy the data that you'll use to configure Rancher for Azure AD authentication and paste it into an empty text file.
|
||||
|
||||
1. Obtain your Rancher **Tenant ID**.
|
||||
|
||||
1. Use search to open the **Azure Active Directory** service.
|
||||
|
||||

|
||||
|
||||
1. From the left navigation pane, open **Overview**.
|
||||
|
||||
2. Copy the **Directory ID** and paste it into your [text file](#tip).
|
||||
|
||||
You'll paste this value into Rancher as your **Tenant ID**.
|
||||
|
||||
1. Obtain your Rancher **Application ID**.
|
||||
|
||||
1. Use search to open **App registrations**.
|
||||
|
||||

|
||||

|
||||
|
||||
1. Find the entry you created for Rancher.
|
||||
|
||||
1. Copy the **Application ID** and paste it to your [text file](#tip).
|
||||
1. Copy the **Directory ID** and paste it into your [text file](#tip).
|
||||
|
||||
1. Obtain your Rancher **Graph Endpoint**, **Token Endpoint**, and **Auth Endpoint**.
|
||||

|
||||
|
||||
1. From **App registrations**, click **Endpoints**.
|
||||
- You'll paste this value into Rancher as your **Tenant ID**.
|
||||
|
||||

|
||||
1. Obtain your Rancher **Application (Client) ID**.
|
||||
|
||||
2. Copy the following endpoints to your clipboard and paste them into your [text file](#tip) (these values will be your Rancher endpoint values).
|
||||
|
||||
- **Microsoft Graph API endpoint** (Graph Endpoint)
|
||||
- **OAuth 2.0 token endpoint (v1)** (Token Endpoint)
|
||||
- **OAuth 2.0 authorization endpoint (v1)** (Auth Endpoint)
|
||||
|
||||
>**Note:** Copy the v1 version of the endpoints
|
||||
1. Use search to open **App registrations** (if not already there).
|
||||
|
||||
### 6. Configure Azure AD in Rancher
|
||||
1. In **Overview**, find the entry you created for Rancher.
|
||||
|
||||
1. Copy the **Application (Client) ID** and paste it to your [text file](#tip).
|
||||
|
||||

|
||||
|
||||
1. Your endpoint options will typically be [Standard](#global) and [China](#china). With the Standard option, perform the steps below and Rancher will take care of the rest.
|
||||
|
||||
- Enter the **Tenant ID**, **Application ID**, and **Application Secret**
|
||||
- Click **Enable**
|
||||
|
||||

|
||||
|
||||
>**For Custom Endpoints:**
|
||||
>
|
||||
>**Warning:** Custom Endpoints are not supported nor fully tested by Rancher.
|
||||
>
|
||||
> You will need to also manually enter the Graph, Token, and Auth Endpoints.
|
||||
>
|
||||
>- From <b>App registrations</b>, click <b>Endpoints</b>:
|
||||
>
|
||||
>
|
||||
>
|
||||
>- Copy the following endpoints to your clipboard and paste them into your [text file](#tip) (these values will be your Rancher endpoint values). Make sure to copy the v1 version of the endpoints.
|
||||
>
|
||||
> - **Microsoft Graph API endpoint** (Graph Endpoint)
|
||||
> - **OAuth 2.0 token endpoint (v1)** (Token Endpoint)
|
||||
> - **OAuth 2.0 authorization endpoint (v1)** (Auth Endpoint)
|
||||
|
||||
#### 5. Configure Azure AD in Rancher
|
||||
|
||||
From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration.
|
||||
|
||||
Enter the values that you copied to your [text file](#tip).
|
||||
|
||||
1. Log into Rancher. From the **Global** view, select **Security > Authentication**.
|
||||
|
||||
1. Select **Azure AD**.
|
||||
|
||||
1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#5-copy-azure-application-data).
|
||||
|
||||
>**Important:** When entering your Graph Endpoint, remove the tenant ID from the URL, like below.
|
||||
>
|
||||
><code>http<span>s://g</span>raph.windows.net/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
|
||||
1. Log into Rancher.
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation menu, click **Auth Provider**.
|
||||
1. Click **AzureAD**.
|
||||
1. Complete the **Configure Azure AD Account** form using the information you copied while completing [Copy Azure Application Data](#4-copy-azure-application-data).
|
||||
|
||||
The following table maps the values you copied in the Azure portal to the fields in Rancher.
|
||||
|
||||
@@ -199,10 +192,122 @@ Enter the values that you copied to your [text file](#tip).
|
||||
| Application ID | Application ID |
|
||||
| Application Secret | Key Value |
|
||||
| Endpoint | https://login.microsoftonline.com/ |
|
||||
| Graph Endpoint | Microsoft Azure AD Graph API Endpoint |
|
||||
| Token Endpoint | OAuth 2.0 Token Endpoint |
|
||||
| Auth Endpoint | OAuth 2.0 Authorization Endpoint |
|
||||
|
||||
1. Click **Authenticate with Azure**.
|
||||
|
||||
>**For Custom Endpoints:**
|
||||
><br/>
|
||||
>The following table maps the custom config values you copied in the Azure portal to the fields in Rancher:
|
||||
>
|
||||
>| Rancher Field | Azure Value |
|
||||
>| ------------------ | ------------------------------------- |
|
||||
>| Graph Endpoint | Microsoft Graph API Endpoint |
|
||||
>| Token Endpoint | OAuth 2.0 Token Endpoint |
|
||||
>| Auth Endpoint | OAuth 2.0 Authorization Endpoint |
|
||||
><br/>
|
||||
>**Important:** When entering the Graph Endpoint in a custom config, remove the tenant ID from the URL, like below:
|
||||
>
|
||||
><code>http<span>s://g</span>raph.microsoft.com/<del>abb5adde-bee8-4821-8b03-e63efdc7701c</del></code>
|
||||
|
||||
1. Click **Enable**.
|
||||
|
||||
**Result:** Azure Active Directory authentication is configured.
|
||||
|
||||
|
||||
### Migrating from Azure AD Graph API to Microsoft Graph API
|
||||
|
||||
Since [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) was deprecated in June 2022 and will be retired at the end of 2022, users should update their Azure AD App to use the new [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) in Rancher.
|
||||
|
||||
#### Updating Endpoints in the Rancher UI
|
||||
|
||||
>**Important:** Admins should create a [backup]../../../..//new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) right before they commit to the endpoint migration in Step 4 below.
|
||||
|
||||
1. Update the permissions of your Azure AD app registration as described [here](#3-set-required-permissions-for-rancher).
|
||||
**This is critical.**
|
||||
|
||||
1. Log into Rancher.
|
||||
|
||||
1. In the Rancher UI homepage, make note of the banner at the top of screen that advises users to update their Azure AD authentication. Click on the link provided to do so.
|
||||
|
||||

|
||||
|
||||
1. To complete the move to the new Microsoft Graph API, click **Update Endpoint**, then click **Save**.
|
||||
|
||||
**Note:** Ensure that your Azure app has a [new set of permissions](#3-set-required-permissions-for-rancher) before starting the update.
|
||||
|
||||

|
||||
|
||||
1. When you receive the pop-up warning message, click **Update**.
|
||||
|
||||

|
||||
|
||||
1. Refer to the [tables](#global) below for the full list of endpoint changes that Rancher performs. Admins do not need to do this manually.
|
||||
|
||||
#### Air-Gapped Environments
|
||||
|
||||
In air-gapped environments, admins should ensure that their endpoints are [whitelisted](#3.2) since the Graph Endpoint URL is changing.
|
||||
|
||||
#### Rolling Back the Migration
|
||||
|
||||
If you need to roll back your migration, please note the following:
|
||||
|
||||
1. Admins are encouraged to use the proper restore process if they want to go back. Please see [backup docs](../../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md), [restore docs](../../../../new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md), and [examples](../../../../../reference-guides/backup-restore-configuration/examples.md) for reference.
|
||||
|
||||
1. Azure app owners who want to rotate the Application Secret will need to also rotate it in Rancher as Rancher does not automatically update the Application Secret when it is changed in Azure. In Rancher, note that it is stored in a Kubernetes secret called `azureadconfig-applicationsecret` which is in the `cattle-global-data` namespace.
|
||||
|
||||
1. **Caution:** If admins upgrade to Rancher v2.5.16 with an existing Azure AD setup and choose to disable the auth provider, they won't be able to restore the previous setup and also will not be able to set up Azure AD anew using the old flow. Admins will then need to register again with the new auth flow. Rancher now uses the new Graph API and, therefore, users need set up the [proper permissions in the Azure portal](#3-set-required-permissions-for-rancher).
|
||||
|
||||
#### Global:
|
||||
|
||||
Rancher Field | Deprecated Endpoints
|
||||
---------------- | -------------------------------------------------------------
|
||||
Auth Endpoint | https://login.microsoftonline.com/{tenantID}/oauth2/authorize
|
||||
Endpoint | https://login.microsoftonline.com/
|
||||
Graph Endpoint | https://graph.windows.net/
|
||||
Token Endpoint | https://login.microsoftonline.com/{tenantID}/oauth2/token
|
||||
---
|
||||
|
||||
Rancher Field | New Endpoints
|
||||
---------------- | ------------------------------------------------------------------
|
||||
Auth Endpoint | https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/authorize
|
||||
Endpoint | https://login.microsoftonline.com/
|
||||
Graph Endpoint | https://graph.microsoft.com
|
||||
Token Endpoint | https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token
|
||||
|
||||
#### China:
|
||||
|
||||
Rancher Field | Deprecated Endpoints
|
||||
---------------- | ----------------------------------------------------------
|
||||
Auth Endpoint | https://login.chinacloudapi.cn/{tenantID}/oauth2/authorize
|
||||
Endpoint | https://login.chinacloudapi.cn/
|
||||
Graph Endpoint | https://graph.chinacloudapi.cn/
|
||||
Token Endpoint | https://login.chinacloudapi.cn/{tenantID}/oauth2/token
|
||||
---
|
||||
|
||||
Rancher Field | New Endpoints
|
||||
---------------- | -------------------------------------------------------------------------
|
||||
Auth Endpoint | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2.0/authorize
|
||||
Endpoint | https://login.partner.microsoftonline.cn/
|
||||
Graph Endpoint | https://microsoftgraph.chinacloudapi.cn
|
||||
Token Endpoint | https://login.partner.microsoftonline.cn/{tenantID}/oauth2/v2.0/token
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.5.0 - v2.5.15" %}}
|
||||
|
||||
## Azure AD Graph API
|
||||
|
||||
>**Important:**
|
||||
>
|
||||
>- The [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) was deprecated in June 2022 and will be retired at the end of 2022. We will update our docs to advise the community when it is retired. Rancher now uses the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) as the new flow to set up Azure AD as the external auth provider.
|
||||
>
|
||||
>
|
||||
>- For new users, or existing users who wish to migrate, refer to the new flow instructions on the <a href="#microsoft-graph-api" target="_blank">Rancher v2.5.16+</a> tab.
|
||||
>
|
||||
>
|
||||
>- For existing users who do not wish to upgrade to v2.5.16+ after the Azure AD Graph API is retired, they will need to either:
|
||||
- Use the built-in Rancher auth or
|
||||
- Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](../../../../../pages-for-subheaders/about-authentication.md) to learn how to configure other open authentication providers.
|
||||
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
+4
-2
@@ -29,7 +29,9 @@ These elements are required to follow this guide:
|
||||
|
||||
### 1. Create a Custom Cluster
|
||||
|
||||
On Rancher server, we should create a custom k8s cluster v1.18.x. Be sure that cloud_provider name is set to `amazonec2`. Once cluster is created we need to get:
|
||||
On Rancher server, we should create a custom k8s cluster. Refer [here](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) to check for version compatibility.
|
||||
|
||||
Be sure that cloud_provider name is set to `amazonec2`. Once cluster is created we need to get:
|
||||
|
||||
* clusterID: `c-xxxxx` will be used on EC2 `kubernetes.io/cluster/<clusterID>` instance tag
|
||||
* clusterName: will be used on EC2 `k8s.io/cluster-autoscaler/<clusterName>` instance tag
|
||||
@@ -483,7 +485,7 @@ spec:
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: "true"
|
||||
containers:
|
||||
- image: eu.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:v1.18.1
|
||||
- image: eu.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:<VERSION>
|
||||
name: cluster-autoscaler
|
||||
resources:
|
||||
limits:
|
||||
|
||||
+1
-1
@@ -20,7 +20,7 @@ _Available as of v2.5.4_
|
||||
|
||||
To create rule groups in the Rancher UI,
|
||||
|
||||
1. Click **Cluster Explorer > Monitoring** and click **Prometheus Rules.**
|
||||
1. Click **Cluster Explorer > Monitoring > Advanced** and click **Prometheus Rules.**
|
||||
1. Click **Create.**
|
||||
1. Enter a **Group Name.**
|
||||
1. Configure the rules. In Rancher's UI, we expect a rule group to contain either alert rules or recording rules, but not both. For help filling out the forms, refer to the configuration options below.
|
||||
|
||||
@@ -13,8 +13,6 @@ Rancher was originally built to work with multiple orchestrators, and it include
|
||||
|
||||
Rancher can provision Kubernetes from a hosted provider, provision compute nodes and then install Kubernetes onto them, or import existing Kubernetes clusters running anywhere.
|
||||
|
||||
One Rancher server installation can manage thousands of Kubernetes clusters and thousands of nodes from the same user interface.
|
||||
|
||||
Rancher adds significant value on top of Kubernetes, first by centralizing authentication and role-based access control (RBAC) for all of the clusters, giving global admins the ability to control cluster access from one location.
|
||||
|
||||
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 [Fleet](http://fleet.rancher.io/) to help you automatically deploy and upgrade workloads.
|
||||
|
||||
+3
@@ -7,6 +7,9 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where a flaw with authorization logic allows privilege escalation in downstream clusters through cluster role template binding (CRTB) and project role template binding (PRTB). The vulnerability can be exploited by any user who has permissions to create/edit CRTB or PRTB (such as `cluster-owner`, `manage cluster members`, `project-owner`, and `manage project members`) to gain owner permission in another project in the same cluster or in another project on a different downstream cluster. | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | It was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3, there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords, and API tokens. The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners`, and `Project Members` on the endpoints `/v1/management.cattle.io.clusters`, `/v3/clusters`, and `/k8s/clusters/local/apis/management.cattle.io/v3/clusters`. | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where sensitive fields like passwords, API keys, and Rancher's service account token (used to provision clusters) were stored in plaintext directly on Kubernetes objects like `Clusters` (e.g., `cluster.management.cattle.io`). Anyone with read access to those objects in the Kubernetes API could retrieve the plaintext version of those sensitive data. The issue was partially found and reported by Florian Struck (from [Continum AG](https://www.continum.net/)) and [Marco Stuurman](https://github.com/fe-ax) (from [Shock Media B.V.](https://www.shockmedia.nl/)). | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | This vulnerability only affects customers using [Weave](https://rancher.com/docs/rancher/v2.6/en/faq/networking/cni-providers/#weave) Container Network Interface (CNI) when configured through [RKE templates](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rke-templates/). A vulnerability was discovered in Rancher versions 2.5.0 up to and including 2.5.13, and 2.6.0 up to and including 2.6.4, where a user interface (UI) issue with RKE templates does not include a value for the Weave password when Weave is chosen as the CNI. If a cluster is created based on the mentioned template, and Weave is configured as the CNI, no password will be created for [network encryption](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/) in Weave; therefore, network traffic in the cluster will be sent unencrypted. | 24 May 2022 | [Rancher v2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) and [Rancher v2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [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) |
|
||||
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Rotation of Expired Webhook Certificates
|
||||
weight: 120
|
||||
---
|
||||
|
||||
For Rancher versions that have `rancher-webhook` installed, certain versions created certificates that will expire after one year. It will be necessary for you to rotate your webhook certificate if the certificate did not renew.
|
||||
|
||||
In Rancher v2.5.12 and up, rancher-webhook deployments will automatically renew their TLS certificate when it is within 30 or fewer days of its expiration date. If you are using v2.5.11 or below, there are two methods to work around this issue:
|
||||
|
||||
##### 1. Users with cluster access, run the following commands:
|
||||
```
|
||||
kubectl delete secret -n cattle-system cattle-webhook-tls
|
||||
kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io
|
||||
kubectl delete pod -n cattle-system -l app=rancher-webhook
|
||||
```
|
||||
|
||||
##### 2. Users with no cluster access via `kubectl`:
|
||||
|
||||
1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.
|
||||
|
||||
2. Delete the `rancher.cattle.io` mutating webhook
|
||||
|
||||
3. Delete the `rancher-webhook` pod in the `cattle-system` namespace in the local cluster.
|
||||
|
||||
**Note:** The webhook certificate expiration issue is not specific to `cattle-webhook-tls` as listed in the examples. You will fill in your expired certificate secret accordingly.
|
||||
Reference in New Issue
Block a user