From 1ce0eb07946deb57fca0f793632060eecb822d8f Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 11:32:35 -0700 Subject: [PATCH 01/30] adding admin settings folder structure --- .../rancher/v2.x/en/admin-settings/authentication/_index.md | 6 ++++++ .../admin-settings/authentication/configuring-ad/index.md | 6 ++++++ .../authentication/configuring-azure-ad/index.md | 6 ++++++ .../authentication/configuring-freeipa/index.md | 6 ++++++ .../authentication/configuring-github/index.md | 6 ++++++ .../configuring-local-authentication/index.md | 6 ++++++ .../authentication/configuring-openldap/index.md | 6 ++++++ content/rancher/v2.x/en/admin-settings/index.md | 4 ++++ .../v2.x/en/admin-settings/pod-security-policies/_index.md | 6 ++++++ .../v2.x/en/admin-settings/rancher-server-url/_index.md | 6 ++++++ content/rancher/v2.x/en/admin-settings/rbac/_index.md | 6 ++++++ .../v2.x/en/admin-settings/rbac/creating-roles/_index.md | 6 ++++++ 12 files changed, 70 insertions(+) create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-github/index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/index.md create mode 100644 content/rancher/v2.x/en/admin-settings/index.md create mode 100644 content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/rbac/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md new file mode 100644 index 00000000000..01f1263911d --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -0,0 +1,6 @@ +--- +title: Authentication +weight: 25 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/index.md new file mode 100644 index 00000000000..8797187e7ec --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/index.md @@ -0,0 +1,6 @@ +--- +title: Configuring Active Directory +weight: 50 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/index.md new file mode 100644 index 00000000000..d715528b4b9 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/index.md @@ -0,0 +1,6 @@ +--- +title: Configuring Azure AD +weight: 75 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/index.md new file mode 100644 index 00000000000..cbe01e803e0 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/index.md @@ -0,0 +1,6 @@ +--- +title: Configuring FreeIPA +weight: 150 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/index.md new file mode 100644 index 00000000000..a1f2b96d213 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/index.md @@ -0,0 +1,6 @@ +--- +title: Configuring GitHub +weight: 100 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/index.md new file mode 100644 index 00000000000..6a9858dcffc --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/index.md @@ -0,0 +1,6 @@ +--- +title: Configuring Local Authentication +weight: 25 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/index.md new file mode 100644 index 00000000000..a92cfc9fa23 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/index.md @@ -0,0 +1,6 @@ +--- +title: Configuring OpenLDAP +weight: 125 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/index.md b/content/rancher/v2.x/en/admin-settings/index.md new file mode 100644 index 00000000000..348ce7b3565 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/index.md @@ -0,0 +1,4 @@ +--- +title: Admin Settings +weight: 25 +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md new file mode 100644 index 00000000000..1a460255621 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md @@ -0,0 +1,6 @@ +--- +title: Pod Security Policies +weight: 25 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md new file mode 100644 index 00000000000..53d825de543 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md @@ -0,0 +1,6 @@ +--- +title: Rancher Server URL +weight: 25 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/rbac/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md new file mode 100644 index 00000000000..3475dd63420 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md @@ -0,0 +1,6 @@ +--- +title: RBAC +weight: 25 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md new file mode 100644 index 00000000000..0c7a72d30a3 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md @@ -0,0 +1,6 @@ +--- +title: Creating Roles +weight: 25 +aliases: + +--- \ No newline at end of file From d769509ca15e8bea90b2cdae0a7de7c8de4e429f Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 11:47:55 -0700 Subject: [PATCH 02/30] moved server url task and concept to new folder, added aliases to index.md, deleted old folders --- .../rancher-server-url/_index-concept.md | 9 +++++++++ .../admin-settings/rancher-server-url/_index-task.md | 12 ++++++++++++ .../en/admin-settings/rancher-server-url/_index.md | 3 ++- 3 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-concept.md create mode 100644 content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-task.md 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 new file mode 100644 index 00000000000..a7bdb887aa8 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-concept.md @@ -0,0 +1,9 @@ +--- +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 new file mode 100644 index 00000000000..6c62117577f --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index-task.md @@ -0,0 +1,12 @@ +--- +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/rancher-server-url/_index.md b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md index 53d825de543..a8194a2241b 100644 --- a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md @@ -2,5 +2,6 @@ title: Rancher Server URL weight: 25 aliases: - + -/rancher/v2.x/en/concepts/global-configuration/server-url + -/rancher/v2.x/en/tasks/global-configuration/server-url --- \ No newline at end of file From 04175801a34829f4dc48b86b6b744c1fbe89c666 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 11:58:02 -0700 Subject: [PATCH 03/30] moved pod security policies task and concept to new folder, added aliases to index.md, deleted old folders --- .../pod-security-policies/_index-concept.md | 19 +++++++++ .../pod-security-policies/_index-task.md | 41 +++++++++++++++++++ .../pod-security-policies/_index.md | 3 +- 3 files changed, 62 insertions(+), 1 deletion(-) create mode 100644 content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-concept.md create mode 100644 content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-task.md 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 new file mode 100644 index 00000000000..7e635fa3235 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-concept.md @@ -0,0 +1,19 @@ +--- +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 new file mode 100644 index 00000000000..e9eb69200a6 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index-task.md @@ -0,0 +1,41 @@ +--- +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/pod-security-policies/_index.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md index 1a460255621..a9b2cb40901 100644 --- a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md +++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md @@ -2,5 +2,6 @@ title: Pod Security Policies weight: 25 aliases: - + -/rancher/v2.x/en/concepts/global-configuration/pod-security-policies + -/rancher/v2.x/en/tasks/global-configuration/pod-security-policies --- \ No newline at end of file From a624ff607b1440c5a42d1883e271e4c4fb6bebfd Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 12:07:33 -0700 Subject: [PATCH 04/30] moved RBAC task and concept to new folder, added aliases to index.md, deleted old folders --- .../en/admin-settings/rbac/_index-concept.md | 197 ++++++++++++++++++ .../v2.x/en/admin-settings/rbac/_index.md | 2 +- .../rbac/creating-roles/_index-task.md | 66 ++++++ .../rbac/creating-roles/_index.md | 2 +- 4 files changed, 265 insertions(+), 2 deletions(-) create mode 100644 content/rancher/v2.x/en/admin-settings/rbac/_index-concept.md create 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/rbac/_index-concept.md b/content/rancher/v2.x/en/admin-settings/rbac/_index-concept.md new file mode 100644 index 00000000000..22847e402a1 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index-concept.md @@ -0,0 +1,197 @@ +--- +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/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md index 3475dd63420..2eecab58f89 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md @@ -2,5 +2,5 @@ title: RBAC weight: 25 aliases: - + -/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/ --- \ No newline at end of file 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 new file mode 100644 index 00000000000..cb4a09b34cd --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index-task.md @@ -0,0 +1,66 @@ +--- +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**. diff --git a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md index 0c7a72d30a3..ae7a130c158 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md @@ -2,5 +2,5 @@ title: Creating Roles weight: 25 aliases: - + -/rancher/v2.x/en/tasks/global-configuration/roles/ --- \ No newline at end of file From a4de81281e4b4de66646b91c7e994338d4b3eedb Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 12:19:38 -0700 Subject: [PATCH 05/30] correcting filenames without underscore in authentication folder --- .../admin-settings/authentication/configuring-ad/_index.md | 6 ++++++ .../authentication/configuring-azure-ad/_index.md | 6 ++++++ .../authentication/configuring-freeipa/_index.md | 6 ++++++ .../authentication/configuring-github/_index.md | 6 ++++++ .../configuring-local-authentication/_index.md | 6 ++++++ .../authentication/configuring-openldap/_index.md | 6 ++++++ 6 files changed, 36 insertions(+) create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md new file mode 100644 index 00000000000..735373a422e --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md @@ -0,0 +1,6 @@ +--- +title: Configuring Active Directory +weight: 50 +aliases: + -/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/ +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md new file mode 100644 index 00000000000..d715528b4b9 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md @@ -0,0 +1,6 @@ +--- +title: Configuring Azure AD +weight: 75 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md new file mode 100644 index 00000000000..cbe01e803e0 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md @@ -0,0 +1,6 @@ +--- +title: Configuring FreeIPA +weight: 150 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md new file mode 100644 index 00000000000..a1f2b96d213 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md @@ -0,0 +1,6 @@ +--- +title: Configuring GitHub +weight: 100 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md new file mode 100644 index 00000000000..6a9858dcffc --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md @@ -0,0 +1,6 @@ +--- +title: Configuring Local Authentication +weight: 25 +aliases: + +--- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md new file mode 100644 index 00000000000..a92cfc9fa23 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md @@ -0,0 +1,6 @@ +--- +title: Configuring OpenLDAP +weight: 125 +aliases: + +--- \ No newline at end of file From cd53d2e045d8cbb7458a2f6621b2b22bde7bf9b8 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 12:29:04 -0700 Subject: [PATCH 06/30] moved authentication tasks and concepts to new folder, added aliases to index.md, deleted old folders --- .../authentication/_index-concept.md | 57 ++++++ .../admin-settings/authentication/_index.md | 2 +- .../configuring-ad/_index-task.md | 52 +++++ .../authentication/configuring-ad/index.md | 6 - .../configuring-azure-ad/_index-task.md | 188 ++++++++++++++++++ .../configuring-azure-ad/_index.md | 2 +- .../configuring-azure-ad/index.md | 6 - .../configuring-freeipa/_index-task.md | 54 +++++ .../configuring-freeipa/_index.md | 2 +- .../configuring-freeipa/index.md | 6 - .../configuring-github/_index-task.md | 51 +++++ .../configuring-github/_index.md | 2 +- .../configuring-github/index.md | 6 - .../_index-task.md | 10 + .../_index.md | 2 +- .../configuring-local-authentication/index.md | 6 - .../configuring-openldap/_index-task.md | 55 +++++ .../configuring-openldap/_index.md | 2 +- .../configuring-openldap/index.md | 6 - 19 files changed, 473 insertions(+), 42 deletions(-) create mode 100644 content/rancher/v2.x/en/admin-settings/authentication/_index-concept.md create 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-ad/index.md create 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-azure-ad/index.md create 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-freeipa/index.md create 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-github/index.md create 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-local-authentication/index.md create 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/authentication/configuring-openldap/index.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 new file mode 100644 index 00000000000..94840b7de1f --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index-concept.md @@ -0,0 +1,57 @@ +--- +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/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md index 01f1263911d..691240b5aaf 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -2,5 +2,5 @@ title: Authentication weight: 25 aliases: - + -/rancher/v2.x/en/concepts/global-configuration/authentication/ --- \ No newline at end of file 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 new file mode 100644 index 00000000000..c79513802ca --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index-task.md @@ -0,0 +1,52 @@ +--- +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-ad/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/index.md deleted file mode 100644 index 8797187e7ec..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Configuring Active Directory -weight: 50 -aliases: - ---- \ No newline at end of file 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 new file mode 100644 index 00000000000..3cf607630bb --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index-task.md @@ -0,0 +1,188 @@ +--- +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-azure-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md index d715528b4b9..b914a5d7a52 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md @@ -2,5 +2,5 @@ title: Configuring Azure AD weight: 75 aliases: - + -/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/ --- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/index.md deleted file mode 100644 index d715528b4b9..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Configuring Azure AD -weight: 75 -aliases: - ---- \ No newline at end of file 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 new file mode 100644 index 00000000000..5f4423261ac --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index-task.md @@ -0,0 +1,54 @@ +--- +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-freeipa/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md index cbe01e803e0..a3bcf92893a 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md @@ -2,5 +2,5 @@ title: Configuring FreeIPA weight: 150 aliases: - + -/rancher/v2.x/en/tasks/global-configuration/authentication/freeipa/ --- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/index.md deleted file mode 100644 index cbe01e803e0..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Configuring FreeIPA -weight: 150 -aliases: - ---- \ No newline at end of file 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 new file mode 100644 index 00000000000..603bb20847f --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index-task.md @@ -0,0 +1,51 @@ +--- +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-github/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md index a1f2b96d213..f019da55a7e 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md @@ -2,5 +2,5 @@ title: Configuring GitHub weight: 100 aliases: - + -/rancher/v2.x/en/tasks/global-configuration/authentication/github/ --- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/index.md deleted file mode 100644 index a1f2b96d213..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Configuring GitHub -weight: 100 -aliases: - ---- \ No newline at end of file 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 new file mode 100644 index 00000000000..189371f7084 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index-task.md @@ -0,0 +1,10 @@ +--- +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-local-authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md index 6a9858dcffc..cddf1a8f8e3 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md @@ -2,5 +2,5 @@ title: Configuring Local Authentication weight: 25 aliases: - + -/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/ --- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/index.md deleted file mode 100644 index 6a9858dcffc..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Configuring Local Authentication -weight: 25 -aliases: - ---- \ No newline at end of file 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 new file mode 100644 index 00000000000..773ed4169e0 --- /dev/null +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index-task.md @@ -0,0 +1,55 @@ +--- +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/authentication/configuring-openldap/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md index a92cfc9fa23..256edbfd899 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md @@ -2,5 +2,5 @@ title: Configuring OpenLDAP weight: 125 aliases: - + -/rancher/v2.x/en/tasks/global-configuration/authentication/openLDAP/ --- \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/index.md deleted file mode 100644 index a92cfc9fa23..00000000000 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Configuring OpenLDAP -weight: 125 -aliases: - ---- \ No newline at end of file From 54092c6558ce7610988e9e744189d7f3b1301c94 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 12:53:12 -0700 Subject: [PATCH 07/30] deleting old files --- .../admin-settings/rancher-server-url/_index.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md index a8194a2241b..ffdc30ac506 100644 --- a/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rancher-server-url/_index.md @@ -4,4 +4,17 @@ weight: 25 aliases: -/rancher/v2.x/en/concepts/global-configuration/server-url -/rancher/v2.x/en/tasks/global-configuration/server-url ---- \ No newline at end of file +--- + +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**. + +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. From f252801908b7da3fd2008baa95195e6e3d022c3d Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 13:15:25 -0700 Subject: [PATCH 08/30] deleting old files using git command (weren't removed before because I deleted the files manually) --- .../authentication/_index.md | 59 ----- .../pod-security-policies/_index.md | 29 --- .../global-configuration/server-url/_index.md | 9 - .../users-permissions-roles/_index.md | 202 ------------------ .../authentication/_index.md | 31 --- .../authentication/active-directory/_index.md | 52 ----- .../authentication/azure-ad/_index.md | 188 ---------------- .../authentication/freeipa/_index.md | 54 ----- .../authentication/github/_index.md | 51 ----- .../local-authentication/_index.md | 10 - .../authentication/openLDAP/_index.md | 55 ----- .../pod-security-policies/_index.md | 41 ---- .../global-configuration/roles/_index.md | 66 ------ .../global-configuration/server-url/_index.md | 12 -- 14 files changed, 859 deletions(-) delete mode 100644 content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md delete mode 100644 content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md delete mode 100644 content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md delete mode 100644 content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/authentication/freeipa/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/authentication/github/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/authentication/openLDAP/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md delete mode 100644 content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.md diff --git a/content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md deleted file mode 100644 index 07e4d8f5946..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md +++ /dev/null @@ -1,59 +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. - -## 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. - - -## Related Links - -- [Configuring Authentication]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication) diff --git a/content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md deleted file mode 100644 index 5fde2ac6d4f..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md +++ /dev/null @@ -1,29 +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. - -## Related Links - -### External Links - -- [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) - -### Tutorials - -- [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy) diff --git a/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md deleted file mode 100644 index a7bdb887aa8..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.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/concepts/global-configuration/users-permissions-roles/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md deleted file mode 100644 index 0fb2e031d1a..00000000000 --- a/content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md +++ /dev/null @@ -1,202 +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. - -## Related Links - -- [Adding Project Members]({{< baseurl >}}/rancher/v2.x/en/tasks/projects/add-project-members) -- [Adding Project Members]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members) -- [Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles) 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 deleted file mode 100644 index bb81cb76f9a..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Authentication -weight: 50 ---- - -You have multiple options for user authentication in Rancher: - -- [Active Directory](./active-directory/) - - Enterprises can use Active Directory (AD) for authentication, allowing users to sign in using their corporate credentials. - -- [Azure AD](./azure-ad/) - - 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. - -- [GitHub](./github/) - - Open source projects or organizations that use GitHub for source control may prefer that users sign in using their GitHub accounts. - -- [OpenLDAP](./openlap/) - - Organizations can use OpenLDAP for authentication, allowing users to sign in using their corporate credentials. - -- [FreeIPA](./freeipa/) - - Organizations can use FreeIPA for authentication, allowing users to sign in using their corporate credentials. - - -- [Local Authentication](./local-authentication/) - - If you don't want to use external authentication, you can always add users directly to Rancher. We recommend using external authentication over local authentication. diff --git a/content/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/_index.md deleted file mode 100644 index c79513802ca..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/_index.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/tasks/global-configuration/authentication/azure-ad/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/_index.md deleted file mode 100644 index 3cf607630bb..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/_index.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/tasks/global-configuration/authentication/freeipa/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/freeipa/_index.md deleted file mode 100644 index 5f4423261ac..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/freeipa/_index.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/tasks/global-configuration/authentication/github/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/github/_index.md deleted file mode 100644 index 603bb20847f..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/github/_index.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/tasks/global-configuration/authentication/local-authentication/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/_index.md deleted file mode 100644 index 189371f7084..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/_index.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/tasks/global-configuration/authentication/openLDAP/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/authentication/openLDAP/_index.md deleted file mode 100644 index 773ed4169e0..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/openLDAP/_index.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/tasks/global-configuration/pod-security-policies/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.md deleted file mode 100644 index e9eb69200a6..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/_index.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/tasks/global-configuration/roles/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md deleted file mode 100644 index cb4a09b34cd..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.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**. 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 deleted file mode 100644 index 6c62117577f..00000000000 --- a/content/rancher/v2.x/en/tasks/global-configuration/server-url/_index.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. From 35e20af292e4789d9da1c5610972b80a170e877b Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:21:18 -0700 Subject: [PATCH 09/30] adding alias for authentication task --- content/rancher/v2.x/en/admin-settings/authentication/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md index 691240b5aaf..f46d35907b2 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -3,4 +3,5 @@ title: Authentication weight: 25 aliases: -/rancher/v2.x/en/concepts/global-configuration/authentication/ + -/rancher/v2.x/en/task/global-configuration/authentication/ --- \ No newline at end of file From 24f8aa8249b676b74111cc11f54264bd54dca3b6 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:27:16 -0700 Subject: [PATCH 10/30] correcting another index.md file without an underscore --- content/rancher/v2.x/en/admin-settings/{index.md => _index.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/rancher/v2.x/en/admin-settings/{index.md => _index.md} (100%) diff --git a/content/rancher/v2.x/en/admin-settings/index.md b/content/rancher/v2.x/en/admin-settings/_index.md similarity index 100% rename from content/rancher/v2.x/en/admin-settings/index.md rename to content/rancher/v2.x/en/admin-settings/_index.md From 2c83fff033bbaa127825d014f2a6d8d94119819c Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:29:36 -0700 Subject: [PATCH 11/30] changing weight to correct position in menu --- content/rancher/v2.x/en/admin-settings/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 348ce7b3565..7ee85e79e2a 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -1,4 +1,4 @@ --- title: Admin Settings -weight: 25 +weight: 1100 --- \ No newline at end of file From 2a51929b2c0c08b33f33c2f810dbdbfc665148eb Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:37:32 -0700 Subject: [PATCH 12/30] merging index files in the RBAC folder --- .../rancher/v2.x/en/admin-settings/_index.md | 195 +++++++++++++++++- .../rbac/creating-roles/_index.md | 65 +++++- 2 files changed, 258 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 7ee85e79e2a..9a32c2222b7 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -1,4 +1,197 @@ --- title: Admin Settings weight: 1100 ---- \ No newline at end of file +--- + +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.md b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md index ae7a130c158..85a29d8597e 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md @@ -3,4 +3,67 @@ title: Creating Roles weight: 25 aliases: -/rancher/v2.x/en/tasks/global-configuration/roles/ ---- \ No newline at end of file +--- + +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**. From 9e2f368711f09395caf91c00265dd7a2f9bcefa7 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:39:02 -0700 Subject: [PATCH 13/30] merging index files for psp folder --- .../pod-security-policies/_index.md | 55 ++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md index a9b2cb40901..d5d813e1aa2 100644 --- a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md +++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md @@ -4,4 +4,57 @@ weight: 25 aliases: -/rancher/v2.x/en/concepts/global-configuration/pod-security-policies -/rancher/v2.x/en/tasks/global-configuration/pod-security-policies ---- \ No newline at end of file +--- + +_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. + +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 From 872e4287b24a7fab81bd8e2144b77c32ba6f41dd Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:42:45 -0700 Subject: [PATCH 14/30] merging index files in \authentication --- .../admin-settings/authentication/_index.md | 56 ++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md index f46d35907b2..8ade3ce655b 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -4,4 +4,58 @@ weight: 25 aliases: -/rancher/v2.x/en/concepts/global-configuration/authentication/ -/rancher/v2.x/en/task/global-configuration/authentication/ ---- \ No newline at end of file +--- + +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. + From 8ec623155983f5415bc2ccf34562359a3bc3d826 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:44:24 -0700 Subject: [PATCH 15/30] merging local auth index files --- .../configuring-local-authentication/_index.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md index cddf1a8f8e3..e65390436cf 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-local-authentication/_index.md @@ -3,4 +3,10 @@ title: Configuring Local Authentication weight: 25 aliases: -/rancher/v2.x/en/tasks/global-configuration/authentication/local-authentication/ ---- \ No newline at end of file +--- + +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. \ No newline at end of file From ac5a1e9108d5fab9d0a5dca6c974c24d8183b83c Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:45:31 -0700 Subject: [PATCH 16/30] merging AD index files --- .../authentication/configuring-ad/_index.md | 50 ++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md index 735373a422e..1f3bbb17231 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md @@ -3,4 +3,52 @@ title: Configuring Active Directory weight: 50 aliases: -/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/ ---- \ No newline at end of file +--- + +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_). From 278354b31867d051f543e9c5065c4233724d9810 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:48:07 -0700 Subject: [PATCH 17/30] merging azure AD index files --- .../configuring-azure-ad/_index.md | 186 +++++++++++++++++- 1 file changed, 185 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md index b914a5d7a52..c2bac9fabe5 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-azure-ad/_index.md @@ -3,4 +3,188 @@ title: Configuring Azure AD weight: 75 aliases: -/rancher/v2.x/en/tasks/global-configuration/authentication/azure-ad/ ---- \ No newline at end of file +--- + +_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. From d47df6ec6d6cd3106b8f58c10b850c7437053581 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:49:42 -0700 Subject: [PATCH 18/30] merging freeIPA index files --- .../configuring-freeipa/_index.md | 52 ++++++++++++++++++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md index a3bcf92893a..d9de6fca98c 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md @@ -3,4 +3,54 @@ title: Configuring FreeIPA weight: 150 aliases: -/rancher/v2.x/en/tasks/global-configuration/authentication/freeipa/ ---- \ No newline at end of file +--- + +_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_). From c06b1401baa81544185ee34175a1ff5b6ea91121 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:50:44 -0700 Subject: [PATCH 19/30] merging github index files --- .../configuring-github/_index.md | 49 ++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md index f019da55a7e..aa5fe468f21 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md @@ -3,4 +3,51 @@ title: Configuring GitHub weight: 100 aliases: -/rancher/v2.x/en/tasks/global-configuration/authentication/github/ ---- \ No newline at end of file +--- + +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_). From 95e92f28c9affc7874c00811616c5e6add14c7c8 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:52:41 -0700 Subject: [PATCH 20/30] merging openldap indexes --- .../configuring-openldap/_index.md | 53 ++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md index 256edbfd899..e1d5e45b5a4 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md @@ -3,4 +3,55 @@ title: Configuring OpenLDAP weight: 125 aliases: -/rancher/v2.x/en/tasks/global-configuration/authentication/openLDAP/ ---- \ No newline at end of file +--- + +_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_). From 6100f984c408defec938eb5e59b61f980ec86c6b Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 12 Jul 2018 16:56:18 -0700 Subject: [PATCH 21/30] 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**. From 30deff69e20cf3df8ba6b50746941ef9a8f03b98 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:03:56 -0700 Subject: [PATCH 22/30] moving content incorrectly copied to admin settings to its inteded file, RBAC. --- .../rancher/v2.x/en/admin-settings/_index.md | 192 ----------------- .../v2.x/en/admin-settings/rbac/_index.md | 195 +++++++++++++++++- 2 files changed, 194 insertions(+), 193 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 9a32c2222b7..28401e4a031 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -3,195 +3,3 @@ title: Admin Settings weight: 1100 --- -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/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md index 2eecab58f89..a5c1575a8e0 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md @@ -3,4 +3,197 @@ title: RBAC weight: 25 aliases: -/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/ ---- \ No newline at end of file +--- + +Within Rancher, each person 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. + From fae75935aa8b0615337afded849e5f8f898770cd Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:08:54 -0700 Subject: [PATCH 23/30] moving global-config concept to root of admin-settings. adding alias as well --- .../_index.md => admin-settings/_index-concept.md} | 0 content/rancher/v2.x/en/admin-settings/_index.md | 2 ++ 2 files changed, 2 insertions(+) rename content/rancher/v2.x/en/{concepts/global-configuration/_index.md => admin-settings/_index-concept.md} (100%) diff --git a/content/rancher/v2.x/en/concepts/global-configuration/_index.md b/content/rancher/v2.x/en/admin-settings/_index-concept.md similarity index 100% rename from content/rancher/v2.x/en/concepts/global-configuration/_index.md rename to content/rancher/v2.x/en/admin-settings/_index-concept.md diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 28401e4a031..2bfaa784c9e 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -1,5 +1,7 @@ --- title: Admin Settings weight: 1100 +aliases: + - /rancher/v2.x/en/concepts/global-configuration --- From 811c9e4953031becac1f0683496288022e42d41c Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:12:07 -0700 Subject: [PATCH 24/30] copying content from global config concept to admin-settings index file --- content/rancher/v2.x/en/admin-settings/_index.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 2bfaa784c9e..d0ffa8a5eb0 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -5,3 +5,11 @@ aliases: - /rancher/v2.x/en/concepts/global-configuration --- +After installing Rancher 2.0, you should configure it to support your users and environment. This section describes the global configurations you should make after installation. + +- [Rancher Server URL]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/server-url) +- [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) +- [Users, Roles, and Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-roles-permissions) +- [Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies) +- [Node Drivers]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-drivers) +- [Node Templates]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-templates) \ No newline at end of file From df05e09721ffe76d85f4d290d05ff9648b0c604c Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:14:48 -0700 Subject: [PATCH 25/30] deleting old global-config index file --- .../v2.x/en/admin-settings/_index-concept.md | 13 ------------- 1 file changed, 13 deletions(-) delete mode 100644 content/rancher/v2.x/en/admin-settings/_index-concept.md diff --git a/content/rancher/v2.x/en/admin-settings/_index-concept.md b/content/rancher/v2.x/en/admin-settings/_index-concept.md deleted file mode 100644 index f4f7545d47c..00000000000 --- a/content/rancher/v2.x/en/admin-settings/_index-concept.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Global Configuration -weight: 1 ---- -After installing Rancher 2.0, you should configure it to support your users and environment. This section describes the global configurations you should make after installation. - -- [Rancher Server URL]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/server-url) -- [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) -- [Users, Roles, and Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-roles-permissions) -- [Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies) -- [Node Drivers]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-drivers) -- [Node Templates]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-templates) - From d49f35389c88aa1ea72c2610cb21e0df24cf26a5 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:29:09 -0700 Subject: [PATCH 26/30] Editing content in admin settings index file --- content/rancher/v2.x/en/admin-settings/_index.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index d0ffa8a5eb0..f461b9a8199 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -5,11 +5,10 @@ aliases: - /rancher/v2.x/en/concepts/global-configuration --- -After installing Rancher 2.0, you should configure it to support your users and environment. This section describes the global configurations you should make after installation. +After installing Rancher 2.0, you should -- [Rancher Server URL]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/server-url) -- [Authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) -- [Users, Roles, and Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-roles-permissions) -- [Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies) -- [Node Drivers]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-drivers) -- [Node Templates]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/node-templates) \ No newline at end of file +1. Set a Rancher Server URL, which your cluster nodes will use to resolve with Rancher. You'll be prompted to set this URL upon your first log in. + +2. Set up external user authentication and permissions so that your organization can log into Rancher. + +After making these initial configurations, you might also want to configure one or more _pod security policies_, which are sets of conditions that your pods must meet for Kubernetes to allow them to run. \ No newline at end of file From 0ef272fd99d3cd3f37de623d5e4cc11f45b99766 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:33:50 -0700 Subject: [PATCH 27/30] weight fix --- content/rancher/v2.x/en/admin-settings/authentication/_index.md | 2 +- .../v2.x/en/admin-settings/pod-security-policies/_index.md | 2 +- content/rancher/v2.x/en/admin-settings/rbac/_index.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md index 8ade3ce655b..616823f54b3 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -1,6 +1,6 @@ --- title: Authentication -weight: 25 +weight: 50 aliases: -/rancher/v2.x/en/concepts/global-configuration/authentication/ -/rancher/v2.x/en/task/global-configuration/authentication/ diff --git a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md index d5d813e1aa2..9857571848c 100644 --- a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md +++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md @@ -1,6 +1,6 @@ --- title: Pod Security Policies -weight: 25 +weight: 100 aliases: -/rancher/v2.x/en/concepts/global-configuration/pod-security-policies -/rancher/v2.x/en/tasks/global-configuration/pod-security-policies diff --git a/content/rancher/v2.x/en/admin-settings/rbac/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md index a5c1575a8e0..b0499ac5746 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md @@ -1,6 +1,6 @@ --- title: RBAC -weight: 25 +weight: 75 aliases: -/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/ --- From d1955858f08f75ffd59d13bea3d10b8b56099763 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:42:23 -0700 Subject: [PATCH 28/30] changed title and replace instances of Active Directory with AD --- .../authentication/configuring-ad/_index.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md index 1f3bbb17231..3bb33c4e4d2 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md @@ -1,25 +1,25 @@ --- -title: Configuring Active Directory +title: Configuring Active Directory (AD) weight: 50 aliases: -/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/ --- -In environments using Microsoft Active Directory (AD), you can configure Rancher to allow sign on using AD credentials. +In environments using Microsoft 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. +>- Have an AD server configured. +>- Create a service account in AD 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**. +3. Select **AD**. -4. Complete the **Configure an Active Directory server** form. +4. Complete the **Configure an AD server** form. You may need to log in to your domain controller to find the information requested in the form. @@ -29,12 +29,12 @@ In environments using Microsoft Active Directory (AD), you can configure Rancher
>**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. + >Search base allows Rancher to search for users and groups that are in your AD. 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. +5. If your AD 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. > @@ -46,9 +46,9 @@ In environments using Microsoft Active Directory (AD), you can configure Rancher > > 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. +6. Enter your AD username and password in **Authenticate with AD** 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_). +- AD authentication is configured. +- You are signed into Rancher with your AD account (i.e., the _external principal_). From 926bcecf063f65dcf5da1a01dd648b0a7a7182cb Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 11:44:24 -0700 Subject: [PATCH 29/30] typo fix --- content/rancher/v2.x/en/admin-settings/authentication/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md index 616823f54b3..3471e124701 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -3,7 +3,7 @@ title: Authentication weight: 50 aliases: -/rancher/v2.x/en/concepts/global-configuration/authentication/ - -/rancher/v2.x/en/task/global-configuration/authentication/ + -/rancher/v2.x/en/tasks/global-configuration/authentication/ --- 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. From 98a1ec3dacf225cdff6030d4d61a16c0f0977d47 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Mon, 16 Jul 2018 12:58:25 -0700 Subject: [PATCH 30/30] updating links --- .../authentication/configuring-ad/_index.md | 2 +- .../authentication/configuring-freeipa/_index.md | 2 +- .../authentication/configuring-github/_index.md | 2 +- .../authentication/configuring-openldap/_index.md | 2 +- .../rancher/v2.x/en/admin-settings/rbac/_index.md | 2 +- .../en/admin-settings/rbac/creating-roles/_index.md | 8 ++++---- content/rancher/v2.x/en/concepts/projects/_index.md | 2 +- .../clusters/adding-a-pod-security-policy/_index.md | 10 +++++----- .../adding-managing-cluster-members/_index.md | 12 ++++++------ .../v2.x/en/tasks/clusters/adding-storage/_index.md | 2 +- .../global-configuration/node-drivers/_index.md | 4 ++-- .../en/tasks/projects/add-project-members/_index.md | 6 +++--- .../v2.x/en/tasks/projects/create-project/_index.md | 8 ++++---- 13 files changed, 31 insertions(+), 31 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md index 3bb33c4e4d2..024b18ff2a1 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-ad/_index.md @@ -11,7 +11,7 @@ In environments using Microsoft AD, you can configure Rancher to allow sign on u > >- Have an AD server configured. >- Create a service account in AD 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). +>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). 1. Sign into Rancher using a local user assigned `administrator` global permissions (i.e., the _local principal_). diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md index d9de6fca98c..6fb0afa428a 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-freeipa/_index.md @@ -13,7 +13,7 @@ If your organization uses FreeIPA for user authentication, you can configure Ran > >- 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). +>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). 1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md index aa5fe468f21..271f45e3627 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-github/_index.md @@ -7,7 +7,7 @@ aliases: 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). +>**Prerequisites:** Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). 1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). diff --git a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md index e1d5e45b5a4..b442a5f1a82 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/configuring-openldap/_index.md @@ -13,7 +13,7 @@ If your organization uses OpenLDAP for user authentication, you can configure Ra > >- 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). +>- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). 1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). diff --git a/content/rancher/v2.x/en/admin-settings/rbac/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md index b0499ac5746..e92a88dacfd 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md @@ -2,7 +2,7 @@ title: RBAC weight: 75 aliases: - -/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/ + -/rancher/v2.x/en/admin-settings/rbac/ --- Within Rancher, each person 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. diff --git a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md index 85a29d8597e..13defa7d559 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/creating-roles/_index.md @@ -13,8 +13,8 @@ Note that _roles_ are different from _permissions_, which determine what cluster > >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. +>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions). +>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions-reference) role assigned. ## Adding A Custom Role @@ -26,7 +26,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als 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). +4. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#locked-roles). Locked roles cannot be assigned to users. @@ -54,7 +54,7 @@ While Rancher comes out-of-the-box with a set of default user roles, you can als ## 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). +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/admin-settings/rbac/#locked-roles). You can lock roles in two contexts: diff --git a/content/rancher/v2.x/en/concepts/projects/_index.md b/content/rancher/v2.x/en/concepts/projects/_index.md index 6da433268a0..d4704f3bfb0 100644 --- a/content/rancher/v2.x/en/concepts/projects/_index.md +++ b/content/rancher/v2.x/en/concepts/projects/_index.md @@ -3,7 +3,7 @@ title: Projects weight: 2150 --- -_Projects_ are a new concept introduced by Rancher. They are not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies. +_Projects_ are a new concept introduced by Rancher. They are not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role). Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies. ### Authorization diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md index 2d2ee026279..6bbd2ef58c9 100644 --- a/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md +++ b/content/rancher/v2.x/en/tasks/clusters/adding-a-pod-security-policy/_index.md @@ -14,14 +14,14 @@ You can add a Pod Security Policy (PSPs hereafter) in the following contexts: > **Note:** We recommend adding PSPs during cluster and project creation instead of adding it to an existing one. -For more information about PSPs, refer to [Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies). +For more information about PSPs, refer to [Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies). ## Cluster Creation: Adding a Default Pod Security Policy When you create a new cluster, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster. >**Prerequisite:** ->Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +>Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). >**Note:** >For security purposes, we recommend assigning a PSP as you create your clusters. @@ -36,7 +36,7 @@ For detailed instruction about assigning a PSP to a new cluster, see [Creating a If you don't apply a PSP as you create your cluster, you can always add one later. >**Prerequisite:** ->Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +>Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). 1. From the **Global** view, find the cluster that you want to apply your PSP to. Select **Vertical Ellipsis (...) > Edit** for the cluster you want to enable PSPs for. @@ -66,7 +66,7 @@ When you create a new project, you can assign a PSP directly to the project. Ass >**Prerequisites:** > -> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). > - Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy](#existing-cluster--adding-a-pod-security-policy). As you create the project, make a selection from the **Pod Security Policy** drop-down to assign a PSP. @@ -79,7 +79,7 @@ You can always assign a PSP to an existing project if you didn't assign one duri >**Prerequisites:** > -> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/). +> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). > - Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy](#existing-cluster--adding-a-pod-security-policy). 1. From the **Global** view, find the cluster containing the project you want to apply a PSP to. diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md index 40f1ab912a5..57d7b0a8c19 100644 --- a/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md +++ b/content/rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/_index.md @@ -29,23 +29,23 @@ Following cluster creation, you can add users as cluster members so that they ca If external authentication is configured: - - Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/) source as you type. + - Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) source as you type. >**Using AD but can't find your users?** - >There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/). + >There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/configuring-ad/). - A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of. - >**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/authentication/#external-authentication-configuration-and-principal-users). + >**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). 4. Assign the user or group **Cluster** roles. - [What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-roles) + [What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#cluster-roles) >**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment. > - > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). - > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#locking-unlocking-roles). + > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role). + > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#locking-unlocking-roles). **Result:** The chosen users are added to the cluster. diff --git a/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md b/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md index 261f51e54e0..f3c86dbaedf 100644 --- a/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md +++ b/content/rancher/v2.x/en/tasks/clusters/adding-storage/_index.md @@ -5,7 +5,7 @@ weight: 3500 >**Prerequisites:** > ->- Working with storage requires the `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#project-role-reference). +>- Working with storage requires the `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#project-role-reference). >- You must have a storage medium provisioned. For more information, see [Provisioning Storage](provisioning-storage). ## Adding a Persistent Volume 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 index 38aaf39fd97..d020dfc0ec7 100644 --- 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 @@ -5,8 +5,8 @@ weight: 150 >**Prerequisites:** To create, edit, or delete drivers, you need _one_ of the following permissions: > ->- [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 Node Drivers]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#global-permissions-reference) role assigned. +>- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions) +>- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#custom-global-permissions) with the [Manage Node Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#global-permissions-reference) role assigned. ## Adding Custom Node Drivers diff --git a/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md b/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md index 0a6400287cd..4dcbc3f94f5 100644 --- a/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md +++ b/content/rancher/v2.x/en/tasks/projects/add-project-members/_index.md @@ -37,12 +37,12 @@ Following project creation, you can add users as project members so that they ca 1. Assign the user or group **Project** roles. - [What are Project Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-roles) + [What are Project Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#cluster-roles) >**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment. > - > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#adding-a-custom-role). - > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/roles/#locking-unlocking-roles). + > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#adding-a-custom-role). + > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/creating-roles/#locking-unlocking-roles). **Result:** The chosen users are added to the project. diff --git a/content/rancher/v2.x/en/tasks/projects/create-project/_index.md b/content/rancher/v2.x/en/tasks/projects/create-project/_index.md index 64ca590e886..8fb7c996ec6 100644 --- a/content/rancher/v2.x/en/tasks/projects/create-project/_index.md +++ b/content/rancher/v2.x/en/tasks/projects/create-project/_index.md @@ -11,9 +11,9 @@ weight: 1. **Optional:** Select a **Pod Security Policy**. - [What are Pod Security Policies?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/pod-security-policies) + [What are Pod Security Policies?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies) - >**Note:** This option is only available if you've already created a Pod Security Policy. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/tasks/global-configuration/pod-security-policies/#creating-pod-security-policies). + >**Note:** This option is only available if you've already created a Pod Security Policy. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#creating-pod-security-policies). 1. **Recommended:** Add project members. @@ -29,9 +29,9 @@ weight: 1. From the **Role** drop-down, choose a role. - [What are Roles?]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#cluster-and-project-roles) + [What are Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#cluster-and-project-roles) - >**Tip:** Choose Custom to create a custom role on the fly: [Custom Project Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/#custom-project-roles). + >**Tip:** Choose Custom to create a custom role on the fly: [Custom Project Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/#custom-project-roles). 1. To add more members, repeat substeps a—c.