Skip to content

Commit

Permalink
v2.3 Docs (#1662)
Browse files Browse the repository at this point in the history
* Cluster Templates docs

* Say to pass private registry as env variable in air gap install

* Add chart compatibility info to Catalog docs

* Edit node pool docs

Add 'the'

Move 'how it works' info to bottom of node pools doc

Move 'how it works' info to bottom of node pools doc

Add steps for disabling node auto-replace

Hide 'How does node auto-replace work' in dropdown

Add hyphen

Only include Rancher UI steps for enable/disable node auto-replace

Only include Rancher UI steps for enable/disable node auto-replace

Change wording around node auto-replace

* Add note about session length setting

* Update _index.md

* quiet option added so output doesn't contain non-image output from RKE in the rancher-images.txt file.

* updating to list-version

* Windows docs usability (#1712)

* Update supported Windows server version

* Edit docs on Windows clusters

* Edit docs on Windows clusters

* Edit Windows node docs

* Minor edits to Windows docs

* Edit node pool docs

Add 'the'

Move 'how it works' info to bottom of node pools doc

Move 'how it works' info to bottom of node pools doc

Add steps for disabling node auto-replace

Hide 'How does node auto-replace work' in dropdown

Add hyphen

Only include Rancher UI steps for enable/disable node auto-replace

Only include Rancher UI steps for enable/disable node auto-replace

Change wording around node auto-replace

* Update _index.md

* Edit Windows cluster docs

* Edit Windows cluster docs for usability

* Update supported Windows server version

* Edit docs on Windows clusters

* Edit Windows node docs

* Minor edits to Windows docs

* Edit Windows cluster docs

* Edit Windows cluster docs for usability

* Minor edits to Windows docs

* Clarify that custom clusters are provisioned with RKE (#1734)

* Clarify that custom clusters are RKE provisioned

* Clarify that custom clusters are RKE provisioned

* Minor edits to Windows/custom cluster docs

* Edit cluster template docs (#1660)

* Cluster Templates docs

* Mention template clusters in cluster provisioning section

* Edit cluster template docs

* Clarify Owner access type for cluster templates

* Mention template clusters in cluster provisioning section

* Edit cluster template docs

* Clarify Owner access type for cluster templates

* Revise cluster template docs

* Revise cluster template docs

* Mention template clusters in cluster provisioning section

* Edit cluster template docs

* Clarify Owner access type for cluster templates

* Revise cluster template docs

* Revise cluster template docs

* Cluster Templates docs

* Mention template clusters in cluster provisioning section

* Mention template clusters in cluster provisioning section

* Edit cluster template docs

* Edit cluster template docs

* Add note about session length setting

* Revise cluster template docs

* quiet option added so output doesn't contain non-image output from RKE in the rancher-images.txt file.

* updating to list-version

* Windows docs usability (#1712)

* Update supported Windows server version

* Edit docs on Windows clusters

* Edit docs on Windows clusters

* Edit Windows node docs

* Minor edits to Windows docs

* Edit node pool docs

Add 'the'

Move 'how it works' info to bottom of node pools doc

Move 'how it works' info to bottom of node pools doc

Add steps for disabling node auto-replace

Hide 'How does node auto-replace work' in dropdown

Add hyphen

Only include Rancher UI steps for enable/disable node auto-replace

Only include Rancher UI steps for enable/disable node auto-replace

Change wording around node auto-replace

* Update _index.md

* Edit Windows cluster docs

* Edit Windows cluster docs for usability

* Update supported Windows server version

* Edit docs on Windows clusters

* Edit Windows node docs

* Minor edits to Windows docs

* Edit Windows cluster docs

* Edit Windows cluster docs for usability

* Minor edits to Windows docs

* Update template docs per UI and permissions changes

* Revise template docs

* Address feedback on RKE template docs

* Fix name of directive in RKE template YAML

* Change env variable to match code from github issue resolution

* Add information for cert-manager

Problem:
cert-manager is old and will be cut off soon

Solution:
Update docs to include current install instructions and instructions on
how to upgrade cert-manager to the current version

* Revamp cert-manager docs

- Condense air gap and normal upgrade instructions for cert-manager down
to a single page. This allowed us to consolidate some repetetive text.
- Add a section explaining cert-manager's API change and the recommended
data migration
- Moved the upgrade instructions out of the cluster administration
section and into the Advanced installation options (not perfect but our
best fit)
- On the pages where we instruct the user to install cert-manger, made a
note and link to our upgrade documentation

* Respond to feedback on RKE template docs (#1757)

* Respond to feedback on RKE template docs

* Respond to feedback on RKE template docs

* Minor edits to RKE template docs

* Change env variable to match code from github issue resolution

* Add information for cert-manager

Problem:
cert-manager is old and will be cut off soon

Solution:
Update docs to include current install instructions and instructions on
how to upgrade cert-manager to the current version

* Add information for cert-manager

Problem:
cert-manager is old and will be cut off soon

Solution:
Update docs to include current install instructions and instructions on
how to upgrade cert-manager to the current version

* Revamp cert-manager docs

- Condense air gap and normal upgrade instructions for cert-manager down
to a single page. This allowed us to consolidate some repetetive text.
- Add a section explaining cert-manager's API change and the recommended
data migration
- Moved the upgrade instructions out of the cluster administration
section and into the Advanced installation options (not perfect but our
best fit)
- On the pages where we instruct the user to install cert-manger, made a
note and link to our upgrade documentation

* Revamp cert-manager docs

- Condense air gap and normal upgrade instructions for cert-manager down
to a single page. This allowed us to consolidate some repetetive text.
- Add a section explaining cert-manager's API change and the recommended
data migration
- Moved the upgrade instructions out of the cluster administration
section and into the Advanced installation options (not perfect but our
best fit)
- On the pages where we instruct the user to install cert-manger, made a
note and link to our upgrade documentation

* Windows docs usability (#1712)

* Update supported Windows server version

* Edit docs on Windows clusters

* Edit docs on Windows clusters

* Edit Windows node docs

* Minor edits to Windows docs

* Edit node pool docs

Add 'the'

Move 'how it works' info to bottom of node pools doc

Move 'how it works' info to bottom of node pools doc

Add steps for disabling node auto-replace

Hide 'How does node auto-replace work' in dropdown

Add hyphen

Only include Rancher UI steps for enable/disable node auto-replace

Only include Rancher UI steps for enable/disable node auto-replace

Change wording around node auto-replace

* Update _index.md

* Edit Windows cluster docs

* Edit Windows cluster docs for usability

* Update supported Windows server version

* Edit docs on Windows clusters

* Edit Windows node docs

* Minor edits to Windows docs

* Edit Windows cluster docs

* Edit Windows cluster docs for usability

* Minor edits to Windows docs

* Edit air gap docs (#1759)

* Edit air gap docs

* Edit air gap installation steps

* add notes about taints on linux worker nodes

* adding node taints docs

* add s3 backup option for self signed certs

* add advanced options systemDefaultRegistry and useBundledSystemChart in helm options

* Add Kubernetes Metadata Feature

* Add google oauth docs

* Air gap install updates (#1791)

* fix single node air gap command

* New air gap layout - overview

* New air gap layout - prepare nodes

* New air gap layout - prepare private registry and add windows instructions

* New air gap layout - install k8s

* New air gap layout - install rancher

* small edits

* Small air gap edits

* small revision to airgap docs

* Edit RKE metadata doc (#1790)

* Edit RKE metadata config docs

* Minor edits to RKE metadata doc

* Minor edits to RKE metadata doc

* Minor edits to K8s metadata doc

* Update note in K8s metadata doc

* Addressing PR review comments

* Google OAuth (#1797)

* Copy edit Google Oauth docs

* Copy edit Google Oauth docs

* Minor edits to Google Oauth doc

* Add info on add ons and agents

* Fix up air gap upgrades based on air gap install edits

* Update example CIDRs for bip ranges

* Missing a L3 Header for General Linux

The current TOC structure is missing a General category which makes it read like CentOS/RHEL is the recommended distro..
Adding a General Linux Recommendations better highlights that the RHEL stuff is additional information for those distros.

* EIO-194: documentation updates for CIS benchmark 1.4.1

* Fix incorrect rendering of bash script

The bash script doesn't display correctly and when copied as is doesn't work due to a leading 'bash' in the command.

* Add info on intermediates recognized CA cert

* Small air gap upgrade updates for consistency

* Remove unnecessary step

* Add taints to nodes

* Update RKE CLI docs with folder info

* Added folder option for s3 backups

* Edit Istio cluster administration docs

* Edit Istio docs

* Edit Istio docs

* Document safe timestamps

* Edit Istio docs

* Edit Istio docs

* Update _index.md

* Add feature flag doc

* Edit feature flag doc

* Change unsupported to experimental

* Change wording

* Edit Istio docs

* Rancher min/max version

* Edit Istio rbac info

* Add c

* Edit Istio rbac section
  • Loading branch information
Denise authored Oct 8, 2019
1 parent 8556884 commit b0a52bb
Show file tree
Hide file tree
Showing 95 changed files with 3,698 additions and 1,374 deletions.
18 changes: 18 additions & 0 deletions content/rancher/v2.x/en/admin-settings/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,3 +41,21 @@ For more information how to create and use PSPs, see [Pod Security Policies]({{<
Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes.

For more information, see [Provisioning Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/).

## Adding Kubernetes Versions into RANCHER

_Available as of v2.3.0_

With this feature, you can upgrade to the latest version of Kubernetes as soon as it is released, without upgrading Rancher. This feature allows you to easily upgrade Kubernetes patch versions (i.e. `v1.15.X`), but not intended to upgrade Kubernetes minor versions (i.e. `v1.X.0`) as Kubernetes tends to deprecate or add APIs between minor versions.

The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the [Rancher Kubernetes Metadata]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rke-metadata/). For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see [Rancher Kubernetes Metadata]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rke-metadata/).

Rancher Kubernetes Metadata contains Kubernetes version information which Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).

For more information on how metadata works and how to configure metadata config, see [Rancher Kubernetes Metadata]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rke-metadata/).

## Enabling Experimental Features

_Available as of v2.3.0_

Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.]({{<baseurl>}}/rancher/v2.x/en/admin-settings/feature-flags)
35 changes: 18 additions & 17 deletions content/rancher/v2.x/en/admin-settings/authentication/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,27 +18,28 @@ The Rancher authentication proxy integrates with the following external authenti

| Auth Service | Available as of |
| ------------------------------------------------------------------------------------------------ | ---------------- |
| [Microsoft Active Directory]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ad/) | v2.0.0 |
| [GitHub]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/github/) | v2.0.0 |
| [Microsoft Azure AD]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/azure-ad/) | v2.0.3 |
| [FreeIPA]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/freeipa/) | v2.0.5 |
| [OpenLDAP]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/openldap/) | v2.0.5 |
| [Microsoft AD FS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/) | v2.0.7 |
| [PingIdentity]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ping-federate/) | v2.0.7 |
| [Keycloak]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/keycloak/) | v2.1.0 |
| [Okta]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/okta/) | v2.2.0 |
| [Microsoft Active Directory]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/ad/) | v2.0.0 |
| [GitHub]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/github/) | v2.0.0 |
| [Microsoft Azure AD]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/azure-ad/) | v2.0.3 |
| [FreeIPA]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/freeipa/) | v2.0.5 |
| [OpenLDAP]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/openldap/) | v2.0.5 |
| [Microsoft AD FS]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/) | v2.0.7 |
| [PingIdentity]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/ping-federate/) | v2.0.7 |
| [Keycloak]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/keycloak/) | v2.1.0 |
| [Okta]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/okta/) | v2.2.0 |
| [Google OAuth]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/google/) | v2.3.0 |
<br/>
However, Rancher also provides [local authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/local/).
However, Rancher also provides [local authentication]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/local/).

