diff --git a/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md new file mode 100644 index 00000000000..9d92dc4229b --- /dev/null +++ b/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md @@ -0,0 +1,89 @@ +--- +title: Authentication +weight: 3075 +--- +You have three options for user authentication in {{< product >}}: + +- **Active Directory**: Enterprises can use Active Directory (AD) for authentication, allowing users to sign in using their corporate credentials. + +- **GitHub**: Open source projects or organizations that use GitHub for source control may prefer that users sign in using their GitHub accounts. + +- **Basic Authentication**: If you don't want to use external authentication, you can always add users directly to {{< product >}}. We recommend using external authentication over basic authentication. + +## Configure an Authentication Method + +### To Configure Active Directory + +>**Prerequisites:** Create a service account in Active Directory with **read-only** access. {{< product >}} uses this account to verify group membership when a user makes a request using an API key. + +1. From the **Global** view, select **Security > Authentication** from the main menu. + +2. Select **Active Directory**. + +3. 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?** + > + Make sure you have an [LDAP certificate installed](placeholder.md). + + >**User Search Base vs. Group Search Base** + > + >When configuring AD authentication, you must enter a search base for your users. This base allows Rancher to search for users that are in your Active Directory. + - If your users and groups are in the 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. + +4. If your Active Directory deviates from the standard AD schema, complete the **Customize Schema** form to match it. Otherwise, skip this step. + +5. Enter your AD username and password in **Test and enable authentication** to confirm that Rancher is configured to use AD authentication. + +### To Configure GitHub + +1. From the **Global** view, select **Security > Authentication** from the main menu. + +2. Select **GitHub**. + +3. 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 to begin using your application (i.e. the splash screen). + + >When you use external authentication, sign on authentication does not actually take place in your application. Instead, authentication takes place externally (in this case, GitHub). After this external authorization completes successfully, the Authorization Callback URL is the location that the user reenters your application. + +4. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into {{< product >}}. + + >**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. + +5. Click **Authenticate with GitHub**. + +6. 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. +
+7. Click **Save**. + +**Result:** + +- GitHub authentication is configured. +- You are signed into Rancher with your GitHub account. +- Your GitHub account is added to Rancher as an administrator. + +### To Configure Local Authentication + +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/tasks/global-configuration/catalog/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md new file mode 100644 index 00000000000..7ff7132e0f2 --- /dev/null +++ b/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md @@ -0,0 +1,9 @@ +--- +title: Catalog +weight: 3026 +draft: true +--- + +## Creating Custom Catalogs + +## Catalog References diff --git a/content/rancher/v2.x/en/tasks/global-configuration/node-drivers/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/node-drivers/_index.md new file mode 100644 index 00000000000..50970e9d5e8 --- /dev/null +++ b/content/rancher/v2.x/en/tasks/global-configuration/node-drivers/_index.md @@ -0,0 +1,21 @@ +--- +title: Node Drivers +weight: 3050 +--- +## Adding Custom Node Drivers + +If you create a cluster using a cloud provider that {{< product >}} doesn't support out-of-the-box, you may need to add the provider's drivers (or create them yourself) so that your nodes function properly. + +1. From the **Global** view, select **Node Drivers** from the main menu. + +2. Click **Add Node Driver**. + +3. Complete the **Add Node Driver** form. Then click **Create**. + +## Activating Node Drivers + +Using the **Custom** option, you can create a cluster using virtually any cloud provider. However, by default, {{< product >}} only activates drivers for the most popular cloud providers. If you want to use another provider, you'll have to activate their drivers. + +1. From the **Global** view, select **Node Drivers** from the main menu. + +2. Select the inactive drivers that you want to use. Then click **Add Node Driver**. diff --git a/content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md new file mode 100644 index 00000000000..60ceaf12e52 --- /dev/null +++ b/content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md @@ -0,0 +1,44 @@ +--- +title: Adding Pod Security Policies +weight: 3150 +--- + +Using {{< product >}}, you can create a Pod Security Policy using our GUI rather than creating a .yaml file. + +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: + +- An existing cluster +- A brand new cluster. For more details, see [Creating a Cluster](../../clusters/creating-a-cluster/_index) + + + + +[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/tasks/global-configuration/roles/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md new file mode 100644 index 00000000000..9574766bbdb --- /dev/null +++ b/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md @@ -0,0 +1,37 @@ +--- +title: Roles +weight: 3100 +--- +While _users_ determine who can log into Rancher, _roles_ determine which Kubernetes API endpoints and Rancher roles that a user can access after login. In other words, roles determine the user's _permissions_ when using Rancher. + +## 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. Assign the role a **Context**. Context determines the scope of permissions assigned to the user. The contexts are: + + - **All** + + The user can use their assigned permissions regardless of context. The user's permissions are valid in all clusters and projects. + + - **Cluster** + + The user can use their assigned permissions within a selected cluster. + + - **Project** + + The user can use their assigned permissions within a selected project. + +5. 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. + +6. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. + +7. Click **Create**. diff --git a/content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.md new file mode 100644 index 00000000000..c980796ef8a --- /dev/null +++ b/content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.md @@ -0,0 +1,13 @@ +--- +title: Rancher Server URL +weight: 3125 +--- +## Updating the {{< product >}} Server URL + +The first time that you log into {{< product >}}, the system prompts for the {{< product >}} 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 {{< product >}} Server URL? + +If URL of your {{< product >}} Server changes, you must update the {{< product >}} Server URL so that your nodes can continue communication with the {{< product >}} Server.