From 6100f984c408defec938eb5e59b61f980ec86c6b Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:56:18 -0700 Subject: [PATCH] deleting old index files --- .../authentication/_index-concept.md | 57 ----- .../configuring-ad/_index-task.md | 52 ----- .../configuring-azure-ad/_index-task.md | 188 ----------------- .../configuring-freeipa/_index-task.md | 54 ----- .../configuring-github/_index-task.md | 51 ----- .../_index-task.md | 10 - .../configuring-openldap/_index-task.md | 55 ----- .../pod-security-policies/_index-concept.md | 19 -- .../pod-security-policies/_index-task.md | 41 ---- .../rancher-server-url/_index-concept.md | 9 - .../rancher-server-url/_index-task.md | 12 -- .../en/admin-settings/rbac/_index-concept.md | 197 ------------------ .../rbac/creating-roles/_index-task.md | 66 ------ 13 files changed, 811 deletions(-) delete mode 100644 content/rancher/v2.x/en/admin-settings/authentication/_index-concept.md delete mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-concept.md delete mode 100644 content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-concept.md delete mode 100644 content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-task.md delete mode 100644 content/rancher/v2.x/en/admin-settings/rbac/_index-concept.md delete mode 100644 content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index-task.md diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index-concept.md b/content/rancher/v2.x/en/admin-settings/authentication/_index-concept.md deleted file mode 100644 index 94840b7de1f..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/_index-concept.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Authentication -weight: 10 ---- -One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows your users to use one set of credentials to authenticate with any of your Kubernetes clusters. - -This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed along with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account. - - - -### External vs. Local Authentication - -The Rancher authentication proxy integrates with the following external authentication services. - -- Microsoft Active Directory -- Microsoft Azure AD -- GitHub -- FreeIPA -- OpenLDAP - -However, Rancher also provides local authentication. - -In most cases, you should use an external authentication service over local, 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 Active Directory is down. - -For more information on how to configure external authentication or local authentication, see [Authentication](../../../tasks/global-configuration/authentication/). - -### External Authentication Configuration and Principal Users - -Configuration of external authentication requires: - -- A local user assigned the administrator role, called hereafter the _local principal_. -- An external user that can authenticate with your external authentication service, called hereafter the _external principal_. - -Configuration of external authentication affects how principal users are managed within Rancher. Follow the list below to better understand these effects. - -1. Sign into Rancher as the local principal and complete configuration of external authentication. - - ![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) - -3. After you complete configuration, Rancher automatically signs out the local principal. - - ![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) - -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) - -6. The external principal and the local principal share the same access rights. - diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index-task.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index-task.md deleted file mode 100644 index c79513802ca..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index-task.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Configuring Active Directory (AD) -weight: 51 ---- - -In environments using Microsoft Active Directory (AD), you can configure Rancher to allow sign on using AD credentials. - ->**Prerequisites:** -> ->- Have an Active Directory server configured. ->- Create a service account in Active Directory with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key. ->- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). - -1. Sign into Rancher using a local user assigned `administrator` global permissions (i.e., the _local principal_). - -2. From the **Global** view, select **Security > Authentication** from the main menu. - -3. Select **Active Directory**. - -4. Complete the **Configure an Active Directory server** form. - - You may need to log in to your domain controller to find the information requested in the form. - - >**Using TLS?** - >If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate. -
-
- >**User Search Base vs. Group Search Base** - > - >Search base allows Rancher to search for users and groups that are in your Active Directory. These fields are only for search bases and not for search filters. - > - >* If your users and groups are in the same search base, complete only the User Search Base. - >* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required. - -5. If your Active Directory deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. - - >**Search Attribute** As of Rancher v2.0.1, the Search Attribute field defaults with three specific values: `sAMAccountName|sn|givenName`. After AD is configured, when a user enters text to add users or groups, Rancher automatically queries the AD server and attempts to match fields by sAMAccountName, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field. - > - >The default field value `sAMAccountName|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields. - > - > * `sAMAccountName`: Username - > * `sn`: Last Name - > * `givenName`: First Name - > - > With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field. - -6. Enter your AD username and password in **Authenticate with Active Directory** to confirm that Rancher is configured to use AD authentication. - -**Result:** - -- Active Directory authentication is configured. -- You are signed into Rancher with your Active Directory account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index-task.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index-task.md deleted file mode 100644 index 3cf607630bb..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index-task.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -title: Configuring Azure Active Directory (Azure AD) -weight: 52 ---- - -_Available as of v2.0.3_ - -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. - ->**Prerequisite:** Have an instance of Azure AD configured. - ->**Note:** Most of this procedure, with the exception of [Configure Azure AD in Rancher](#configure-azure-ad-in-rancher), takes place from the [Microsoft Azure Portal](https://portal.azure.com/). - -## 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. - - - ->**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. - -1. [Register Rancher with Azure](#1-register-rancher-with-azure) - - Before enabling Azure AD within Rancher, you must register Rancher with Azure. - -1. [Create an Azure API Key](#2-create-an-azure-api-key) - - From the Azure portal, create an API key. Rancher will use this key to authenticate with AD. - -1. [Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher) - - Next, set API permissions for Rancher within Azure. - -1. [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. - -1. [Configure Azure AD in Rancher](#5-configure-azure-ad-in-rancher) - - From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration. - -### 1. Register Rancher with Azure - -Before enabling Azure AD within Rancher, you must register Rancher with Azure. - -1. Log in to [Microsoft Azure](https://portal.azure.com/) as an administrative user. Configuration in future steps requires administrative access rights. - -1. Use search to open the **App registrations** service. - - ![Open App Registrations]({{< baseurl >}}/img/rancher/search-app-registrations.png) - -1. Click **New application registration** and complete the **Create** form. - - ![New App Registration]({{< baseurl >}}/img/rancher/new-app-registration.png) - - 1. Enter a **Name** (something like `Rancher`). - - 1. From **Application type**, make sure that **Web app / API** is selected. - - 1. In the **Sign-on URL** field, enter the URL of your Rancher Server. - - 1. Click **Create**. - -### 2. Create an Azure API Key - -From the Azure portal, create an API key. 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. - - ![Open Rancher Registration]({{< baseurl >}}/img/rancher/open-rancher-app.png) - - **Step Result:** A new blade opens for Rancher. - -1. Click **Settings**. - -1. From the **Settings** blade, select **Keys**. - -1. From **Passwords**, create an API key. - - 1. Enter a **Key description** (something like `Rancher`). - - 1. Select a **Duration** for the key. 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 **Save** (you don't need to enter a value—it will automatically populate after you save). - - -1. Copy the key value and save it to an [empty text file](#tip). - - You'll enter this key into the Rancher UI later as your **Application Secret**. - - You won't be able to access the key value again within the Azure UI. - -### 3. Set Required Permissions for Rancher - -Next, set API permissions for Rancher within Azure. - -1. From the **Settings** blade, select **Required permissions**. - - ![Open Required Permissions]({{< baseurl >}}/img/rancher/select-required-permissions.png) - -1. Click **Windows Azure Active Directory**. - -1. From the **Enable Access** blade, select the following **Delegated Permissions**: -
-
- - **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 **Save**. - -1. From **Required permissions**, click **Grant permissions**. Then click **Yes**. - - >**Note:** You must be signed in as an Azure administrator to successfully save your permission settings. - - -### 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. - - ![Open Azure Active Directory]({{< baseurl >}}/img/rancher/search-azure-ad.png) - - 1. From the **Azure Active Directory** menu, open **Properties**. - - 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**. - - ![Open App Registrations]({{< baseurl >}}/img/rancher/search-app-registrations.png) - - 1. Find the entry you created for Rancher. - - 1. Copy the **Application ID** and paste it to your [text file](#tip). - -1. Obtain your Rancher **Graph Endpoint**, **Token Endpoint**, and **Auth Endpoint**. - - 1. From **App registrations**, click **Endpoints**. - - ![Click Endpoints]({{< baseurl >}}/img/rancher/click-endpoints.png) - - 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 Azure AD Graph API Endpoint** (Graph Endpoint) - - **OAuth 2.0 Token Endpoint** (Token Endpoint) - - **OAuth 2.0 Authorization Endpoint** (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](#4-copy-azure-application-data). - - >**Important:** When entering your Graph Endpoint, remove the tenant ID from the URL, like below. - > - >https://graph.windows.net/abb5adde-bee8-4821-8b03-e63efdc7701c - - The following table maps the values you copied in the Azure portal to the fields in Rancher. ~~~~ - - Rancher Field | Azure Value - ---------|---------- - Tenant ID | Directory ID - 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**. - -**Result:** Azure Active Directory authentication is configured. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index-task.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index-task.md deleted file mode 100644 index 5f4423261ac..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index-task.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Configuring FreeIPA -weight: 55 ---- - -_Available as of v2.0.5_ - -If your organization uses FreeIPA for user authentication, you can configure Rancher to allow your users to login using their FreeIPA credentials. - ->**Prerequisites:** -> ->- You must have a [FreeIPA Server](https://www.freeipa.org/) configured. ->- Create a service account in FreeIPA with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key. ->- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). - -1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). - -2. From the **Global** view, select **Security > Authentication** from the main menu. - -3. Select **FreeIPA**. - -4. Complete the **Configure an FreeIPA server** form. - - You may need to log in to your domain controller to find the information requested in the form. - - >**Using TLS?** - >If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate. -
-
- >**User Search Base vs. Group Search Base** - > - >Search base allows Rancher to search for users and groups that are in your FreeIPA. These fields are only for search bases and not for search filters. - > - >* If your users and groups are in the same search base, complete only the User Search Base. - >* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required. - -5. If your FreeIPA deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. - - >**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After FreeIPA is configured, when a user enters text to add users or groups, Rancher automatically queries the FreeIPA server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field. - > - >The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields. - > - > * `uid`: User ID - > * `sn`: Last Name - > * `givenName`: First Name - > - > With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field. - -6. Enter your FreeIPA username and password in **Authenticate with FreeIPA** to confirm that Rancher is configured to use FreeIPA authentication. - -**Result:** - -- FreeIPA authentication is configured. -- You are signed into Rancher with your FreeIPA account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index-task.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index-task.md deleted file mode 100644 index 603bb20847f..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index-task.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Configuring GitHub -weight: 53 ---- - -In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials. - ->**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). - -1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). - -2. From the **Global** view, select **Security > Authentication** from the main menu. - -3. Select **GitHub**. - -4. Follow the directions displayed to **Setup a GitHub Application**. Rancher redirects you to GitHub to complete registration. - - >**What's an Authorization Callback URL?** - > - >The Authorization Callback URL is the URL where users go to begin using your application (i.e. the splash screen). - - >When you use external authentication, authentication does not actually take place in your application. Instead, authentication takes place externally (in this case, GitHub). After this external authentication completes successfully, the Authorization Callback URL is the location where the user re-enters your application. - -5. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher. - - >**Where do I find the Client ID and Client Secret?** - > - >From GitHub, select Settings > Developer Settings > OAuth Apps. The Client ID and Client Secret are displayed prominently. - -6. Click **Authenticate with GitHub**. - -7. Use the **Site Access** options to configure the scope of user authorization. - - - **Allow any valid Users** - - _Any_ GitHub user can access Rancher. We generally discourage use of this setting! - - - **Allow members of Clusters, Projects, plus Authorized Users and Organizations** - - Any GitHub user or group added as a **Cluster Member** or **Project Member** can log in to Rancher. Additionally, any GitHub user or group you add to the **Authorized Users and Organizations** list may log in to Rancher. - - - **Restrict access to only Authorized Users and Organizations** - - Only GitHub users or groups added to the Authorized Users and Organizations can log in to Rancher. -
-8. Click **Save**. - -**Result:** - -- GitHub authentication is configured. -- You are signed into Rancher with your GitHub account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index-task.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index-task.md deleted file mode 100644 index 189371f7084..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index-task.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Configuring Local Authentication -weight: 56 ---- - -Regardless of whether you use external authentication, you should create a few local authentication users so that you can continue using Rancher if you your external authentication service encounters issues. - -1. From the **Global** view, select **Users** from the main menu. - -2. Click **Add User**. Then complete the **Add User** form. Click **Create** when you're done. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index-task.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index-task.md deleted file mode 100644 index 773ed4169e0..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index-task.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Configuring OpenLDAP -weight: 54 ---- - -_Available as of v2.0.5_ - -If your organization uses OpenLDAP for user authentication, you can configure Rancher to allow your users to login using their OpenLDAP credentials. - ->**Prerequisites:** -> ->- You must have an [OpenLDAP Server](https://www.openldap.org/) configured. ->- Create a service account in OpenLDAP with `read-only` access. Rancher uses this account to verify group membership when a user makes a request using an API key. ->- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). - -1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). - -2. From the **Global** view, select **Security > Authentication** from the main menu. - -3. Select **OpenLDAP**. - -4. Complete the **Configure an OpenLDAP server** form. - - You may need to log in to your domain controller to find the information requested in the form. - - >**Using TLS?** - >If the certificate is self-signed or not from a recognized certificate authority, make sure you provide the complete chain. That chain is needed to verify the server's certificate. -
-
- >**User Search Base vs. Group Search Base** - > - >Search base allows Rancher to search for users and groups that are in your openLDAP. These fields are only for search bases and not for search filters. - > - >* If your users and groups are in the same search base, complete only the User Search Base. - >* If your groups are in a different search base, you can optionally complete the Group Search Base. This field is dedicated to searching groups, but is not required. - - -5. If your OpenLDAP deviates from the standard OpenLDAP schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. - - >**Search Attribute** The Search Attribute field defaults with three specific values: `uid|sn|givenName`. After openLDAP is configured, when a user enters text to add users or groups, Rancher automatically queries the openLDAP server and attempts to match fields by user id, last name, or first name. Rancher specifically searches for users/groups that begin with the text entered in the search field. - > - >The default field value `uid|sn|givenName`, but you can configure this field to a subset of these fields. The pipe (`|`) between the fields separates these fields. - > - > * `uid`: User ID - > * `sn`: Last Name - > * `givenName`: First Name - > - > With this search attribute, Rancher creates search filters for users and groups, but you *cannot* add your own search filters in this field. - -6. Enter your OpenLDAP username and password in **Authenticate with OpenLDAP** to confirm that Rancher is configured to use OpenLDAP authentication. - -**Result:** - -- OpenLDAP authentication is configured. -- You are signed into Rancher with your OpenLDAP account (i.e., the _external principal_). diff --git a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-concept.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-concept.md deleted file mode 100644 index 7e635fa3235..00000000000 --- a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-concept.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Pod Security Policies -weight: 75 ---- - -_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification (like root privileges). If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod is forbidden: unable to validate...`. - -- You can assign PSPs at the cluster or project level. -- PSPs work through inheritance. - - - By default, PSPs assigned to a cluster are inherited by its projects, as well as any namespaces added to those projects. - - **Exception:** Namespaces that are not assigned to projects do not inherit PSPs, regardless of whether the PSP is assigned to a cluster or project. Because these namespaces have no PSPs, workload deployments to these namespaces will fail, which is the default Kubernetes behavior. - - You can override the default PSP by assigning a different PSP directly to the project. -- Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP. - -Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). - ->**Best Practice:** ->Set Pod Security at the cluster level. diff --git a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-task.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-task.md deleted file mode 100644 index e9eb69200a6..00000000000 --- a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-task.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Pod Security Policies -weight: 125 ---- -Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file. - -## Creating Pod Security Policies - -1. From the **Global** view, select **Security** > **Pod Security Policies** from the main menu. Then click **Add Policy**. - - **Step Result:** The **Add Policy** form opens. - -2. Name the policy. - -3. Complete each section of the form. Refer to the Kubernetes documentation linked below for more information on what each policy does. - - - Basic Policies: - - - [Privilege Escalation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privilege-escalation) - - [Host Namespaces][2] - - [Read Only Root Filesystems][1] - - - [Capability Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#capabilities) - - [Volume Policy][1] - - [Allowed Host Paths Policy][1] - - [FS Group Policy][1] - - [Run As User Policy][1] - - [Host Ports Policy][2] - - [Run As User Policy][3] - - [SELinux Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#selinux) - - [Supplemental Groups Policy][3] - -### What's Next? - -Now that you've created a Pod Security Policy, you can apply it to clusters and projects. For more information, see [Adding a Pod Security Policy to a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy). - - - -[1]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems -[2]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces -[3]: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups diff --git a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-concept.md b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-concept.md deleted file mode 100644 index a7bdb887aa8..00000000000 --- a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-concept.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Rancher Server URL -weight: 5 ---- - -This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL. - -- You are prompted for this URL upon the very first Rancher login. -- You can edit this URL later by selecting **Settings**. diff --git a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-task.md b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-task.md deleted file mode 100644 index 6c62117577f..00000000000 --- a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-task.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Rancher Server URL -weight: 25 ---- - -The first time that you log into {{< product >}}, the system prompts you for the Rancher Server URL, which is the IP address or host name that your Kubernetes nodes register with. - -If you need to update this URL, select **Settings** from the **Global** view. - -### When Should I Update the Rancher Server URL? - -If the URL of your {{< product >}} Server changes, you must update the {{< product >}} Server URL so that your nodes can continue communicating with the {{< product >}} Server. diff --git a/content/rancher/v2.x/en/admin-settings/rbac/_index-concept.md b/content/rancher/v2.x/en/admin-settings/rbac/_index-concept.md deleted file mode 100644 index 22847e402a1..00000000000 --- a/content/rancher/v2.x/en/admin-settings/rbac/_index-concept.md +++ /dev/null @@ -1,197 +0,0 @@ ---- -title: Users, Global Permissions, and Roles -weight: 15 ---- - -Within Rancher, each user authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication), users can either be local or external. - -After you configure external authentication, the users that display on the **Users** page changes. - -- If you are logged in as a local user, only local users display. - -- If you are logged in an an external user, both external and local users display. - -## Users and Roles - -Once the user logs in to Rancher, their _authorization_, or their access rights within the system, is determined by _global permissions_, and _cluster and project roles_. - -- **Global Permissions:** - - Define user authorization outside the scope of any particular cluster. - -- **Cluster and Project Roles:** - - Define user authorization inside the specific cluster or project where they are assigned the role. - -Both global permissions and cluster and project roles are implemented on top of [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). Therefore, enforcement of permissions and roles is performed by Kubernetes. - -### Global Permissions - -Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are two default global permissions: `Administrator` and `Standard User`. - -- **Administrator:** - - These users have full control over the entire Rancher system and all clusters within it. - -- **Standard User:** - - These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters. - ->**Note:** You cannot create, update, or delete Global Permissions. - -#### Global Permission Assignment - -Assignment of global permissions to a user depends on their authentication source: external or local. - -- **External Authentication** - - When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the `Standard User` global permission. - -- **Local Authentication** - - When you create a new local user, you assign them a global permission as you complete the **Add User** form. - -#### Custom Global Permissions - -Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a custom set of permissions. - -_Permissions_ are individual access rights that you can assign when selecting a custom permission for a user. - -Using custom permissions is convenient for providing users with narrow or specialized access to Rancher. See the [table below](#global-permissions-reference) for a list of individual permissions available. - -#### Global Permissions Reference - -The following table lists each custom global permission available and whether it is assigned to the default global permissions, `Administrator` and `Standard User`. - -| Custom Global Permission | Administrator | Standard User | -| ---------------------------------- | ------------- | ------------- | -| Manage Authentication | ✓ | | -| Manage Catalogs | ✓ | | -| Manage Node Drivers | ✓ | | -| Manage PodSecurityPolicy Templates | ✓ | | -| Manage Roles | ✓ | | -| Manage Users | ✓ | | -| Create Clusters | ✓ | ✓ | -| User Catalog Templates | ✓ | ✓ | -| Login Access | ✓ | ✓ | - -> **Note:** Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalroles`. - -### Cluster and Project Roles - -Cluster and project roles define user authorization inside a cluster or project. You can manage these roles from the **Global > Security > Roles** page. From this page you can: - -- Create and manage new roles for use across all clusters and projects -- [Lock/unlock roles](#locked-roles) so that they may not be used in any new role assignments (existing assignments will still be enforced). - - -#### Membership and Role Assignment - -The projects and clusters accessible to non-administrative users is determined by _membership_. Membership is a list of users who have access to a specific cluster or project based on the roles they were assigned in that cluster or project. Each cluster and project includes a tab that a user with the appropriate permissions can use to manage membership. - -When you create a cluster or project, Rancher automatically assigns you as the `Owner` for it. Users assigned the `Owner` role can assign other users roles in the cluster or project. - -> **Note:** Non-administrative users cannot access any existing projects/clusters by default. A user with appropriate permissions (typically the owner) must explicitly assign the user membership. - -#### Cluster Roles - -_Cluster roles_ are roles that you can assign to users, granting them access to a cluster. There are two primary cluster roles: `Owner` and `Member`. - -- **Owner:** - - These users have full control over the cluster and all resources in it. - -- **Member:** - - These users can view most cluster level resources and create new projects. - -##### Custom Cluster Roles - -Rancher lets you assign _custom cluster roles_ to a user instead of the typical `Owner` or `Member` roles. These roles can be either a built-in custom cluster role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a user within a cluster. See the table below for a list of built-in custom cluster roles. - -##### Cluster Role Reference - -The following table lists each built-in custom cluster role available in Rancher and whether it is also granted by the `Owner` or `Member` role. - -| Custom Cluster Role | Owner | Member | -| ---------------------------------- | ------------- | ------------- | -| Manage Cluster Members | ✓ | | -| Manage Nodes | ✓ | | -| Manage Storage | ✓ | | -| View All Projects | ✓ | | -| Create Project | ✓ | ✓ | -| View Cluster Members | ✓ | ✓ | -| View Nodes | ✓ | ✓ | - -> **Note:** Each cluster role listed above, including `Owner` and `Member`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page. - -#### Project Roles - -_Project roles_ are roles that can be used to grant users access to a project. There are three primary project roles: `Owner`, `Member`, and `Read Only`. - -- **Owner:** - - These users have full control over the project and all resources in it. - -- **Member:** - - These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members. - -- **Read Only:** - - These users can view everything in the project but cannot create, update, or delete anything. - -##### Custom Project Roles - -Rancher lets you assign _custom project roles_ to a user instead of the typical `Owner`, `Member`, or `Read Only` roles. These roles can be either a built-in custom project role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a user within a project. See the table below for a list of built-in custom project roles. - -##### Project Role Reference - -The following table lists each built-in custom project role available in Rancher and whether it is also granted by the `Owner`, `Member`, or `Read Only` role. - -| Custom Cluster Role | Owner | Member | Read Only | -| ---------------------------------- | ------------- | ------------- | ------------- | -| Manage Project Members | ✓ | | | -| Create Namespaces | ✓ | ✓ | | -| Manage Config Maps | ✓ | ✓ | | -| Manage Ingress | ✓ | ✓ | | -| Manage Secrets | ✓ | ✓ | | -| Manage Service Accounts | ✓ | ✓ | | -| Manage Services | ✓ | ✓ | | -| Manage Volumes | ✓ | ✓ | | -| Manage Workloads | ✓ | ✓ | | -| View Config Maps | ✓ | ✓ | ✓ | -| View Ingress | ✓ | ✓ | ✓ | -| View Project Members | ✓ | ✓ | ✓ | -| View Secrets | ✓ | ✓ | ✓ | -| View Service Accounts | ✓ | ✓ | ✓ | -| View Services | ✓ | ✓ | ✓ | -| View Volumes | ✓ | ✓ | ✓ | -| View Workloads | ✓ | ✓ | ✓ | - -> **Note:** Each project role listed above, including Owner, Member, and Read Only, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page. - -### Defining Custom Roles -As previously mentioned, custom roles can be defined for use at the cluster or project level. The context field defines whether the role will appear on the cluster member page, project member page, or both. - -When defining a custom role, you can grant access to specific resources or specify roles from which the custom role should inherit. A custom role can be made up of a combination of specific grants and inherited roles. All grants are additive. This means that defining a narrower grant for a specific resource **will not** override a broader grant defined in a role that the custom role is inheriting from. - -#### Locked Roles - -You can set roles to a status of `locked`. Locking roles prevent them from being assigned users in the future. - -Locked roles: - -- Cannot be assigned to users that don't already have it assigned. -- Are not listed in the **Member Roles** drop-down when you are adding a user to a cluster or project. -- Do not affect users assigned the role before you lock the role. These users retain access that the role provides. - - **Example:** let's say your organization creates an internal policy that users assigned to a cluster are prohibited from creating new projects. It's your job to enforce this policy. - - To enforce it, before you add new users to the cluster, you should lock the following roles: `Cluster Owner`, `Cluster Member`, and `Create Projects`. Then you could create a new custom role that includes the same permissions as a __Cluster Member__, except the ability to create projects. Then, you use this new custom role when adding users to a cluster. - -Roles can be locked by the following users: - -- Any user assigned the `Administrator` global permission. -- Any user assigned the `Custom Users` permission, along with the `Manage Roles` role. - diff --git a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index-task.md b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index-task.md deleted file mode 100644 index cb4a09b34cd..00000000000 --- a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index-task.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Roles -weight: 100 ---- -Within Rancher, _roles_ determine what actions a user can make within a cluster or project. - -Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access. - ->**Prerequisites:** -> ->To complete the tasks on this page, the following permissions are required: -> ->- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions). ->- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions-reference) role assigned. - -## Adding A Custom Role - -While Rancher comes out-of-the-box with a set of default user roles, you can also create custom roles to provide users with very specific permissions within Rancher. - -1. From the **Global** view, select **Security > Roles** from the main menu. - -2. Click **Add Role**. - -3. **Name** the role. - -4. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#locked-roles). - - Locked roles cannot be assigned to users. - -5. Assign the role a **Context**. Context determines the scope of role assigned to the user. The contexts are: - - - **All** - - The user can use their assigned role regardless of context. This role is valid for assignment when adding/managing members to clusters or projects. - - - **Cluster** - - This role is valid for assignment when adding/managing members to _only_ clusters. - - - **Project** - - This role is valid for assignment when adding/managing members to _only_ projects. - -6. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role. - - You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign. - -7. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. - -8. Click **Create**. - -## Locking/Unlocking Roles - -If you want to prevent a role from being assigned to users, you can set it to a status of `locked`. For more information about what this status means, see [Locked Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#locked-roles). - -You can lock roles in two contexts: - -- When you're [adding a custom role](#adding-a-custom-role). -- When you editing an existing role (see below). - - -1. From the **Global** view, select **Security** > **Roles**. - -2. From the role that you want to lock (or unlock), select **Vertical Ellipsis (...)** > **Edit**. - -3. From the **Locked** option, choose the **Yes** or **No** radio button. Then click **Save**.