In most cases, you should use an external authentication service over local authentication, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if your external authentication provider is unavailable or undergoing maintenance.

## Users and Groups

Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, multi-cluster apps, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/).
Rancher relies on users and groups to determine who is allowed to log in to Rancher and which resources they can access. When authenticating with an external provider, groups are provided from the external provider based on the user. These users and groups are given specific roles to resources like clusters, projects, multi-cluster apps, and global DNS providers and entries. When you give access to a group, all users who are a member of that group in the authentication provider will be able to access the resource with the permissions that you've specified. For more information on roles and permissions, see [Role Based Access Control]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/).

> **Note:** Local authentication does not support creating or managing groups.
For more information, see [Users and Groups]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/user-groups/)
For more information, see [Users and Groups]({{<baseurl>}}/rancher/v2.x/en/admin-settings/authentication/user-groups/)

## Scope of Rancher Authorization

Expand Down Expand Up @@ -75,22 +76,22 @@ Configuration of external authentication affects how principal users are managed

1. Sign into Rancher as the local principal and complete configuration of external authentication.

![Sign In]({{< baseurl >}}/img/rancher/sign-in.png)
![Sign In]({{<baseurl>}}/img/rancher/sign-in.png)

2. Rancher associates the external principal with the local principal. These two users share the local principal's user ID.

![Principal ID Sharing]({{< baseurl >}}/img/rancher/principal-ID.png)
![Principal ID Sharing]({{<baseurl>}}/img/rancher/principal-ID.png)

3. After you complete configuration, Rancher automatically signs out the local principal.

![Sign Out Local Principal]({{< baseurl >}}/img/rancher/sign-out-local.png)
![Sign Out Local Principal]({{<baseurl>}}/img/rancher/sign-out-local.png)

4. Then, Rancher automatically signs you back in as the external principal.

![Sign In External Principal]({{< baseurl >}}/img/rancher/sign-in-external.png)
![Sign In External Principal]({{<baseurl>}}/img/rancher/sign-in-external.png)

5. Because the external principal and the local principal share an ID, no unique object for the external principal displays on the Users page.

![Sign In External Principal]({{< baseurl >}}/img/rancher/users-page.png)
![Sign In External Principal]({{<baseurl>}}/img/rancher/users-page.png)

6. The external principal and the local principal share the same access rights.
103 changes: 103 additions & 0 deletions content/rancher/v2.x/en/admin-settings/authentication/google/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,103 @@
---
title: Configuring Google OAuth
---
_Available as of v2.3.0_

If your organization uses G Suite for user authentication, you can configure Rancher to allow your users to log in using their G Suite credentials.

Only admins of the G Suite domain have access to the Admin SDK. Therefore, only G Suite admins can configure Google OAuth for Rancher.

Within Rancher, only administrators or users with the **Manage Authentication** [global role]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) can configure authentication.

# Prerequisites
- You must have a [G Suite admin account](https://admin.google.com) configured.
- G Suite requires a [top private domain FQDN](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains) as an authorized domain. One way to get an FQDN is by creating an A-record in Route53 for your Rancher server. You do not need to update your Rancher Server URL setting with that record, because there could be clusters using that URL.
- You must have the Admin SDK API enabled for your G Suite domain. You can enable it using the steps on [this page.](https://support.google.com/a/answer/60757?hl=en)

After the Admin SDK API is enabled, your G Suite domain's API screen should look like this:
![Enable Admin APIs]({{<baseurl>}}/img/rancher/Google-Enable-APIs-Screen.png)

# Setting up G Suite for OAuth with Rancher
Before you can set up Google OAuth in Rancher, you need to log in to your G Suite account and do the following:

1. [Add Rancher as an authorized domain in G Suite](#1-adding-rancher-as-an-authorized-domain)
1. [Generate OAuth2 credentials for the Rancher server](#2-creating-oauth2-credentials-for-the-rancher-server)
1. [Create service account credentials for the Rancher server](#3-creating-service-account-credentials)
1. [Register the service account key as an OAuth Client](#4-register-the-service-account-key-as-an-oauth-client)

### 1. Adding Rancher as an Authorized Domain
1. Click [here](https://console.developers.google.com/apis/credentials) to go to credentials page of your Google domain.
1. Select your project and click **OAuth consent screen.**
![OAuth Consent Screen]({{<baseurl>}}/img/rancher/Google-OAuth-consent-screen-tab.png)
1. Go to **Authorized Domains** and enter the top private domain of your Rancher server URL in the list. The top private domain is the rightmost superdomain. So for example, www.foo.co.uk a top private domain of foo.co.uk. For more information on top-level domains, refer to [this article.](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains)
1. Go to **Scopes for Google APIs** and make sure **email,** **profile** and **openid** are enabled.

**Result:** Rancher has been added as an authorized domain for the Admin SDK API.

### 2. Creating OAuth2 Credentials for the Rancher Server
1. Go to the Google API console, select your project, and go to the [credentials page.]((https://console.developers.google.com/apis/credentials) )
![Credentials]({{<baseurl>}}/img/rancher/Google-Credentials-tab.png)
1. On the **Create Credentials** dropdown, select **OAuth client ID.**
1. Click **Web application.**
1. Provide a name.
1. Fill out the **Authorized JavaScript origins** and **Authorized redirect URIs.** Note: The Rancher UI page for setting up Google OAuth (available from the Global view under **Security > Authentication > Google**) provides you the exact links to enter for this step.
- Under **Authorized JavaScript origins,** enter your Rancher server URL.
- Under **Authorized redirect URIs,** enter your Rancher server URL appended with the path `verify-auth`. For example, if your URI is `https://rancherServer`, you will enter `https://rancherServer/verify-auth`.
1. Click on **Create.**
1. After the credential is created, you will see a screen with a list of your credentials. Choose the credential you just created, and in that row on rightmost side, click **Download JSON.** Save the file so that you can provide these credentials to Rancher.

**Result:** Your OAuth credentials have been successfully created.

### 3. Creating Service Account Credentials
Since the Google Admin SDK is available only to admins, regular users cannot use it to retrieve profiles of other users or their groups. Regular users cannot even retrieve their own groups.

Since Rancher provides group-based membership access, we require the users to be able to get their own groups, and look up other users and groups when needed.

As a workaround to get this capability, G Suite recommends creating a service account and delegating authority of your G Suite domain to that service account.

This section describes how to:

- Create a service account
- Create a key for the service account and download the credenials as JSON

1. Click [here](https://console.developers.google.com/iam-admin/serviceaccounts) and select your project for which you generated OAuth credentials.
1. Click on **Create Service Account.**
1. Enter a name and click **Create.**
![Service account creation Step 1]({{<baseurl>}}/img/rancher/Google-svc-acc-step1.png)
1. Don't provide any roles on the **Service account permissions** page and click **Continue**
![Service account creation Step 2]({{<baseurl>}}/img/rancher/Google-svc-acc-step2.png)
1. Click on **Create Key** and select the JSON option. Download the JSON file and save it so that you can provide it as the service account credentials to Rancher.
![Service account creation Step 3]({{<baseurl>}}/img/rancher/Google-svc-acc-step3-key-creation.png)

**Result:** Your service account is created.

### 4. Register the Service Account Key as an OAuth Client

You will need to grant some permissions to the service account you created in the last step. Rancher requires you to grant only read-only permissions for users and groups.

Using the Unique ID of the service account key, register it as an Oauth Client using the following steps:

1. Get the Unique ID of the key you just created. If it's not displayed in the list of keys right next to the one you created, you will have to enable it. To enable it, click **Unique ID** and click **OK.** This will add a **Unique ID** column to the list of service account keys. Save the one listed for the service account you created. NOTE: This is a numeric key, not to be confused with the alphanumeric field **Key ID.**

![Service account Unique ID]({{<baseurl>}}/img/rancher/Google-Select-UniqueID-column.png)
1. Go to the [**Manage OAuth Client Access** page.](https://admin.google.com/AdminHome?chromeless=1#OGX:ManageOauthClients)
1. Add the Unique ID obtained in the previous step in the **Client Name** field.
1. In the **One or More API Scopes** field, add the following scopes:
```
openid,profile,email,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly
```
1. Click **Authorize.**

**Result:** The service account is registered as an OAuth client in your G Suite account.

# Configuring Google OAuth in Rancher
1. Sign into Rancher using a local user assigned the [administrator]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/global-permissions) role. This user is also called the local principal.
1. From the **Global** view, click **Security > Authentication** from the main menu.
1. Click **Google.** The instructions in the UI cover the steps to set up authentication with Google OAuth.
- **Step One** is about adding Rancher as an authorized domain, which we already covered in [this section.](#1-adding-rancher-as-an-authorized-domain)
- For **Step Two,** provide the OAuth credentials JSON that you downloaded after completing [this section.](#2-creating-oauth2-credentials-for-the-rancher-server) You can upload the file or paste the contents into the **OAuth Credentials** field.
- For **Step Three,** provide the service account credentials JSON that downloaded at the end of [this section.](#3-creating-service-account-credentials) The credentials will only work if you successfully [registered the service account key](#4-register-the-service-account-key-as-an-oauth-client) as an OAuth client in your G Suite account.
1. Click **Authenticate with Google**.
1. Click **Save**.

**Result:** Google authentication is successfully configured.
Original file line number Diff line number Diff line change
Expand Up @@ -49,3 +49,16 @@ If you are not sure the last time Rancher performed an automatic refresh of user
**Results:** Rancher refreshes the user information for all users. Requesting this refresh will update which users can access Rancher as well as all the groups that each user belongs to.

>**Note:** Since SAML does not support user lookup, SAML-based authentication providers do not support the ability to manually refresh user information. User information will only be refreshed when the user logs into the Rancher UI.

## Session Length

_Available as of v2.3.0_

The default length (TTL) of each user session is adjustable. The default session length is 16 hours.

1. From the **Global** view, click on **Settings**.
1. In the **Settings** page, find **`auth-user-session-ttl-minutes`** and click **Edit.**
1. Enter the amount of time in minutes a session length should last and click **Save.**

**Result:** Users are automatically logged out of Rancher after the set number of minutes.
Loading

0 comments on commit b0a52bb

Please sign in to comment.